LAST MODIFIED: 2002/12/30 21:14:18 UTC
不定期更新の日記です。ディスクスペースの関係上、 あまりに古くなったものは順次消していきます。 この日記の更新は、今野さんの *BSD Diary Links から取得することが可能です。
年賀状のためにカラーインクジェットプリンタを新規購入。 研究室で EPSON PM-920C を一回だけ使ったことがあったので、 EPSON のものを店頭で比較する。
「PM-9xx 系でもそんなに高くないなぁ」と思ったら、 インクがバラバラのものは 1 色で 1,000 円前後するみたいなので、 EPSON PM-870C に決定。 こちらはカラーインク一体型で一個 1,000 円強。 友人から話を聞く限りではグレードによって印字品質が結構変わるらしいのだけど、 まあ、どうせ枚数刷らないし、 普通紙に印刷するならこだわっても仕方なかろう、とコスト優先。 最近はこんな感じでミッドレンジの商品を選ぶことが多くなった気がする。
画質優先で印刷すると 1 枚刷るのに 5-6 分くらい。 はがきを 50 枚ほど印刷したところインクは 5% も減ってないので、 インクがすぐになくなる、なんてことはなさそう。
FreeBSD は ftpmirror を使用。 一回の接続で 2 時間弱。ムダな再送は発生せず安定動作するのだけど、 距離 & 通信量の割にはちょいと接続時間が長すぎる。 要検討。
NetBSD の FTP ミラーは途中でぶちぶち切れるので、 FTP を使うのをやめて sup に変更。 結構メモリを使うけど、安定はするみたい。 選択肢としては rsync が残っているので、要比較検討。 速度は 2Mbps 程度。
OpenBSD は ftp.openbsd.org からだとかなり切れやすかったので ftp.usa.openbsd.org (コロラド大学) に変更して様子見。 こちらも選択肢に rsync があるけど、 内容のバラつきが場所によってけっこう大きくてうーむ、という感じ。 速度はこちらも 2Mbps 程度。
3 種類合計で 250GB 程度。ただし、(おそらく) distfiles に重複多数。 どうにかならんものかしら、これ。
材料は揃ってきたので、次は cvsweb と global の設定に移る予定。
の邦訳版を購入。
邦訳版を買ってくる。重い & 高い。
予約ページが NN4.8 で表示できなくて、 面倒になって予約してなかったのだ。
M さんのとこから。 そういえば、cvsup.jp.openbsd.org に取りに来る人には、 root ユーザでアクセスしてる人がほとんどいないですね。 cron でまわしっぱなしにして、 エラーを確認してなさそーな人はいますけど。
某所の NIS サーバが最近止まるようになったと言われて調査。 どうも、ローカルから hosts.* マップを引こうとして失敗、 という処理を 2-3 秒に 1 回繰り返しているようで、 "ypserv[n]: res_mkquery failed" がばしばし出ている。 /etc/hosts を NIS で共有する必要はないとのことなので、 とりあえず hosts.* マップだけ引けないようにしたら状況は改善したもよう。 クライアントからの利用状況がよくわからない環境ということもあって、 直接原因はいまのところ不明。 スレーブ増やすというのは解決になっていない気がするので、 統計情報を調べるための仕掛けをいくつか入れておくことにする。
んー、こんなので ypserv が刺さるほど負荷かかるかなぁ‥‥。 ローカルから ypserv に DoS attack かけて、 処理できないくらいの負荷をかけることができるとしたら あり得ない話ではないかも知れないのだけれど。
実運用しているところではさすがに怖くて試せないから、 今度実験環境を作って実験してみよう。
うーむ。ftpcopy を詳しく見てみたところ、 --symlink-hack に相対パスを正しく処理できないバグがあるみたい。 ls-lR.gz と MDTM を使わなければムダな再送が起こらなくなったので、 ftpmirror に戻してみる。 何か本末転倒な気もするけど、毎回数十 GB の再転送を行なうくらいなら、STAT or LIST でがんばるほうがなんぼかマシだろう。
モジュール統合。とりあえずミラー設定をはずして、さくっと mv。
cvsup.jp.NetBSD.org がなかなかつながらない。 当分はこれが続くのだろうなぁ。
MDTM を使わないようにすると、ムダな再送の繰り返しがなくなった。 ftp/ftpcopy の api_futimes.c に hook を仕掛けて動作を追って見たところ、 どうも、MDTM を使った場合に一部のファイルの更新時刻を正しく認識できてないもよう。
DOCBOOK-APPS に何度か投げたメールを見たのか、 最近個人あてに「Jade で日本語で使うにはどうしたらいいの?」 という質問がよく来るようになったので、 その回答を書きつつ、長い間懸案になっている pTeX+JadeTeX 問題について、再度いろいろと試行錯誤してみる。 今までの結論としては、基本的に pTeX で JadeTeX を使うことはできるものの、処理量が多い (約 150 ページを超えるもの) は正常に処理できない (ちなみに FreeBSD FAQ は処理可能)。以前はマクロレベルで小細工してみたりしたのだけれど、 使えない機能ができてしまうなど問題点が多いので方針を転換。 原因は pTeX の構造的な部分にあることが分かっているので、 ptex-base.ch を追っかけてみる。 TeX のソースそのものを読むのは初めて。
JadeTeX は (DSSSL で言う) ノードに対応するスタイル情報の保持に ¥def で定義した control sequence を使っている。 original TeX でも multi-letter control sequence 用に hash_extra を相当大きくしないと動かないのだけれど、 実は pTeX では、大きい hash_extra を正常に扱えない。 コードを見る限り、一つは eqtb 配列の一部 (厳密にはちと違うけど) を日本語処理のために使っていること、もう一つは wchar_token_base が 32768 の offset に存在することが原因のもよう。
単純に wchar_token_base を増やすと状況は緩和されるものの、 120000h 以上に増やすと漢字判定処理でコケるので、 他の offset も変更しなければならないのかも。 eqtb がどこでどう使われているのかをかなり詳しく追っかけないとダメそうなので とりあえずのんびりと構える方向で。マジックナンバがばしばし入っていて、 全体像を見ないで対処するのは難しそうな感じ。
Jade を捨てて XML+XSLT に逃げるというのが正しい姿なのかしらん。 pTeX の本が欲しいのだけど、さすがにもう手に入らないだろうなぁ。
FreeBSD の ports にある pTeX とか dvips も新しくなってくれないかなぁと思ったりする。 ports を手元で管理するのはちと面倒。
FTP サイトのミラー用のツールをいろいろ試してみる。 手始めに ftpmirror。daily に仕掛けておいたら、なぜか何度も 同じファイルを持ってきちゃうみたいで謎。 いくつかは「同じなので転送しない」になってくれるのに、 明らかに更新されてないものを持ってくる。 いろいろオプションを変えてもダメっぽい。
現在 ftpcopy を試し中。こっちもなぜか初回 fetch 時にタイムスタンプが正常に記録されないという症状が出るもよう。 うーん、何か使い方がまずいのだろーか。
うきゃー、すっかり忘れてた。 今さらだけど出すだけ出しておこう。
前は遅れていると「訳出さないんですか」 メールが来たりしてたのですが、 最近は日記に概要が書かれたりすることも多いようですし、 翻訳は害悪であるという意見も目にするので、 もう需要は減っているのかなと (勝手に) 思ってたりしてます (まあ、それが忘れた原因というわけではないんですが :-P)。
今さら反応ですが、 ここらへんからたどれる場所に Sol7 用 package があります。わたしは prngd 使ってましたけど。
Ultra 5 ってそんなに安いのかー。
先週、いろいろ予定を先送りしたツケを支払い中。
やっぱり pst(4) の attach が原因なのかなと思って src/dev/pci/pci_pci.c あたりを調べてみる。 hw.pci.unsupported_io_range=0 で attach できないのは、 pst(4) の要求するメモリと、 PCI-PCI ブリッジのメモリ範囲が一致していないのが直接原因。
E7500 のデータシートを読んでみる。 PCI スロットのデバイスは PCI-PCI ブリッジ P64H2(82870) の後ろにある。 MCH にも virtual bridge という PCI デバイスがあって、 それぞれが pcib# として認識されて memory decode range と prefetched memory decode range を持っている。 dmesg を見る限り、MCH の memory decode range は 0xfc100000-0xfc1fffff に設定されていて、 P64H2 の方の はデフォルト値のまま。 pst(4) は 0xfe400000-0xfe7fffff を要求しているので、 メモリ範囲が合わないよ、と怒られる。
‥‥のはいいんだけど、 これ、どうなっているのが正しいのだろう。 hw.pci.unsupported_io_range=1 すると、 何の補正もいれずに alloc_resource してしまうので、 ブリッジのデコードが正しく働かない気がする。
PCI の規格を全然理解していないので、なんとも手詰り状態。 勉強しないとダメか。
LAST MODIFIED: 2002/12/30 21:14:18 UTC