唐沢俊一氏が2007年12月27日分の裏モノ日記のタイトルに
「師走だなぁ。ぼかぁ、君といるときが一番師走なんだ」
http://www.tobunken.com/diary/diary20071227140541.html
というのを取り上げていますね。
これはかの有名なタモリの発禁アルバム「タモリ3」のネタだと思うのですが、それには言及はありません。
もっとも、受けが違いますけどね。。。
まぁ唐沢氏がこのようなネタを知らないとは思えないので、意図的なんだと思うのですが、、。
唐沢俊一氏が2007年12月27日分の裏モノ日記のタイトルに
「師走だなぁ。ぼかぁ、君といるときが一番師走なんだ」
http://www.tobunken.com/diary/diary20071227140541.html
というのを取り上げていますね。
これはかの有名なタモリの発禁アルバム「タモリ3」のネタだと思うのですが、それには言及はありません。
もっとも、受けが違いますけどね。。。
まぁ唐沢氏がこのようなネタを知らないとは思えないので、意図的なんだと思うのですが、、。
という話題があちこちに出ています。
たくさんあるので、個別リンクは省略します。
世ではGmail(Google)の認証などのHTTPS(SSL)通信の失敗だけが言及されていて、そのせいかWillcomからはGoogleに問い合わせて欲しい旨の対応をされたと書いている方もいます。
で、私は別にSSL通信できない例を発見しました。
http://jvman.jp/
の右肩にある「MyページLOGIN」を選ぶと「SSL通信ができません」と表示されてリンク元の画面に戻ります。
(このページは期間限定だと思うので、そのうちアクセスできなくなると思います。)
Gmailの場合に比べて
・SSL通信ができない旨のメッセージが明確に表示される。
・通信が終了することはない(PTなどの表示はそのまま)
という違いはありますが、なんだかなという感じですね。
ひょっとするとサイト証明書の暗号化鍵のビット長が決めうちで、それを超えると駄目だとか。。
(jvmanの場合はプログラム中でエラーになって表示するけど、Gmailの場合はバッファオーバフロー起こしてるとか言うギャグを思いついたけど、、、さすがにそれはないと信じたい。)
とりあえず、Willcomのサポートに問い合わせを送りました。果たしてどうなるか?
(nineの製造元にも送った方がよいかなぁ??)
小型デジタル一眼レフのことです。
前から「APS-Cはやはりファインダー像が小さい」とか、「フォーサーズはファインダー像が小さくて云々」という評を書いている人が多くて謎だったのですが、その謎が解けました。
アサヒカメラの最新号をみて気づいたのですが、なんと今の小型デジタル一眼レフカメラのファインダー倍率表記はどうやら焦点距離50mmのレンズを装着したときの値だということです。そんな馬鹿なことを一流光学&カメラメーカーがやるわけないと確認したら、、、。
http://olympus-imaging.jp/product/dslr/e3/
とか、
http://www.nikon-image.com/jpn/products/camera/slr/digital/d300/spec.htm
とか、、。。
これってたとえば、あの名機オリンパスペンFのファインダーの倍率を50mmレンズの場合であらわすようなもんだけど、、。
あくまでも標準レンズとは実焦点距離で50mmだという「こだわり」(あまりいい意味ではない方の)かもしれないけど、その一方でレンズに関しては「35mm換算」の画角が同等な焦点距離も示してるんですよね。
実際撮る側の立場では画角が問題なわけでレンズの実焦点距離にこだわれてもねぇ。。
疑問なのは、その点を各種カメラ誌や写真誌などカメラマンやカメラ評論家などが誰も問題として取り上げてないこと。
で、ちょっと探したらAPSフィルムのデジタルカメラでも同様に表記していたらしい。たとえばニコンのプロネア
http://www.nikon.co.jp/main/jpn/whatsnew/1998/proneas_98.htm
とか。。
だからといって、たとえば110とか16mmのカメラで50mmを基準にはしないだろうし、ハッセルの1眼レフを50mmでというのもありえない。
カタログスペック至上主義ではありませんが、もう少し実質的な値を仕様として欲しいなぁ。。
先日自宅サーバ(FreeBSD5.x)の ATA Soft RAID1の片割れがセクタエラーを起こしまくってDEGRADEしました。
それを本日復旧したので、その作業メモです。
なお、もし故障したのが起動ドライブだったばあい、4.のディスク交換時にマスターとスレーブの設定を入れ替えるなどしないとFreeBSDそのものの起動ができない恐れがあるので注意すること。
えー、先日PAEにするかamd64にするか迷っていたFreeBSD機ですが、愛用のjvimをports collectionからインストールしようとして罠にはまりました。
jvim3-canna+freewnnをportinstallしたのは正常にできたわけです。
jvimの起動も一見正常。
でも、かな漢字変換しようとするとcore dump。。。
でmake時のメッセージにpointerをサイズの違う整数型に入れているとか何とか言う趣旨の警告メッセージを発見。
で、こういうプログラムを作って試しました。
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>main ()
{
printf("%d\n", sizeof (char));
printf("%d\n", sizeof (int));
printf("%d\n", sizeof (long));
printf("%d\n", sizeof (long long));
printf("%d\n", sizeof (char *));
printf("%d\n", sizeof (int *));
printf("%d\n", sizeof (long *));
printf("%d\n", sizeof (long long *));
}
さて、これをi386機でコンパイル実行すると、、、
1
4
4
8
4
4
4
4
のようになることは自明と言っても良いでしょう。が、amd64機だと、、、
1
4
8
8
8
8
8
8
となんとまぁ、64ビットだから当たり前と言えば当たり前ですが、ポインタは8バイトになります。どうやら件のプログラム中にはこれをintに入れているのがあると見た。
もっと驚いたのがlongも64ビットになっていることかな。VAX-11以来32ビット機主流が長く続いたから、long=int=32ビットと言う前提のプログラムも多いと言う気もするんだが、、。
逆に考えれば、ポインタをlongに入れていれば問題はなかった、、、ってそういう使い方をさせてしまうC言語の「アセンブラ」としての側面がそもそもの原因ですね。
もちろん、本来はそれを活用できるのがC言語のうまみであって、アーキテクチャが変われば、それにあわせて変えなきゃならんということを忘れなければいいだけですが、(え?普通のアセンブラとの違い?、ニーモニックが変わらないって事だけでしょう:-)、、。
巷では「高級言語」ってことにされているから、つい忘れてしまうわけですね。
まぁ高級言語でもアーキテクチャ依存性があるものもあるから、Cだけが悪いってわけじゃないですが。
そもそも、charのビット数からして処理系依存なんだってことをなぜ忘れるかって言うと、それだけ世のアーキテクチャが変わり映えしない単調なものになっていたってことで、、、。
PS. 結局jvimはjvim3-direct_cannaなら問題なく使えることがわかったので、それを使おうかと、、。うーん、Wnnにしたかったんだけど。。それに、まだ例の警告が数ヶ所出てるのが怖い。。
久々に。
現在DELL PowerEdge840のIntel Xeon 3070(?core2つの奴)に4GB-RAM搭載っていうのにFreeBSD入れつつあるんですが、普通の(?)のi386用だと512MB程メモリを使わなくなってしまう(32ビットメモリ管理の関係で)ので、拡張メモリモデルに対応させなければならないんだけど、Intel64の場合、タイトルのどっちのパターンがいいのかなぁ?と言う状態です。
そもそも巷の書籍にはこういうリッチ(?)な構成を前提に説明しているのがまだないみたいだし、最近オフィシャルなところに報告している事例が激減している気がする。
(これはおそらくブログの影響だと思う。ブログの検索はかなり厄介なので、ブログばやりも善し悪しですなぁ。)
個人的にはIntel64なのにamd64ってのが好みですが、i386ベースの方が無難な気もするけど意外とPAEって検証が済んでないドライバとかも多いようだし、、。
まぁ一晩探してエイやってところですかね?
ちなみに入れようとしているのはもちろん、FreeBSD 6.2 RELEASEです(すぐcvsupするだろうからSTABLEになるだろうけど)。