この前テレビ放送を見た時、変速操作っぽいことをしているのに気が付いて、気になっていたが、なんと 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