不幸にして、あるいは私の誤った予想に惑わされて「学園お嬢様奇譚」を入手してしまった読者諸氏のために、簡単な攻略法を記しておく。
まず、キャラの出現表は以下のとおり。
| 日 | キャンパス | 図書室 | 食堂 | 職員室 | 鈴の教室 | 圭子の教室 | 美和の教室 | 御門邸 |
| 2 | 真美子 | 空振り | 美和 | 彩 | 空振り | 圭子 | 空振り | |
| 3 | 美和 | 圭子 | 彩 | 菜美 | 空振り | 空振り | 空振り | |
| 4 | 菜美 | 圭子 | 美和 | 真美子 | 空振り | 空振り | 空振り | |
| 5 | 美和 | 真美子 | 空振り | 彩 | 空振り | 圭子 | 空振り | |
| 6 | 空振り | 真美子 | 美和 | 彩 | 鈴 | 圭子 | 空振り | |
| 7 | 空振り | 空振り | 空振り | 彩 | 空振り | 圭子 | 空振り | |
| 8 | 真美子* | 圭子 | 美和 | 彩 | 鈴 | 菜美 | 空振り | |
| 9 | 真美子 | 空振り | 彩 | 空振り | 空振り | 圭子 | 美和 | |
| 10 | 菜美 | 圭子 | 美和* | 空振り | 鈴 | 空振り | 空振り | |
| 11 | 菜美 | 圭子 | 真美子 | 美和 | 空振り | 菜緒 | 彩 | |
| 12 | 真美子 | 彩 | 美和 | 空振り | 菜美 | 圭子 | 空振り | |
| 13 | 真美子* | 空振り | 空振り | 彩 | 鈴 | 圭子 | 空振り | |
| 14 | 菜美 | 美和 | 空振り | 彩 | 空振り | 空振り | 空振り | |
| 15 | 美和 | 圭子* | 菜美/真美子 | 空振り | 鈴 | 彩 | 美和 | |
| 16 | 空振り | 真美子 | 彩 | 菜緒 | 鈴 | 圭子 | 美和 | |
| 17 | 空振り | 菜美 | 空振り | 空振り | 空振り | 圭子* | 美和 | |
| 18 | 菜美* | 彩 | 美和 | 圭子 | 鈴 | 空振り | 菜緒 | |
| 19 | 空振り | 彩 | 鈴 | 空振り | 菜美 | 圭子 | 美和 | |
| 20 | 真美子* | 美和 | 鈴 | 圭子 | 久美子 | 空振り | 彩 | 信也* |
| 21 | 美和 | 空振り | 空振り | 彩* | 菜美/久美子 | 圭子 | 空振り | |
| 22 | 空振り | 圭子 | 真美子 | 彩 | 鈴 | 空振り | 美和 | |
| 23 | 菜美* | 彩 | 美和 | 真美子 | 鈴 | 圭子 | 空振り | |
| 24 | 真美子 | 空振り | 圭子 | 久美子 | 鈴 | 空振り | 彩 | |
| 25 | 真美子 | 美和 | 鈴 | 彩 | 久美子 | 圭子 | 空振り | |
| 26 | 久美子 | 菜美 | 空振り | 圭子 | 鈴/久美子 | 空振り | 美和 | |
| 27 | 菜美 | 真美子 | 久美子 | 彩 | 鈴 | 圭子 | 美和 | |
| 28 | 久美子* | 空振り | 空振り | 彩 | 空振り | 空振り | 空振り | |
| 29 | 鈴 | 真美子 | 彩 | 空振り | 菜美 | 圭子 | 美和 |
アスタリスク付きはイベントを意味するが、パラメータ・フラグ・場所・曜日（日曜日イベントの場合）が揃ったときに起動するイベントなので、あまり意味がない。
パラメータについて。説明書にあるとおり、基本的には各務のテクニックを上げればいい。ただし、彩と鈴の攻略には陰陽術が要る。久美子の救出にも要るような気配がある。
修行のとき、スロットで思いどおりの値を出すには、PrintScreenキーを使う。スロットが回っているときにPrintScreenキーを押すと、0.5秒ほど画面が止まる。この瞬間にクリックすると、スロットはその値を出す。
ギャル理論研究のため、阿智太郎の「僕の血を吸わないで」を読んだ。
「なにを書くかじゃありません、どう書くかなんです」というのは戦前から言われていることらしいが、現在においても（少なくとも電撃文庫のギャル小説では）事実であるらしい。
私は目的―目標モデル（たとえば、「百合の普及発展」は目的、「コミケのジャンルコード」は目標）や戦略―戦術モデル（「百合の思想・技術を流布する」は戦略、「日記を書いて全文検索でトラップする」は戦術）が好きなので、「なにを書くかじゃありません、どう書くかなんです」には抵抗がある。うーむ。
「学園お嬢様奇譚」には、真美子×沙絵はないらしい。シーズウェアにアナテマ。
表現したい状況にぴったりの言葉が見つかると嬉しい。逆に、言葉にぴったりの状況が見つかるのも嬉しい。言葉と状況がぴったりと噛み合っているさまを見るのは、プログラミング的な喜びがある。
「学園お嬢様奇譚」は、この種の喜びを私に与えてくれた。噛み合っている言葉とはもちろん、「箸にも棒にもかからない」だ。
企画責任者はいったいなにを考えていたのだろう――ああ、なにを考えていたのかね君は？ 君はウテナを見たのかね？ あの最終回、一秒一秒が宝石のように輝きながら惜しげなく流れてゆくのを感じなかったのかね？ 体を震わせながら劇場のスクリーンを狂ったように凝視しなかったのかね？ 私はどうしても、君がそうしたとは信じられないのだがね？
女同士物への理解ときたら、80年代からやってきたのかと思うような程度の低さだ。ウテナを見たあとでどうしてここまで程度の低い理解にとどまっていられるのか、正気を疑う。
今はまだこのくらいにしておこう。なにしろ私はまだすべてのイベントを見たわけではない。もし真美子×沙絵があるなら、猶予の余地もあるだろう。もしなかった場合、シーズウェアにアナテマを発する。
L作戦。
ブートローダを書き換えないかぎり、HalfDisk
0.2でもシステムパーティションにはインストールできないという結論に達した。どうせ大した手間でもないので、書き換えてもいいものの、面倒くさいので後回しにする。それにリバースエンジニアリングと書き換えとなれば、法的にかなり真っ黒だ。IFS
kitでブートローダを公開してくれないものか。
コミティアは眠かった。きゅう。
L作戦。
HalfDisk 0.2の課題をメモしておく。
・不良クラスタをマークする方法
直接ディスク上のFATを書き換えると、ファイルシステムが持っているキャッシュと整合性が取れなくなる。
・最終マウント時刻・アンマウント時刻・マウント回数など、マウント履歴に関する情報の有無と所在
もしこの情報がないとなると、HalfDisk 0.2の構想が危うくなる。HalfDiskドライバが入っていないシステムからでもHalfDisk化されたパーティションにアクセスできるので、たとえばWindows98とのデュアルブートでWindows98から書き込まれると、二重化された部分の整合性が失われ、しかもそれを検出することができない（二重化された部分の全部をチェックする――とてつもなく時間がかかる――以外は）。
・ドライバのセキュリティ問題
現在のHalfDiskドライバは、ioctlからセクタ指定で書き込みができるので、セキュリティがまったくない。インストール時用のドライバと運転時用のドライバを別に作らなければ。
ベンチマークソフトを作っている最中に、重大な事実に気づいた。システムファイルのあるパーティションを測定する場合、再起動する必要があるのだ。
本当にHDDの性能を知りたい向きにとってはたいした面倒ではないものの、ベンチマーカーにとっては致命的なデメリットかもしれない。簡易測定としてファイルシステムの上からI/O
per secondを測定するモードと、精密測定としてドライバをインストールするモードの二つに分けるべきか。
急告：
明日27日のコミティアで初売り予定の「小春日和情報」は、諸事情により6部のみとなっている。必ず当日に入手したいと望む諸氏は、適切に行動されるようお勧めする。
また、解説の「ギャル理論からみた『小春日和情報』」はできあがっていない。あしからず。
なお、当日はスペースで通販の申し込みを受け付ける。通販では「ギャル理論からみた『小春日和情報』」が無料でついてくるので、ギャル理論に興味のある諸氏にはこちらをお勧めする。
シーズウェアの「学園お嬢様奇譚」を手に入れた。
パッケージを開け、説明書の裏表紙とDVD-ROMの印刷を見た瞬間にまず左フックがヒット。そうか、君はそんなにウテナが好きか。私も好きだ。
ゲーム開始。
やべえ… やべえよアニキ… 薔薇が回ってるよ… でも世界観はちっともウテナじゃないよ… 一発ギャグに6000円も払ったわけじゃないよ僕は… きゅう。
デジタル・ジャコバンの諸君、おはよう。NECのSmart
Vision Pro for USBはもう買ったかい？ あいにく私はまだなんだよ… 金がなくてね。
あれは早く手に入れて、解析しなければいけないね。コマンドを調べて、オリジナルのソフトから使えるようにしなければ。ドライバの下を解析したほうがいいな… このご時世に、Windows2000で使えないというのは、ちょっと臭いよ。もしかしたら、出す気がないのかもしれない。そうしたら、我々の手で作るしかないだろう？ …この程度のことで、ひるんじゃいけないよ。なにしろ我々は革命家なんだからね。
エンコードのレイテンシはどのくらいなんだろうな。ずいぶん反応速度の遅い機械らしいから、0.5秒くらいはあるのかもね。まあ、1分も2分も遅れるわけじゃないだろうから、かまわないさ。録画データのなかの特定のフレームを指定する方法は、なにも時計ばかりじゃない。
たとえば、そう… 画面の輝度を縦軸、時間を横軸にしたグラフを考えてみよう。これは固有の――uniqueという意味のね――形になる。この形を、いわば鍵に使える。鍵穴は録画データだ。
鍵を鍵穴に入れて、前後にゆっくり動かしてやる――すると、どこかで錠前が回る。鍵と鍵穴の位置がぴったり合った地点でね。こうして、インデックスの原点が決められる。インデックスの原点が決まれば、原点から数えたフレーム数を使って、特定のフレームを指定できる。…ほら、簡単だろう？
鍵のデータ量は、1フレーム1バイトもあればいい。1分間を使うとして、4KBほどだね。48kbpsでダウンロードすれば、1秒もかかりゃしない。
民放は一日にいくつの番組を放送するんだろう？ 100くらいかな？ チャンネル数は6として、全部で600番組あるわけだ。たった10分間のダウンロードで、一日分の鍵が全部手に入るわけさ。もちろん、普通は全部なんて要りやしないね。
鍵を手に入れてどうするかって？ やだなあ、決まってるじゃないか…（くすくす） CMをカットするんだよ。フレーム単位でね。
…え？ 誰がその鍵とCMカット情報を作るのかって？ 簡単なことさ。どこかの誰かが、だよ。これからは、MP3をエンコードするかわりにCMをカット！ ってわけさ。
ちょっとばかりジャコバン的で人のためになる、ほんのついでの1分間のクリック、クリック、クリック。MP3がこんなに流行らなかったら、誰も信じなかっただろうね。人間がまだ、こんなにも親切だなんて。――もちろん、くだらないバラエティ番組のCMカットなんか、誰もやりゃしないさ。でも、誰が困る？ CMのほうがまだ面白いような番組だっていうのに。
ああ… 自分に必要なCMカット情報を手に入れるには、どうすればいいかって？
ねえ君、これは違法行為だと思う？ そうだね――鍵が放送局の著作物として認められて、鍵の配布が違法にされるかもしれない。ゲームソフトが映画として認められるこのご時世なら、なんだってありうる。
きっとそのうち、本にはみんなパラパラマンガ――アンシーがノートの端に描いてたあれだよ――がつくようになって、本はみんな映画になるのさ。なにしろ出版社はBOOK
OFFが憎いからね。映画と認められるには映写機を使うシステムでなきゃいけないらしいから、パラパラマンガ上映機を作るんだろうね。それとも、高密度バーコードに動画を記録するのかな？
君はそんな馬鹿騒ぎにつきあうの？ まさかね。君は栄えあるデジタル・ジャコバン、魂の底からの革命家だ。CMカット情報を交換するサイトを立てるのを、ためらいやしないだろう？ 固定サイトならDoS攻撃で潰されるかもしれないけど――Gnutellaみたいに、固定した中央サイトを設けないって手もあるんだ。
嫌がらせに、偽のCMカット情報を流す奴がいるかもしれない。そこでまた君たちの出番だ。偽情報の報告が出たら、君たちがチェックして削除するのさ。削除システムは公開鍵暗号で守ればいい。CMカット情報そのものにもPGP署名が欲しいね。実績のある署名のついた情報を優先的に使うようにすれば、嫌がらせの入り込む隙もないってわけさ。
このシステムの肝心なところは、どこまで簡単にできるか、だね。予約録画システムだから常駐するのが当然だっていうのは、なかなか助かるよ。ダイヤルアップ接続したとき、自動的にCMカット情報を探しにいくようにできる。自分でCMカット情報を作るのも、ごく簡単な作業でなきゃいけない。カットの前後のフレームを並べて表示するくらいは当然だね。放送開始から五分後に見始めて、CMにでくわしたらそのつどカット。それから軽くネットサーフィン――これで任務完了。
そうそう、Smart Vision Pro for USBでなくても使えるシステムにしておかないと。ちょっとドライバと定義ファイルを書くだけで、どんなハードにも対応できるようでなけりゃね。
どうだい諸君？ もう革命は目の前だよ。
L作戦。
I/O per secondの代表値の算出方法は、なにを使ってもうまくないような気がしてきた。というわけで、一定容量・均一分布でのI/O
per secondを使うことにした。容量は512MBあたりか。
HalfDiskは、書き込み時にデータの一貫性を保証するロック機構が必要だということに突然気がついた。というより、いままでなぜ気がつかなかったのか。ううう。
ロック機構そのものは、トラックグループごとにシステム予約セクタを設けておいて、書き込みの前後にフラグを立て倒しすればいい。パーティション全体にもフラグを設けて、起動時に立てて終了時に倒す。もし起動時にすでに立っていたら、全トラックグループのフラグをチェックしにゆく。
機構そのものは単純だ（ついていなかったら大変だが）。問題は、これで書き込みがまた遅くなるということだ。うーむ。
「小春日和情報」は100ページを越えている。ううう。
ギャル理論による解説も20ページを越えている。きゅう。
L作戦。
パーティション容量に依存しないシーク性能を、ベンチマーカーにもわかる単一の指標として示す方法を考えている。
とりあえず、IntelのIometerに倣って、I/O per secondを使うのがわかりやすい。I/O
per secondでもまだわかりにくければ、名前を「快適指数」とでもすれば、さすがのベンチマーカーにもわかるだろう。
問題は、シーク距離（これは「平均」だの「full
length」だのといった虚偽に満ちた値ではなく、容量をスケールとした距離であることを重ねて強調しておきたい）と重み付けである。いったい、シーク距離の分布をどう仮定すべきなのか。どうやって代表値を求めるのか。
・シーク性能が同じで、パーティション容量が違う場合：パーティション容量が大きいほうに有利
・シーク性能もパーティション容量も違う場合：よほどパーティション容量に差がある場合（少なくとも100倍以上）を除いて、シーク性能が優れるほうに有利
この二つの条件を満たす指標でなければならない。うーむ。
L作戦。
FAT32ではとりあえず（ファイルシステムの構造としては）バッドクラスタ率に制限がないことがわかった。というわけで、HalfDisk
0.2は、FAT32とのコンビネーションでいくことに大決定した。これならブートパーティションはおろか既存のパーティションにも導入可能である。対抗グループトラック方式でシーケンシャルリードも改善し、総合系ベンチマークのスコア改善を狙う。
オリジナルのベンチマークは、とりあえず既存のバグは取れたので、どんな値を示すかを考えている。
・コマンドオーバーヘッド（算出式は、（1KB
sequential read time）-｛（1KB sequential read time)-(512B
sequential read time)｝×2でいいのか？）
・track-to-trackとフルストロークのシークタイム（コマンドオーバーヘッドを入れるか外すか？）
・ヘッド数（ヘッドスイッチ時とシリンダスイッチ時のシークタイムの違いを利用して推定）
・スキュー
・シークタイムを、シーク距離（容量表記）を横軸に取ってグラフ表示。サンプリング周期と横軸の倍率は選択式
・HDDのキャッシュ容量
・最大転送レート（最外周と最内周）
・平均回転待ち時間・回転数
と、これくらいか。
この二つが完成したら、いよいよベンチマーカー（想定キャラ：パソコンを始めて3年目。シークタイムとシーク距離の関係などまるで知らない。Windows2000 RC2が出たときには真っ先にインストールしてベンチマークを取ってみた。PromiseのIDE RAIDカードでRAID 0を導入して、「体感はかわんねーなー、HDBENCHは速くなってんのになー」とつぶやいている今日このごろ）に動員をかけることになるだろう。
ちなみに、シーク距離（スケール：トラック本数）―シークタイムのグラフは、以下のような曲線になる。
縦軸の単位はマイクロセカンド、横軸は移動トラック数の対数である。グラフの凹凸は、まだシークタイム測定部の出来が悪いせいで生じている。
L作戦用のデュアルマシンの、システム用HDDが全壊した。ううう。
あのガタガタという音の禍々しさときたら、まるで悪魔がはいずりまわっているかのようだ。
HalfDiskで影になる領域を隠す手法として、バッドクラスタにみせかけてCHKDSKをかけることを思いついた。これならブートドライブにもインストールできる。
問題は、NTFSやFAT32がどれだけの数のバッドクラスタに耐えられるかだ。容量の50%がバッドクラスタで占められているHDDを使うことなど、普通は想定しないだろう。
今月の「電撃大王」も百合だった。
どうやら「電撃大王」は本当に百合でゆくのかもしれない。ためらうことなくアキオカーのように突っ走ってほしい。
コミティアでの新刊に向けて、「小春日和情報」のギャル理論的解説を書いている。すでに90%ほど書いた。
頒価は100円を予定している。乞うご期待。
L作戦用のデュアルマシンの、システム用HDDにもバッドクラスタが出てきた。まだシステムを直撃していないのでそのまま使っているが、近い将来に使用不能になるだろう。ううう。
HalfDiskの副産物、HDDのベンチマークソフトにとりかかった。
おかげで、HalfDiskのインストーラ（というかフォーマッタ）には、片手に余る数のバグがあることが判明した。よくまあこれで動いたものだと感心する。
ところでIntelのIometerによれば、現在のHalfDiskでも、5400rpmのHDD（IBM
DTTA 351010）、使用可能容量225MBのパーティションにおいて、I/Os
per second（read 100%）は120を超える。これは7200rpmのHDDでも出せない値だ。
そのうえ、シャルルの指摘していった対向トラックグループ方式がある。
私は勝利を確信した。
山田南平の「紅茶王子」11巻を読んだ。
たまらねえ、たまらねえぜアニキ…！ ハンパじゃねえよ、この百合！
山田南平といえば少女まんがにおける百合テイストの第一人者だが、今回、百合テイストから百合そのものへと前進している。まさに目からビーム、必読といえよう。
11時間ほど寝たら、脳内にシャルル（藤本ひとみのマリナシリーズ）が降臨して、HalfDiskを改良していった。
トラックを円で描くと場所ふさぎなので位相で示すと、トラック一本は下図のとおりである。
トラックが複数並んでいるところを下図に示す。トラック先頭・終端はスキューのため位相がずれる。
位相はどんどんずれてゆくので、そのうち一回りする。
水色のトラック6本でちょうど一回りになっている。現実にはぴったり360°になることはありえないが、HalfDiskは位相がぴったり合っていなくても問題ない。
さて、この水色のトラック6本を前半と後半に分けると、位相が180°ずれたペアができる。aとa'、bとb'、cとc'がそれぞれ、位相が180°ずれたペアである。
このペアを、二重対向トラックのペアにする。最大でトラック3本を連続して読み出せるので、トラック先頭・終端をまたぐことによるコマンドの煩雑さや、容量とスループットの損失が避けられる。
だがcの終端から先へと延びるファイルがあった場合、黄色のトラックを読みにゆけば、半回転以上もの回転待ち時間が生じるのではないか？ もちろんシャルルに抜かりのあろうはずもない。
おわかりだろうか。
トラックcを読んだ次には、トラックdを読みにゆく。と、ちょうどスキューの分だけ位相がずれているので、回転待ちによる損失なしに読み出せるのだ。c'からd'へのつながりは言うまでもない。
かなり余裕を設けてあるとはいえ、track-to-trackのシークタイムを元に決定されているスキューが、トラック6本をまたぐときのシークタイムより小さくないという保証はあるのか？ もちろん、ない。そのような場合には、トラックd（およびd'）の先頭に不使用領域を設けて、スキュー量を増やす。
実測値から推測すると、最悪の場合でも不使用領域はトラック1本の30%以下である。よって全体としては、不使用領域は10%以下になる。トラック先頭・終端をまたぐことによる容量の損失は10%（実測値）なので、最悪の場合でも二重対向トラック方式より容量の損失が少ないことになる。現実には5%以下だろう。
というわけで、この方式（対向トラックグループと名づけた）は、現在の二重対向トラック方式よりもあらゆる面で優れている。
こんなうまい手があったというのに、二重対向トラック方式を実装してしまった。気分はモーリス氏。
言い忘れていたが、SDF作戦を終了した。ダメなすっとこどっこいになってしまったような気がする。うーむ。
L作戦用のメモを残しておく。
・パーティションに分かれる前（gendisk、/dev/?d?）でヘッド位置を把握し、読み込み先を決定することに大決定
・最初は猫をかぶって普通のgendiskとして行動、が、ioctl()でイニシャライズされて本性を現す
・HDD全体のジオメトリ情報、および、当該パーティションのトラック属性情報（未使用・二重対向・通常）は、グループディスクリプタとして各ブロックグループの先頭に配置
・ブロックアドレスは仮想化せず、アロケーションにより二重対向トラックの配置を行う
・ジオメトリ情報とトラック属性情報は、ファイルシステムのイニシャライズ時にgendiskに渡される
・二重対向と通常を相互に変換するツールを用意
・ディレクトリごとに、「常に二重対向」「常に通常」「ファイルサイズで変化」の情報を持たせる。/usr/binは「ファイルサイズで変化」、書き換え頻度の低いRDBのファイルは「常に二重対向」、読み込みに比して書き込みの頻度の高いファイルの置き場は「常に通常」。iノード番号のmodを使う？
・読み込みには手をつけず、ブロックのアロケーション時の配置で二重対向配置を実現
プリアロケーションのアルゴリズムは、
・最初は二重対向トラックにプリアロケート。アルゴリズムはext2と同じ
・実ファイルサイズが有効限界サイズ（回転待ち時間の短縮が無意味になるサイズ）を超えた時点で、通常トラックに再アロケートする。ページキャッシュ（残っていなければ読み込む）のオフセットを変更、フラグを起こして未書き込み状態にする。iノード情報の変更も忘れずに
二重対向トラックと通常トラックのアロケーションは、
・通常トラックの後ろに二重対向トラックをアロケートするときは、スキューが一回りか二回りして元に戻る（ヘッドスイッチのスキュー2ms、シリンダスイッチのスキュー2.6ms、ヘッド数6、回転数5400rpmなら、1回転11.1ms、(2.6+2×6)
mod 11.1=3.5msで7トラック――でも7は奇数なのでもう5トラック足して、(2.6×2+2×10)
mod 11.1=3ms、12トラック）数を連続的にアロケートする
・二重対向トラックのエリアを伸ばす場合は、シークタイムとスキューをあわせる
調査検討すべき事項は、
・ディスクI/Oのタスクキューを並べ替えて最適化しているかどうか、また、すべきかどうか
・先読みのアルゴリズム
・ファイルシステムとgendiskで、ジオメトリ情報とトラック属性情報を二重に保持するのを避ける方法があるかどうか。ジオメトリ情報はgendiskが、トラック属性情報はファイルシステムが保持すべき
・ソフトウェアRAIDをどう扱うべきか
・ディスク読み込みトランザクション速度（IOPSならぬIPS）と読み込みターンアラウンド時間が決定的要因になるベンチマークを探す
・デバイスのブロックサイズとファイルシステムのブロックサイズは異なる模様。ならファイルシステムのほうはクラスタサイズと言えである
ふふふ… このファイルシステムはデタラメに速いぜジョニー…
V-J Dayを記念して一言。
アフガニスタンはなぜまだ戦争を続けているのか。
1. 正義のため
2. 国のため
3. 成り行き上しかたなく
私の見解は3である。
今度のコミティアでの新刊「小春日和情報」の表紙のネタに困っている。
自分でちょっとラフ絵でも描いてお茶を濁そうかと思い、タブレットをいじってみたら、30分で絶望してやめた。絵を描く人というのはきっと、プログラマ以上に自分の不完全さに耐えられる人種なのだろう。とりあえず手と線を切り離すために、円を描く練習を1時間。ううう。
千号作戦を再開した。
我ながらキャラの行動のロジックに感嘆した。普仏戦争（プロシア側）のような読み切りと決め込みのロジック、キャラたちのクリークシュピール。もしかして僕は馬鹿なのかいジョニー…？
Linuxのファイルシステムをあらかた調べた。主な情報源はここだ。
当面わかったかぎりでは、
・当然ながら、マウント時のイニシャライズが必要
・ディスクブロック確保アルゴリズムを新規に作成（トラックレベルの確保とブロックレベルの確保がある）
・ということは、struct file_operationsのread、writeから下を全部実装
・inodeうんぬんは他のところに押し付けられる、またはソースを取ってこれる
判明した障害は、
・ブロックサイズが1KB（2セクタを1セットで処理する必要がある）
・ディスクI/Oが集中するときを避けるように遅延書き込みを工夫して負荷を分散するのが難しい
くらいか。
とりあえず決めるべきことは、
・読み込み先の決定を行うレベル（ファイルシステムでか、それともパーティションに分かれる前か）
パーティションに分かれる前だと、どうやってファイルシステム層と通信するかが問題になる。これが簡単に解けるかどうかだ。
例によって直前だが、夏コミにおいて百合的に注目すべきサークルを掲げておく。
| 東 | N | 15 | 竜の子太郎 |
| 東 | N | 17 | サリーガーデンズ |
| 東 | O | 39-44 | （百合その他の指定地帯） |
| 東 | W | 13 | レモナード |
| 東 | W | 14 | ALICE LIDDELL |
| 東 | Z | 28 | STUDIOホフーナ解放戦線 |
| 東 | Z | 45 | BERRIES |
| 西 | う | 26 | 兎茶屋 |
| 西 | こ | 24 | B5同盟 |
| 西 | ま | 22 | TEA PA. |
もっとも注目すべきは、へっぽこくんのサークル「STUDIOホフーナ解放戦線」である。もし読者諸氏がコミケに行くのなら、必ず訪れて買わなければならない。
女同士物との情報をかねて受けていた、「檻の中のわたし」というエロゲーを手に入れた。
かなり、相当、非常に目からビーム。とりあえず女同士物のエロゲーのなかでは、最大級にビーム。見る聞くないで即ゲット級である。
言い訳と性的妄想は似ている。
どちらも、黙っているうちは素晴らしいが、言葉にすると滑稽だ。酔っ払いの足取りよろしく、右へ左へふらふらさまよい、まっすぐに進もうとしない。
「檻の中のわたし」も、ふらふらとさまよう滑稽な作品である。妄想的な突拍子のなさと偉大な一般性が、いたるところでごっちゃにされ、右にいったかと思えば左、左にいったかと思えば右、そのたびにプレイヤーは苦笑させられる。
が、滑稽さと同時に、真実がある。それはきっと、右へ左へとさまようことなしにはたどりつけない――まっすぐに進んでいてはたどりつけないところにある。
帆船は、航路をジグザグに取ることで、風上へと進む。追い風を受けてまっすぐ進む船はいかにも速いが、風向きに恵まれたにすぎない。
設定や展開が笑えるのはともかくとして、セリフ（女性キャラはフルボイス）が笑えるのには困った。
熱演だし、クリティカルヒットも時々あるものの、たいていは、声優さんに申し訳ないと思いながらも笑ってしまう。セリフ自体が笑える場合もあるが、主にピーという音のせいだ。あれは、ソフ倫通過のために必要なのか、それともサービスのつもりなのか。
タロカンの攻防はいよいよ山場を迎えている。
タリバーンはタロカン北方で、タジキスタンに通じる街道を遮断した。マスード派にわずかに残された生命線のうち、もっとも太いものである。
タロカン攻略へ向けて圧力を強めるタリバーンに、マスード派は虎の子のスティンガーを投入し、戦闘爆撃機（旧式のミグ）を一機撃墜した。
私の記憶によれば、この4年ほどのあいだでマスード派がスティンガーを投入してきたのはこれが初めてである。旧式のミグは容易に補充できるが、スティンガーはそう簡単には手に入らない。本来なら巻き返しのときに使うべき兵器を、拠点防衛のために手放したのだから、マスード派の台所事情の苦しさはかなりのものらしい。
現在タリバーンはタロカン郊外に達し、マスード派と戦っている。以前にタロカンが陥落したときには数ヵ月後にマスード派が奪還したが、今回はスティンガーを手放してまでしがみついているわけだから、今度陥落すれば奪還は難しいだろう。
L作戦の次の目標（撤退先ともいう）はHDDのベンチマークソフト、その次はフリーUNIX用のファイルシステムとなっている。今のところネットニュースの反響がないので、ファイルシステムの設計を始めた。
調べてみると、FreeBSDよりLinuxのほうが作りやすいことがわかった。こういう小回りのきかせかたに、Linuxの優位（FreeBSD等に対して）の理由があるような気がする。しかしLinuxは2.4でキャッシュ関係を書き換えたばかりなので、それをさらにいじるのは面倒くさいような気もする。うーむ。
実際にパフォーマンスの出るものを作るには、I/O負荷の隙を使ったり、先読みのアルゴリズムを調整したりと、かなり複雑なことをやる必要があるので、作れるかどうかは難しいところである。ファイルシステムより下層にも手を加えることになるだろう。できれば避けて通りたい。ううう。
ペトログラード・ソヴィエトからの情報によれば、「檻の中のわたし」というエロゲーは、女同士物として注目すべきものであるという。情報を求む。
「はじめに地代（レント）があった。」
――アダムによる福音書
19世紀後半、ニューヨークの印刷業者ヘンリー・ジョージは経済学について思索をめぐらせ、「進歩と貧困」という本を書いた。この本は数百万部を売り上げた。ヘンリー・ジョージは1886年のニューヨーク市長選に立候補し、当選の一歩手前に達した。
ヘンリー・ジョージが見出した経済学上の真理を、経済学の用語で書くと、次のようになる。
「土地の純粋レントは、重税を課しても生産の刺激誘引または効率をゆがめることのないような「剰余」の性格を持っている。」
経済学に明るくない読者に、レントの意味を少し説明しよう。
都会の道路には、しばしばパーキングメーターが設置されている。誰も路上駐車しないような場所には、パーキングメーターは設置されない（まったくの無意味だ）ので、パーキングメーターがあるのは、路上駐車が多い場所である。
もしパーキングメーターがないとしたら、なにが起こるか。先にそこに駐車した人が、いつまでも駐車しつづけていて、なんの損もしない、という事態が生じる。あとから来た人は、前の人が車を動かさないせいで損失（時間やガソリンや肉体的苦痛）をこうむるが、前の人はなんの損もしない。ただ先にそこに来たというだけで、そんな特権を得るわけだ。
となれば、もしかすると、先に来ることが競争になるかもしれない。その競争に勝つために、誰かを使いにやるようになるかもしれない。
その使いの給料は、いったいどこから出てくるのか？ その使いは、いったいどんな生産をもたらすのか？ いったいどんな幸福（財・サービス）を社会にプラスするのか？
明らかに、この使いは、社会にプラスになる結果をなにひとつもたらさない。早起きして、車を目的地に駐車させにゆく、それはただの空回りだ。雇い主が得した分（駐車スペースのメリット－使いの給料）よりも多くの損失（駐車スペースを無駄に長時間占有されるデメリット）を、社会にもたらす空回りだ。
パーキングメーターは、このような空回りを軽減できる。時間制の料金という形で、「ただ先に来たというだけ」の人に、「あとから来た人」と同様の損失を与え、先に来た人の特権を奪い取るのである。
この仕組みにおけるパーキングメーター料金が、「レント」である。
社会にとっては、駐車スペースが無駄に長時間占有される事態を減らせればそれでいい。パーキングメーター料金を手に入れるのが誰であっても、この話の仕組みは変わらない。また、道路やパーキングメーターの持ち主が誰であっても、これまた話の仕組みは変わらない。
パーキングメーター料金の大半を税として徴収すべきだと考えたのが、ヘンリー・ジョージである。
（ただし、維持管理費のことを考えはじめると、話が複雑になる。
パーキングメーターの維持管理費がパーキングメーター料金から支払われるのは当然として、道路のほうはどうなのか。パーキングメーターが道路を使用するからという理由で負担を配分すべきなのか、それとも、パーキングメーターが渋滞を減らして道路の維持管理を楽にしているからという理由でパーキングメーターに助成金を出すべきなのか。そして、どれだけの額を負担する（受け取る）べきなのか。
この問題は、理論的には解決方法があるかもしれないが、その方法はおそらく技術的理由により実行不可能である。これが現実のパーキングメーター料金（レント）と、理論上の「純粋レント」の差だ）
もちろん19世紀後半には、パーキングメーターはなかった。
「路上駐車のスペース」のかわりに「農地」を。「パーキングメーター料金」のかわりに「地代」を。
地主の不労収入（地代）の多くを税として徴収しようというのが、ヘンリー・ジョージの掲げた政策だったのである。
誰がどれだけの金を手に入れるか。
社会の経済効率にとってプラスかマイナスか。
この二つの問題を、はっきりと区別して考えることから、すべてが始まる。
以下、次回に続く。
よう兄弟、こいつを見たかい…？
クックックックックッ… さかりのついた雌猫みたいに震えが止まらねえぜ…
とりあえずWindows2000だけ復旧した。が、動作がかなり怪しい。ううう。
「ディスクアレイテクノロジ RAID」なる本を読んだ。
同一シリンダ内でのトラックの切り替えには（少なくとも1年ほど前のIBM
DTTAでは）リード時で1.4msかかり、スキューは2msである（ちなみにシリンダをまたく場合はそれぞれ2msと2.6ms）。が、この本には、「数十マイクロ秒単位」で切り替わると書いてある。いったいどこから出てきたデータなのだろう。
やられた… やられたぜアニキ… HDDのクラッシュにな！
不良クラスタがシステムフォルダを直撃、現在も不良区域は拡大しつつある。きゅう。
コミティアのサークルカットに新刊予告（「小春日和情報」）をしてしまったので、そろそろ作らなくてはならない。
が、400枚もの量を印刷する手間を思うと、なんとも気が重い。うーむ。
「マール王国の人形姫」における最大の不満は、なんといっても王子様だ。へのへのもへじでもよさそうな、影の薄い王子様と結婚してめでたしめでたし、では納得するほうがおかしい。王子様に傾くかどうかを選択肢で選ばせ、傾かない場合はエトワールEDになるようにすれば、はるかに納得できる。
…と考えてみて気がついたが、もしかして「リトル・ウィッチ パルフェ」は、「マール王国～」への批判にもとづいて構想されたのかもしれない。
L作戦はようやく翻訳を完了、あとは図を作ってネットニュースに投稿するだけとなった。
おそらく私の人生において、金銭面でのこれ以上の機会は二度と訪れないだろう。さて、どうなるか。
「マール王国の人形姫」を終わらせた。後半のテンションにもう一押しが足りない節はあるものの、大傑作である。
セリフの隅々がきらりと光っている。私もこんな風にセリフを使いたい。
SDF作戦用に17世紀ヨーロッパを知るべく、I・ウォーラーステインの「近代世界システム
1600～1750」を読んでいる。
経済成長なき資本主義世界における搾取と収奪に萌え萌えである。貧乏人のプロレタリア化が進んでいるので、現代の読者になじみやすいのも17世紀ヨーロッパの利点だ。
マチダで「カサブランカ帝国」を手に入れた。
とりあえず森奈津子のだけを読んだ。いい根性をしているというか、なんというか。20世紀に置いていっていいかもしれない、と一瞬思った。実は、今でも思っている。