wget を複数動かしていた所為なのだろうか。
確かにダウンロードしてあるはずのファイルが沢山消えている。
まあ、確かに指定していたダウンロード先は生物扱いで、何時消えるか（消されるか）判らないし、実際消えても文句を言えないところなのだけど。
しかし、ホームディレクトリに直接ダウンロードするのは何時 quota が復活するかわからなくて怖いからなぁ。
やっぱり、夜中に sagami2 で wget を動かし、翌朝 mo に回収するという生活は無理があるのだろうか。
日中でも海外向けの ftp なら Proxy を通しても、通さなくても大して速度に影響は無いことだし、今後は mo に直接落とせる環境で wget を実行することにしよう。
どのみち、翌朝にならなければ現物を確認出来ないのだから。
昨日午後６時の時点でも 8hz-mp3 がアップされていなかったのは多分時差の関係なのだろう。
まあ、日本は比較的早く一日が始まる位置にあるから仕方が無い。
多分今日は入手できることだろう。
しかし、ネットから色々なものをダウンロードしていた所為で、そろそろノートパソコンの 2G ハードディスクもそろそろ限界がやってきそうだ。
残り空き容量が 200M を切ろうとしている。
まあ、ディスクの肥やし状態になっているいくつかの mp3 ファイルを消せば 50M 程度はすぐに開くのだが……。
そもそもノートをメインマシンにしている私の態度にも問題がある（でもそういう人は結構居るのだろうな）のだが……。
うーん、ノートの内蔵ディスクを 4G のものに換装すべきか、それともデスクトップ自作プロジェクトを始動すべきか……。
MO ドライブを買って、必要度の低いデータをそちらに追放するという手も無くは無いのだが……。
追記
どうも Windows95 OSR2 の QuickTime codec は腐っている（幾つかの mov ファイルの再生でハングアップする）ようなので、アップルの Web サイトから QucikTime を入手しようとしているのだが……。
どうして、ミラーサイトを用意したりしないのかね、連中は。
何も自前で用意しろとは言わないから、アーカイブを変更しない限りでの再配布を許可すれば、あちこちで勝手に ftp mirror されるだろうに。
さっきからどんどん転送速度が落ちていくうえに、予想残り時間が 43 sec のままちっとも変化しないところがますます腹立たしい。
sagami2 の /etc/passwd (実体は /etc/shadow?) が初期化された関係で折角変更していたデフォルトのシェルが csh に戻ってしまった場合、passwd -e では root ユーザー以外はシェルを変更できないので、chsh を使うこと。
昨日散々悩んだ挙句事務室に聞きにいった結果教えてもらったことである。
ただ、何度かすでに passwd -e とかを打ち込んでいる場合は、何故か chsh で shell を変えることが出来ないことがあるみたいなので、一度 logout してからもう一度入りなおすと今度は chsh が効くようになるようだ。
細かい原因は不明。
8hz-mp3 の Ver. 0.02b のソースを入手できたので、早速 make して、pub にインストールしてみた。
途中マクロ変数の PI が定義されていないというエラーに悩まされたが、"types.h" の中に #ifdef PI という部分があったので、そこに多少手を加えれば後は問題無くコンパイルできた。
今は暇を見つけてソースを読んでいるところだが、やはり mp3 の基本は fft だったのか。
確かに一つのフーリエ成分に必要なパラメーターは振幅と位相の遅れの二つだけだし、振幅は量子化 16 bit なら、16 bit 取っておけば充分だろうし、位相のほうはサンプリングレート 44.1 kHz なら……、こちらは基本周期をどれぐらいで取るかによるだろうけど、もし 0.01 sec で取るとしたら 8 bit で十分だろう。
とすると、128 kbit/sec でエンコードすると 54 個のフーリエ成分が取れることになるからかなり似た波形が出来あがる訳か。
なんだか人間の可聴範囲を無視してる議論だと自分でも思うけど、大筋は間違っていないと思う、が。まあ、この辺はうだうだ考えているよりも、ソースを読んだほうが一目瞭然なのだろうな。
追記
quota が復活し、気がついたら pub の使用量が 20M を超えていた。
慌てて調べてみたところ、何故か消し忘れていたらしい mp3 が pub/share にあったので消したのだが、それでももう 18M も使ってしまっている。
……とりあえず「茶筌」を名義変更することを考えよう。あと MHonArc もだ。
これで当座はしのげるはずなのだが……。
時間が無い。
つーよりも暇が無いと言うのかな、こういう場合は。
これが他人事なら、時間は作るものだよと訳知り顔で言いっぱなしておけば良いのだが、自分の事となるとそうもしていられない。
ああ、やりたいこともやらなければいけないことも山ほどあるはずなのに。
ToDo リストの中で片付いたものはほとんど無いと来ている。
やっぱり締め切りを設定されていない作業はどうしても後回しになってしまうから……。
とりあえず、だれか英文メールの手引きを教えてくれないものだろうか。
これは普通のビジネスメールなんかと同じように書けば良いものなのかなぁ。
やはり、mov ファイルが上手く再生できなかったのは Win95 OSR2 の QuickTime codec が腐っていたかららしい。
某 ftp サイトからダウンロードしてきた 40M の mov ファイルも QuickTime3.0の MoviePlayer なら快適に再生してくれる。
なんと言っても、表示領域を二倍にしてもほとんどコマ落ちが感じられないのがありがたい。
できるものなら永遠に眺めつづけたいのだが、そうもしていられない。
まあ、一度見たら消してしまおうかとも考えていたのだが、もったいないから、当分このまま取っておくことにしよう。
またディスク容量が大幅に減ってしまう……。
ああ、CD-R が欲しい。何時になったら gear は使えるようになるのだろう……。
追記
学内向けに「UNIX の基礎知識」を追加した。
基本的には去年「UNIX 用語の基礎知識」として途中まで作成してから破棄したものを改めて作りなおしてみたものである。
とりあえず、基本的な（と私が判断した）ことはすべてここに入れてしまい、「学内向け」内の他のページから必要に応じてリンクしてしまおうというつもりである。（今のところ利用しているのは color-ls だけだが）
昨日学内向けに置いた「UNIX の基礎知識」だが、よくよく考えてみると、ちっとも基礎知識じゃないような気がしてきた。
……まあ、内容に関しては「サルでも出来る」系の記述では不満で、もっと詳しく仕組みを知りたいという人のためだから、多少難しくなってしまうのは仕方の無いことだし、あんなもので満足しなきゃいけないのかな。
追記
Sagami2 ではあまり大きなファイルは落さない方が良いようだ。
昨日試してみたものは見事に全てパーになってしまっていた。
実験のレポートの提出は本日午後一時にせまり、さらに今週の木曜には量子力学の中間試験も迫っている。再履の電磁気学は容赦無く演習でレポートを義務づけるし、量子力学でも課題が出ている。
というわけで、私は先週の土曜に新宿まで足を伸ばしたついでに、「雫」・「To Heart」・「雪色のカルテ」・「Adobe StreamLine」を買い込んだのだ。
後悔こそしていないが、総計４万強はなかなか痛い出費であった。
まあ、「雫」はとりあえずトゥルー・エンド二つと、さおりん・みずぴーのハッピーエンドが見れたし、「To Heart」は雅史編・HMX-12 編・芹香編のエンディングが見れたから良いのだ。
しかし、長瀬一族の謎は深まるばかりだな……。
「雫」の祐介と、現国教師の長瀬。「痕」では県警の長瀬。「To Heart」の長瀬開発主任とセバスチャン。そして「White Album」ではフランク長瀬。
どうして長瀬一族はああまで変人を大量生産できるのだろうと不思議になってくる。
妄想電波人間の祐介は別格としても長瀬開発主任は……、だってどんな顔をして、どんな意図を持って HMX-12 を開発していたのか、想像すると怖くなってこないかな。
いや、メイドロボットの分泌系の機能として、HMX-12 の水準が標準なのならばそれほど異常な人ではないのかもしれないけど……、作中に出てきた他のメイドロボットの情報と比較すると、あれが標準だとは思えないし……。
と、昨日一昨日はこういった思索にふけっていたため、レポートは現在（午前三時）ほとんど進んでいないのだ。
うむ。人生とはこれだから素晴らしい。
本日の成果：「琴音編」・「あかり編」・「委員長編」
ただ、あかりの CG 達成率がどうしても 100 に行かない。
信頼できる筋からの情報では智子はんと一緒に攻略していれば……という話だったので、「委員長編」と「あかり編」を平行してやってみたのだが、その回は「あかり編」のエンディングへ行けなくなってしまった。
何故か風邪を引いてくれないのだ。
何が抜けているのだろう……。
「あかり編」をクリアしたときは、「琴音編」と平行してやっていた時だから、ストーキングは元々完璧でなくてもいけるはずなのだが……。
なにかやってしまうと拙いイベントをこなしてしまっているのだろうか。
しかし、もう一度「あかり編」と「委員長編」をやるのはちょっと……。
Leaf の Web サイトから「To Heart」および「White Album」の修正プログラムをダウンロードして、入れてみて、しかもそれからもう一度「あかり編」をクリアしてみたのだがそれでもあかりの CG 達成率が 100 に届かない。
まさかとは思うが、「White Album」の「その他」の CG 達成率と同じように、88% が最高だというのではないだろうな。
まあ、期末対策中の重なっている４枚が抜けていると考えればその辺は問題ないのかも知れないが……。
でも「葵編」では、きっちり部活に通いつめた場合とそれ以外でご褒美がちがったりしたからなぁ……。
まあ、今日昼休みと三限の空いている時間に調べてみることにしよう（明日は量子力学の中間だというのに……）。
ところで残るは「レミィ編」「志保編」のみ。
さすがに今日やるわけには行かないだろうしなぁ。
まあ、後回しにすることにしよう。
一応水分の供給源としては、燃料電池の廃液という正当な（でっちあげたとも言うかもしれん）理由があったのだな、HMX-12 には……。
だからといって、長瀬開発主任が変態だという評価は揺るぎようが無いのだが。
結果はともかく、量子力学の中間は昨日終わったので、少しは余裕ができた。
「To Heart」もめでたく CG 達成率が 100% に行ったし、おまけシナリオも読めた。
ようやく Adobe StreamLine を入れることもできたし、試してみた限りでは、設定次第でなかなか使えるものになりそうだ。
やっぱり、ディスプレイ出力を前提にしたビットマップ画像をカラーのアウトラインに認識させるのはつらいようだけど。
あと、最近 PhotoDeluxe のファイルへの出力と終了が異常に遅くなっているのが気になるのだが……。
5 秒近く止ったままで、ハングしたかと疑いたくなるという状況はどう考えても普通ではないだろう。
いずれ調べてみなければなるまい。
which は csh のスクリプトか何かなのだろうか？
友人で、ここに載せてあるサンプルのスクリプトが動かないという人が居たので、調べてみたところ、${HOME}/.cshrc に `which xhime` が問題の記述を実行したさいのプロセス ID になってしまっていた。
とすると、which が ${HOME}/.cshrc を読みこんでいるとしか思えないし、とすると which は csh のスクリプトだと考えるのが自然なのだが……。
考えるよりも、where which を実行してから、file `which which` をしてみたほうが早いか。
うーん、最近日記が飛び飛びになっている。まあ、土日が抜けただけだから、問題ないか。
さて、先週は量子力学の中間の準備をしていたために提出できなかった実験のレポートを今やっているのだが……。
嘘です。
先週の日曜から月曜午前中にかけてはシュレディンガー音頭なんて踊らずにぶっとおしで「To Heart」やってました。
……それはさておき、流石に今週も提出しないとなるといいかげんやばくなってくるので、今日は真面目にレポートを書いているのだが……。
金土とやっていた「雪色のカルテ」が思っていたよりも面白くなかった所為だという説もあるので油断が出来ない。
うん「雪色のカルテ」なんだけど、まずパラメーター上げにあまり喜びを見出せないということと、ストーリーが淡白（まだ全部見たわけじゃないから言いきってしまうわけにはいかないけど）なこと、そして「デジタルな生死」という問題がある。
なんと言うべきなのだろうか……「エンディングのバリエーションが少なくて、キャラクターが三人だけだけど、Ｈシーンが多少豊富な『卒業』」と言いきってしまうのは「完全乾燥済み、御利用の際は熱湯を注いで三分間お待ちください」な評価だろうし……。
とりあえず、一番気に入らなかった点を一つ挙げておく。
なんで、パラメーターが１足りないだけで死ななければいかんの？
つーか、どうして後二日の命か全快かしか選択肢が無いわけ？
なんだろな、量子の中間が終わったから多少は暇になっているはずだったのだが、相変わらず忙しかったりする。
とりあえず、CGI での入力フォームの制御用に JavaScript の勉強など始めているのだが、こうやってあちこちに手を出しまくっているのもいけないことなのかも知れない。
Linux-USERS ML で話を聞いた ssh のソースを取り寄せて README を読んだりもしているのだが、やっぱり root 権限が必要なんだよな……。
端末側でならひょっとしたら要らないのかも知れないけど、ドラエもんを動かすとなるとやっぱり root 権限で動かさないことにはまずいだろうし。
passwd は shadow 化されてるからそもそも root じゃなきゃ読めないし。
とりあえず作ってテストしてから相談すれば採用してくれるだろうか？
まあ一応壁の中でしか telnet/rlogin を使えないのだし、そもそも passwd を覗こうとする根性のある人は居ないだろうから必要性は乏しいのだろうけど。
なんだか、ssh の README を良く読んでみると "The software can be installed and used (with restricted functionality) even without root priviledges." とか書いてあるなぁ。
とすると一通り動かすだけなら root 権限も要らないみたいだし、とりあえず make してみて、動かしながら調べてみるか。
いかんなぁ。どんどん講義をさぼりはじめている。
今日は３・４・５と午後は全てサボってしまった。
ssh はとりあえず一般ユーザーでの使用に成功したので事務室の方にメールを書いてみたのだが、果たしてどうなることか……。
せめて sagami2 にはインストールしといた方が良いと思うのだけど。
あと、IslandOffice を startx 側から使う方法も判った。
しかし、日本語入力で kinput2 か Wnn の OpenWin 用フロントエンドしか無いというのはなかなかに……。
試しに使っていても、特に kinput2 の方は、スペース・英数文字が入力できなかったりするのでなかなかにつらかったりする。
これは設定を変更すれば何とかなるものなのだろうか。
それから、IslandOffice のために色々と妙な設定を追加したため、X の起動がさらに遅くなってしまった。
font の問題は半分解決できたので、後は IM を何とかすれば完璧になると思うのだが……、あといい加減 makebdf も試してみないとな。
せっかく話を聞いたのだから、試してみないことにはもったいないだろう。
startx による Window System の起動でも、sun の明朝やらゴシックやらが使えるようになったので、Netscape の方でもそちらを使う設定にしてみたのだが、どうやら問題なく使えているようだ。
ただし、スケーリングは行わない方が賢明。
いまいち良く判っていないのだが、どうやらベクトルタイプのフォントでは無いらしく、スケーリングを行わせるとビットマップフォントを無理やり拡大したような形になり、しかもページの表示にやけに時間がかかるようになった。
とりあえず、次の目標は ${IOFFICE}/fonts 以下にあるポストスクリプトフォントの数々を利用する方法を見つけることなのだが……。
何となく無理かも知れないと今では思い始めている。
とりあえず goo, infoseek などで一通り探してみた結果はあまり芳しいものではなかったので、これから altavista へ旅立とうかとしているのだが、こういうことが出来るのかどうか判らずに調べているものだから、どうしても根気が続かない。
うーん、でもなぁ。
IslandWrite 等を動かしていて、目の前で 72 pt のフォントがきれいに表示されているのを見たりすると、どうしても欲が出てきてしまう。
現在０時なぜかまだ処理室に居たりする。
漫然と Web で探し物をしていたらついついこんな時間になってしまった。
はっきり言って既に明日になってしまっている。
急いで帰ることにしよう。
とりあえず家に着いたのは１時だったりする。
ちょうど良い時間だから、「OUTLAW STAR」を見てから寝ようかと思ったのだが、多少時間が余っていたのでノートパソコンの電源を入れて「痕」をはじめようとしたところ、どうも表示がおかしくなっている。
良く判らないなりに、再起動を繰り返したりディスプレイの設定を変更したり、「シンジャ・ムワ」でデスクトップアイコンの設定を変更したりしたところ、アイコンラベルの背景を透過色に変更したら元に戻ってくれた。
一時はメーカー修理――ハードディスクバックアップ――MO４枚――来週提出のレポートをどうしよう――とまで考えたので、直ったときはまあ嬉しかったのだが……。
こう……原因不明のエラーというものにはあまり出会いたくないものだな。
追記
危うく忘れるところだった。
ssh は現在のコマンドとの互換性なども含めて前向きに検討するとのことである。
うーん、クライアント版だけならコンパイルさえしてしまえば簡単にインストール可能なんだけど、やっぱりドラえもんを全ての端末で動かすように設定しなおすのは大変だしなぁ。
とりあえずプロバイダ経由でも telnet 可能なはずの sagami2 だけにでもインストールしてみるという訳には……、それなりにネットワークへの影響が少ない端末で実験してからじゃなきゃ無理か。
追記其の二
/usr/meiji/X11/lib/X11/fonts/100dpi/ には -adobe-utopia-* があるが、-bitstream-charter-* が無い。
/usr/openwin/lib/X11/fonts/ 以下と /usr/meiji/X11/lib/X11/fonts/ 以下で fonts.dir を sed やら sort やら sdiff やらを使って比較しているのだが、同じディレクトリでも入っているフォントは微妙に違うようだ。
まだ色々とてこずっている所為で、100dpi しか調べ終わっていないが、この調子だと他も微妙に入っていたり入っていなかったりしているのだろう。
追記其の三
${HOME}/.netscape/preferences.js を色々と変更してみたところ、何とか iso8859-1 ではスケーラブルフォント形式で日本語フォントと大きさの釣り合いが取れるように設定することが出来た。
日本語フォントでの設定は悲しいことだが見通しが立たず。
あと、gear は動くようになったと聞いたので、明日 cd を一つ焼いてみる予定。
何枚コースターが出来るか楽しみだったりするが、まあその辺はエラーを重ねる内に何とかなるだろう。
CD を焼くのに成功。
とりあえずサンプルには某 ftp サイトから落してきた mp3 やら mpg やら mov やらを選んでみたのだが……。うん、きちんと焼けている。
音楽 CD ７枚と各種ムービーファイル併せて１枚の CD に焼けたのだから良い具合いだ。
とりあえずコースターは１枚しか作らずに済んだのでまあまあだろう。
使用したメディアは生協で売っている TDK の CDR-74S だったが、多分他のものでもうまく行くだろう。
で、どれくらいの時間がかかるかだけど、４倍速で書き込もうとするとエラーになってしまったから２倍速で試してみたところ、書き込みとチェックで併せて１時間半ほどかかってしまった。
というわけで、書き込み後のチェックは行わない方針で決定。
エラーがあると判ってもどうしようもないのだから、チェックするだけ無駄だろう。
あれから何度か４倍速での書き込みに挑戦しているのだが、どうもうまく行ってくれない。
いや、一回目の失敗は２倍速で書き込んでいて、妙なスワップを発生させてしまっただけだから４倍速だけがいけない訳じゃないのだけど、でも最初の失敗は４倍速でだったからなぁ。
うー、すなおに２倍速でやった方が良いのだろうか。
現在までに失敗した枚数は４枚、そのうち４倍速でのものが３枚だから……。
次に失敗したら２倍速でやってみることにしよう。
追記
とりあえず４倍速でも無事 CD を焼くことに成功。
基本的方針としては、バッファサイズは最大限に取り、他の SCSI デバイス（MO DAT）にはメディアを入れないこと、そしてなるべく /tmp は開けておき、出来れば X を起動せずにコンソールから gear を起動した方が良い、等がある。
あと、これはほとんど呪術的部類にはいることだが、なるべく席を離れずに、そのまま焼かれている状態を監視していた方が成功率が高いような気がする。
以上、もし焼いてみたいという人が居たら参考にしてください。
なお、gear のマニュアルは運が良ければ samba81 の端末のそばに置いてあることでしょうから、興味があれば読んでみるのも良いでしょう。（英語ですが）
それから、印刷されている必要はない、ディスプレイ上で読めれば十分だという人は
/usr/meiji/pub/bin/acroread /usr/meiji/pub/doc/gear/manuala4.pdf &でも実行してみてください。（同じく英語です）
Adobe Streamline だがどうも私が期待していたような使い方には向いていないような気がしてきた。
もう少しシンボリックな認識をしてくれるものと思っていたのだが、今のところその方法を発見するに至っていない。
中心線による認識という設定があったので試してみたのだが、これだと細切れの直線の組み合わせになってしまうし、水平線・垂直線と組み合わせたら、今度は斜めの線が認識されなくなる。
輪郭線で認識させるとひたすら同じ色の領域を一つにまとめようとするし……。
テンプレートの中からテクニカルイラストというものを選んで認識させてみても、それでもきちっとした形には認識されてくれない。
やっぱり、手書きの下絵をスキャナか何かで取りこんだ後、線画に変換させて、それを Illustrator か PhotoShop で着色するという用途にしか使えないものなのだろうか。
うーん、二万円無駄にしてしまったかなぁ。
まだ実験のレポートは終わっていないのだが、こういうときにかぎって馬鹿な考えが浮かんでくるから困る。
まあ、内容的にはたいしたことでは無い。
最近 CD が焼けるようになったのは良いのだが、肝心の焼くものが無いというという困った状況についてのつらつらとした考察だ。
とりあえず先週買ったのは10枚組みのものだったので、今４枚ほどメディアが余っているのだが、誰か何か CD を貸……ってこれは犯罪か。
ふう、ぎりぎりで踏みとどまることが出来た。
うん、足がつく形で募集するのはいけない。こういうのは証拠が残らない形でやるべきだろう。
で、CD-R の活用法で今思いついたことがあるのだが、こんなことをするのも楽しいかもしれない。
たとえばワーグナーの「ニーベルンゲンの指輪」(Wargner "Der Ring des Nibelungen")。これは全４夜構成のオペラで、１夜につき２時間半以上必要として CD ８枚組というすさまじいセット＆値段で売られていたり（LD なんかだともっとすごい値段なんだろうなぁ）するものなのだが、mp3 で圧縮してしまえば何とか１枚の CD に焼いてしまうことも不可能ではないだろう。
欠点としては、普通の CD プレイヤーでは聴けなくなることだけど、CD を入れ替えなくて済むというのはなかなかの利点では無いだろうか。（通して聞くとすると、１０時間以上かかるだろうからよっぽど暇なときでないと無理だろうけど）
誰かやってみた人とか居ないのかなぁ……
居たら尊敬するのだけど。
「学内向け」に「Windows アプリケーションでレーザープリンターから出力する方法」を追加した。
とりあえずニーズがあるようなので、作成してみたのだが……「学内向け」の作成予定の方は少しも手を付けていないというのに、いったい何をやっているのだろう私は。
あ、そうだ、作成予定に「gear 簡易マニュアル」も追加しておこう。
うーん、宿題ばかりがたまっていく。
だれか代わりにやってくれる人は……といっても私は協調性に欠けるからついつい全部自分でやってしまいたくなるんだよなぁ。
他人がやってくれたのでもどうしても手を加えたくなってしまうし。
いくらなんでもそれは失礼だしなぁ。
xv が pub から消えてしまったらしい。
とりあえず代替手段はあるからあんまりあせってはいないのだが……。
やっぱりインストールした方の残り容量が少なくなってきた所為なのだろうか。
それとも、xv はシェアウェアだから自粛したのだろうか。
まあ、仕方が無いことかもしれない。
追記
CD を焼いている最中にネットワークから妙なジョブを投入されると結構腹が立つものだな。
まったく、どういう気持で人が焼き上がりを待っていると思っているのだろう。
CD ドライブの立てるシュルシュルという音に脅え、スワップの発生を知らせるカリカリという音に胃を痛める。
彼らはそういうことを理解してはくれないのだろうか。
まあ、それはともかくとして、CD-ROM -> CD-R ならば４倍速でもめったに問題が発生しないことが判明した。
やっぱり、NFS を通したり、同じディスクでスワップがカリカリカリカリ……と音を立てたりすると問題があるようだけど、CD-ROM -> CD-R ならばその辺は問題ないらしい。
追記其の二
NFS 経由では細かなファイルがたくさん重なっているような場合に２倍速書き込みでもエラーが出る。
local ディスク上にデータがある場合でも、念のために２倍速のままで書き込みを行った方が良い。
CD-ROM -> CD-R が出来る場合には４倍速で何の問題もない。
日本語のファイル名などが使われている場合は NT で読み込んで FTP で送れば正しくファイルを認識してくれる。
この４つが今日１１枚コースターを作成した結果得ることの出来た結論である。
うーん、まあ定価を越えずに済んだので良いと思うことにしよう。
追記其の三
コースターは累計１７枚に達した。（内バッファが空になった完璧な書き込み失敗は１２枚、成功率が５割を切っているのが悲しい）
CD ４枚焼くだけだと言うのに、どうしてこういう目にあうのだろう。
とりあえず残っているのは４枚目だけなので、明日こそはコンプリート出来ることだろう。
今日はもう０時２３分だしタマも無くなってしまったから帰ることにしよう。
ついさっき、CD 全てをハードディスクにコピーする必要は無いと気付いたので、今度はもう少し効率よくやれることだろう。
電子の連中は何をやっているのだろう。
頼むから samba[1-8][1-2] ではネットワークから SIZE 86M とかいうふざけたジョブは動かさないでいてほしいのだが……。
しかも、どこの端末でも動いていたりする。
……あぁぁ、切ってしまいたい。
こういうのは７時半以降に教室が閉ってから、全１２０台？の端末全部で動かすとか、メモリを 512 M 積んでる tango0[a-d] で動かした方が絶対良いと思うんだけどどうなのかな。
というか、CD-R 焼いてる最中にこれがあったらホントに嫌になるよ〜〜。
今は今で似たようなのが２個も動いているし。
ちょっとこの状況だと、焼いてみる気にはならないよな。
ついさっきもメールを書いてみたのだけど、ひょっとして読んでないのかなぁ。多分同じ研究室の人間だと思うのだけど。
流石に全員にメールを書く気にはなれないしなぁ。
あー、システム課の方に相談した方が早いかも知れない。
/etc/inet/inetd.conf から telnet や login, shell などのエントリーをコメントアウトするだけで済むのだろうから。
追記
xv を再び入れた人間がいるらしい。
なんともまぁ、恐い物知らずな人が居たものだ。
とりあえず xloadimage で十分 xv の代りにはなると私は思うのだけどね。
追記其の二
嗚呼、物理イメージを作りたい。明日相談してみることにしよう。
いくらなんでも成功率５割というのは非道すぎる。
特に某ソフトの為には一体何枚費やしたことだろう……。
教訓：
CD とハードディスク上のファイルを混成させた形で CD-R を焼く場合は細心の注意を払い、コピー元ファイルの連続性を考慮すること。
一度焼くのに失敗した場合は、小手先の修正で間に合わせず、２倍速＆ファイル全てをハードディスク上にコピー、した状態で焼いてみること。
現在の所、成功率はかなり低い（５割前後）ので焼いてみようと言う場合は失敗を覚悟した上で行うこと。
今日の格言
「偶然失敗することがあっても、偶然に成功するということはない。成功するからには、何らかの、成功するだけの理由が存在するはずである」
CD を焼いているとついついこう言うことを考えてしまう。
特に、buffer empty が連続して何枚も出てくるような場合には。
失敗する要因が残っている限り、常に失敗しつづけ成功しないのだけど、その要因を取り除くために出来ることといったら条件を変更しながらのトライ＆エラーのみという状況では、一つ躓くとあっという間にコースターが増えていってしまう。
ああ、転送能力のチェック用にテストモードでも用意してあればここまでコースターを増やさずに済んだだろうに。
とりあえず今までに焼いた CD は総計 37 枚だったりするのだが、そのうち buffer empty でコースターになってしまったのが 19 枚という素晴らしい状況である。
何時になったら buffer empty を一掃出来るようになるのだろう。
とりあえず今は生協から CD-R のメディアが消えてしまったらしいのであんまり書き込み実験を行えないのだが、やっぱり物理イメージを使用するのが一番なのだろうか。（でもディスクが無いんだよなぁ）
追記
とりあえずうだうだと考えているよりも「まずコマンドを打ち込んでホントに出来ないのか試してみよう」と思い、CD の物理イメージを作るべく、適当にトラック情報などを gear の上で設定してから physvol と打ち込んでみると……。
……出来てやがる。
ローカルディスクの上に、一つのファイルとして物理イメージを作るのなら最初っからそう書いときやがれ。
教訓：
「まずマニュアルを信じること、そしてマニュアルを疑うこと」
まずマニュアルに目を通すときは全て真実が書いてあると考え、きちんとどんなことが書いてあるか記憶しておかなければならないが、実行するときにはきちんとコマンドを打ち込んで確かめること。
実際に動かして確認するまでは暫定的にしか信用してはいけない。ましてやマニュアルを読んだだけで、出来ないのだと思い込んで実行してみない等ということはしてはいけない。
gear のマニュアルだが、構成自体は良くできていると思う。きちんと目的別に整理されているし、脚注なども活用して非常に読みやすくできている。
だけど、コマンドの解説が少なすぎる。オプションがどういう意味を持つのかぐらいきちんと載せておいてほしい。
実際に使おうとするとき、勘や推測に頼って実行しなければならないのでは恐すぎる。
追記其の二
gear の製造元である Electroson が倒産したらしい。
CD-R Maniacs のソフトウェア情報で知ったのだが、６月１日にオランダ本社が倒産したらしい。
サポートなどはアメリカの販売会社が継続するらしいのだが……。
試しに、Electroson のサイト に行ってみたところ、一応つながるようだし、last update も 6/24 だったりするのでこの辺は一体どうなっているのだろう。
とりあえずリンクのページがいいかげん古くなってきたので、相互リンクの依頼があったのを機会に作りなおそうとしているのだが、どうしたものかな。
まあ普通に作って、後はブックマークからちょこちょこと追加すれば良いのかな。
友人たちも色々とページを作り始めたみたいだし（あんまり更新してないけど）リンクしておくのも良いかもしれない。
時代の流れというか、まあ仕事の関係というか、最近新たに作成しているページは HTML4.0 & CSS2.0 を意識して作っているのだが……Netscape4.0x にしても IE4.0 にしても HTML4.0 と CSS2.0 を完全にサポートしている訳ではないのだよなぁ。
どちらも中途半端にしかサポートしていないし、しかもその範囲が微妙にずれていたりするものだから、作るほうは大変だよなぁ。
とりあえず、最新版のブラウザでも、旧版のブラウザでも普通に表示されるようにしようと思うと、色々と考えなければならないことが増えてくる。
まあ、学内向けのページなら Netscape のことしか考えなくてもオッケーなんだけど、FORM と CGI でちょっとした物を作ろうとしたところ、Netscape 4.03 だと disabled オプションが使えないようなのだ。
あれが使えるなら JavaScript を併用することで CGI スクリプトの方が楽になるのだが、まあ出来ない以上は仕方がない。
IE の方はまた <UL> <OL> <DL> 等を併用した場合に妙な出力をしてくれるし……。
とりあえず Mozilla.org の方々に期待することにしよう。
追記
物理イメージでの書き込み実験だが、無事４倍速でも成功した。
この分なら、多分他のものでもエラーを発生させずに焼くことができそうだ（でも油断は出来ないのだけど）
とりあえず物理イメージでの書き込みの成功率は今の所１００％である。
あと音楽 CD の WAVE データへの吸出し方法も判明した。
gear を起動してから、readtrack -wave [Track_Number] [File_Name] で .wav ファイルを作ってくれる。
物理イメージでの書き込みに初めて失敗した。
どうしてだろうと疑問に思いつつ、繰り返してみるものの、再度失敗してしまう。
しかも失敗する位置は決まっていない。
あるときはトラック１で失敗したかと思うと、次はトラック２３で失敗し、３度目は半分ほど書き込んだところで失敗してしまった。
そこでハタと思い当たり、top を動かしてみると…… emacs が動いてる。
なるほど、常に不思議に思っていたが、まあこれくらいなら影響無いだろうと放っておいた xbiff はこういう目的のものだったのか……。
せめて最初から emacs を動かしっぱなしにしておいてくれるのならエラーも起きなかっただろうに……。
システム課の方に samba81 から telnet で入れないように（何故か私が見たことのある人々は常に telnet を使っているようだ in.rlogind が動いている事は滅多にない）相談してみたのだが、やっぱりすぐにそれをやってくれるという訳には行かないらしい。
とりあえず SWAP は増やしてみてくれるそうだから、これで上手く行くようになってくれれば良いのだけど。
それはそれとして、問題の方にお願いだから samba81 ではそんなことをしないでというメールを書くことにした。
これでこの手のメールを書くのは２回目である。
教訓：
gear を利用する際は、エラーの際の原因究明をたやすくするために top を動かしておくこと。
gear を動かしながら top を眺めているときに気になる点としては異様なまでの空きメモリの少なさと iowait レベルでの CPU 使用率の高さがある。
top で見る限りではそれほどリソースを大量に消費しているプログラムというのは見つからないところをみると、おそらくこのメモリは純粋にディスクキャッシュに使われているのだろう。
ただ、gear の CD-R への書き込みと言う処理の性質から考えて、一度アクセスしたファイルに再び読みこみをかけるようなことはまずあり得ないから、このディスクキャッシュははっきり言ってほとんど無駄な処理でしか無いわけだ。
しかもただ無駄なだけなら良いのだけど、空きメモリが少ないときにそれ以上のリソースを必要とするプログラムが起動したりすると、必要とされてないディスクキャッシュを開放して必要とされるメモリ領域を確保し……と言った作業を矛盾が発生しないように行わなければいけないから、その所為で buffer empty エラーが発生することになるのだと思う。
おそらく例の iowait レベルでの CPU 使用率の高さもディスクキャッシュの開放と確保を繰り返しているためなのだろう。
とすると、対応策としては、余計なジョブを起動しないようにすると言う以外に、ディスクキャッシュに使われる最大容量を減らして、メモリの空き容量を増やし、システムの対応度を広げてみるという選択肢が出てくるのだが、果たして Solaris でそれは出来るのだろうか。
多分出来無いことは無いと思うのだが……まあここまでの推論が間違っているという可能性もあるしなぁ。
そもそも UNIX にとってリアルタイム処理は決して得意じゃない分野だし、その分野でも比較的シビアな条件を必要とする CD-R の書き込み処理を行わせるのが間違っているのかもしれないけど……。
とりあえず現在のところ一般ユーザーに出来る buffer empty エラーを減らすための努力と言えば、誰が入ってくるか判らない昼間はなるべく書き込みを行わずに、早朝・深夜に処理を行うようにするぐらいなんだよなぁ。
まだ私以外で焼いている人は見たことが無いけれど、焼く場合には以上のことを気に留めて、十分に注意して焼くようにしてください。
CD-R の書き込みは順調に失敗と失敗と成功を繰り返している。
昨日は /tmp を増やしてもらったので、試しに物理イメージを作って実験してみたのだが、相変わらず成功率は伸びない。
とうとう２倍速書き込みでも悶死するようになってしまった。（悶死：一般に再現性が低く、原因の追究が困難なエラー。この場合不特定の場所で Buffer Empty エラーが発生する事に使っている）
とりあえず、一度 writecd コマンドを打ち込んでしまったら後は出来ることは祈ることだけである。
胃が痛くなるような３０分間が過ぎるのをひたすら待ち続けるしかない。
あとは、トラックの書き込みが終わるごとにマウスを動かしてみるぐらいかな。
というわけで、祈るときぐらいは祈る対象である神様がどこかに居てくれたほうが良いわけで、まあ居なくてもたいして困らないのだけど、居てくれた方がなんとなく、こう、何を書いてるんだろう私は、まあそういうわけだ。
それはともかくとして、相性の一言で片付けるのはホントは嫌なんだけど、こう言うときはその一言で全てを言い尽くしてしまいたくなる。