2009/04/22(水)IE6,7でGoogleにアクセスすると GC をおすすめされる
たまーに、必要に迫られてIEを起動することがあるのですが、Googleにアクセスするとこんな表示が出てきます。

Google Chromeに乗り換えようってことですね。IE7でも同じ表示です。
Firefoxだとでてこないので、Safari、Operaとか適当に調べてみたところ、IEのときだけ表示される模様。
じゃあIE8だとどうなるか。

Google Chromeはいいのかよ!(笑)
これは暗にモダンじゃない(HTMLの表示が狂ったウェブ製作者泣かせの)ブラウザ(IE6/IE7)を使うなということだと思う。そこまでやるならいっそIE6/IE7ではGoogle検索を使えなくしたらどうだろうか。そうしたらウェブ製作者から拍手喝采されるのに。
でも、日本だとYahooも一緒にやらないとダメだよなあ……。
2009/04/20(月)レールスプリット簡易検証
2V~動作可能なレールスプリット回路。よくカレントミラーが使われるけど、ほんとにいいのかと疑問に思って簡単に検証。

組むのが面倒だったのでLTSpice。よって正確じゃないけど目安程度にはなるかなと。シミュレーション結果がこれ。

カレントミラー(赤色)とダイアモンドバッファ(緑色)の比較。一応ダイアモンドバッファの方がいいらしいけど、圧倒的でもない。どっちもアイドル電流を変えると改善します。
カレントミラーは電圧バランス崩れを定電流充電するという感じだと思いますが、電流性出力だからインピーダンスは低くないようで。一方低出力インピーダンスの定番ダイアモンドバッファも、入出力電圧の差が小さいときには出力インピーダンスが大きくなる(バイアス電流による)ので、これまた万能とはいえず。
こう見るとレールスプリットはオペアンプと組み合わせた方が性能が飛躍的にあがりますが、今度はレールスプリット回路安定性が微妙に。LT1498とかだとかなり安定ですけど。
備考
- LTSpiceシミュレーションファイル rail_split_LTSpice.lzh
掲載回路のダイアモンドバッファはそのまま使いませんように。電圧をあげていくと熱損失でトランジスタが壊れたり抵抗が発火する危険があります。
追記
Q5~Q8のカレントミラーですが、R6/R7を1kΩにすると12Vが限界でした。15VかけるとQ6/Q7が熱暴走します(普通の電源ならばそのままトランジスタが焼け死にます)。熱結合すれば解消されますが、微妙ですね。
Q6/Q7のコレクタ側に10mA程度のCRDを付けて補償することもできますが、応答性がCRDで頭打ちされるため電源としての性能は明らかに劣化するようです。オシロで音楽再生時に観測すると倍(6dB)ぐらい違います。
2009/04/18(土)Firefox3 のブックマークを同期
LAN内のマシンで、Firefoxのブックマークを共有したくなったのですが、それがなかなか厄介なことに気付きました。
ファイルサーバがあるので、そこにブックマークファイルだけ置けば終わる話だったのですが、Firefox2まではできたその方法もFirefox3ではそれができない。かといってプロファイルディレクトリをまるごと置きたくもない。
仕方がないので
WebDAVをサーバに導入して、XMarks(旧Foxmarks)で同期させることにしました。
たったLAN内の同期のためにここまで用意するなんてアホらしいなあ(苦笑)
調べてたら
Firefox3は、履歴とかブックマークとかのデータの保存に SQLite を使用してるみたいで、これが肥大化すると反応が遅くなることがあるらしい。
SQLite Managerをいれて vacuum と、インデックス再構築。
もっとも、いかんせんマシンが非力な説も。
2009/04/15(水)OpenLDAP の Berkeley DB が壊れた……
長年運用してきた某所にある OpenLDAP の Berkeley DB が(リセットなどのトラブルで)ファイル破損しました。
# slapd.sh start
して一応数秒返ってくるんですが、OpenLDAPシステムが起動したまま接続を受付ない。どうも起動プロセスの途中で止まってしまう模様で、ログにもスタートしました以外、何も残ってない。
# slapd.sh stop
してもプロセスがみつからないと言われるし、実際にプロセスはあるんだけど kill -KILL しないと落ちてくれない。「telnet 127.0.0.1 387」しても何も応答がない。
結果的には、OpenLDAPのデータ管理している Berkeley DB の故障で、故障すると BDB 関係の関数がハングアップする模様。さてこれは困った。
復旧コマンドがあったらしい
BDBを開こうとするだけで停止するので、ダンプも何もできない。さて困った……と思ったら、db_recover という復旧コマンドがあるらしい。OpenLDAP 2.2.30 on FreeBSD だったので、DBDはVer4.2。ということで、
/var/db# db_recover-4.2 -c -v -h openldap-data db_recover: Finding last valid log LSN: file: 1 offset 10445896 db_recover: Recovery starting from [1][28] db_recover: Recovery complete at Wed Apr 15 00:11:18 2009 db_recover: Maximum transaction ID 800019e7 Recovery checkpoint [1][10445896]
とやって無事復旧しました。Berkeley DBは壊れたとき、必ずしも「エラー」になってくれないので原因究明が厄介ですね。
svnとかもそうだけど、Berkeley DBは時々壊れてくれるので、バックアップ取っておかないと痛い目みる。
参考
2009/04/11(土)いいLANカードが売ってないらしい
GbEのLANカードといえば、安価な定番品GbE-PCI2(玄人志向/VT6122)が既に廃盤になっているらしく現在売ってないらしい。友人がギガLAN環境を構築するとのことで「おすすめ」と言ったんだけど市場にないんじゃなあ……。*1
つまり今、PCIのLANカードは蟹NIC(Realtek)とIntelしか手に入らない模様。蟹Giga-NICなんてただの自殺行為なので、Intel一択かあ。高いなあ。
Giga-HUBはとりあえずC社とB社はやめとけと言っておきました。CentreCOMの8ポートあたりが無難だとは言ったものの、最近のPCネットワーク事情的はどんなもんなんでしょう。
教えてえらいひと!
えらいひと曰く
Intel PRO/1000XT Server Adapter(中古)がおすすめらしい。オクやアキバの中古ショップ(サーバ系)に流れているそうです。値段は1~2kぐらいで。
ハブは壊れてもいい前提でB社の安価なモデルが一番費用対効果が高い気がします……だそうです(笑) まあでも倍額出せるなら、やっぱりCentreCOMだよなあ。ハブ壊れると泣けるので(苦笑)