ギャグ漫画家は、才能をすり減らして連載しているから、長続きしない傾向が有るけど。
「がんばれ酢めし疑獄!!」はしぶとく続けているうちに、復活気味。

こんなツールがあったのか。
まだPR中でportsに入っていないけど試してみよう。

「極悪がんぼ」を読むよりも断然面白い。
リアルだから当然か。

そういや「紅の豚」も、当初はクロアチアあたりを舞台にした設定のはずだったけど。
製作中に内戦が始まって、急遽アドリア海のイタリア側に変更したって話があったな。
「雑想ノート」でもあのあたりを取り上げた回があったような。(適当な記憶。無保証)

「内戦が始まったのでクロアチアを風景として参考にした」という意見もあり:

最初のうちは「自分で圧着するなんてメンドクセェ」と思っていました。そして売っているLANケーブルを買ったほうがトラブルも無いだろうと思い込んでいた。
しかし。
ハブから端末の距離なんて、メートル単位で違いますし。
クロスとストレートが混在していると、それこそトラブルの元だし。
あとCAT5eやCAT6の売り物ケーブルは高い!
それに信用できないケーブルも散見されたり。
なんだかんだで圧着工具と100mのCAT6ケーブルを買って、端末が増えるたびに自作していたら、えらい楽なことに気がつきました。
買い置きの予備LANケーブルなんてのを置いておく必要もなくなったし。(工具置き場がずいぶんさっぱりする。既に買ってあるケーブルはゴンゴンとニッパーで切断してしまえるし)
自作Power over Etherをするときも、圧着工具が必要。

続報。
しかし前の話題はもう記憶の片隅に追いやられているなぁ。
Webだと2週間もたっちゃうと「過去のネタ」になっちゃうし。

　また、前回、多くの人から“常軌を逸した行為”“非常識な行為”と指摘された「５秒に一回のFTP」について、ご説明します。
　この出来事は１年前の事で、自分にも記憶違いがありました。確かに初めは、５秒に一回の設定をしていましたが、さすがにそれではまずいと思い、その後すぐに20秒に一回に変更しました。プロバイダーから注意を受けたのは、20秒間隔で運用して２週間くらい経ったころです。以下は、その際のプロバイダーからのメールの抜粋です。
「（20秒という）短時間でファイルを更新されますと、弊社サーバに必要以上の負荷が生じ、他のお客様のご利用に影響を及ぼす可能性がございます。（中略）10 〜 15分程度の間隔で設定していただきますようお願い致します」
　その後、このプロバイダーを退会し、別のプロバイダーに乗り換えたのですが、そこでも同じことをすると注意されるだろうと思い、「ブロードバンド時代のホームセキュリティ術(2)」でご紹介したように、ドアセンサーに連動させてドアが開いた時だけ画像がFTPされる仕組みを作ったわけです。以上が、「５秒に一回のFTP」の顛末です。

反応するのなら、即座にやらないと意味がないなぁ。と、感じました。
少なくとも前の記事が出てから、今日までの数ヶ月の間は「非常識なライターさん」という認識でしたし。

従来の文字コードとUnicodeの対応に関する諸問題_ もメモ。

kogureさんから、board.cgiでは長すぎてエラーになったというのでメールが来た。
なるほど。

気付かずにお返事遅れました。元の投稿を確認致しました。ちょっと
不正確な内容ですね。例えば


>>Mac OS X 10.2.8 の /etc/rc では、
>>概ね物理メモリ 64KB あたり 1 個の vnode テーブルエントリ (+1024) を用意するように
>>なっているようです。


というのは，実際には otsune さんがご指摘の通り SystemTuning で
調整されます。Boot 時には kern.maxvnodes = 1328 となっています
ので，defvnodes が 1328 となり，後は base memory (32MB) を除い
た物理 memory 32MB 毎に 512 の vnodes が追加されています。結
果，例えば手元の機械であれば

Powerbook (1,024MB): 17,200
Xserve (2,048MB): 33,584

の様になります。

また


>>従って、64KB よりも小さいファイルをたくさん (maxvnodes 以上の数) 、
>>そして何回もアクセスするような処理を行う場合、
>>ファイルをキャッシュするためのメモリは空いているのに、
>>vnode テーブルの空きがないことにより (キャッシュから追い出されて)
>>処理効率が上がらない、という事態が予想されます。


この部分は 4.4BSD の知識を前提にしていらっしゃる様に見えます。
Darwin ではこの部分は UBC (Unified Buffer Cache) という手法を
使っている為，残念ながら検討外れの議論になっています。確かに 
vnode が足りないと cache が棄てられるので，最初の実験の様な結
果になりますが，vnode 毎に 64KB の cache という制限がある訳で
はないので，二番目の実験の解析は間違っています。二番目の実験
で maxvnodes = 30,000 でも cache が有効に効かないのは，単に 
512MB の実 memory で総量 1.2GB 程度（64KB x 20,000）の file 
を操作した為，物理的に memory が足りなくなり cache が捨てられ
たからでしょう。

64KB の制限がない事は，適当な大きさの file を一つだけ作ってそ
れを同様の方法で計測してみればすぐに判るでしょう。例えば手元
では以下の様になります。

$ yes|head -n50000000> big
$ ls -l big
-rw-r--r--  1 kogule  staff  100000000 Oct 16 18:41 big
$ time pax -w -f /dev/null big 

real    0m8.239s
user    0m0.010s
sys     0m1.480s
$ time pax -w -f /dev/null big 

real    0m0.554s
user    0m0.030s
sys     0m0.450s

Buffer cache で速度が上がるのは当然ながら二回目の access から
です。実験例の様に cache が残っている間に大量の同じ file に何
度も access が生じる事が実務上どれだけあるかという問題もあり
ます。勿論 vnode 自体も cache されていますので，maxvnodes が十
分であれば一回目の access でも早くなりますが，実 memory が足り
なくなれば maxvnodes が如何に十分あろうとも結局読み直す事にな
るので，速度は余り向上しません。

この様に色々な要素が絡む為，最適な maxvnodes の値を割出すのは
結構大変です。やるのであれば典型的な状態で実測しながら割出すし
かないでしょうけど，色々な要素が絡む中からその典型的な状態をど
うやって見付けるかという事が問題になります。ですから，実 memory 
を最大限積むというのが実際的な解答になると思います。事実元の投
稿の実験では maxvnodes が多い例として 30,000 にしていますが，
実 memory を 2GB 積めば SystemTuning 任せでも上記の様に 30,000 
を超えます。

尚 Boot 時の kern.maxvnodes の値，1328 は xnu/bsd/conf/param.c 
の中の以下の部分で計算されています。こゝで MAXUSERS は出荷され
ている kernel では 32 です。また desiredvnodes が 
kern.maxvnodes の実体です。

80  #define NPROC (20 + 16 * MAXUSERS)
81  int     maxproc = NPROC;
82  int nprocs = 0; /* XXX */
83  
84  #define NTEXT (80 + NPROC / 8)                  /* actually the object cache */
85  #define NVNODE (NPROC + NTEXT + 300)
86  int     desiredvnodes = NVNODE + 350;