2005-11-25

歴史認識

ディスカバリーチャネルの番組:
クレオパトラの死

「(ぼくの|あたしの)アウグストゥスタソはそんなことしないもん!」と言ったら塩野七生シンパだな。

2005-11-22

Becky! の優位性

ちょっと古いけどトップに出ていた日経BPの記事:
Becky! 大量の処理に威力を発揮する上級者向けメーラー

Becky! の優位性は保存形式にあると思う。
デスクトップ検索と併用し始めると、必要なメールはその場その場で検索するので、メールの振り分けなんて一切やらなくなる。せいぜい、1ヶ月ごとにまとめてフォルダに叩き込むくらい。そうなるとメッセージが大量に溜まったフォルダが出来るので、 Mailbox みたいな 1フォルダ=1ファイルとか、 Maildir みたいな 1メッセージ=1ファイルの保存形式は無理が出てくるのですよ。

サーバサイドだとファイルシステムは比較的簡単にいじれるので、 Maildir on reiserfs にするのがベターな解だけど、 Windows 様はそうは行かない。で、Becky! みたいに適当なサイズでファイルを切り分ける。というのが生きてくるわけですね。

個人のメールは完全に Gmail に移行したし、会社では IMAP なので、Becky! だと、どうも動作にプロトコルバグっぽいのが多かったから、使うのやめちゃったけど。

Pythonの根本的な問題だとは思うんだけど

trac-MLで、「UTF-8だとマルチバイト文字の切り取りがうまくいかないからデータベースを含めてUnicodeを使うことにするつもり」という、とても恐ろしいお言葉が。
リポジトリを見てみると、それらしいブランチがあるじゃありませんか。

PythonのCodecがダサいのに、そんな方法で解決して欲しくないなぁ。
コンソールから読めないエンコードでデータベース作ったときの大変さを知らないんだろう。きっと。

strftime() の出力を strptime() で読めないようなダサいライブラリに依存するのがいけないですね。
# それ以前に、Linuxとかのja_JPのLC_TIMEは何とかして欲しい。マジで。

2005-11-18

3年早ければ

ITmediaの記事:
Sun、C/C++およびFortranの開発環境「Sun Studio 11」も無償化

Java にうつつ抜かしてるうちに、エンタープライズ市場をとられちゃったのよね。 3 年早ければ hp の台頭はなかったかもしれん。

プロトコルスタックは BSD 由来のちゃんとしたやつ積んでるんだから、コンパイラさえあれば開発者の間口が広がっていたのでしょうか。だって、 gcc インストールするのめんどいんだもん。