カーネル比較: 2.4と2.6でのWeb処理(ibm.com)。
2.6カーネルのブロックI/Oレイヤーは書き直され、カーネルのスケーラビリティーとパフォーマンスが改善されています。2.4のグローバルI/Oリクエスト・ロックは無くなりました。2.6カーネルのブロックI/Oバッファー（kiobuf）ではPAGE_SIZEよりも大きなI/Oリクエストができます。よく見られる問題の大部分はバッファー・ヘッドとkiobufを使用することで起きていますが、この問題は新しいレイヤーで対応されています。I/Oスケジューラーは完全に書き換えられました。SCSIのサポートに関しても重要な改善がなされています。
そうかio_request_lockなくなったんだ。ソースを見るとやはりなくなっている。今気づいたというのが恥ずかしいところ。アナウンスくらい読めよと。
現在、川崎ルフロンのヨドバシでHDDを買ってきて、ThinkPad X21にFedora Core 1、という状態になっている。今回は円満にルータで切り替えた。設定メモ。
ログ取得ツールcurl_setopt($xxx, CURLOPT_SSL_VERIFYPEER, 0);のように条件を緩くするオプションをつける必要がある。curl側の変更かな。コマンドラインでもオプションつけなきゃだめだし。default-character-set=ujis、httpd.confでAddDefaultCharset EUC-JP、php.iniでもdefault_charset = "EUC-JP"と、しつこくEUC-JPを指定しまくればいいと思う。前のディスクはUSB接続のHDDケースからつないでみたけど、なんか認識できず。うるさいファンを止めると、回転はしてるみたいな微妙な音がしている。ちょっとは救える望みがあるのかもしれない。
長らくxpdfの調子がおかしいと思っていたのだが、そのついでにpdftotextの調子もおかしいと思っていたのだが、やはり設定の問題だった。$HOME/.xpdfrcにこう書いたらだいぶ問題が消えた。
cidToUnicode Adobe-Japan1 /usr/share/xpdf/japanese/Adobe-Japan1.cidToUnicode unicodeMap ISO-2022-JP /usr/share/xpdf/japanese/ISO-2022-JP.unicodeMap unicodeMap EUC-JP /usr/share/xpdf/japanese/EUC-JP.unicodeMap unicodeMap Shift-JIS /usr/share/xpdf/japanese/Shift-JIS.unicodeMap cMapDir Adobe-Japan1 /usr/share/xpdf/japanese/CMap toUnicodeDir /usr/share/xpdf/japanese/CMap displayCIDFontX Adobe-Japan1 "-*-fixed-medium-r-normal-*-%s-*-*-*-*-*-jisx0208.1983-0" ISO-2022-JP
こういうのはデフォルトで/etc/xpdfrcに入っていてほしいところ。 これで、日本語のPDFでもpdftotext -enc EUC-JP hogehoge.pdfでhogehoge.txtができて、それなりに読める。
私はプログラムはviで書くことが多いのだが、実はXEmacsも愛用していて、xeをxemacsのgnuclientへのエイリアスにしている。これがすこぶる便利なのである。起動も猛烈に速いし、xeというのは左親指と左中指の連打なので非常に打ちやすいし。 ところがxeは一つ間違えばex(vimのexモード)なのである。こちらも起動は一瞬だがvisualと打ってもxemacsにはならない。しょうがない、と言いつつexで編集しちゃったりできないのがまだまだ未熟者だ。exの操作ができなきゃ一人前でない(？)わけで、打ちのめされる。
蘭でのLindows(itmedia.co.jp)。挑戦は続く。 この名前を聞くと私はいつも竜胆(りんどう)を思い出す。なんかの武器の名前だと思っていたが、調べてみると植物の名前だ。林道に咲く竜胆、と覚えよう(覚えてどうする)。 武器の名前だと思ってしまうのは、どっかのゲームに武器か防具かアイテムかなんかに出てきたからだと思う。たぶん三國無双あたりかな。 竜胆は美しい花で、家紋(e-kamon.net)によく使われているらしいよ。 花と咲くか、月と欠けるかLindows。
あーれー、sharってむかしsharコマンドそのものもシェルスクリプトじゃなかったっけ？
shar - GNU sharutils 4.2.1
/usr/bin/shar: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5,
dynamically linked (uses shared libs), not stripped
/usr/bin/unshar: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5,
dynamically linked (uses shared libs), not stripped
けっこうショックはでかい。MD5のチェックサムとかついてるし。どうせならsharだけに(？)SHA-1にしたいかも。
(追記) 2004-02-04 14:13
FreeBSDではシェルスクリプト(freebsd.org)みたいだ。いーなー！(そういう問題か？)
(追記) 2004-02-04 14:23
GNUのsharutilsにもcontrib/の下にシェルスクリプト版(オリジナル？)が入っていた。さすがに機能は低いがuuencode/uudecodeするとかgzipやcompressをかますとかMD5でチェックするとか、その程度ならシェルスクリプトで書けると思う。出てくる結果もシェルスクリプトなんだし、やっぱアーカイバもシェルスクリプトで書かれていたほうがきれいだ。
このDVALをLVALに変えればいいって問題か？ そうじゃないのか？ see include/linux/smb_fs.h(DVAL/LVALの定義)、 fs/smbfs/proc.c(DVALでf_sizeを取ってきてるあたり) 週末にでもやってみようっと。 (追記) 2004-01-30 18:43 あら、f_sizeがoff_t(IA32では32bits)だ。まだやってなくてよかった。プロトコルの中には64ビット入るのだろうか。 smbclientのスループットの表示とかも2GB越えるとマイナスになっちゃうし、いろいろ大変だな。CIFSなんぞで2GB越えようという人が悪いのか？ そうじゃないはずだ。たしかNFSでも2GB問題はあったなぁ。NFSv3で解決したんだっけ？？ (追記) 2004-01-30 19:21 Sambaのソースを見ると、64bitのオフセットかそうじゃないかというフラグがプロトコルの中に書いてあるらしい。それを確認すれば上位のも見ていいってことなんだろう、たぶん。…めんどくさいなー、直すの、smbclientの表示だけにしとくか。 (追記) 2004-01-30 19:23 というかsmbclientならsambaだけアップデートすれば直りそうだ、ということに気づいた。今どきファイルサイズの2GB問題なんてあっちゃいけねえんだよ。 (追記) 2004-10-11 17:13 カーネルをアップデートしたときのタイミングで変わったんだと思うけど、いつのまにか2GB超も普通に扱えるようになっていました。
オープンソースのウソ発見器(sourceforge.net)がリリースされた。 試したい。あー試したい。でも今はなんかエラーになってダウンロードできないな。 思わずB’zのあの曲を聞いてます。ハッピーになりゃそれでいい。 (追記) 2004-01-26 24:42 これ、ぜったいネット中で話題騒然になると思ってたんだけど、ダウンロードの障害のせいかわからないけど全然話題になってねー！ 拍子抜け。
朝と夜の時間差の話ではなくて、PCを“ほぼ瞬時に”ブートする新技術(itmedia.co.jp)、という話。
InstantONはカリフォルニア州フレモントのInterVideoが開発した技術。PCのエンターテインメント機能をほとんど瞬時に——InterVideoによると10秒足らずで——起動させられる。オープンソースのLinuxの軽量版「LinDVD」を走らせているからだ。
(中略)
この技術はシャープのノートPCや中国のLegend Groupのコンピュータなど、アジアで販売されているいくつかの製品で既に採用されている。
なんか説明がよくわからないけど(LinDVDってWinDVDの会社がWinDVDをLinuxに移植したやつでしょ？ ブートと関係ある？？)、10秒で起動か。サスペンドにしては長く、ブートにしては短い。 ハードウェアのprobeや各種サービス、ウィンドウシステムを上げる必要がないので殺しているんだろう。カーネル内のハードの初期化の処理をすっとばして/sbin/initの代わりにそのLinDVDを上げればいいということなんだろう、たぶん。なら確かに、早くなっても不思議はない。 Cocoonのように常時起動している(OFFにしても消費電力はついているときと変わらない。出力を出さないだけで、起動している)機器であるにも関わらず余計なフェードイン効果を出して起動にイラつくような製品もある。
LANDISKに/homeのバックアップをとってみたが、やたらに遅い。なんでだろーと思ったのだが、ハタと思い当たった。 要するにこういう話の続きなのだが、
というのをパイプでつないでやっている。tarはいつも使っているもので問題ないしgpgのスループットは出るしsplitが何をやっているわけでもないしsmbfs+LANDISKも満足しているわけではないが3MB/sは出る。そう言えばbzip2が遅いのだった(ちゃんちゃん)。たしかにそうだった。 昨日の夜に仕掛けて遅いなぁと思い、今朝起きてから気がついた。 まあ、次からは差分バックアップになるので問題なかろう。 結局差分バックアップは単にタイムスタンプを使うってことにした。 (追記) 2004-01-29 09:25 実はfindの式が狂っていて以下だとPRUNEPATHが効きません。そのうち修正するかも。 #! /bin/sh set -x cd umask 077 TWOG=1024m tar_raw(){ OUT=$1 shift tar cfp - $* | split -b $TWOG - $OUT.tar. } tar_crypt(){ OUT=$1 shift tar cfjp - $* | gpg -e | split -b $TWOG - $OUT.tbz2.gpg. } tar_raw_t(){ FILE=$1 shift cat $FILE.tar.?? | tar tvfp - } tar_crypt_t(){ FILE=$1 shift cat $FILE.tbz2.gpg.?? | gpg -d | tar tvfpj - } tar_raw_x(){ FILE=$1 shift cat $FILE.tar.?? | tar xfp - } tar_crypt_x(){ FILE=$1 shift cat $FILE.tbz2.gpg.?? | gpg -d | tar xfpj - } diff_tar(){ OUTFILE=$1 DATE=$(date +%Y%m%d%H%M) shift if [ -e $OUTFILE.last ] ; then TMPFILE=$(mktemp /tmp/backup.XXXXXX) EXP="" for i in $PRUNEPATH; do EXP="$EXP -path $i -prune -o" done find $* -follow -type f $EXP -newer $OUTFILE.last -print0 > $TMPFILE if [ -s $TMPFILE ] ; then touch $OUTFILE.last tar_${FORM} $OUTFILE.$DATE –null -T $TMPFILE fi rm $TMPFILE else touch $OUTFILE.last EXP="" for i in $PRUNEPATH; do EXP="$EXP –exclude $i" done tar_${FORM} $OUTFILE.$DATE $EXP $* fi } (以下、秘密) FORM=crypt PRUNEPATH="" diff_tar LANDISK/bak/home . みたいな感じ。