欠陥交差点か検証しないのか

大津の交通事故は,幼い子供が2人亡くなり,重体,重傷を含むけが人も多く出る惨事となりました.

もちろん一番責任があるのは右折をして事故を起こした,逮捕取調中の容疑者であることは間違いないでしょう.

しかし,この交差点の作り自体に問題はなかったのか,とふと思いました.自分で運転をしていても,右折しにくい交差点にしばしば遭遇します.なんでこんな作りにしてあるのか,なんでこんなタイミングの信号にしてあるのか等々.

危険を感じるドライバーが多数いれば,必ず事故はあるでしょう(ハインリッヒの法則).

交差点の管理は警察がやってますから,仮に交差点に問題があったとしても,発表をするわけないことは,皆知ってます.

今こそ,正義の味方のマスコミ・ジャーナリストの皆さんの出番です.この交差点の検証を徹底的に行って欲しいのとともに,同じような悲劇を減らすために,全国の危険交差点についてもこの際洗い出して報道して欲しいと思います.

Slackware ARM: ntpパッケージupdate時の注意

自分宛の注意事項です.

Raspberry Piは,バッテリーで駆動される時計を持っていませんから,起動時は1970年1月1日になってしまいます.

Slackware ARMは他のdistroと違って,起動スクリプトにこれをなんとかする仕組みがないので,ntpdが同期して最初に内蔵時計を更新するまで,1970年1月1日のままで,いろいろ不都合が起きます.

そこで,rc.ntpdのstart()内に,ntpdateを使ってとりあえずどこかの時間サーバーから時刻をもらってくるコマンドを書き加えています.

しかし,ntpのパッケージをupdateすると,オリジナルのntpdateコマンドの入ってないスクリプトに上書きされて,この機能が失われてしまいます.

ということで,リブートしたとき1970年1月1日になるようだったら,rc.ntpd-has-ntpdateとして保存しているスクリプトをrc.ntpdに上書きコピーすること(念のため当該スクリプトが更新されていないかも確認する).

CWKはLibreOfficeで読める

ときどき,自分のPC(Macintosh)や,サーバー内に,”.cwk”という拡張子のファイルが見つかることがあります.これは,もとはApple Works(さらに前はClarisWorks)で作成したドキュメントのファイルの拡張子です.

けしからん事にAppleは,AppleWorksをディスコンした後,AppleWorksで作成されたファイルを読み込める機能のソフトを提供していません.

今日,中身を,とある目的に再利用できる可能性のあるファイルを見つけたんですが,そういうわけで読み込む方法がなく,中身をダンプして,テキスト部分だけ抽出して,文字コード変換でもしようか考えていました.

ネット検索範囲を英語のforumまで広げたところ,LibreOfficeで読み込めるのではないかという情報を見つけたので試ました.若干の字化けがあったものの,みごと再利用できる状態で読み込むことができました.

辞書作る奴らはバカか

ときどき,「ステロタイプ」なる言葉を見聞きします.もとはstereotypeだから,「ステレオタイプ」とかな書きするものと私は信じてきました.

それで,パソコン内蔵の辞書やネットの辞書を引くわけです.すると,「ステロタイプ」という見出しはありますが,「ステレオタイプ」のこととあります.

「ステロタイプ」を引く人は,そんなことを知りたいわけじゃなくて,なぜ,「ステレオタイプ」と「ステロタイプ」という表記があるのかを知りたいに違いないって,普通の頭を持っていればわかるに決まってます.

一部のなんとか袋的なところには,読み間違いだかなんだかで「ステロタイプ」になったようなことが書いてあります.そうかもしれませんが,なんとも頼りない情報です.

ますます,もやもやしてきました.

Kernel 4.19.36ではext4(SLAB?)関係のバグ改善か(Raspberry Pi)

以前,Raspberry PiのKernelが4.14系列から4.19系列になったときupdateしたら,rsyncを使う自作バックアップスクリプトを実行すると,rsync実行中にシステムが無応答になったので,しばらくKernelを4.14系列の最終1Raspberry Pi用としての「最終」.の4.14.98-v7+にとどめていました(「Kernel 4.19.xはRasPiにNGか」).

昨日,久しぶりに,4.19へのupgradeを敢行してみました(4.19.36-v7+)ところ,1度目のバックアップスクリプト実行は,トラブルなく終わりました.

まだ,1度だけですが,以前は1度で確実にトラブりましたので,改善された可能性が高いです.しばらくこのまま様子を見ます.

追記

よく理解しているわけではありませんが,rsyncによるバックアップ中slabtopで観察していると,4.19.23, 25のときは,ext4_inode_cacheのcache sizeは増える一方で制御が効いていないようでしたが,4.19.36では,増えたり減ったりしています(「アンダーコントロール」の状況^^; ).

SLAB関係のbugというよりは,ext4関係のbugなのかもしれません.動きゃいいのでこれ以上調べませんが^^;