先週は鹿児島にいたので、雨は降ったことは降ったけど、関東みたいに毎日ではなかったわけだが、今日はさっそく雨であった。
Nginx を使って noVNC の WebSocket proxy を動かすことができるかどうか、調べたら、noVNC の Wiki に書かれてたw
Proxying with nginx - kanaka/noVNC Wiki - GitHub
そんなわけで、とりあえず LAN 用に使っていた thttpd をアンインストールし、Nginx をインストール。Debian stable (wheezy) の nginx パッケージは noVNC 用としては古すぎるので、wheezy-backports を使用。
インストール後、デフォルトではなぜか root /usr/share/nginx/html; になっているので、root /var/www; にする。 あと、autoindex on; を入れておいた。 いろいろと設定していくと違うのかも知れないが、初期の設定ファイルは Apache HTTP Server よりもずっと簡単そうに見える。
ログは /var/log/nginx/access.log に出ているようだ。 書式は Apache HTTP Server に似ている気がする。 もしかして、Webalizer みたいなログ解析ツール用に合わせてあるのかな? と思って調べたら、Webalizer を使うときは log_format を調整するらしい。 似てると思ったけど、違うのか。
原付を動かしてみた。 チョークをめいっぱい引いて始動、しばらく暖機、発進しようとしたらエンストしそうになったりして、予想通りというか、やっぱり放置するとこういう感じになるなぁ。 キャブレターにたまっているガソリンを使い切るまで調子が悪いんだろうか? と考えたんだけど、こうして放置後に乗ると、12 時間置いてエンジン始動するとまたちょっと不安定だったりとかする気が、あ、でも気温が低くなってるからそのせいもあるのかな。
録画してあったスーパーフォーミュラの番組を、また VLC でストリーミングして Nexus 10 で再生してみた。 今回はなぜか VLC のクラッシュはなかったが、LAN で http でもコマ落ちしたり乱れたりっていうのはあった。
VLC のスケール 0.25 って、縦 1080/4=270 ドットってことだろうか? 意外とまともに見られるのが不思議。 動画はコマ落ちもあったし残像があったりしたけど、字幕などはブラウン管テレビで見るよりも見やすい気がした。 ブラウン管テレビが 480i だとすれば、レターボックスで黒くなる部分を差し引いて 360i 相当で見ているはずなので、やっぱりインターレースのせいなのかな。
先月分。157 円/l。 満タンかどうか不明。 燃費計算 19.0km/l。 燃費表示 18.0km/l。
先月分。162 円/l。 燃費計算 22.0km/l。 燃費表示 21.0km/l。
今日は原付に給油。158 円/l であった。
今日はブリタの交換用カートリッジを買おうと思ってドンキホーテへ。 あると思ってたんだけど見当たらず。 うーん。
ホームセンターならあるかなと思って J マートへ。 閉店時間を過ぎていた。
別のホームセンターを目指してイトーヨーカドーへ。 なんと、セブンホームセンターのお目当ての階は今月から改装中!
あきらめて帰る途中、ヨドバシという手を思いつき、ヨドバシ.com で探すと、在庫あった。 明日行くくらいなら、どうせ送料無料だしすぐ届くだろうから送ってもらえばいいや、というわけで結局通販か。 はぁぁぁ。
うどん屋さん、やっぱり閉まってるみたいだ。 閉店しちゃったのかな。 残念。
gpsshogi コマンドの詳細は --help を見ろとかそんな感じだが、+2726FU みたいな CSA 形式を食わせる方法があるみたい。 まず、-c オプションをつけるとこんな感じ:
using /usr/share/gpsshogi-data as OSL_HOME, word size 64 use cpu 4 using alpha beta using alpha beta CsaClient start waiting Fri Sep 5 08:26:31 2014 P1-KY-KE-GI-KI-OU-KI-GI-KE-KY P2 * -HI * * * * * -KA * P3-FU-FU-FU-FU-FU-FU-FU-FU-FU P4 * * * * * * * * * P5 * * * * * * * * * P6 * * * * * * * * * P7+FU+FU+FU+FU+FU+FU+FU+FU+FU P8 * +KA * * * * * +HI * P9+KY+KE+GI+KI+OU+KI+GI+KE+KY + TIME[0:0]
ここに、+2726FU とか入れると、次の手はコンピューターが返してくれる。 ふむ。 手を打ち間違うと終了してしまう。 最初は乱数でやっているようだが、途中から思考中の手の情報を日本語で出力してくるので端末の設定によっては注意が必要。 で、最初にある程度の棋譜を入れて進めた状態から始めるには、-f オプションを使うらしい。 ファイルに CSA 形式で棋譜を入れておく。 ファイルの最初に、上に出ている P1〜P9 のところの初期の盤面を入れておく必要がある。
コンピューターに先手をプレイさせるなら -s オプションをつける。1 手だけ考えさせて終わらせるなら、標準入力に /dev/null を食わせておけば、istream error (maybe closed) などとエラーを吐きながら終了する。 これで、ある状況でコンピューターがどんな手を最善とするか、スクリプトから見ることができるかも。
なお、コマンドの詳細を知るのにソースコードを見るときは、gpsshogi コマンドではなく、libosl1 ライブラリーのソースコードを見る。 他に gpsshell コマンドというのもあるようだが、ドキュメントがないみたい。
全米オープン、クルム伊達公子とバルボラ・ストリコバのペアは準決勝で敗退だそうで。 あとは錦織圭か!
ここ最近涼しいから松岡修造がテニス関係でアメリカに行っているのかと思っていたが、どうも違うみたいだな。
SHIDAX というカラオケ店、聞くところによると、水曜日にレディースデー、木曜日にメンズデーというのがあって、1 オーダー制ではあるものの、ルーム料金が 2 時間無料なんだとか。 夜間もやっているらしいので、ちょっとお得感ある。
ただ、この割引を受けるには、ケータイ会員とやらに入会しなければならない。 この手のサービスは、10 年前だと、PHS は使えないとかで、イライラさせられることもあったが、近年のスマートフォンの急速な普及のおかげか、メールアドレスとして @gmail.com が許されている。PHS のドメインはリストに入っていないが、代わりに任意のドメインを指定できる選択肢がある。 というわけで、手持ちのスマートフォンからでもログインすれば見られないこともないというメールアドレスを指定して、必要事項を記入すれば登録完了である。
おそらく、無線 LAN や MVNO のことを考えれば、IP アドレスの制限もされていないんだろうな。 スマートフォンの普及に感謝。
テレビでやってた映画。2011 年公開の邦画。
始まりが英語で字幕がついていて、一瞬まさかの洋画かと思ったが、その後日付が字幕で入ったからやっぱり邦画だった。 戦争の頃の話で、終戦直前に学生を動員してお宝を隠すという物語。 当時っぽい車とか出てくるのは雰囲気が出ている。 刀を振るシーンとか、いかにも演技でちょっとなんか迫力がないというか、そんなシーンもあった。 結末はちょっと悲しい物語。 結末は、っていうか、そろそろ終わりかなと時計を見たら残り 20 分、いや、これがいつもより延長されていて、実際は残り 35 分だったわけで。 長かったけど、ちゃんとまとまってた。
ストーリーはフィクションのはずだが、舞台は現在の稲城とからしい。 武蔵小玉駅とかいう架空の駅が南武線に、あ、いや、南部鉄道に存在するという設定。 現地は米軍施設内にあるという設定で、実在する多摩サービス補助施設とやらの位置を指しているっぽい。 そういえば稲城に米軍のゴルフ場があるんだっけね。 府中にも通信施設とか未だに残っているし、返還されて国有地になっても廃墟が残っているところもあるし、意外と東京都には米軍関係の場所が残っているんだよな。
noVNC と Nginx の関係としては、Nginx はあくまでもただの proxy として動くということで、Nginx を経由して、さらに Websockify あるいは相当のプログラムを通して本来の VNC サーバーにつながる、ってことのようである。
というわけで websockify 相当のプログラムを動かさなければならないわけであるが、パッケージ以外の daemon を増やすのは避けたいとおもって、inetd で何とかできないかと。
これを使ってみた。 実際のところはブラウザーのヘッダーが気にくわないらしくてエラーを出すので、修正した。
diff --git a/wsproxy.c b/wsproxy.c
index 54b2476..7b41eac 100644
--- a/wsproxy.c
+++ b/wsproxy.c
@@ -501,7 +501,7 @@ main(int argc, char *argv[])
} else if (strncasecmp(line, "Sec-WebSocket-Protocol: ",
24) == 0) {
protocol = parsestring(line + 24);
- if (strcmp(protocol, "base64") != 0) {
+ if (strstr(protocol, "base64") == 0) {
DPRINTF("Unsupported protocol: %s", protocol);
return (1);
}
あとは Nginx の設定を適当に。
location /vnc/ {
alias /path/to/noVNC/;
}
location /websockify {
proxy_pass http://127.0.0.1:41337;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
こんな感じでいけた。SSL はまだ試していない。
きのうは wsproxy でいけたと思ったんだが、Chromium で試すとつながらない。 微妙に wsproxy の WebSocket 実装が間違っている?
おまけに、websockify を使い、Android 端末の Google Chrome から試したら、接続はできて操作もできるものの画面が表示されないことが発覚。Bisect してコミットは特定。
commit dfcedffc16a278815f56b78d6543f524fd4ba1cc
Author: samhed <samuel@cendio.se>
Date: Mon Jul 22 15:46:59 2013 +0200
Make noVNC follow the RFB protocol and keep only one outstanding
framebufferUpdate request at a time.
コミットは特定したものの、何が悪いんだかさっぱり。 そんなわけでまだ SSL には手を付けていない。
Node.js って CGI みたいに HTTP サーバーと組み合わせて使うものかと思っていたが、Node.js 自身が Web サーバーになるらしい。 ほうー。 調べていたら、xinetd からつながるようにする実装を行った記事を見つけた。
Node.js server and xinetd | Ted X Toth
おもしろい。 じゃあこれを websockify に応用できないか、と思って、Node.js で WebSocket プログラミングをする方法を探す。ws とか websocket とか socket.io とか、そんな感じのキーワードがたくさん見つかるのだが、共通するのは npm という Node 用のパッケージマネージャーを使うということ。 うーん。 そういうのいやなんだよなー。 せっかくシステム全体を unattended-upgrades で自動アップデートにしているのに、独立したパッケージマネージャーを使ったら、脆弱性の修正とか、個別に見なきゃならないから。
と思っているんだけど、違うんだろうか? 世の中ではどうやって運用されているんだろうか。
テレビ朝日が開幕前の紹介番組的なものを深夜にやっていた。 へんな芸能人とかは出てこなくて、片山右京とテレビ朝日のアナウンサーが出てくるだけなのは好感が持てるが、内容はちょっと... イケメンがどうとか... までも地上波だとこうなっちゃうのかなぁ。 あ、テレビ東京のスーパー GT プラスも地上波だ。
番組中ではさらりと流された話。 排気ガスがゼロ。 一般に、排気ガスとは走行する車から排出されるものを指すので、ゼロというのは正しい。 環境保護になるか。 直接的には、燃焼で得たエネルギーを直接走行に使うか、電気に変換して蓄電した上で使うかという話なので、電気といっても今までのガソリン車によるレースと何も変わらないわけだが、レース活動によって電気自動車の開発が促進され、電池やモーターの効率が上がるのならば、それは間接的には環境保護につながるのであろう。 今年はワンメイクだし、まだ開発云々というよりはレースそのものを軌道に乗せていくための最初の段階だろうな。
ワンメイクといえば、スーパーフォーミュラはシャシーがワンメイクだったかな。 タイヤも? エンジンは 2 種類あるが、その違いくらいなので基本的にはトヨタ対ホンダ的な雰囲気になっている。 でもレース自体はなかなか高いレベルのものだし、それを考えればワンメイクでも見応えのあるレースになりうる。
個人的には変速機がない (だろうという) ところに注目していて、フォーミュラカーのレースで無段変速あるいは直結ってのはまだ見たことがないので、どんな感じになるのか興味がある。F1 なんかでよくショートシフトとかいって、早めにシフトアップしてホイールスピンを防ぐとか、そういう話があるけど、変速機がないってことはアクセル操作をがんばるしかないのだろうか。 トラクションコントロールやスタビリティコントロール、アンチロックブレーキはあるのかな。
省エネ構成な Windows PC に使っている AMD C-60 のアップグレード案を考えた。C-60 は Ontario という初期の世代で、Kabini 世代ならば 28nm bulk でいろいろと改善しているらしい。 プロセッサーオンボードなファンレスマザーボード自体は気に入っているので、案はふたつ:
E1-2100 は TDP が C-60 と同じ 9W、クロックも C-60 の定格と同じ 1GHz で、コア数も 2 つで同じ。CPU 性能は改善はしているようだが、大きな差はない。ECS と GIGABYTE からファンレスマザーボードが出ているよう。ECS は前に CMOS エラーが出まくっていた A770M-A の記憶が。GIGABYTE 版は PCI スロットという大変懐かしいものがついていて... いまいちか?
A4-5000 は TDP 15W、クロックは 1.5GHz、コア数 4。 これなら CPU 性能は明らかに改善が期待できる。BIOSTAR からファンレスマザーボードが出ている。BIOSTAR ってどうなんだろう? あと、power supply - PicoPSU problems with BioStar A68N-5000 - Super User という質問、PicoPSU という電源装置 (Mini-Box picoPSU-150-XT 静音PCショップ OLIOSPEC と同じようなやつかな?) と組み合わせたらやたら不安定だと、そういう話を見つけてしまってウーン。 今使ってるのは NT-ZENO/DC60-D3 だったかな、とにかく 60W 電源なのでだいぶ不安が。C-60 では今のところ安定してそうなんだけど。
AMD A4-5000 搭載の超小型 PC ベアボーンキットが存在するらしい。ZOTAC。 少し気になったが、これってファンレスじゃないんだな。Windows PC として使うには、今使っている Windows 7 のライセンスの都合上、一緒に買った 3.5 インチ HDD を使わざるを得ないので、向いていないし、自宅サーバー PC として使うには、高い計算性能よりもファンレスが望ましい。
もう一クラス上になると TDP 25W の Athlon 5350 などというモデルがあるようだ。 まさかの Athlon 復活みたいな。SoC で、バスやら SATA コントローラーやらを内部に持っているらしい。CPU クーラーが新しい方式になって、取り付けにくい上にサードパーティー製がないという残念な状況のようだが、そんなものも出ていたんだということは頭の片隅にでもいれておこう。
日曜日の F1、モンツァ。 ハミルトンがタイヤ交換後にとんでもない勢いでロズベルグの背後に迫ったところ (解説の人が何も言わない間にあっという間に差が無くなった)、ロズベルグのミス (?) が笑えたことと、リカルドのオーバーテイクがお見事だったのが見所だった。 リカルド、ほんとにすごいな。1 コーナーでひょっこり出てきてどうしようもないくらいきれいに並んでみたりとか、右から抜くのか? 残念左でしたー的なライン変更してズバリと一発で前に出ていたりした。 タイヤをロックさせたシーンもあったがそれでも危なくはなっていなくて、お見事。 ベッテルを抜いたのは、今回はタイヤ交換のタイミングのせいだと思うけど。
あ、あとマッサの今季初表彰台。 イタリア語か何か、ぺらぺらと。 同時通訳の人、しばらくだまってて「みなさんありがとう」的な訳を入れたけど、あってたのかどうかw
残念ながらロズベルグのチャンピオンが見えてきてはいるが、どうなることやら。
ダイハツの軽トラ「ハイゼット トラック」がフルモデルチェンジされたというのは先週のニュースである。
製品情報[ニュースリリース] 【ダイハツ 広報発表】
2014/09/02 ダイハツ軽商用車「ハイゼット トラック」フルモデルチェンジ 〜基本性能を進化させ、選べるパックオプションを豊富に設定〜
価格を見ると、一番安いグレードの 5MT モデルが 653,400 円となっている。10 年前は 50 万円台の商用車があった気がするが、今でも 60 万円台で車が買えるということである。 へぇー、と感心していたが、グレード名を見て驚いた。
スタンダード "エアコン・パワステレス"
え? えっ? 21 世紀になってもう 14 年目ですよ? まさかと思って主要装備表をよく確認する。
ABS もないのか! 今でもこういう車が出せるんだな、という事実に驚きである。 横滑り防止装置の義務化とかなかったっけ? 商用車は対象外か。
主要諸元表を確認してまたびっくりである。 主要燃費向上対策を見ると、「可変バルブタイミング、電子制御式燃料噴射、電動パワーステアリング(パワーステアリング装着車)」とある。 つまり 4AT はロックアップすらない昔懐かしいトルクコンバーター 4AT である。 一応電子制御式のようだが、ロックアップを付けないのは何か理由があるのだろうか。 ちまたを走る郵便局の軽ワゴン車などから聞こえる、AT の甲高い音が思い浮かぶ。 エンジン型式はミライースと同じ KF 型だが、圧縮比が違うところを見ると最新の第 3 世代ではなく、第 2 世代である。 これは出力を重視してなのかも知れない。 最大トルクがミライースより大きく、最大トルクの回転数は低め。 最高出力は 5MT はミライースより小さいが、4AT は大きい。
軽トラの、ABS どころかエアコン・パワステすら取っ払えるほどの設計を見ると、どこか原付に似ているところがあるなぁ。 スーパーカブは、21 世紀に入っても、数年間は手動チョークのキャブレター方式だったわけだし、バーディーは未だにセル付が別グレードになっている。 方向指示器も、電圧変化で点滅間隔が変動するようなやつが原付では普通にあるし、スピードメーターも機械的なケーブルでつながってるのは多いんじゃないかな。
きのう・今日と、傘を持っていったもののほとんど使わないで済んでいる。 今日はランチの帰りが降っていたがそれだけだった。
ムーバスに乗ってみた。 日野の車両だそうだが、オートマチックトランスミッションの制御が、よくロックアップされて低回転で静かに走っていて、いすゞのエルガのに似ているような気がした。 セレクトレバーは普通の乗用車のようなタイプ。 バス停の間隔が短く、そんなにスピードを出さないからか、乗り心地は悪くない。 空調はかなり弱め、外より暑いほど。
SHIDAX というカラオケ店に行ってみたのであった。Gmail のアドレスで登録したケータイ会員とやらのおかげで、メンズデーにつきルーム料金 2 時間無料。 ワンオーダーはドリンクでなくてもよく、部屋で注文してくれと念を押されるスタイル。 まねきねこの、最初にワンドリンク注文スタイルに慣れていたせいで、とまどった。
部屋には注文用の専用端末が用意されていて、それを操作するだけで注文できる。 見てみると、お湯が 0 円! これは良い。 さっそくお湯を注文したが、0 円はさすがにワンオーダーにカウントされないだろう。 腹が減っていたので適当に食べ物を注文した。
今回は職場から一番近いところに行ってみたが、駐車場がなく、中をエレベーターで移動するタイプで少々フロアの狭さを感じるものの、部屋自体は狭くはなくて、禁煙ルームもあって好印象であった。 自宅から一番近いところ、および、より西のほうにある車で行けそうな店舗には駐車場があるようで、悪くない。 まぁ行くとしても木曜日しか行かないだろうけどね。
「STAND BY ME ドラえもん」。 レイトショー。 いわゆる子供向けの映画を映画館で見るのはポニョ以来か。 短いので気楽に見られる。
3D アニメ。3D 上映もあるようだが、2D 上映のほう。3D アニメと聞いて、ピクサー風のものを想像していたが、ちょっと違った。 光の加減がもうちょっとリアルっぽい感じがして、人物・ロボットはともかく、物についてはそれこそレイトレーシングでもしたのかな、みたいな、そんなことをぼんやり考えながら見た。 あ、もちろん、声の中の人は今の若い人になっているので、最初は違和感があった。 顔も 3D だが、びっくりした顔などで特徴的な目玉の形は漫画のまま。
ストーリーは、ドラえもんが未来からやってくる前のところからスタートし、ドラえもんがいなくなる (?) までのところ、というような感じ。 もちろん、ドラえもんは未来からやってくるので、タイムトラベル物である。 もっとドラえもんに詳しかったら、ここは原作のアレで... みたいなところも、あったんじゃないかと思うが、昔、いろんな道具がのってる漫画か何かを読んだくらいで、小ネタについていけるほどではないので。 ドラえもんの映画というと、探検物みたいなイメージがなんとなくあるのだが、そういうのではなかった。 でも、ドラえもんとして、期待は裏切られないストーリーだった。 ちょっと感動物っぽいところもある。
いつもの家、いつもの公園なんかはそのまま漫画の雰囲気だが、いろんなシーンに車が映っていて、それが時代を感じさせるデザインである。 角張っていて、小さくて。 孫を連れて行くような人ならそういう細かいところが楽しめるんじゃなかろうか。 未来のシーンもあるが、現実よりも未来っぽい感じ、昔の本で 21 世紀はこうなりますみたいに書かれていたような、そういう世界が描かれている。 でも具体的な年代の数字は出ていなかったっけ、いや、計算しないと求まらないかな、のび太の年齢からして...
何度か大きな川が出てきた。 あんまりテレビアニメ版で大きな川が出てきた印象はないので新鮮であった。 多摩川みたいな感じで、河川敷があって、橋を電車が走る。 でも天気予報のところ、練馬区とか言ってたっけ? 東京には大きな川が多いからなぁ。 もしかしたら、タッチの舞台と近いところかも知れない。
テレビでやってたテスト走行を見て、予選は CS だから見れず、決勝は明日だと思い込んでいて見逃した。 いや、BS でやってた決勝ダイジェストの後半は見た。 最後に派手目なクラッシュがあったみたいで、うーん、F1 ドライバーの子供と、F1 で 10 回以上もの表彰台経験がある元 F1 ドライバーだったら、やっぱり F1 ドライバーの子供のほうが悪いよね! みたいな。 次は 11 月? だいぶ先な感じ。
レイトショーで。 そういえば多摩センターは株主優待の値引きは昼間だけなんだっけ! 帰りの移動時間も変わらないから、武蔵村山にしとけばよかったか。
先月見た京都大火編の続き。 まだ京都か。 ここにきて師匠が登場。 アクションシーンがあり、主人公が進化。 そして東京へ向かう。 そこに前作では闘わなかった相手が登場し、アクションシーン。 強烈な峰打ちも相変わらずだ。
主人公が東京に来るまでの間、敵は敵で政府に脅しをかけている。 いろいろあって主人公は敵のいる船へ。 仲間とともに乗り込み闘う。 前作で勝てなかった相手も登場。 最終的に敵のトップと戦うことになる。 みんなで闘う感じか。 ただ、どうやって乗り込んできたんだコイツ、みたいなところはあった。
そんなかんじで最後はめでたしめでたし、と。 やはり、前作京都大火編の物足りなさが、今作で埋められた感じ。 伝説の最期というのは、まぁ、そんな感じの言葉が作中で出てくるし、納得はできた。
こちらは映画ではなく、実際の昭和 30 年代の映像のようだ。 当時の未舗装道路、バス、パトカー、消防車や、製鉄所の様子など、興味深い映像がいっぱいある。 製鉄所では電動モーターにベルトを掛けたものが使われていて、そういえば昔はそういうのを使ってたと、そんな話を親から聞いたんだった。 警察官が工事用ヘルメットみたいなのをかぶってパトカーに乗っているのも印象的。 安全装備がしょぼい当時の車だからだろうか。 駐車禁止の標識が違うのなんかも、標識って結構変わってたりするのか? ゴミ問題やら落書きやら、今とは比べものにならないほどひどい様子があって、まぁ、今でも外国ではそういう場所もあるよね。 ほんの 60 年そこそこで、そんなに変わるものなんだな。
ナレーションの声が、昔はこんな感じだったのか、という印象と同時に、このしゃべり方ってカーグラフィック TV っぽいという、しょうもないことに気づいてしまった。 カーグラフィック TV のナレーターは古谷徹、1953 年生まれとのこと。
最後の「休日にどこにも行かずに街をブラブラしている青年たち」には笑った。 今なら街をブラブラしてればいいほうで、どこにも行かずにというなら、家でゴロゴロが当たり前だw
60 年前でなくても、自分が子供の頃と今を比べても、例えば喫煙可能な場所の減りっぷりは明らか。 そういう意味では、60 年前と 20 年前の比較でも、道路は舗装され、交通マナーはマシになり、列車の外に乗る人もいなくなり、迷惑行為も減ったわけ。40 年でそれだけ変わったということ。40 年といえば、日本に原子力発電所ができたのが 40 年以上前だったな。 うん。
おととい見た映画「STAND BY ME ドラえもん」は、エンディングがおもしろかった。 名前がスクリーン右側でスクロールしていくのはそっちのけで、スクリーン左側に出ているおまけシーンをずっと見てた。 子供向けとしては、こういうのありかも知れない。
きのう見た「るろうに剣心 伝説の最期編」は、いたって普通のエンディングだった。 主題歌は ONE OK ROCK の歌。 ワンオクロックと読むらしい。
原付のエンジンオイル交換をした。 前回余った 400ml。 本来 600ml 入れるべきなので、最後まで出し切る前にとめて、400ml を放り込んで、少しアイドリングさせ、残量を見ると、一応 L より上ではあったが、1/3 くらいか? ねじのしめかたが甘くて若干漏らしたことがあっただけに、少々心許ない。
で、どうせ 4 か月に 1 回交換してるんなら、1liter 買ってきても 1 年以内に使い切れるからよかろうと思って、買ってきて少し足しておいた。
蚊? 刺されたけどね、多磨霊園まで 1〜2km の地域だから、都心の公園に行くような人は少ないはず... きっと大丈夫だろ...
この前帰省した時、鹿児島市電の車両の運転台では、でかい箱についたコントローラーを手袋をした運転士が操作していたという話を聞いた。 昔の話、かと思いきや、未だに 1950 年代の車両である 500 形や 600 形と呼ばれる車両も現役のようだ。 直接式抵抗制御というもので、箱の部分には抵抗器がついていたものと思われる。
さらに驚いたことに、9500 形と呼ばれる車両などは、1995 年から 2000 年の新しめの車両なのに、1967 年の 800 形と呼ばれる車両の主要機器を流用しているらしく、直接式抵抗制御らしい。 直接式ということは、最初は電流がたくさん流れすぎないように抵抗器で抑えて、スピードが乗ってきたら抵抗を減らしていく、というのを運転士が操作するわけで、車の運転のような感覚からすれば大変面倒くさそうであるが、40km/h だし、人が乗っているわけだから急加速することもないと考えれば、そんなに面倒でもないのかな。 抵抗器が燃えないように抵抗器を使いすぎないようにする (速度が出すぎる場合はニュートラルと加速を繰り返す) のは、抵抗制御である限り、直接式でも間接式でも同じ。
運転台の動画を探していたら、脱線事故の動画を見つけた。
路面電車を路面電車で引っ張ろうとしてる! 自走できなくなったバスをバスで牽引するのと同じような話か。 ドアーを開けたまま動かしているところを見ると、バスのようなインターロックはないのだろうか。
まぁしかし、市営バスと衝突しってのもなかなか。 この前は、都通の電停のところで、右折待ちでギリギリ軌道にかからないくらいのところで待ってたら電車はギリギリを通ってくれたけど、まぁあそこは電停があるから大惨事ってこともないだろうが、事故になれば大変な迷惑がかかるな。
きのうはスバル 360 を見かけたのだった。 エンジンオイルを買いに行った時に目の前で信号待ちしてた。 今見るとすごく小さくてかわいい車。 方向指示器はブレーキランプ (テールランプ?) と共用になってるタイプだった。 ボロロッボロロッという漫画みたいな 2 気筒エンジンの音が独特だった。
原付のエンジンオイル量を見るとき、少しアイドリングしてからというのは正しかったようだが (自動車の場合は冷間時に見るんだったような)、ねじをまわさずにゲージを突っ込んで抜いて見るんだそうで。 そういえばまわしてた。 あれ? そうすると、きのうエンジンオイルを買いに行った時には L を下回ってたかも知れぬ... まいっか。 そういえばエンジンが軽そうに回ってたのはオイルが少ないために抵抗が小さく... まいっか。
藤野。4 回乗ってベストは 39.352 秒。
きのうは渋滞がひどそうだったので今日にしたのだが、正解。 きのうの一般道は事故渋滞だったそうな。 今日は快適で、帰りは温泉に寄って帰った。
最近はスマートフォンやタブレットでコントロールできるラジコンヘリコプター的なものがあるらしい。 本体が軽いことで、落ちたときの被害が少ないとか、カメラがついていて空撮できるとかで、なかなかおもしろそう。
ところが、近所で遊ぼうと思ったら、そこには調布飛行場という飛行場があるので、何かしら制限があるはずである。 ちょっと調べてみたところ、制限されるのは以下のような空域のようだ。
ハァ? ってなったのでもう少し詳しく。 なんとか表面というのは制限表面というもので、調布飛行場制限表面図は東京都港湾局のホームページからダウンロードできる。
都営空港に関する飛行場制限表面図ダウンロードサービス|ビジネス利用|東京都港湾局公式ホームページ
地図が古くて明治安田生命武蔵野台グラウンドがまだ残っているが、道はほとんど変わってないのでだいたいわかる。 図は大変わかりやすく、高さが示されている。 滑走路のすぐ脇、武蔵野の森公園あたりは十分な注意が必要だが、少し離れれば高さ 45m まで OK となる。 調布飛行場は水平表面の半径が 1,000m のようなので、円の外側で滑走路の延長線上からも外れている場所ならば、150m は OK なんだろう。
他には航空交通管制圏、これが、航空管制塔から 9km 圏内だと高さ 150m 以下でもまずいとしている web サイトがある。 でも管制圏は 150m 以上がだめとの記述もある。 調布飛行場の管制圏は 2006 年 3 月 31 日をもって廃止されたとのことで、今は気にしなくてよさそう。 特別管制空域は全域のようだが、たぶんこの辺では羽田の近辺以外は関係ない。
他の飛行場、例えば入間基地や横田基地は、9km 以上離れているから問題ないはず。 立川飛行場は、9km なら府中だと浅間山公園あたりがきわどいかも知れない。9km かどうかは問題で、例えば調布飛行場は以前は半径 5km だったとか。
この図では浅間山公園や平和の森公園は OK ということになるが、これって管制塔の位置で決まるんだろうけど、管制塔ってどこだ。 英語では control zone dimensions というらしくて、探すと半径は 5NM (国際海里) すなわち 9,260m となる。 でもこの英語の情報だと CHOFU が残ってたりして、調布の管制圏は廃止されたんだってば。 まぁでも 150m 以下なら OK か。
ちなみに、花火の打ち上げも同じ制限を受けるようである。 武蔵野の森公園で打ち上げ花火をやるなら注意が必要である。
スマートフォンのデータ使用量。 今月は試しに IIJmio のクーポンをオンにしたまま使っている。 クーポン切り替えアプリでは IIJ 側が認識しているクーポンの残量が表示されるのだが、現時点で 1963MB と表示されているから、今月のような使い方をしてれば、半月で 40MB 程度... クーポンは 1 か月ごとに有効期間 2 か月の 1000MB が付くとかそんな内容だったはずなので、超余裕。
そういえば、4 年半ほど前までは、WILLCOM (現 Y!mobile) のパケコミネットという料金コース (現料金プラン) を使っていたのだった。20 万パケットまで定額だったから、1 パケット 128 バイト換算で、25.6MB まで定額という計算。 自分の使い方では、あれで余裕だったんだよなー。 そう考えると 1000MB は十分で、もちろん web ブラウザーが使うコンテンツも当時より大きくはなったが、それに加えてアプリのアップデート等を 3G 回線でやったとしてもまだ使い切れないくらいの量なわけだ。
PC のビープ音を鳴らす機能を利用して PCM を再生するというプログラムを、昔 PC-98 でよく実装して遊んだ記憶がある。 いったいどういう理屈で鳴っていたのか。 基本的に見るべきところは 8254 タイマーである。
8253 も 8254 も同じようなものである。5MHz 系は 2.4576MHz、8MHz 系は 1.9968MHz だったとある。 そんなだったかな、懐かしい。 カウンター 0 がタイマー割り込み用、カウンター 1 がビープ音用。 上の記事ではポート 0x3fdb でないと多くの機種ではアクセスできないとあるが、PC-9801 だけでなく PC-9821 においても 0x73 も問題なく使用でき、実際、某メニューアプリは汎用レジスター活用のためか 0x73 を使用していた。 某メニューアプリをリバースエンジニアリングして調べたところ、確か、以下のような作りになっていたと思う:
何なのかと言うと、これは各サンプルごとに L の時間と H の時間のバランスを変えることによる一種の PWM なのである。 各サンプルが 1 波長になるのでだいぶおおざっぱな感じがするが、一応理屈としては間違ってはいないように思えるし、実際、自分で最初に作った PCM 再生プログラムは、ビープ音そのものの出力・停止を繰り返し、その比率をビジーウエイトにより変化させるプログラムであったので、ある意味考え方は同じ。
さて、これとは別に、兄者が作ったもっと信じられないほど単純なプログラムがあった。 このアルゴリズムに何か裏付けがあったとは思っていない。
めちゃくちゃ簡単な実装なんだけど、11.025kHz あたりの PCM は意外と普通に聞けていた記憶がある。 これはどういう理屈だったのか。
モード 3 はまさにビープ音に使われるモードで、デューティ比が約 50% になるモードである。 なので、PWM の考え方からいえば、デューティ比が変化しないのだからずっと一定の出力をしているに等しい。 いや、サンプルの値 0〜255 をそのままカウンターにセットしているので、タイマーのカウンター 0 が 11.025kHz の 181 であれば、サンプルが 181〜255 の場合、デューティ比が 50%〜71% (256/2/181) の間で変化することになるし、181 未満の場合でも、打ち切られる位置によってデューティ比は変化することになる。H, L, H となるのは 121〜180 か? その場合 67% (((181-121)+121/2)/181)〜50% の間で変化!? H, L, H, L となるのは 91〜120 で、50%〜67%。 みたいな感じでずいぶんアレな出力っぽい感じがする。
試しに昔使ってた音源データを引っ張り出してきて (日付が 1994 年 9 月なので、たぶん、カウントダウンジャパンで流れた短いバージョンの曲を録音したカセットテープをさらにダビングしたカセットテープをラジカセで再生し、その出力を PC-9821 で録音したもの)、その音質の悪さに愕然としつつ、0〜181 のサンプルを 128 にそろえてみるとさすがに音楽に聞こえない。 ちなみに曲は恋しさと せつなさと 心強さとで、だいたい時期もあってる。 試しに簡単なプログラムを書いて、サンプルの値を変換する tr コマンドの引数を生成して変換してみたら、一応音楽には聞こえたが、ノイズが激しい。 もうちょっときれいに聞こえていたような気がするんだよなぁ。 うーん、わからん。
a="tr '\\1-\\377' '";
for(i=1;i<256;i++){
if(i%2)h=(i+1)/2,l=(i-1)/2;else h=l=i/2;
for(s=x=0;s<181;)s+=h+l,x+=h;
if(s>181)s-=l;
if(s>181)x-=s-181;
//print(i+"\t"+x/181);
a=a+"\\"+Math.floor(x*255/181).toString(8);
}
a=a+"'";
print(a);
理想的にはどうすべきだったのだろうか。8254 の仕様的にはデューティ比をコントロールする術はなさそうで、とするとモード 0 を使うのは確実ではあるが 1 波長ずつの出力というのが気になるわけで、それを細かくしようとするならば、結局、標本化周波数を上げるのと同じように、より細かく制御するしかなかったのかも知れない。 上に書いたモード 0 の使い方では、標本化周波数が上がれば上がるほど、量子化誤差が増えてしまうのは避けられないのだけど、実際の標本化周波数よりも高い頻度で制御することで、例えば 1 サンプルあたり 3 波長ずつとかの出力になれば、それだけ精度の高い出力が得られたのかも。 そもそも、標本化周波数をタイマー 0 に設定する段階の誤差でさえも気にしないほど当時はいい加減だったので、そんなことに気づくわけはなかったんだけど。
2 日前にスマートフォンのデータ使用量のことを書いたが、きのう、データ量が倍増するというニュースが。
「IIJmio高速モバイル/Dサービス」、料金据え置きでデータ量を倍増 - ケータイ Watch
ミニマムスタートプランなので、つまり、うん、現状の 1000MB でさえ使い切れてないのに、2000MB になるというわけなんだ。 つよい。 おまけに、今使っている FXC-5A は LTE 対応端末じゃない、すなわち、下り最大 14.4Mbps で、これは 10 分近く連続通信してやっと 1000MB とかそういう速度なので、あんしん。
Linux 上でプログラム書いて試してみた。 符号無し 8bit を標準入力から入力しビープ音で再生するプログラム。
タイマー 0 は、Linux kernel との衝突を避けるために、いじっていない。 代わりに、ACPI PM Timer をポーリングしてタイミングを見ているという、何とも時代錯誤な感じが漂うプログラムである。
モード 0 版は第 2 引数により制御頻度を n 倍に上げる機能を実装してある。 つまり 1 サンプルは n 波長の出力となる。 それによって生じる誤差は n 回分の制御により取り戻すように作ったつもり。 効果があるのかというと、11,025Hz では耳障りなピー音が聞こえるところ、2 倍以上にすればピー音がなくなって聞きやすくはなる。 そういえば昔作った時もピー音が鳴ってたりしたような気がする。
ビープ音出力停止版は、昔作ったようなモード 0 版と似て非なる実装というのではなく、今時の高性能 PC にものを言わせて、より細かい単位での PWM を目指してみたものである。 正直なところ、結果はいまいちであった。
PC-98 とはスピーカーまわりの接続が違うのかも知れないが、とにかく、上の 2 つはある程度うまく再生できているものの、モード 3 を試したらまるでだめだった。 うーむ。
Linux 上だから仕方ないかも知れないが、割り込みノイズ的なものも耳障りである。 昔はそれを嫌って、わざわざ VCPI か何かを使って、拡張メモリー上にデータをすべて読み込んでから割り込み禁止で再生するようなプログラムを書いた記憶がある。 どこにやったかな、あれ。
そして普通に PCM 使ってみるとめちゃきれいに再生できる。 やっぱ次元が違うな。 でもおもしろいことに、ビープ音は 1, 0 しかない代わりに、制御の単位は細かいのである。PCM だと 48kHz とか、96kHz とかその程度だが、ビープ音は MHz 単位での制御も夢ではない。PCM 出力で PC エミュレーターを作るなら、そして、もしその上で PWM による音声再生ソフトウェアを実行させるつもりがあるなら、タイマー出力の 1, 0 のデューティ比から PCM のサンプルを求めるような処理を作っておかないとだめかも知れない。
この前テレビ放送を見た時、変速操作っぽいことをしているのに気が付いて、気になっていたが、なんと 4 段変速になっているらしい。 うーん。 そっか...
電動モーターで変速機搭載の意味がないかというと、たぶん、ないわけではなくて、高いギヤで低いギヤと同じ強い加速をしたいなら、それだけたくさん電気を食うわけなので、電車のように電線から大きな電力がもらえる状況ならいいけど (おまけに電車は急加速をしない)、バッテリーからの場合は限界があるから、ってことなのかなぁ。 ついでに、変速機からの音もドライバーに伝わるから、内燃機関を持つフォーミュラカーに慣れたドライバーにとっては、ドライバビリティーもいいのかも知れない。 何年か続いて、レギュレーションが変わって、各チームの開発が許されるようになってからが、本当の未来っぽい感じになるのかも?
変速機ありといえば、電動原付で、自転車スタイルっぽいのも出てきているらしい。
エコで毎日を豊かに ISOLA（イソラ）| 製品情報 IS006
まだちょっと大きいかな。 下のみたいになるといいよね、おもちゃとしては。 日本で走らせるには、スピードメーター・前照灯・尾灯・制動灯・方向指示器などをつけてナンバーつけてヘルメットをかぶることになるだろうけど。 もう少し最高速度が遅ければ、方向指示器等の省略が許されるだろうけど。
wsproxy は Chromium からつながらないし、他に inetd で使えそうなものもないので、websockify の代替品を Perl で自作した。 データはどうやらそのままバイナリーで乗っけているだけっぽいので、適当にこしらえてみたところ、最初に引っかかったのは、クライアントへはデータが届いたみたいだが、クライアントからデータが送られてこない。 これは、Sec-WebSocket-Protocol: binary ヘッダーを付けることにより解決。 意味がずっとわかっていなかったが、これってブラウザーが対応するしないではなく、完全にアプリケーション用で、JavaScript 側で扱うだけかも。noVNC が以前は (ブラウザー側の対応の問題もあって) base64 のみの対応で、その後 binary 対応が入ったとか、そういう話みたいだ。wsproxy は base64 仕様だった。
次に、クライアントから送られてくるデータが、ヘッダー 2 バイトとそこに書かれている長さを合わせてもそれよりさらに 4 バイト長いことで、何だろうと数時間悩んでいたが、これは mask の存在をすっかり忘れていたせいだった。 前に WebSocket を nph CGI で試したが、あれはサーバーからクライアントに送りつけるだけだったので、反対向きのことは考えていなかったのだ。Mask はバイト列に対して排他的論理和を計算していく必要があり、単純に unpack して for ループ回して pack するようにしたが、性能はよくなさそうである。 まぁ、クライアントから送られてくるのはマウスとキーボードくらいしかないだろうから、性能悪くてもいいかな?
あとはどうしてもクライアントに送る方向のデータが多いので、そっち向きはたくさんデータが送られるように修正。
ソースコードは Bitbucket に置いた。
inetd に登録しなくても dpipe nc -l 10000 = in.yawsproxy.pl 127.0.0.1 5900 みたいな感じで試せる。 それを利用して試しに Windows PC への接続をテストしたら、Android の Google Chrome からでも問題なく表示されるらしいことがわかった。 やはり、前に見つけたコミットによる影響は、VNC サーバーとの相性問題になるのか。
FIN ビットは 1 のみ受け付けるようにしてあるが、実際送られてこないのでどうしていいものか何とも。 コメントで指摘して頂いた長さの計算ミスとか、長さの分メモリー確保しちゃう問題の修正とか、ブラウザー側にデータを送る時のメモリーコピーの削減とか、意味がどれだけあるかわからないけど TCP_NODELAY の設定とか、WebSocket じゃない方法でアクセスした時に止まらないようにする変更とか、やった。
双方向通信は単純に fork して方向別に別プロセスで行っている。 親プロセスがブラウザーからの受信、子プロセスが VNC サーバーからの受信。 親子プロセスは独立して動作している。 最後も「もう送るデータはないよ」という意味を shutdown を使って通信相手に通知するのみで、終了処理を含めて親子プロセス間のやりとりはしない。 実際のところどうやって終わるのかを見てみると、まず、noVNC 側から WebSocket で close 通知が来る。 それを受信した親プロセスは、VNC サーバーに対して「もう送るデータはないよ」とやって終了する。 それを受けた VNC サーバーが直ちに接続を閉じるらしく、子プロセスは受信できるデータがなくなって終了する。 そんな感じのようだ。
某駅前の市営バイク駐車場の定期とやらについて、係の人に聞いてみた。 今は一杯で、待ち行列になっているらしいのだが、その長さがなんと 80 人超! 何年かかるかわからない、みたいな話で。 うわぁぁぁ。
道路交通法と道路運送車両法で微妙に車両の区分が違うというのは何となくは知っていた。 例えば、原動機付自転車と言う場合に、道路交通法は運転免許と同じ 50cc (0.6kW) 以下、道路運送車両法では 125cc (1.0kW) 以下、みたいな。 そのノリで、もっと排気量の大きなところまで見てみようと、軽い気持ちで調べ始めたのだが。
とりあえず、50cc (0.6kW) 以下だけでも知らないことがあった。
二輪扱いの場合、ヘルメット着用義務や 30km/h 制限のルールが適用される。 ミニカーは普通自動車扱いである。 いずれも税金は軽自動車税、長さや幅の制限も二輪の軽自動車と同一。
二輪の軽自動車というのが、軽二輪、いわゆる 125cc (1kW) 超 250cc 以下の二輪車、と普通は考えるところ。 まず、内燃機関ではない場合、定格出力 1kW 超の二輪車は、どれだけ出力が大きくても、軽二輪にあたるのはおもしろいところ。 さらに、三輪車 (トライク) の場合、50cc (0.6kW) 超 250cc 以下が、側車付軽二輪という分類らしく、普通自動車扱いで車検が不要らしい。 トライクに関しては特定二輪車という二輪扱いされるものもあるらしく注意が必要だが、0.6kW 超の電動トライクであれば、どんなに大出力でも、車検不要で普通免許で乗れるというのが存在しうるということになる。
あれ? ミゼットなんかは 250cc でも側車付軽二輪ではないよな? 軽三輪車? わけがわからない...
ついでに、サイドカーというやつは、原付 (50cc) にも付けられるらしいが、乗車定員は増えない。 さらに、自転車にもサイドカーを付けられるらしく、そうすると軽車両になって、乗車定員は増やせるらしい。 なんだそれ! あ、でも、リヤカーというやつも、自転車や原付で牽引するのは OK だったりする。
まったり祝日。
Nginx に SSL の設定を入れた。 割と簡単。 完全に予想外なことに、SSL にしたら Android の Google Chrome からも noVNC がちゃんと使えるようになった。 すばらしい。
SSL は、Aterm ルーターがしょぼいせいで、LAN から自身のグローバル IP アドレスでの接続ができないので、LAN から使うのとそうでない場合でホスト名が違っちゃうのをどうやって対処しようかと考え、結局、Common Name にワイルドカードを使い、DNS にプライベート IP アドレスのホスト名を別途追加することで対処した。
実際に Android スマートフォンから noVNC を使ってみて思ったのは、Android 版の VNC クライアントアプリには拡大縮小機能がついているのだが、noVNC ではそれができないっぽくて、スクロールしなきゃいけないのがちょっと面倒だと思ったのと、ずいぶん解像度の低い画面が転送されてきている感じ。 あと、3G 回線で使う場合は True Color オプションを外しておくほうがよさそう。
スクーターによく使われる V ベルトと無段変速について、web 検索したらいい感じの情報が見つかった。
プーリーがエンジン側とタイヤ側にあり、それをベルトがつないでいる。 自動遠心クラッチはタイヤ側のプーリーとタイヤの間にある。 変速はプーリーの径の変化による。 前後に外装変速機を持つ自転車に乗っていた経験があるから、それに例えるとイメージしやすい。 停車時は自転車でいうと前が小さく後ろが大きい状態。 タイヤ側プーリーにあるクラッチセンタースプリングとやらの力により、大きい状態にされている。 エンジン側プーリーに入っているおもりが遠心力で動くことで、前が大きく後ろが小さい状態に移行していく。 ふむふむ。
発進の時はエンジン回転数を上げるが、おそらくまだ変速には至らない程度の回転数でクラッチがつながるものと想像。 自動遠心クラッチはレンタルカートや原付で慣れているから、ゆるやかに発進する場合はそのままあの感じでクラッチがつながり加速に至るものと考えられる。 クラッチが完全につながったらさらに回転数が上がり、シフトアップしていく、と。 そのとき、シフトアップすれば回転数が下がるわけだから、まだレブリミットにはほど遠い状態でバランスが取れて、うまく加速するのかな。
発進時からめいっぱいアクセルを開けた場合は、クラッチがつながる前に変速が始まるものと思われる。 カートなんかでは、クラッチがつながるまでは、ゆるやかな発進よりも高い回転数をキープして加速するが、V ベルトではクラッチがつながる前から変速することで、ゆるやかな発進の時との回転数の差は小さくなるのかな。 乗ったことがないので完全に想像でしかない。
と、いうことまではわかった。 別の説明を見ると、トルクカムというのがあって、シフトダウンに寄与しているらしい。 うーむ。
ああ。 トルクカムがないと、例えば全力で最高速で走行中、登坂を始めた時に、回転数ばかりが落ちて、シフトダウンが行われないということか。
アクセルをゆるめた時の挙動もいまいちぴんと来ない。 すぱっと離すとクラッチつながりっぱなし、ゆっくり戻すと回転が落ちてしまってクラッチが切れる的な話を聞いたことはあるが、どういうわけなんだろう。
FK-9、無段変速のカートがあるとは知らなかった... このサイトの変速の説明はわかりやすくてよい。 負荷がかかることによりタイヤ側のプーリーにある 2 枚の回転板 (?) に速度差が生まれて、それによって変速が、シフトダウンが起きる的な話のよう。 自転車でいうとチェーンが張る感じのあの時のことだな。 逆にタイヤ側からの負荷が大きい時にはシフトダウンしにくくようになっているっぽい。 すげぇな、これ... スーパーカブのネジ機構 (クラッチセンターとドライブギヤアウター) と同じで、よく思いつくなぁ。
ここまでわかったところで、今まで何か違和感を持っていたのは何かというと、自動遠心クラッチについてスーパーカブのエンジンのものしか知らず、スーパーカブの場合は車と同じでエンジンの回転をまずクラッチが伝えるしくみ。 その先に変速機があって、チェーンでタイヤのほうまで力が伝わる。 それと同じようなものがスクーターにも使われているはずだと、考えたので、チェーンの代わりにベルトで、エンジンのところにクラッチがあるのかと思ってた。 どうやら全然違うわけだ。
いや〜、なんだかんだ言ってもハミルトンは速い。 予選、それはもう誰がどう見ても明らかと言えるほど盛大に 1 コーナーでミスったのに、それでも 7/1000 秒差でトップタイム。2 番手タイムを出したロズベルグも、7/1000 秒くらいは絞り出せたかもというようなコメントだったが、ハミルトンの 1 コーナーのミスがなかったらと考えれば完敗じゃないか。
そして決勝のロズベルグのトラブル。 時折映し出されていたオンボードカメラの映像では、2 速ずつ変速しながらの走行。 解説陣はその映像に関しては何も触れていなかったが、どうやらあれもトラブルのせいだったようで、後からのコメントによれば最初は無線すら使えなかったとか。 ピットロードの速度リミッターさえも使えないとか (無線の話からすれば 60km/h が 1 速 6000rpm? みたいだな)、まれに見るトラブルであった。 ブラウン GP どころかホンダ時代から使っていた部分のトラブルだったらしく、今はメルセデスのワークスチームには違いないんだけど、前身のホンダの名残は残っているんだね。 ロズベルグのリタイヤで、ドライバーズポイントランキング的にはおもしろくなった。
ライコネンは前の車のおしりをつつきそうな感じで走っているシーンが何度かあった気がするが、後のコメントによれば、案の定、前の車に近づくとダウンフォースが減るか何かで追い抜けなかったみたいで。 タイヤ戦略的にもセーフティーカーはあまりおいしいタイミングではなかったのだろう。 ペースは悪くなかったと思うので次戦に期待か。
ベッテルはなんだかんだ言いながらプライムタイヤを持たせて表彰台。 すぐ後ろにはリカルド、さすが。
ハミルトンは決勝でもほとんどリードしていたが、セーフティーカーでギャップがなくなり、その後オプションタイヤの限界まで飛ばしまくって最後のタイヤ交換で 2 位で戻り、タイヤがくたくたなベッテルをあっさりと抜き去り優勝。 やっぱり今年のメルセデスは速ぇ。
小林はよりによってフォーメーションラップでリタイヤ。 ルノーエンジンのエンジニアが何かしら直前まで作業していたとかで、どうもトラブルみたいだが、深夜の謎の極秘従業員ミーティング的なものがニュースに出ていただけに、わざと走れないようにしたんじゃないかとか想像してしまう。
UNIXとLinuxの「Bash」シェルに重大なセキュリティホール - セキュリティホール memo
今朝、偶然この話を知って、ちょっと緊急作業をしたのであった。 とりあえず、CGI 系で bash を使っているものはやばい。 狙われたら世界中に迷惑をかけることになりかねない。 さくらのレンタルサーバは FreeBSD なので、意図的に指定しない限り bash が使われることはあり得ないが、探したら意図的に指定したものが出てきた。
これ。 どう見ても bash スクリプト。 見ての通り Sec-WebSocket-Key ヘッダーを受け取るのに環境変数を使っている。 つまり、その環境変数にはクライアントが好きな文字を何でも入れられることになる。 今回の脆弱性は、任意の環境変数に特定の文字列を入れることにより、bash にスクリプトよりも前にコマンドを実行させるもの。 だから、どう見てもアウト。 とりあえず実行属性を落とした。 他には見当たらなかったのでとりあえずこれだけ。
さて、これはどうも bash が持っている関数のエクスポート機能、その仕様が元凶のようだ。 仕様として、任意の関数を環境変数経由で他プロセスに渡せるのだ。 試したところ、if や case は無理だけど、test, [, cd, exec のような、シェルの内部コマンドと同じ名前の関数は渡すことができた。 すなわち、cd したり引数を追加したりして単に exec するだけのとてもありがちなシェルスクリプトでも問題が起こりうる:
$ cat /usr/bin/yacc #! /bin/sh exec '/usr/bin/bison' -y "$@"
こういうのは、C で書くのと差はないだろうと思っていたんだけど、/bin/sh が bash となっている環境においては、exec という名前の関数が環境変数にエクスポートされているかどうかによって、動作が変わるということ。 外部コマンドなら PATH によって動作が変わるのは考えられることで、だから PATH を意図的に設定したり、コマンドをフルパスで指定したりして問題を回避するわけだけど、内部コマンドまで信用がおけないのでは、どうしようもない。 それも、csh のように、-f オプションを付け忘れて .cshrc を先に実行してしまったから... というのとは違い、伝統的な /bin/sh なら当たり前に安全に動作していたスクリプトが、bash だと安全ではなくなるというのだから、bash はとても危険な機能を導入してしまったのではないかと思う。
そして Debian が採用した dash が bash より速いという理屈もわかったし (環境変数の無駄な解釈がないのだから)、Debian は /bin/sh のデフォルトを dash にしたとはいえ、多くのシェルスクリプトが bash スクリプトになってしまっており、bash が抜けるようにはなってないということも気づかされた。
直接関係はないけど、最近はやりの systemd、あれは init の代替品でありながら非常に巨大で何でもやっちゃうやばそうな感が漂っているのだけど、元はといえば Red Hat か、あるいは、もっと前の Linux ディストリビューションかも知れないが、そのあたりで /bin/sh を bash にしちゃった時から、何でも巨大化しちゃう方向に進んでいたのかも知れないし、今回の bash 問題は、systemd のようなむちゃくちゃなやり方に対する警告に... なってほしいな、と。Debian は kFreeBSD サポートの関係もあって systemd 以外の選択肢が残るので、まだいいんだけれども。
今日、アクセル全開での走行後の一時停止でエンスト。 停止前までブリッピングしながらシフトダウンをしていたので、エンジンは一応自力で回ってはいたはずだが、アイドリングせずにストールした。 スターターモーターで再始動を試みるも、かかる気配なし。 キックでもかからない。 プラグがかぶったかと思いアクセル全開でキックして戻してキック等したものの、かからない。 うーん?
ええい面倒だ、と思って 4 速に入れて早歩きで押し掛け。30m ほど押したところでわずかに手応えあり。 アクセルをわずかに開けながらさらに 30m ほど押し、何とか加速できそうな感じになってきたので、止まらずにそのまま乗ってシフトダウンして走行、その後はちゃんとアイドリングしてた。 さすがに 60m 以上もの押し掛けに相当するキックをしたら疲れるだろうな。 スターターモーターに無理をさせるのも手だったんだろうけど。
原因について Google 検索してみたが、いくつか可能性があって難しい。 キックが軽かったかと言われても、軽かったような、そうでもないような... そもそも 50cc なんで軽いからねぇ。
まず、いやなほうからいくと、軽い焼き付きを起こしている場合、過熱するとストールし、さめると復活するというような症状になるらしい。 そのまま乗り続ければどんどん症状が悪化していく可能性も。 走行中に本格的に焼き付くと、エンジンがロックしてしまい大変危険な状態となる。 スーパーカブの駆動系は、自動遠心クラッチでありながら押し掛けが可能な構造のため、もし走行中にエンジンがロックすれば、エンジンをタイヤ側から回そうとして、タイヤもロックすることになる。 ただ、アクセル全開走行後のエンストは初めてではないし、全開ではないものの停車と同時にエンストして再始動しにくかったこともある。
次に、バルブへのカーボン付着の可能性がある。 原付を人に言えないスピードで走らせていると、点火系の制御により、リミッターがかかっている場合がある。 でも、燃料供給はキャブレターにより機械的に行われているから、きちんと燃え切らない状態となり、バルブへカーボンが付着するんだとか。 それによってバルブがきちんと閉まらなくなれば、圧縮ができなくなりエンジンは機能しなくなる。 また、減速時のエンジンブレーキでも、燃料供給は行われ続けるから、問題が起こりうる。 燃料にカーボン除去用の添加剤を入れることで改善する可能性がある。 なお、スーパーカブのエンジンではこの問題は起こりにくいらしい。4 速時の点火系リミッターも、間引くのではなく、タイミングをずらしているだけだったはずだし。
最後に、燃料供給系統の問題の可能性があるらしい。 燃料供給が間に合わないと、キャブレター内の燃料がたまる部分の燃料量が少なくなってしまう。 燃料をエンジンのほうに吸い上げる口の位置は、アイドリング用のスロー系統のほうが高くなっているため、メインジェットには燃料が供給されていても、アイドリングができないという症状はあり得る。 しばらく待てば燃料がたまり、復活するというわけ。 でも、キャブレターそのものは、ボアアップしても調整のみで使っている人もいるようなので、いくら全開走行をしたからって、50cc エンジンで燃料供給が間に合わなくなるとは考えられない。 あとは、燃料タンクからキャブレターにつながる部分が詰まりかけているとか、その可能性は否定できない。 燃料添加剤での改善の可能性はあるかもね。
とまぁそんなわけなので、燃料添加剤でも入れてみて様子を見るか。 ガソリン 50L に一本、みたいな量で売られているらしいので、原付にはほんのちょっとでいい。32L タンクの車には半分ちょっとだからそっちにも入れれば使い切れるか。
よく寝っ転がって使ったりしているせいなのだが、ノート PC の電源ケーブルは AC アダプター側に引っ張られやすく、根元が断線しやすい印象があるので (過去に使ってきたノート PC で合計 3 回やらかしている)、根元に力がかからないよう、ひとつ輪を作って根元と束ねるようにして使っていた。 それの固定に、ねじるタイプの結束バンドを使っていたのだが、結構ゆるみやすく、ずれやすく、いまいちだった。 しかも、この前、ゆるんだのを締め直そうと、結束バンドを力一杯引っ張ったら、劣化していたのか、芯じゃない部分がもげてしまった。 うーん。
テープをじかに貼るとべたべたしそうでいやだし、それを避けるために紙かなんかを挟めば滑ってしまって意味がなさそうだし。 ん、滑る...? 滑り止めか! というのを思いついて、こんな感じにした:
これでしばらく使っているが、さすがに滑り止めだけあって、全くずれない。 いい感じだが、あまりにもずれないので、根元と束ねている途中の部分が力を受けすぎて断線したりして... ずらそうと思ってもずれないし。
テレビでやってた映画「逃亡者」(原題: The Fugitive)。1993 年。
何となく見たことあるやつに違いないと思って見始めたが、どうやら 11 年前に見たようだ。 序盤に出てくる護送バス横転事故から続く列車衝突事故シーンが派手でいい感じだった。 その後の逃走、水路をたどってダムに飛び込むあたりは、見た記憶があった。
1993 年だが携帯電話らしきものも出てくるものの、無線機を使っている場面が多い。 電話の録音を聞くシーンはオープンリールだったな。 病院にあるコンピューターはさすがに昔っぽい仕様、Windows 95 が出る前だから、現実に使われているもの、映画を撮る人達の認識も含め、ああいうのだったのかな。 実際自分も当時は DOS を使ってたしね。
車は、アメリカ映画によくあるというか、ホーム・アローン (1990) とかターミネーター 2 (1991) とかマスク (1994) とかも時期が近いね、そのへんで見慣れているのかも知れないが、サスペンションがふかふかで、いかにもアメ車な感じ。
1993 年だと、今はもう 20 年ぐらい経っているわけで、あんなにふかふか揺れる車は今時ないだろうし、スマートフォンはほぼみんな持ってて当たり前、監視カメラは駅などいろいろな場所にたくさんあって録画がされており、録音も映像も当然のことながらディジタル処理、机をあさって出てくる写真より、スマートフォン、ディジタルカメラのメモリーカードやパソコンを探って出てくるほうが多かろう。 マルチメディア、って言葉ももう聞かなくなったけど、当時は手軽に扱えなかった容量のディジタルデータが今は本当に簡単に扱えるようになったからなぁ。
朝から藤野へ向かう。 何も考えずに調布 IC に向かい、ランプに入った瞬間、上の電光掲示の表示が読めてしまった。 「調布-国立府中 渋滞 4km」とか... そして料金所まで達している車の列。 原因は府中バス停での交通事故に伴い、車線規制が行われていたらしいこと。 発炎筒みたいなやつで左車線を遮っていたらしい跡が残っているところを通った。 っていうか、10km/h くらいでしか流れておらず、明らかに国立府中から乗るべきだった...
レンタルカート。 藤野。 イベント日。4 回乗ってその後耐久レース。 くじ運が良く結果は 2 位。
駅前で食事してから帰宅。 渋滞はなかったが、信号タイミングがひどく、おまけに中途半端に遅い車がいる甲州街道はイケてない。
夜のテレビ東京 SUPER GT+ が 15 分遅れ。 今年初開催のタイのサーキットや、GT500 に出ている GT-R の改良点の紹介、GT300 の、エアコンがついていない BRZ のドライバーの、レース前とレース後の体重比較など、おもしろかったが、見てる時からやたら眠くて、見終わったらバタンキュー。
ついにきた。 自宅に IPv6。 ながかった。
さくらのレンタルサーバにログインしたら、known hosts に IPv6 アドレスが追加されたので気づいた。 おとといあたりにもログインしたはずだから、今日あたりだったのかな。
Warning: Permanently added the ECDSA host key for IP address '2403:3a00:101:a:21 9:94:129:48' to the list of known hosts.
まだ GNU/Linux 環境しか確かめていないが、驚くほど自然に IPv6 通信をし始めている。 すばらしい。 あ、トレースされるという観点ではいまいちかも知れない。
ログを探したら時刻が判明。 こんな風に残っていた (一部伏せ字):
Sep 29 18:36:21 nojima avahi-daemon[2633]: Leaving mDNS multicast group on inter face br0.IPv6 with address fe80::***:****:****:****. Sep 29 18:36:21 nojima avahi-daemon[2633]: Joining mDNS multicast group on inter face br0.IPv6 with address 240f:**:****:*:***:****:****:****.
職場近くの讃岐うどんの店が閉店したらしいことが確定してしまった。 複数の人が閉店の張り紙の写真を撮っているようなので間違いなさそうだ。 先月頭くらいから閉まってて、時々チェックしに行ってて、ずっと張り紙はなかったと思っているが、どうも 2 週間前くらいには張り紙が貼られていたみたいだ。 残念。
週末は、御嶽山が噴火したとかで、今も救助活動が行われているなどたいへんなことになっている。 知らなかったんだけど、桜島も 1955 年の爆発音を伴う噴火で登山者に死者が出て、入山規制が始まったんだとか。
「1955年10月13日午後3時前」だそうなので、木曜日である。 木曜日だったから被害が小さかったのかも知れない。 図書館かどこかで当時の新聞でも見てみれば当時の状況がわかるかも。 今回の御嶽山は、よりにもよって、天気のいい土曜日の真っ昼間。 あと 12 時間ズレてれば... なんて言ってもどうしようもない。
桜島だって、ずーっと噴火が続いているから入山規制も続いているわけで、落ち着いている時間が続いていたら、徐々に規制が解除されていたのだろうし、その時間に比例して、登山する人達の、噴火することはないだろうという気持ちも、大きくなるのだろう。 まぁ、今後、桜島の入山規制が解除されることがあるとしても、歴史的事情からして、退避壕などは確保されるだろうけど、御嶽山の火山活動はそんなに歴史に残っていないみたいだし、退避壕がなくても不思議ではないよなぁ。 誰も責められないよねぇ。
最近は ifconfig コマンドが PATH の通っていないところにあることもあり、ip addr コマンドをよく使っているのだが、IPv6 になると、見慣れない表示が出てくるようになった。
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 192.168.0.21/24 brd 192.168.0.255 scope global br0
inet6 240f:**:****:*:***:****:****:****/64 scope global dynamic
valid_lft 290sec preferred_lft 290sec
inet6 fe80::***:****:****:****/64 scope link
valid_lft forever preferred_lft forever
valid_lft と preferred_lft の部分。 今までのリンクローカルアドレスのところにも forever というのが出ていたみたいなんだけど、グローバルの部分にはだいぶ具体的な数字が出ていて、しかも意外と小さい。 なんと ip(8) のマニュアルには表示項目に関する説明は一切無く、仕方がないので Google 検索である。
valid_lft forever preferred_lft forever
valid_lft = Valid Lifetime
preferred_lft = Preferred Lifetime
ほほー。 どうやら RA と呼ばれる IP アドレス自動設定用のメッセージに載ってくるようだ。 スタティックに IP アドレスを割り当てれば関係なくなるようだ。 リンクローカルアドレスは当然無効になることはないので forever ということか。 へぇー。
仕事中に知った x86 命令 MWAIT。 てっきり WAIT (FWAIT) 命令の親戚か何かかと思っていたが、全く別物であった。 ちなみに、WAIT は浮動小数点コプロセッサー用の命令で、8086 時代からあるものだ。 浮動小数点演算命令には昔から興味を持たなかったため (IBM JX にコプロセッサーはついてなかったしね!)、あぁ浮動小数点演算命令ね、ふーん、くらいしか思っていなかった。
で、どうやら MWAIT というのは、MONITOR 命令と合わせて使って、メモリー上の特定の番地が、他の論理プロセッサーによって変更されるのを待つ、というような機能を持つ命令として、Pentium 4 の頃に登場したものらしい。 それがどうも最近では、HLT 命令の代わりとして、アイドル状態の時に実行されて、HLT 命令よりも深く CPU が眠ってくれる、というような用途にも使われているらしい。 へぇー!
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU