先日、Enigmail 0.94.0 用のLanguage Packを作ってみたと書いたのだが、
http://enigmail.mozdev.org/langpack.html
こちらのEnigmailのWebに掲載されました。うれしい。
「TSUBOI Yoshihiro, with credits to Satoru Fujii」とFujiiさんのお名前も書いてくださっていて良かった。
(ちゃんとファイルを送るときにFujiiさん作に手を加えましたと申告しておきました。)
と思っていたら、“kiyo4_k”さんが翻訳された部分もあったんですね… すみません。
Category Archives: Computing - Page 18
EnigmailのLanguage Packが掲載された
Posted by ytsuboi
on 2006年1月14日
1 comment | 2,712 views
Enigmail 0.94.0 用のLanguage Packを作ってみた。
Posted by ytsuboi
on 2006年1月12日
1 comment | 2,967 views
今日、Thunderbirdの1.5がリリースされたので、
受取人のメールクライアントによって、添付ファイル名が正しく表示されない場合がある
という問題はさておき、さっそく導入してみた。
EnigmailはPGPをThunderbirdで便利に使うプラグインなのだが、Thunderbird 1.5で使えるのは、Enigmail 0.94.0以降なのだ。
で、Enigmail 0.94.0 で使える日本語 (Japanese)ランゲージパックがまだ置いてなかったのでしばらく英語で使うかと思ったのだが、
ちょっといじってみると意外と簡単にランゲージパックが作れそうだったので、作ってみた。
(Satoru Fujiiさんの前の翻訳に手を加える形で作りました。Fujiiさんありがとうございます。)
enigmail-ja-JP-0.94.0.xpi
これである。
FreeBSD上で編集して、Windowsで使っているが特に問題はない。
私以外の環境の人でも使えると思うので、本家に送ってみたものの、とりあえず配布してみます。
訳を含めて、なにか問題があれば教えてください。
Equalizer 劇的改善
Posted by ytsuboi
on 2006年1月12日
No comments | 1,998 views
2005/12/13 Equalizerのアホ〜
2006/1/9 もうEqualizer嫌いだ
といままでさんざん書いてきたが、今回入手したパッチで劇的改善を見せた。
いままでは、”7.1.0i”というバージョンだったのだが、”7.1.0s”というのが配布され、
パッチを当てて再起動してみると、ロードアベレージが激減している。すばらしい。
0.4くらいだったのが、0.05以下という劇的改善。
結局はnatdのbugだったんですかね。
もう少しでロードバランサが置物になるところだったので、なんにせよ良かったです。
E350を導入してすぐに、後継のE350siが出てアナウンスしてくれよと怒り心頭でしたが、
ちゃんと動いてくれればまぁいいです。後継はどうなんだろう。
MacBook Pro が出るらしい
Posted by ytsuboi
on 2006年1月11日
1 comment | 3,401 views
今年には出るかもと言われていたintelアーキティクチャのMacが出た。しかもノートである。
でも、PowerBookでなくって、MacBookって慣れのせいかいまいちなネーミング。
Microsoft OfficeもPhotoshopも動くnote PCということでかなり欲しいのだが、intel搭載で
軽くなったりバッテリのもちが良くなるかと思いきや、2.54kgとのこと……
バッテリ駆動時間は書いてないし。
面白そうだけれども、あえて買うほどの魅力もない。
PowerPCなPowerBookとあまり違いを付けたくなかったのかな。
もうEqualizer嫌いだ
Posted by ytsuboi
on 2006年1月9日
6 comments | 6,409 views
前にも書いたので詳しいことは省略するが、本当に腐っている。
何が腐っているってEqualizer E350だ。
これを買おうと思っているシステム管理者は、評価機借りてからにしたほうがいい。
(とはいえ、2週間程度の貸し出し期間では気づけないと思うが。)
-bash-2.05b$ uptime
1:40AM up 11 days, 3:02, 1 user, load averages: 0.96, 0.99, 0.99
-bash-2.05b$ top
last pid: 34616; load averages: 0.97, 0.99, 0.99 up 11+03:02:46 01:41:10
58 processes: 3 running, 55 sleeping
CPU states: 62.5% user, 0.0% nice, 6.3% system, 31.3% interrupt, 0.0% idle
Mem: 36M Active, 74M Inact, 133M Wired, 28K Cache, 48M Buf, 132M Free
Swap: 1024M Total, 1024M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
77 root 64 0 22400K 22160K RUN 55.2H 90.43% 90.43% natd
34616 xxxx 28 0 1992K 1192K RUN 0:00 1.19% 0.54% top
32807 root 2 0 2868K 2468K accept 20:55 0.00% 0.00% lbd
32812 root 2 0 2868K 2476K select 1:15 0.00% 0.00% lbd
32810 root 2 0 2868K 2448K select 0:43 0.00% 0.00% lbd
前回同様に、connection張りすぎているみたいなのが、原因はnatdっぽい。
uptime取ってびっくりである。 本当になんとかしてくれよ、ネッ○ワー○ド。
こんな信頼性の低いロードバランサ、Ultra Monkeyかなんかで自前でロードバランサ組んだほうがよっぽどましだぞ。
