タグ別アーカイブ: 本の虫

本の虫: プログラミングを学ぶ方法がわからない

そもそも、広告とは、本来必要のないものである。ドワンゴが優秀なエンジニアを求人しているのは、いまさら言うまでもない。ドワンゴに限らず、まともな企業ならば、優秀なエンジニアは常時喉から手が出るほど欲しいに決まっている。広告など、いまさら行うまでもないのだ。

そして、広告というのは、極めて邪魔なものである。もし広告が邪魔だと感じられてしまうようであれば、それは広告としての機能を果たしていない。むしろ逆効果である。即座にadblockのフィルター行きになることは確実である。特に、優秀なエンジニアであれば、adblockは当然使っているであろうから、なおさらだ。現に筆者は、自分のブログの広告をadblockで消している(ドワンゴ広告は消していない)。読者も当然消すべきである。

そのため、筆者は、消さずとも許容できる広告を書くことにした。許容できるとはいったいどういうことか。他ならぬ筆者がadblockで消すほど邪魔でもないと感じるのであれば、あるいは、読者も許容できるかも知れない。

矛盾するようだが、筆者にとって許容できる広告は、adblockで消せる広告である。広告は広告であるとマークアップで意味付けするべきである、もし、広告がCSSセレクターで指定しにくいマークアップであれば、許容できない。そのような広告を使うWebページ自体が許容できない。

したがって、このドワンゴ広告は、adblockのようなユーザー指定のCSSで消しやすいマークアップをしている。

これにより、広告が邪魔だと感じられるようであれば、即座に消されてしまうわけだ。広告が邪魔だと感じられないような努力を強いられる。

もし、読者がこのドワンゴ広告を邪魔だと感じているが、消す方法が分からず、消し方を調べようともしない場合、残念ながら、読者は本物のエンジニアではないと言わざるを得ない。

ドワンゴは本物のエンジニアを募集しています。

引用元: 本の虫: プログラミングを学ぶ方法がわからない.

本の虫: 表計算をマジなことに使わないほうがいいよ(マジで)

だいたい、表計算というものは手早いやっつけ仕事には向いているものの、真面目で重要な作業には向いていないのだ。

まともなソフトウェアには詳細なテストが付随するべきである。テストなしで、どうして自分の書いた機能が、自分が意図する通り正しく動作すると言えるのだ? 表計算は、テストをサポートしていない

表計算は、コードレビューを困難にする。コードは何十、何百もの小さなセルの中に散らばっている。コードを自分で注意深く検証できず、また他人による検証も難しい状況で、どうして信頼できようか?

表計算はコピペプログラミングとやっつけ仕事を自然と行わせてしまう。コードの検証、テスト、保守を難しくする。

引用元: 本の虫: 表計算をマジなことに使わないほうがいいよ(マジで).

本の虫: Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子

syscallトラップのパフォーマンスは興味深いものだ。

15年前[訳注:この記事が書かれたのは2004年なので、1989年頃]、IntelとMicrosoftと会議があった(残念ながら、私はこの会議に参加していなかったので、この話は伝聞なのだが)

Microsoftというのは、Intelの最大の顧客のひとつなので、Intelの代表はよくMicrosoftを訪問して、最新のプロセッサーを紹介したり、カーネル開発部に新しいプロセッサーの機能をサポートするようロビーしたり、どのような機能を追加すれば、もっとも役立つかという知見を吸い上げたりしていた。

この会議で、Intelの代表がたずねた。「でさ、たったひとつだけ、速くして欲しいところがあるとすれば、どこ?」

躊躇なく、カーネルの開発主任が答えた。「無効命令のfaultingの高速化」

Intel社員は笑い転げた。「いやぁ、Microsoftのエンジニアは愉快でいらっしゃる」というわけで、会議は冗談で締めくくられた。

研究所に戻った後、IntelのエンジニアがWindowsカーネルのプロファイルをしたところ、驚くなかれ、彼らはWindowsがかなりの時間を、無効命令例外をさばくためにつかっていることを発見したのである。何だと! ひょっとして、Microsoftのエンジニアは冗談を言ったのではなかったのか?

冗談じゃない。

この当時の80386チップで、V86モードからカーネルモードに移行する最速の方法は、無効命令を実行することだったのだ! そのため、Windows/386は、無効命令をsyscall trapに使っていたのであった。

この話の教訓? よくわからない。たぶん、何か物を作ったならば、それが作成者の意図しない方法で使われるだろうということか。

引用元: 本の虫: Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子.

本の虫: なぜTheo de RaadtはIETFに激怒しているのか

ではなぜTCP keep-aliveではだめなのか。たいていのOSでTCP keep-alive間隔があまりに長時間に設定されているためか。それなら必要であると感じるものだけがOSの設定を変えれば良い話だ。なぜわざわざ同等機能の規格を重複して作るのか。そもそも、大多数の一般人にとって必要なのは、もっと上のアプリケーション層でのKeep-alive実装ではないのか。

このHeartbeatという機能は、基本的に誰からも必要とされておらず、事実、さっくりと無効にしても誰も困らない機能である。だからOpenBSDでもさっくりと無効にした。なぜそんな誰からも必要とされていない無用の機能を規格化するのか。規格化された以上、規格準拠のソフトウェアは実装しなければならない。新しく実装した機能には不具合が含まれる可能性が高い。誰からも使われない機能は、不具合が発見されにくい。無駄な機能を規格化するとは、いったいIETFは何をしているのか。

引用元: 本の虫: なぜTheo de RaadtはIETFに激怒しているのか.

本の虫: Multipath TCPについて

問題は、SCTPのその他の利点は、とてもニッチな分野でしか需要がない。古い歴史を持つTCPには様々な問題があるとはいえ、既存のTCPからの移行コストを支払ってまで置き換えるほどの利点ではない。

それに、既存のほとんどのルーターが、SCTPパケットを、単に破棄してしまう。卵と鶏の問題と同じで、SCTPの利用者がいないので、ルーターベンダーはSCTPをサポートしない。ルーターがSCTPをサポートしていないので、開発者はSCTPを使えない。

引用元: 本の虫: Multipath TCPについて.

本の虫: Multipath TCPについて

今日のインターネットは、当初のインターネットとは大きく違う。経路上に、実に多数の、中間箱(middlebox)が存在する。ルーターやスイッチだけではなく、ファイヤーウォールやらNATやらロードバランサーやらDeep Packet Inspectionやらだ。多くの中間箱が、TCPパケットを書き換える。

そもそも、モダンなNICは、効率化のために、勝手にTCPパケットを分割する。この際、TCPヘッダーは、単にコピーされてしまう。そのため、MTCPがTCPヘッダー内で予約して使うデータシーケンス番号が、コピーされてしまう。

MTCPシーケンス番号のコピーは、従来のTCPシーケンス番号の範囲のマッピングにより対処した・・・つもりであった。しかし、これでも問題があった。なんと、多くのルーターが、シーケンス番号を書き換えているのだ。背景には、最初のシーケンス番号をランダムに開始しない脆弱性ある実装に対処するため、ルーター側でシーケンス番号を振り直すということが、広く行われているようなのだ。このため、マッピングを絶対的ではなく、相対的にすることで、対処した。

さらに、active FTPなど、複数のTCPコネクションを貼り、ASCIIでIPアドレスをエンコードするような特定のプロトコルに対し、中身を書き換える(すなわち長さも変わる)などの改変を行うルーターすら存在する。

Linuxカーネルに実装されたMTCPでは、チェックサムを使うことで、データの改変を検知し、従来のTCPにフォールバックする実装になっている。

研究者がインターネット上の中間箱(middlebox)について調査を行ったところ、どうやら今日のインターネットでは、TCPパケットのあらゆる部分は、中間箱により改変される可能性があるということが判明した。これは、将来のTCP拡張を設計する上で考慮に入れなければならないことである。TCPヘッダーの中身のあらゆる箇所は、改変されないという保証がないのだ。

引用元: 本の虫: Multipath TCPについて.

本の虫: OpenSSLはサルによって書かれた

むかし、OpenSSLのメモリ確保で、バグがあったら意図的にクラッシュさせるチェック用のコードを仕込んでおいたが、メモリ確保が何重にもレイヤー化されるにしたがって、そのチェック用のコードは何の意味もなくなってしまった。しかし、誰もそのチェク用のコードを無効にしてテストしていないので、その無駄なコードが残っているというお話。コモンズの悲劇にも似ているが、あまりにも公共すぎるソフトウェアは、誰からも関心を払われないということか。

引用元: 本の虫: OpenSSLはサルによって書かれた.

本の虫: アニメにおけるセルシェーディングの利用について

アニメは完全にセルシェーディングにして、ビルドして映像生成という形にすべきではないのか。すなわち、ソフトウェアだ。ソフトウェアである以上、自由ソフトウェアにすべきだ。そうすれば、稚拙な3Dメッシュが直されたり、シェーダーが改良されたりするのではないか。

いい加減に人の手で努力しただけのものを評価するのは、やめようではないか。もはや、写実画は写真に負けている。人間がまだ優位に立てると安心しているデフォルメの世界だって、例えばアニメ塗りのようなものは、セルシェーディングで近似できる。セルシェーディング技法は今後もますます発展することに疑いはなく、人間の優位性はいよいよ危うい。

将来は、ピカソのような絵や、デフォルメ化された3Dメッシュなども、自動的に生成できるようになるだろう。

私の観測できる範囲では、プログラマーとアニメの親和性は高い。私はアニメが好きではないから、これは不思議なことだ。私には、なぜ彼らがアニメを尊ぶのか、理解できない。現行のアニメが、単に人の手による単純作業で作られている。アニメ制作者が安く買い叩かれているのは、やはり、ある程度の画力があれば、代わりはいくらでもいるような単純作業だからだろう。

変えようではないか。現状を。アニメは技術者が作ればいいのだ。作画は3Dメッシュに取って代わられる。塗りはセルシェーディングに取って変わられる。高品質な3Dメッシュを作成するのは困難だが、一度作成してしまえば、後はアニメーションを作ればどのようなシーンもアニメーションできる。破綻しない自然な塗りをシェーダー言語で記述するのは困難だが、一度書いてしまえば、後はどのようなシーンでもレンダリングできる。

怠惰は美徳である。機械的な作業は機械に任せようではないか。もし、ある手動作業が自動化できるとするならば、我々はむしろ自動化するための準備に労力を注ぐべきなのだ。そうすれば、後は全て自動化される。我々人間は、機械を作るべきなのだ。その身を機械におとしめてはならない。

なるほど、私がアニメを好まない理由が、今にしてわかった。アニメは手動の単純作業だから感動しないのだ。そして、その映像の描画方法、すなわちソースコードが公開されていないから嫌悪するのだ。ああ、残念ながら、この考え方はあまりにも先進的すぎる。おそらく、数百年は理解されないことだろう。

ただし、2013年にこのような考えを持つ進んだ一個の人間がいたということは、ここに記しておく。

本の虫: アニメにおけるセルシェーディングの利用について.

本の虫: xkcd: 暗号的、パスワード再利用

先日、Adobeのユーザー登録情報が大規模に流出する事件があった。流出したのは、xkcdでも言及しているように、AdobeユーザーのEメールアドレスと、暗号化されたパスワードと、パスワードのヒントだ。この暗号化されたパスワードというのがクセモノだ。

モダンな暗号は、ブロックと呼ばれる決められたビット数単位で行われる。DESのブロック長は64bitである。もし、ブロックごとに独立して暗号化した場合、同じ値のブロックは、同じように暗号化されてしまう。

これを防ぐために、ブロック単位をまたぐような長い平文を暗号化する際は、次のブロックの暗号化は、前のブロックの結果に依存するようにするものだ。このブロック単位の暗号化の際に、どのように暗号化するかというのを、「モード」という。詳しくは、Wikipediaのブロック暗号モードを参照。

Block cipher mode of operation – Wikipedia, the free encyclopedia

パスワードという短い単位と、ブロック暗号モードの不適切な適用により、流出した暗号化されたパスワードは、同じパスワードが同じ暗号文になってしまっている。同じ暗号パスワードに設定されたヒントをかき集めれば、推測が容易になる。

これは、史上最大のクロスワードパズルと言える。

引用元: 本の虫: xkcd: 暗号的、パスワード再利用.

本の虫: 完全に秘密を守るコンピューターシステムを求めて

プリンターは、一切信用してはならない。現状では、プリンターを所有するのは危険だ。なぜか。ほぼすべての現行のプリンターは、印刷に秘密のドットパターンをすりこませている。このドットパターンは、肉眼では確認できないほど微小だが、プリンターの固有番号や印刷日時といった情報をエンコードできるほどの情報量を持っている。したがって、プリンターとは、印刷物から、プリンターの個体が特定され、身元特定にもつながるハードウェアであり、セキュリティ上の脅威だ。また、プリンターのドライバーには不自由なバイナリブロブを必要とするものが多いのも危険だ。

引用元: 本の虫: 完全に秘密を守るコンピューターシステムを求めて.