.ほほえましい 。 例のバカライタといい、こういう知性のかけらもないことを書く奴がいるから Mac の評価が上がらないんだよな。 こういうサイトはぜひ(検閲削除) .サーバ数対クラック数の比で示せば、まだ根拠ある数字が出ると思う。 いや、実際、その比率で示したとしても Mac は低いんじゃないか、と思うぞ。 だって、マイナーだからクラックするための情報の流通も少ないし、 何より芋づる式に穴を開けられるホスト数の絶対数が少ないから、 苦労して穴空けても爽快感もないし旨味も少ない。 つまりは、Mac ってのはクラッカーのモチベーションが上がらない プラットフォームなのは確か。クラックされるかどうか、ってのは、 技術的なことよりもむしろ、そういうソーシャルというかメンタルな面も 非常に大きいから、「マイナーであること」に 一定のメリットがあるのは事実だな。 .もちろん、本物のクラッキングハッカーが、ある特定のサイトを クラックしたいと考えた場合には、そんなことはほとんど関係ないんだが :-)。 「マイナーであること」にメリットがあるとすれば、 むしろ愉快犯的 wanna be 系クラッカーや、 ワームみたいな無差別系クラックの方に対する耐性だろうね。 |
.\. から Why Linux Will Never Be as Secure as OpenBSD 。 OpenBSD の code audit の仕組みは非常に評価できるよな。 標準で入るものは、たとえそれが 3rd party 製であっても、 ちゃんと検証して、検証結果を公開しようとしてるのは評価できるな。 Linux は、どのディストリビューションもそんなことはほとんどやってない。 Secure な用途で Linux を使うのなら、 fix の早さと素性の良さで Debian くらいしか選択肢がないよな。 .Linux はカーネルすら secure かどうか怪しい、 ってのももちろんあるけど、それ以上にディストリビューターは、 3rd party 製のソフトを integrate するということに対して、 責任を持たなすぎる気はするな。 ユーザにとっては、出てきたものが全体として secure かどうか、 でしかないんだから、「いやそれは XXX ソフトのせいであって 我らが YYY Linux (あるいは総称としての Linux でもいいが) のせいではありません」なんてのは所詮言い訳なんだが。 一方で、OpenBSD は全体的に secure にしていこうとする努力の跡が見られる。 繰り返しになるけど、OpenBSD は 3rd party 製のソフトでも 標準で入るものは検証してるし、 その検証結果に対して責任持とうという努力はしてるもんな。 |
.リスト:
|
.なんとなく思い立って、XUL で遊んでみる。 .こいつの実体は XML + CSS + JavaScript でしかないので、 これらの知識があれば、いろいろと遊べる。 .たとえば、bookmark menu の add bookmark は jar:resource:/chrome/comm.jar!/content/navigator/navigatorOverlay.xul の id="Browser:AddBookmark" な broadcaster の oncommand ハンドラで フックされる。 .んで、ここに小細工して apache に URL を 渡せることを確認してみたり。外部ブックマークは案外簡単かもね。 |
.しかし、離脱しようとしたところで捕まって計画断念。あう。 しかし、捕まってやろうとしていた仕事は今日のところは頓挫したのであった。 萎えたからシンクロ行くか…。 |
.夜中に Beyond the Galaxy の記憶コピー(記憶からコピーすること)で ベースを弾く。結構弾けるな。 ベースソロかっこええな。 青木さんのような音色で弾くとかっこよさそうだぞ。 .私が Beyond the Galaxy のオリジナルを初めて聞いたのは 実は最近だったりするのだが、 ベーマガに載った楽譜を見て当時衝撃を受けて譜面だけから MML 打ち込んだことがあるのでよーく覚えてる。 ただ、オリジナルは「変態」なのはいいんだが 「音楽的に同意できないほど変」なところも多いので、 前者はともかく後者は勝手に直したバージョンを覚えてたりするな。 |
.Defeat 。 一小節目から怪しいコードですな。 私の中では、あれは変態なだけで変なのではない、 という位置づけになってますけども。 ファンキー K.H. さんが心の師匠であるところの私としては、 ブリッジのところのベースのフレーズまわしとかは、くるものがあります。 .私の経験的一般論として、あるコードが単体で変ってことはほとんどなくて、 あるとすればフレーズとかコード進行みたいな時系列が絡む場合が ほとんど、ということになってる。 Beyond the Galaxy は、普通の調性を持ってる部分で コードとフレーズの間の調性のミスマッチがあるので非常に目立つ。 一方で Defeat は全体的に調性が浮遊してるところで なかなかかっこいいフレーズが乗ってる。 この辺は Defeat の方がよくできてると思います。 .いずれにしろ、音楽としてそれなりに完結してた System16 諸作とか After Burner までの体感シリーズとかと比べると、 どうも Galaxy Force は全体的に未完成だなぁ、 という印象は受けますです。 ただ、嫌いじゃないんですな。私としても好きな系の音楽なので、 一度再構成に挑戦したい気もする。 すんげー難しい音楽なんだけども、それなりになじんでる系統の音楽ではある。 |
.買ったもの:
.MIDI ケーブルでは必要な信号が出てなくて惨敗。 |
.うちの NetBSD マシンで mount /dsk/kotori/home を 2 回実行した結果: aoi% uname -a NetBSD aoi.bogus-hosts.imou.to 1.5V NetBSD 1.5V (AOI) #22: Sun May 6 05:15:31 JST 2001 root@aoi.bogus-hosts.imou.to:/dsk/wd0f/current-build/root/build/src/sys/arch/ i386/compile/AOI i386 aoi% mount /dev/wd0a on / type ffs (NFS exported, local) /dev/wd0e on /usr type ffs (local, soft dependencies) mfs:106 on /tmp type mfs (asynchronous, local) /dev/wd0f on /dsk/wd0f type ffs (NFS exported, local, noatime, soft dependencies) kernfs on /kern type kernfs (local) procfs on /proc type procfs (local) kotori:/dsk/kotori/wd0g/home on /dsk/kotori/home type nfs kotori:/dsk/kotori/wd0g/home on /dsk/kotori/home type nfs .… NFS ってこういうもんだっけ? |
.backward compatibility を大切にするのは 他のライブラリをちゃんと使おうとするからだし、 backward compatibility を大切にしないのは、 車輪の再発明を美徳だと思ってるフシがあるからじゃないかな。 .不思議なのは、目的のために新しいものを導入しようとするんではなくて、 新しくするために新しいものを導入しようとする姿勢なんだよな。 基本的にハッカーは面倒くさがりが多い。従って、 パッケージを使わないのも、CORBA とか使わないのも、Unicode を使わないのも、 XML を使わないのも、結局は新しいものを覚えるのが面倒くさいからなんだよね。 で、新しいものを覚える労力に対して、どれだけ進歩するのか、 と考えた場合に、大して進歩しないんだなこれが。 別に懐疑的なんじゃなくて、単に必要性が理解できないだけ、というか。 .コンピュータ業界の生き方には 2 つの道があって、 一つは誠実に stable な仕事をする方法。 もう一つは、新しい技術で客を踊らせて稼ぐ方法。 後者の道は、多くの場合自分も踊る羽目になるので、疲れるよ。 MS を頂点とした食物連鎖を見てみるとよくわかるでしょ。 食物連鎖の中間ではみんな踊ってないといけない。 前者で食いっぱぐれないんなら、その方がずっと楽だよ。 .とマジレスつけてどうするよ>オレ |
.英語っぽい 。 あれははっきり言って「open .. or die」とか「read .. while ...」みたいな シンタクスシュガーがピンポイントに英語っぽいだけで、 あとは全然英語っぽくないですな。 .OS 中立な ps2dev-ja とか作るか :D psdev っていう英語の psx なメーリングリストなら、sourceforge にあるが。 |
.ReiserFS と UFS の話 。 UFS だって -o async でマウントすれば ext2fs 並の速度は出ると思うし、 LFS にすればもっと速くて、しかも論理的には耐障害性もある。 もっとも、実用上、という話をすると、 LFS は未だにガベコレ走ると壊れるらしいので使いものにならんが。 世の中の論文では、LFS みたいな all logging より ReiserFS とか JFS とか XFS みたいな metadata logging の方が良い、 とされる傾向もある模様。 .ReiserFS は、確かに B+Tree の効果で 一つのディレクトリに 100000 個とかファイル作って消しても、 一瞬で消えてくれる。けど、取り立てて利点ってそこだけのような。 耐障害性は UFS の metadata sync や softupdate なら同程度に確保される。 だいたい、一つのディレクトリに 10000 個とかファイル作るような状態は、 プログラムの方がタコなんだよ、うん。 news spool とか mail holder ではありがちだけど。 .ただ、ReiserFS には DARPA が研究開発に 10 万ドル出して、 暗号モジュールとかのプラグイン化をさせる、 という話もあるので、今後どうなるか良くわからん。 |
.しろぺんさんが個人で Blade100 を買ったそうなので、 6F まで分解しに行く。なんか、中身 PC そのものなんですけど :D Ultra5 も PC 臭かったけど、何かインチキな台湾製マザーみたいな 濃い緑色の基板に、370pin の CPU とか、 ALi の Aladdin TNT チップセットの South Bridge とか、 旧 DEC の PCI-PCI ブリッジとか、AD1881 AC97 codec とか、 そのまんま PC の部品が乗ってたりするあたりがアレだ。 そもそも、x86 とか書いたジャンパも大量にあるので、 周辺回路追加して、BIOS なんとかすれば、 x86 でも動くんじゃないか、っていう噂もあるな。 |
.今日買ってきた USB MIDI デバイス: .非常に正しい YAMAHA USB MIDI デバイスだなうん。 UX256 は MS Interface Header Descriptor の wTotalLength が 変な値だったので、fixed ports な quirk にしてしまったのだが、 これで Yamaha Specific な部分のテストができるな。 .一昨日、この辺外人さんから「初期化が変やでー」ってメールが来て、 目視で直したのだが、とりあえず直す前のカーネルで挿してみる。 案の定パニック。 今日のカーネルだと、パニックしないけど port 数の 検出が変だ。手術開始。 .とりあえず、Product ID を登録。Yamaha の場合、動作とは無関係だけど。 .jack のカウントは合ってたのだけど、 endpoint の取得方法が間違ってたのでデバイス全体が無効化されてた。直した。 .endpoint の数だけ pipe を割り当てるとこで、interface の数でループしてた。 直した。 .in/out が非対称な mididev では、片っぽの jack 情報構造体が NULL になることがあるのに、そのチェックをしてなかった。直した。 .よし、動いた。 |
.こんなの 。 おあつらえむきに BSD 風ライセンスじゃん(謎)。 「必要ないでしょう?」って奴を enable すればいいな。 「圧縮ライブラリ」って、libz は win でもコンパイルできるけど…。 |
.ううむ、 UNIDENTIFIED ARC SYSTEM [NEC-J95] VENDOR [ NEC W&S] PRODID [00:00:4C:FFFFFF81:58:59:00:FFFFF80] だそうです。arcbios.c 書き換えんとあかんな。 でも、cross 環境作るのめんどいな。 .Express5800/230 には何通りかあるんかね。arctype.h には、 NEC-JC94 というやつに Express5800/230 と書いてある。 で、この NEC-J95 っていう ID でも NEC_JC94 扱いにしてみたが、 やっぱりうまく動かんな。BIOS_IDENT_DEBUG 付けたら、 CPU identify までは来てるんだけど、そのあとうんともすんとも言わん。 .options DEBUG 付けると mips/pmax.c でワーニング吐かれて コンパイル失敗するな。 .やっぱり BIOS_IDENT_DEBUG の PROD ID とかの表示は出るけど、 それ以降表示が出ないな。よくわからんな。 .仕事しろ>オレ |
.運転中の携帯電話ネタ。 この記事 は just in time で読んだけど、 「ふーん、結構割合としては少ないんだね」 という印象は受けたな。まあアメリカだしな。 ただなんというか論調が、駐車違反で捕まった奴が、 「オレの車ばっかりつかまえて、なんで向こうの車はつかまえないんだ」 とか逆切れしてるような感じでみっともない。 .個人的には、全体の 1.5% も占めてる事故の幾許かが、 こんな楽な対策で減るんなら、費用対効果という点ではいいと思うぞ。 「臭い物にフタ対策」は、時として本質的問題をマスクしてしまうので 一般的には嫌われるべきなんだけど、 「携帯電話が原因の事故が 1.5% 存在する」というのは いいかえれば「1.5% の事故は携帯電話が本質的原因」なので、 その 1.5% を防ぐために携帯電話を禁止するのは合理的だと思う。 「携帯電話禁止論」に対する「なんで他の原因は放っておくの?」という 反対意見は、半分は論点のすり替えだから反駁の意味を成してないといえるし、 半分は「費用対効果を考えればリーズナブルでしょ?」っていう 反々駁で打ち消される程度の論拠でしかないな。 まさしく「駐車違反者猛々しい」理論と変わらん。 一方で、「それで満足しちゃいけない」という風に言うのは正論だけどね。 安全は結局、地道な作業でしか達成されないんですな。 .セキュリティ対策も似たようなところがあって、 「とりあえず片っ端からデーモンを止める」はとっかかりとしては 非常に有効なんだね。 そのかわり、利便性が失われるのは覚悟しないといけないけど。 多くの場合、安全性と利便性は両立しないというだけの話で。 あるいは、「素の telnet でなくて skey 使う」とかは 「路肩に止めてから通話する」に通じるな。 ちょっとだけ面倒くさくなるけど安全にはなる。 もちろん、「デーモン止めただけで満足してちゃいけない」 というのもよく似てるな。 セキュリティも地道な作業でしか達成されないし、 ssh みたいな「rsh の利便性を残しつつ安全性も確保できる」っていうような 革命的なものは、なかなか現れないね。 .直感的に言って、 「何らかのボタン操作をしながら運転をするのが危険だ」 というのは正しいと思う。 「直感は大切にするべきだ。ただ、検証を忘れちゃいけない」 っていうワインバーグ流の問題解決理論で言えば、 あとはそれを検証するだけだと思うし、実際検証が足りてないとも思う。 もう一つ直感的に感じるのは、 「1.5% という数字は、実はとんでもなく大きい数字なんじゃないか」 ってことだな。 さらにもう一つ、 「ある事故原因が単独で満たされてる時に n% (ただし、n << 100%)の 確率で事故が起こったとすると、 このような原因が二つ重なったときに事故になる確率は 2n% ではなくて もっと大きくなる」というのも直感的に正しそうだな。 従って、どんな小さなことでも、それが取っ払えるのなら なるべく事故原因を取っ払っていくべきだ、というのも直感的に正しそうだ。 全部検証が伴ってないけど、思考実験した限りでは、どれも正しそう。 .まあ、人間ってのは私も含めてバカなので、 直感的にわかりにくいリスクを法律って形で別のリスクとして明文化するのは 時として必要だと思うぞ。 特に、運転みたいな半ば思考停止状態でやるようなことではね。 「携帯電話をかけながら運転すると(自分を含めた)誰かが死ぬ」 とはなかなか考えない(でも確実に存在するリスクだ)けど、 「携帯電話かけながら運転してるのがバレると罰金取られてポイントが増える」 は非常にわかりやすいリスクだからな。 .いやいや 。 むしろ、そういう 1 か 0 か、みたいな話に落としちゃうと 元記事の術中にハマってると思います。 セキュリティの喩えでいえば、たとえば、 「ネットワークにつながなければいい」ってところまで 落としちゃうようなもんで。 この観点だと、本質的解決は「車を運転すること自体違法」でしかない。 1/0 でやってるといつまでたっても進まないから、 できるところからやろうね、という現実的な話。 ちゃんと、「それだけで安心してたらアホ」という旨のことは 上で書いてますな。 .まあ、こういうことをやりやすいんだね、携帯電話ってのは。 ことあるごとに携帯電話ってのは目の敵にされるから、 駐車違反者の理論に陥る気持ちもわからんでもない。 世の中、その程度には不公平なもんだと思う。 「rsh は塞げるけど telnet は塞げない。本当は両方塞ぎたいんだけど…」 なんて事情は世の中どこにでもある。 まあ、携帯電話が目の敵にされるのは、たとえば、 「telnet 塞げない理由は、一人だけ ssh 使えない人がいて、 その人ってのが他でもない、 この会社のワンマン社長だったりするからなんだけどね (←これ実話(笑)。もちろん A 社ではないけど)」 っていうような理不尽さにも近いものがあるんだけど。 でもいずれにしろ、それは rsh を塞がないでいい理由にはならんよね。 いつかは telnet も塞ぐか、あるいは安全に telnet できるようにするか、 のどっちかが必要なのも事実で、携帯電話の場合「それだけで安心してたらアホ」 のアホ状態に陥る可能性が高い気はするけど。 |