年を重ねると、だんだん物忘れがひどくなってくる。 トラブルとその対処方法、使い方のノウハウ、独自の設定内容など、 こまめに書き留めておかないとあとで大変な目に会う。
Linuxではjpegtranというプログラムで-rotateオプションを使うと圧縮劣化を伴わない 画像回転が可能。 また、-cropオプションでトリミングも行なえる。
新しく購入したデジカメは700万画素クラスで、 それで撮影した写真画像をHDDにアップロードするのに 元々PCにあったUSB1.0インターフェース経由では時間がかかりすぎる。 ということで、PCIバスに差すUSB2.0インターフェースボードを購入してトライ。
買ってきたのは、玄人志向のUSB2.0V4-LPというボード。 ホストコントローラはVIA系のVT6212が載っている。
Linuxであっさり認識され、問題なく動作した。 ドライバは ehci-hcd と uhci-hcd 。
目的は、デジカメで撮った写真画像(HDDに保存してある)のバックアップ。 去年(2004年)の10月にI-O DATAのスーパーマルチドライブDVR-ABH12Wを 買ってあるので、(追記が簡単な)DVD-RAMに入れることにした。
メディアはWindows側でvfatにてフォーマット。/etc/fstabにエントリを登録。
.... /dev/dvdram /mnt/devram vfat rw,noauto,user,codepage=930,iocharset=utf8 0 0 ....
で、マウントして、ファイルをコピー。
$ mount /mnt/dvdram $ LANG=ja_JP.utf8 cp -a /some/where /mnt/dvdram
等幅(monospace)のフォントで半角英数字が全角のピッチで表示されてしまう。 とりあえず、libfontconfig1とlibfontconfig1-devはhold。
少し前の話だが、xftの方に問題があったのが原因で、2.1.7-1になって解消された。 また、http://everybody.good-day.net/~ikuya/にイタリックボールドの問題を解消した独自パッケージあり。 IA32 sidはまだdeb化されていないようなので、代わりにsargeを用いる。
deb http://everybody.good-day.net/~ikuya/debian/sarge/bold/ ./ deb-src http://everybody.good-day.net/~ikuya/debian/sarge/bold/ ./
とりあえず、upgradeは様子見
2.6.11-rc2 incompatible with current nvidia driverなるWEBページを見つけたが、、、時間がないので様子見を続ける。
上記のページにあったパッチ(計４つ)を適用したところ、 今のところうまく動作しているようだ。 linux-2.6.11-rc3もOKみたい。
nvidia-kernel-sourceの1.0.6629+1-2では上記のパッチが当たっている。 また、1.0.7167-1にて本問題は解消している。
なんらかの拍子で、/usr/X11R6/lib/X11/fonts/encodings/encodings/encodings.dirが 消えてしまう。xfonts-baseパッケージを再インストールすればよい。
apt-get --reinstall install xfonts-base
新しいメジャー番号は180なので、以下のようにデバイスノードをつくり直す。
rm ub* mknod uba b 180 0 mknod uba1 b 180 1 ...
これは、kernel-2.6.10-rc[123]およびkernel-2.6.11-rc1にも当てはまる。
下とほぼ同様なのだが、Kernel 2.6.10-rc1 - ngc891's weblogにパッチの当たったドライバのソース、 あるいはdiffがある。修正量は大したことないので、手で直してもよい。
nvidia-kernel-sourceの1.0.6111-2以降では正しく対応しているようだ。
これはkernel-2.6.9, 2.6.9-final, 2.6.9-rc[34]に当てはまる。
Kernel 2.6.9-rc3, patches - ngc891's weblogにパッチというか、 パッチの当たったNVIDIAのドライバがあるのだが、要は、 /usr/src/modules/nvidia-kernel/nv/nv.c をエディットして22行目あたりに 以下の一行を追加すればよい。
#define __VMALLOC_RESERVE (128 << 20)
nvidia-kernel-sourceの1.0.6111-2以降では正しく対応しているようだ。
(locate-library "ライブラリ名")
なんと、udevを使うとbootlogdと共存できないようだ。
このバグは直っているようだが、別のバグが。mountがアンマウント時にsegfaultで落ちるのだ。
また、このバグが復活している。下記のように/etc/udev/links.confで対応する?
ひょんなことからudevを使ってみることになった。
(ひょんなことというのは、2.6.9以降から新しく搭載されたUBドライバを使うように コンフィグしたこと。UBデバイスのメジャー番号は125(後に180に変更))。
(この情報は2.6.10-rc3以降では古くなっています) uba 125 0 uba1 125 1 ...
色々問題が出てきた。
まず、Xウィンドウが立ち上がらない。NVidiaのドライバを使っているので、 udevの導入で /dev/nvidia0 と /dev/nvidiactl が無くなったのが原因。 /etc/modules に nvidia を追記して解決。
次に、VMwareが立ち上がらない。Googleしたらズバリ解決法が わかり、/etc/udev/links.confに以下の行を追加すればよいとのこと。
M vmmon c 10 165 M vmnet0 c 119 0 M vmnet1 c 119 1 ...
その他、VMwareで /dev/ttyS0〜1がないだの、/dev/parport0の読み書き権限がないだの いろいろ文句を言ってくるが、後日、じっくり腰を据えて取り掛かることにした。
たぶんvmware-any-any-update84以降だと思うが、udev対応になったようだ。
下手な小細工は時間と労力の無駄であるという話。
spam対策としてbogofilterを導入してから数カ月になる。 最初の頃は面白いようにspamメールを選り分けてくれるその威力にいたく関心していた のだが、最近、spamメールの検出率が少し落ちてきたことに気がついた。 特に日本語のspamメールをポロ、ポロと取りこぼしているようだ。 なるほど、導入当初は英語や仏語などの外国語のspamメールばかりだったのだが、 徐々に日本語のspamメールが増加し、それらを結構取りこぼしている模様。
取りこぼすたびに、そのメールをspamとして学習させているのだが、 なかなか思うように賢くはなってくれない。 これはきっと日本語のメールと外国語のメールをいっしょくたに扱っているのが原因 なのだろうと、スクリプトをちょこちょこと書いて、それぞれ別々の学習データベース を用意して判定を行なうように設定してみた。
結果は却って悪化した。それまでは約2500通のspamメール中46通を取りこぼしていたの が、少し増えて50通を取りこぼすようになった。 要は効果がなかったということ。
そこで初心に戻ってドキュメントを丹念に読み返してみる。 Debianの場合は、/usr/share/doc/bogofilter/bogofilter-faq.html あたり。 色々調べた結果、 賢いデータベースにするにはbogominitrain.plというcontribユーティリティを 使うのが良さそう。 Debianの場合は、/usr/share/doc/bogofilter/examples/contrib の下にある。
まずは、学習させるためのspam集とnon-spam集をmbox形式でつくっておく。 spamメールは~/Mail/spamに取ってあるから、
#! /bin/sh for f in `find ~/Mail -name "[0-9]*"`; do case $f in */Mail/spam/*) nkf -Zme $f | kakasi -w | formail >> /tmp/spam.mbox;; *) nkf -Zme $f | kakasi -w | formail >> /tmp/good.mbox;; esac done
実行すると、spamが約2500通、non-spamが約4700通ほど集まった。 そこで、bogominitrain.plを実行
bogominitrain.pl -vf ~/.bogofilter /tmp/good.mbox /tmp/spam.mbox '-o 0.99,0.3'
bogominitrain.plは"training on error"および"traininig to exhaustion"という種類 の学習をさせるPerlスクリプト。 オプション-vは、verbose表示。 オプション-fは、検出エラーがなくなるまで学習を繰り返す、 すなわち training to exhaustion を実行を指示する。 最後の'-o 0.99,0.3'という引数は、bogofilterに受け渡されるオプション。 これは、spamとみなすスコアを0.99以上、non-spamとみなすスコアを0.3以下とする設定 で、デフォルトよりnon-spamの判定を厳しくしてある。
私の場合、用意した約7200通のメッセージを使って、bogominitrain.plは2回の繰り返し で検出エラーのないデータベースを作成することができた。 この時、実際に学習に使われたメッセージはspamが260通、non-spamが104通。 7200通のメッセージを全て学習に使わなくても賢いデータベースが得られることを 知った。
$HOME/binにシェルスクリプトmybogoを準備する。
#! /bin/sh nkf -Zme | kakasi -w | formail | bogofilter $*
$HOME/.procmailrcの内容を以下とする。
PATH=$HOME/bin:/usr/bin:/bin: MAILDIR=$HOME/Mail LOGFILE=$MAILDIR/procmail.log LOCKFILE=$MAILDIR/procmail.lock :0HB: * ? mybogo spam/. #:0HB: #* ? mybogo -u #spam/. #:0 #* ^Subject:.*iso-2022-jp #* ^Subject:.*\/.* #* ? echo "$MATCH" | nkf -me | egrep '未承諾広告' #maybe-spam/.
$HOME/.fetchmailrcを以下とする。ただし、nnnnnはlogin名、ssss.some.domainはPOP3サーバー、xxxxxxxはそのパスワード。
# Configuration created Thu Jul 12 00:29:59 2001 by fetchmailconf
set postmaster "nnnnn"
set bouncemail
set no spambounce
set properties ""
poll ssss.some.domain with proto POP3 and options uidl
user 'nnnnn' there with password 'xxxxxxx' is 'nnnnn' here
options keep mda "formail -s procmail"
root権限で、exim4 -ql を実行する。
Exim4は1回のSMTPセッションで即座に配送する受信メッセージの上限数を定めている。 通常は10通までで、残りはキューに溜められ、ユーザーに配送されるまでには しばらく時間がかかる。 メールサーバーからfetchmailなどで受信してExim4経由で配送するような設定を していると、朝一番に大量のメッセージがサーバーに貯っている場合には10通目以降は 遅延され、すぐには見ることができない。 この場合、上記のように明示的にキューの処理をExim4にリクエストする。
The Exim FAQ : What does no immediate delivery: too many message received in one SMTP connection mean?
+draftフォルダに入って、編集を再開したいメッセージに対し wl-summary-reedit (キーバインドは 'E')を実行する。
まず、Ctrl+Alt+SPACE を押す。 そして、SPACEキーのみ離す。 最後に、Fn キーを押す。
http://www.vmware.com/support/ws4/doc/running_prefs_ws.htmlより。
以下の設定を ~/.wl に設定して解決
(setq elmo-nmz-default-index-path "~/namazu/index")
いつものように、Folderバッファで g[hogehoge] とやったところ、 "No updates for [hogehoge]" となり、何も検索されなかった。 どうやら、Wanderlust(実際には elmo)からnamazuコマンドを起動する際の インデックスファイルの指定が、~/Mail となっており、小生の ~/.namazurc の設定と対応が取れていなかったのが原因と思われる。なぜ、こうなったのかは不明。 とりあえず、上記のようにWanderlust側の設定を ~/.namazurc に合わせることにした。
以下のLisp式を M-x eval-expression (M-:) などで実行する。
(elmo-message-file-name wl-summary-buffer-elmo-folder (wl-summary-message-number))
これはもう必要なくなった。 Namazuフォルダのサマリで、着目メッセージの上にマウスカーソルを近づけると 元の場所をhelp-echoとして表示する機能がついた。
flagフォルダでは同様の機能が Ver.2.10.0 から搭載されているが、Namazuフォルダ では使えなかった。Namazuで検索して移動や削除を行ないたい場合が多く、 非常に不便であった。
flagフォルダにて、解除したいメッセージを単純に削除する(Dマークして実行)
通常のフォルダでは'$'キーを押すたびに重要マークの設定と解除が切り替わる。 flagフォルダがまだmarkフォルダと呼ばれていた頃、markフォルダでも'$'キー によって重要マークを解除できた (markフォルダでは最初から全てのメッセージに重要マークがついている)。 名前がflagフォルダに変わってからはそうした解除の仕方はできなくなり、 元メッセージを頑張って探して、そこで重要マークを解除していた。
しかしながら、オンラインマニュアル(info)をよく読むと、 ただ単に削除('D')マークをつけて実行してしまえば重要マークを解除したことになる、 ことがわかった。
GnomeのMain MenuにあるRecent Documentsを無効化する方法をいろいろ調べていたら、 その実体である ~/.recently-usedファイルの読み出し権限を無効にすればよい というのがあった。 ところが、このテクニックを使うとGnomeセッションのumaskが0077に設定されてしまう というバグがある。
これはその後解決された。 xemacs21があるタイミングキーボードの設定が変だよと警告してくる。 xmodmapで見ると会社のマシンの設定とは異なっている。 xlibsを4.3.0.dfsg.1-4にダウングレードして一時しのぎ。