三ヶ月目に突入した日記

1年が過ぎ行くなり

今日から実家に帰省。
しばらく日記の更新はなし。

年賀状を買い直す

近所の郵便局には年賀状がまだ売っていたので これを買って年賀状を書き上げる。 さすがにインクジェット対応の年賀状は売っていないので、 普通の年賀状になる。 プリンタで打ち出すとインクが着き過ぎて 他の部分に転移してしまう。

インクジェット対応の年賀状は 5年くらい前から売り出したはず。 初年度に偶然 インクジェット対応年賀状を見つけて、 翌年 別の郵便局でインクジェット対応のものを買おうとしたら、 郵便局員から「そんな年賀状はない」と言われた記憶がある。

Google Fight!

1998年に登場 以来、 Google は インターネット検索エンジンの代表となった。
GOOGLEFIGHT はその Google を使ったお遊びページで、 対立する 2 つのキーワードを Google で検索して、 そのヒット数を較べて無理矢理 勝敗をつけるというもの。

このページは本来 charset として ISO-8859-1 が指定されているため 日本語が通らないはずなのだが、 設定を豪快に無視してくれる Internet Explorer では なぜか使えてしまう。

で、色々チェックしてみる。

日本語検索には難があるようで、 Googlefight の結果と Google を直接検索した結果を較べると差が出てしまう。

[Java] BEA WebLogic JRockit 7.0 を色々調査 (1)

BEA 社がスウェーデンの Appeal Virtual Machines 社を買収して 手に入れた JRockit は、 J2SE レベルの商用 JavaVM としては SUN、IBM に続く知名度を誇っている。
(Compaq や HP の JVM は SUN の Hotspot VM を移植したものがベース)

しかし、公開されている情報が少なくて チューニング方法が分かりづらい。
少し調べたことを書いてみる。

• オブジェクトヘッダサイズは 2ワード(8バイト)
  
  オブジェクトヘッダサイズは、 ぶっちゃけて言うと java.lang.Object の大きさである。 これは、 Java 言語仕様にも JavaVM 仕様でも規定されていなくて、 JavaVM の実装者が任意に選んでよい。
  
  32 ビット版の JavaVM は SUN の Hotspot VM が 2ワード(8バイト)、 IBM VM が 3 ワード(12バイト)となっている ( ここを参考)。 実際には、 IBM VM はダブルワード境界にオブジェクトを並べるはずなので、 空のオブジェクトは 4 ワード(16バイト)となる(はず)。
  
  JRockit のオブジェクトヘッダサイズは、 SUN Hotspot VM と同じ 2 ワード(8バイト) のようだ。
  
  
• ガーベージコレクション方式は 4 種類
  
  JRockit は 4種類の GC アルゴリズムを持っていて -Xgc オプションで切替え可能。
  

  -Xgc:[gencopy|gencon|singlecon|parallel]
  

  デフォルトで選択される GC オプションは -Xmx サイズが 128M 未満なら gencopy、 128M 以上で CPU 数が 4 個未満なら gencon、 128M 以上で CPU 数が 4 個以上なら parallel が 指定される。
  ここまではマニュアルにも書いてあるので OK だが、 問題はこの 4 種類の GC の性質。
  
  gencopy と gencon は世代別 GC (新・旧の2世代) で、 singlecon と parallel は世代がなく -Xmx/-Xms で指定された連続空間をフラットに使うようである。
  
  世代別 GC の場合 -Xns で指定したサイズを新世代のサイズ、 残りを旧世代サイズとするようだ。
  無指定の場合の 新世代サイズは GC アルゴリズムによって固定で、 gencopy は -Xns640k、 gencon は -Xns16m のようだ。
  
  サーバープログラムで性能を上げるには 新世代を大きくするのが常道。
  しかし、 gencopy においては -Xns に -Xmx サイズの半分以上を指定するとエラーが発生する (Windows 版の場合 エラーダイアログが表示される)。
  また、 -Xns の指定を大きくしていくと、 通常の GC が発生しなくなり、 強制的に Full GC のみになる閾値があるようだ。

  -Xmx128m -Xms128m -Xns22m ... GC が起こる
  -Xmx128m -Xms128m -Xns23m ... Full GC しか起きない
  
  -Xmx256m -Xms256m -Xns44m ... GC が起こる
  -Xmx256m -Xms256m -Xns45m ... Full GC しか起きない
  
  -Xmx512m -Xms512m -Xns89m ... GC が起こる
  -Xmx512m -Xms512m -Xns90m ... Full GC しか起きない
  

  -Xmx サイズの 1/6 あたりに境界があるようだ。
  
  gencon は -Xns が -Xms サイズの 1/4 に制限されているようだ。
  それよりも大きな値を設定すると、 警告を出して止まる。
  
  
• シン・スレッド(Thin thread)
  
  Classic VM は、 ネイティブスレッド(native thread) と グリーンスレッド(green thread) の 2 つのモードががあった。
  ネイティブスレッド方式は、 Java スレッド 1 つに対して OS のスレッドを 1 つ割り当てる方法で、 Java スレッドのスケジューリングは OS のスケジューラ任せになる。
  グリーンスレッド方式は、 JavaVM の内部のスレッドが タイマー割り込みと setjump/longjump を使用しながら、 Java スレッドを時分割で見せる方法だった。 スケジューリングは JavaVM が任意にコントロールできるが、 初期のグリーンスレッドはワーカースレッドが 1 つだけだったので、 マルチ CPU マシンでも 1 CPU 分のパワーしか使えなかった。
  
  SUN の J2SE の本流 Hotspot VM は、 結局 グリーンスレッドを止めてネイティブスレッド 1本になった。
  しかし、 非常に多くの Java スレッドを作る Java プログラムの場合、 ネイティブスレッドで動かすとリソースが足らなくなったり スケジューリングのオーバーヘッドが問題になるのである。
  そこで出てきた Thin thread。 マルチ CPU で動作するグリーンスレッドである。
  
  理論上、 アクティブに動く Java スレッド数が多い場合に 動作が向上するはずである。 JRockit は -Xthinthreads を付ければオンになる。
  で、 実際に計ってみるがオンにした方が必ずよいと言うわけではないようだ。 SPECjbb2000 の Warehouse 数が大きい場合には性能のが向上するが、 1番効果があがりそうな Volano Benchmark では 逆に性能が低下してしまった。
  
  
• Thread-Local Allocation
  
  これは SUN Hotspot VM の UseTLE や、 IBM VM の cache allocation と同じもののように見える。

参考

• ホワイトペーパー： BEA WebLogic JRockit-The Server JVM

不正アクセスの集計

今日は仕事おさめということで、 サーバーへの不正アクセスを 計測を初めてから 3ヶ月分 集計してみた。

非公開ポートへアクセス数をカウントすると計 1,144 サイト。 ご苦労さまです。 攻撃ポートでいうと 137、443、445、139、9090、1433、20、50、1080、6488 の順に多い。

攻撃サイトの国別の内訳は以下の通り。

IIS を攻撃する Nimda 系のウィルスは今も活動し続けているようで、 攻撃を仕掛けてきたサイトは三ヶ月の合計 112。

SMTP サーバーに対して、 spam メール配信させようと 不正なメールを投げてきたのは 42 サイト 52 回。

この集計データは 先々月、 先月の 累計なので、 国別統計の上位陣はあまり変わらなくなっている。
ここまでは面白がって不正アクセスをロギングしてきたが、 そろそろ攻撃されるのも嫌になってきたので 攻撃サイトを沈黙されるなんらかの手段をとろうと思う。

またやってしまった

人間は失敗するパターンが脳に記録されるようで、 無意識のうちに同じ失敗を繰り返す。

例えば、筆者は年賀状が売れ切れるのを恐れて12月の頭に買う。 忙しいのでしばらく放置しておくのだが、 いざ書こうとすると年賀状がどこかに行方不明になっていて、 結局買い直すはめになる (無くした年賀状は、なぜか2月ごろ湧いて出てくる)。 失敗がパターン化していて、ここ5年で3回も同じことをしている。

また反対方向の電車に乗るというミスも、決まって同じ路線でやる。
神奈川在住の筆者が秋葉原に行くときは、 東急東横線で渋谷駅まで出て銀座線で神田駅で降りる。 このルートは間違えない。
しかし帰るときは別のルートを通り、 銀座線の末広町駅から溜池山王駅に行き、 そこで南北線に乗り換え 東横線の武蔵小杉駅まで帰る。 この時 なにか別のことを考えながら電車の乗り換えをやると、 なぜか溜池山王で逆方向の電車に乗ってしまうことが多い。
今日も所用で都内に出ていたが、 帰りのルートでまた逆方向に乗ってしまった。
しかも今回は 本駒込駅 まで気づかなかった！！

と8駅分も逆走。。。

あまりの失態に呆然としながら帰宅すると、 買ったはずの年賀状が行方不明になっていた (涙)

Doxygen & Graphviz

Doxygen の紹介を書こうと プログラミングに関することとかの ページにはエントリだけ用意しているが、 忙しいためにちっとも書き進まない。 とりあえず 自分への覚書として、関連する URL をここに残しておく。

参考

• Doxygen の公式ページ
• Doxygen を使おう ... OKA Toshiyuki 氏による doxygen の紹介(日本語)
• Graphviz ... AT&T の Graphviz の公式ページ

獣ヲ殺セ！ ソノ喉ヲ切レ！ 血ヲ流セ！

Amazon.co.jp に 注文を入れていた小説がやっとくる。
注文したのは一ヶ月以上前だが 取り寄せの本が混じっていたため遅れた模様。

今回買ったのは、 救いようない物語がお好みの方にと ウィリアム・ゴールディングの「蝿の王」と一緒に紹介されていた、 ジャック・ケッチャムの 「隣の家の少女」 「オフシーズン」、 ネビル・シュートの 「渚にて - 人類最後の日」の3冊。
「隣の家の少女」から読みはじめる。 1/3 ほどの読んだところだが、序々に狂気がオーバーヒートしてくる。
面白いが残りは帰省中の楽しみということにして、会社に出勤する。

自分への覚書

これを読んだらゴールディングの「後継者たち」、 ジョナサン・キャロルの「天使の牙から」を読め。
あと、ジョナサン・キャロルは翻訳のペースが遅いので、 訳書を待たずに原書で読め。

サーバーマシンのHDDを置換

サーバーマシン(自作PC4号機/VineLinux2.5) の Maxtor 4k080H4 (ATA100/81.9GB/5,400rpm) の調子がおかしく、 dmseg に以下のような シークエラーや CRC エラーを出すようになった。

hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdb: dma_intr: error=0x84 { DriveStatusError BadCRC }

そこで完全に壊れる前にと、新しい HDD を購入して置換した。

回線速度の遅い ftp サーバーのデータディスク用なので 発熱の少ない 5,400rpm の 160GB HDD が欲しかったが、 今どうもこの条件にある HDD が売っていない。 しょうがないので Maxtor DiamondMax Plus9 6Y120P0 (ATA133/120GB/7,200rpm/8MB Buffer)を買う。 7,200rpm だしバッファを 8MB を積んでいるこのディスクは 手持ちで1番高速な HDD になった。 年末・年始はこれで凌いで、 5,400rpm の大容量 HDD が出た時点で移し替えて、 6Y120P0 はクライアントマシン用の起動ディスクにするつもり。

追記1：12/24

6Y120P0 の standby 機能がうまく働かない。
Standby モードから active モードへの戻る時に リブートが掛かってしまう。What's?

追記2

kernel バージョンを 2.4.19-0lv26 に上げるも改善されず。
取りあえず spin down を停止して、凌ぐしかないのか？

追記3

spin down 時間を指定しない場合でも、 数時間アクセスせずにほおっておくと リブートが掛かってしまう。
別のマシンにつけている HDD と 6Y120P0 を 交換するしかなさそう。

追記4：12/25

Windows98 用の 80GB HDD を 6Y120P0 と置換。
耐久テストのために 6Y120P0 に負荷を掛けまくる。
サーバーマシンの HDD は Maxtor 4k080H4 に戻したのだが、 ここ数日警告メッセージを出さずにちゃんと動いている。
摩訶不思議

[Java] ガーベージコレクション(GC) の accuracy について

Java やスクリプト言語の多くは陽に陰に GC をサポートしているが、 一口に GC といっても色々種類がある。
切り口の 1 つが GC の正確さ(accuracy) である。 GC の正確さによって、 厳密な (exact) GC と保守的 (conservative) GC の 2 通りに分けられる。 GC の正確さとは、 ランタイムがメモリ中のある箇所に入っているデータを ポインタ(参照)なのかそうでないのか判断の確かさで決まる。 判断に曖昧さが残る場合、 ラインタイムはその箇所に入っているデータがポインタであろうと みなして処理を進める。これが conservative GC。 逆にポインタであると迷わず判断できるものが Exact GC。

普通、 ランタイムが扱う記憶領域は、 ヒープ、スタック、レジスタの 3 種類に大別できる。 このうちヒープに関しては、 最初から GC のある言語の場合、 ほとんどポインタかどうかが正確に判断できる。 問題はスタックとレジスタで、 ランタイムの多くが C/C++ で記述されている関係で、 注意しないとポインタかどうかが正確に判断できない。 この場合、かなり厳密な conservative GC になりがちである。

と、ここまでが話の枕なのだが、 各種 JavaVM の場合、 SUN Classic VM (J2SE 1.2 まで採用されていた JavaVM)、 IBM JDK 1.3.1 までの JavaVM が conservative GC。 SUN Hotspot VM (J2SE 1.3 以降で採用された JavaVM)、 SUN の EVM (研究用)、 IBM の Jalapeno 以降(研究用) が exact GC である。 SUN KVM (J2ME の JavaVM) は おそらく conservative GC で、 JRockit は詳細は不明だが 挙動から判断するに conservative GC くさい。

Exact GC は conservative GC と比べてスタックやレジスタの内容を正確に判断する必要がありその分コストも大きいが、 1つ大きな利点が存在する。 それは オブジェクトを指している参照が正確に分かっているために、 任意のオブジェクトを自由に移動できる点である。 移動したオブジェクトのアドレスを持つポインタの内容を書き換えてやれば 移動前と後で論理的矛盾は生じない。 このオブジェクトを任意に移動できるという性質は、 GC アルゴリズムの自由度を高める。 そのため exact GC を採用した時のみに許される GC 手法が 色々開発されている。

一方、conservative GC の場合、 ポインタなのか数値なのか分からない箇所から指されている オブジェクトは移動できない。 曖昧な箇所をポインタだと見なして書き換えて、 実際は数値が格納されたメモリワードだと エラーとなるからだ。

そのため exact GC の方が conservative GC よりも 優れていて性能を上げやすいと考えていたのだが...(続く)。

掲載誌をもらう

原稿を書いた Java World 誌の掲載号をもらう。
なぜか記事の前半部分がカラーページに載っている。
別にカラーがはえる内容ではないけど...

[Tips] CVS にコマンド

バージョン管理システム CVS を長く使っているが、 いままで CVS では無理だと思っていたことが ちゃんとサポートされていることが分かった。 というか CVS のメイン機能であり、 この機能を利用しなかったのはかなり間抜けである。

気づかなかった機能とは、 オリジナルのソースツリーが自分の手の届かない場所でメンテナンスされており、 独自の変更をオリジナルのリポジトリに反映できない場合、 オリジナルの変更と自分用のローカル変更をどのようにして 整合性をとればよいかという機能である。

1. まず、オリジナルのソースコードを持ってきて 自分の CVS にインポートする。
   
     cvs import module vendor branch1
   
   
2. ソースコードに独自の修正・変更を加える。
   その間にオリジナルソースも変更が加えられる。
   
   
3. 適当なタイミングで、 修正されたオリジナルソースコードを持ってきて 自分用の CVS に再度インポートする。
   この時、 module と vendor は一致させ、 ブランチ名を 1. と異なる名前を付けて行う。
   
     cvs import module vendor branch2
   
   このインポート終了後、 オリジナル側の修正点とローカルな修正に衝突する点がなければ、 これで終了となる。 CVS のリポジトリは 最新のオリジナルソースコードに独自の修正・変更を加えた 形となっている。
   修正の競合が起こった場合には、 CVS はユーザーに競合の回避を求めてくる。
   
   
4. CVS がソース間の競合の回避を求めてきた場合、 別の場所でモジュールをチェックアウトして、 問題点を修正する。
   
     cvs checkout -jvendor:yesterday -jvendor module
   
   このチェックアウトしたコードの修正をすませたら、 コミットを行う。
   
     cvs -q commit
   
   
5. すでにチェックアウトを行っていた作業リポジトリがあれば、 アップデートを掛けてファイルを最新のものにする。
   
     cvs -q update
   

上のようにできることを知るまで、 初期にインポートしたオリジナルソースツリーと 現在のオリジナルソースツリーの差分を作って、 それをローカルな変更として加えていた...。

参考

• CVS --Concurrent Version System (in Japanese)

[MyWeb] Boehm GC のページの続きを書く

Boehm GC のページは途中で書くのを止めていたが、 アクセスログを見ると このページを読んでいる人もいるようなので、 ぼちぼち続きを書くことにした。

とりあえず、 Boehm GC の finalizer 機能について書くが、 書いている最中に 自分でもちゃんと理解していない点があることに気づいた。 しょうがないので、 サンプルプログラムを書いて finalizer 呼び出しの挙動を 確認する作業を行う。
この忙しいのに、何をやっているのだろう > 俺

友人 doden 氏がシリコンバリーに行く

大学1年からの友人で、 今は茨城の方の会社に勤めていた友人 doden 氏が、 シリコンバレーに転勤になった。 本日 成田を立ち、今頃は機上の人だ。 会社の独身寮を確保しての転勤らしいので、 あまり長期の勤務ではないようだが、 洋行が氏にどのような化学反応を起こすのかが、 楽しみではある。

睡眠不足なり

リンク集にリンクが切れがだいぶ発生していたので修正。
あと bjorb による暗号化通信のやり方が分かったので、 12/12 の日記を少し修正した。

同じタイトルの DVD が増えてゆく

服を買いに行こうと上野の町をぶらついていたら、 なぜかティム・バートンのナイトメアビフォアクリスマスの コレクターズ・エディションを手にしていた。 すでに通常版は持っているのに、 特典につられてほいほい買ってしまう 自分が悲しい。

午後は川崎市教育文化会館で開かれた第九のコンサートを聞きに行く。 今日一日で万歩計は 2万歩を指していた。

[Food] 「かに道楽」でかに三昧

友人 aze を誘って神田というか秋葉原の裏のかに道楽に行く。
この場所にかに道楽が立って1年ぐらいたつが、気にはなっていたが値段が高いので入りそびれていた。
今回は半月前から心づもりをして挑戦。

かに会席の松会席を頼み、カニ味噌、カニ豆腐、茹でたカニ、カニの天麩羅、焼いたカニ、と次々に出てくる。

ぞんぶんカニを堪能するも、メニュー中の「かに寿司」に密に心を引かれながら神田を後にする。
これぞ弓道の極意 「残心」である。

[Java] Servlet/JSP プログラムの訳の分からない挙動に苦しむ

Java のバイトコードの話だが、JSP タグを自動生成するTaglibのようなソフトウェアを使うと、 プログラマが手で書けば絶対ない大きさのメソッドができてしまう。 Java は 1 つのメソッドの大きさを 65,535 バイトまで認めているが、1万バイトを越えるような巨大なメソッドを作成すると、JavaVM の動作がすこしおかしくなる。

• SUN Java2 Standard Edition の 1.3.x、1.4.x では、 巨大メソッド呼び出し中に起きる GC が非常に時間が掛かる。 通常の GC が 0.1秒未満で完了するとしたら、 1〜10 秒程度は停止する。
• IBM JDK 1.3.1 では、 巨大メソッドが呼び出し中に GC が起きると、 その最初の GC がとんでもなく長く停止する。 通常の GC が 0.1秒未満で完了するとしたら、 10〜100秒程度は停止する。
  ただ、2回目の GC からは普通の GC とおなじぐらいの時間しか掛からない。

どちらも exact garbage collection を持つ JavaVM なので、stack map を作成するのだが、その作成タイミングに問題があるようだ。

追記：2003/1/19

読み直して気づいたが、大嘘八百を書いている。 IBM VM は conservative GC で exact ではない。
そのため IBM VM は stack map を必ずしも必要としない。
個人的な予想では、最初の GC での長めの停止は stack map 作成ではなく、JIT compiler のためかもしれない。

あと、JRockit では GC 時間が延びたり停止したりという現象そのものが発生しない。

[Tips] 暗号化 + SOCKS 対応のプロキシ

こんなことに時間を割いている暇はないのに...

とりあえず SOCKS5 には runsocks と呼ばれるコマンドがあり、引数で指定して起動する子プロセスの socket 通信を socks 経由の通信に置き換えることができるようだ。例えば、 socks 化されていない telnet で SOCK を使いたい場合以下のようにすればよい。

> runsocks telnet remote-server port

この場合、ホスト毎に通常の socket 通信を行うか socks 経由で通信を行うかは、/etc/libsocks5.confを用いて決定できる。 ローカルホストが 10.0.0.0/8 のネットワーク内にあり、この中の端末とは通常の socket 経由でのやりとりを行い、それ以外の IP では SOCKS5 サーバー socks.hoge.moge.jp を 経由させるには以下のようになる。

noproxy - 10.	- -
socks5	- - 	- - socks.hoge.moge.jp

この socks 化と bjorb を組み合わせて暗号化プロキシを達成する。
実験として、ローカルホストからリモートホストへの telnet を暗号化してみる。
ローカルホストのポート 23 番を待ち受けポートとし(ローカルに telnet サーバーは立てない)、そのポートへの接続はリモートホストの 9023番ポートへ転送される。この際、ローカルホスト - リモートホスト間の通信は SSLによって暗号化される。 リモートホストは 9023番で受けた SSL 通信を復号して、自身の telnet サーバ(リモートホストの 23 番で待機)へ接続することにする。

結果、ローカルホストの 23 番ポートは、リモートホストの telnet サーバーとつながり、途中の通信も暗号化されるはずなのである。

# runsocks bjorb -f client.conf 

# bjorb -f server.conf

log_level	1
access_log	/var/log/bjorb.log
error_log	/var/log/bjorb-err.log
do_fork	        true

entry "MyClientSetteing" {
  accept 23 with SSL
  connect remote-host:9023
}

log_level	1
access_log	/var/log/bjorb.log
error_log	/var/log/bjorb-err.log
do_fork	        true
CA_cert_file    /etc/bjorb.pem
CA_cert_path    /etc/CA
max_connection  100

entry "MyServerSetteing" {
#  service_type "SSL Telnet" # (追記参照)

  accept 9023 with SSL
  connect 127.0.0.1:23
}

理論上、 これでいいはずなのだがなぜかうまく動かない。 泣きそうだ。

追記：12/17

うまく動かない理由はサーバー側の service_type の設定にあったようだ。 これをコメントアウトするとうまく動作した。 元の設定ではサーバー側の bjorb は SSL Telnet 接続 を待っていたのに、 クライアント側の bjorb は SSL 化した Telent 接続 を行おうとしていた。
クライアントとサーバーで異なる通信プロトコルを 使えば接続できなくても無理はない。

bjorb は単なる telnetd を SSL telnetd に仕立てる機能はあるが、 単なる telnet を SSL telnet にする機能はないようだ。
SSL Telnet 通信の方が汎用性が高いが、 とりあえずは今のままで我慢。忙しいから。

ついにダウン

連日のオーバーワークで、ついに動けなくなる。
今日は一日寝て過ごした。

雪が降ってから HDD の調子が...

昨日は関東地方は全域雪だったようで、 川崎も日曜の夜から降り始めずっと降りやまなかった。
深夜、寮に帰ると部屋の中は冷え冷え。
Athlon XP の自作 PC の電源を入れると、 ファンがキィキィ、HDD がカラカラ鳴っている。
10分ぐらい暖気運転をすると正常に戻ったが、 こんなことが毎日続くとHDD が壊れそう。

追記：12/13

パソコンのすぐそばの窓が空けっぱなしになっていた。
道理で室温が低いはずだ...

暗号化プロキシツールを次々に試すも

BJORB では通信経路の SSL 化は可能だが、 SOCKS5 に対応させるのが難しいことが判明。

以降、 deletegate、stone、sslrap 等を検討する。
sslrap は 2 千行強のプログラムなので、 これを socks 対応さえるように自力で修正するのが 早いように思われる。

追記：12/10

SOCKS5 には runsocks という 子プロセスの socket 通信を自動的に interrupt して、 SOCKS 通信化してくれるコマンドが あることを発見。
アプリの SOCKS 化の前にこれを試してみる。

[CPU] さらば Alpha チップ

DEC の遺産、Alpha 21x64 シリーズがいよいよ最期の時を迎えるようだ。
CNET Japan の この記事によると、 来年 Alpha EV7 のアップデートバージョン EV79 が出て それで終わりになるらしい。
Alpha チップの型番 21x64 は 『21世紀の 64ビットプロセッサー』という意味だったが、 21世紀を迎えて 3 年目に倒れてしまうようだ。

一節には、 Intel が Alhpa EV11 を作るという話も聞くけどね。 ＼（^o^）／

[Tips] BJORB (びょうぶ)を使ってみる

しばらく前から SSH に代わる汎用 secure proxy を探していた。
要求としては 伝搬するプロトコルの種類を選ばず、 通信経路を暗号化可能なものだ。
BJORB と STONE というものが見つかった。 現在、BJORB と格闘して、SSH の代わりにしようとがんばっている。

BJORB は 0.5.7a が最新のようだ。
一応、公式だと以下の手順を踏めば よいようになっている。

% cd  bjorb-0.5.7a/src
% ./configure --prefix=/usr/local --sysconfdir=/etc --localstatedir=/var --with-ssltop=/usr
% make
% su
# make certificate
# make install-<platform名>
# make install

<platform名> には準備されたプラットフォーム名が入る。
しかし環境によっては、 ソースコード上の問題でコンパイルエラーが発生したり、 インストーラ箇所がおかしかったりするので、 目視と手作業による修正が必要である。

まず、 当方の Vine Linux 2.5 + gcc version 2.95.3 (20010315) では Config.cc コンパイル中にエラーが発生する。 これを以下のように修正する

diff Config.cc.orig Config.cc.modifed
336c336
<   csoc = ::accept(soc_accept, (SOCKADDR *)&sa_client, (int *)&addr_len);
---
>   csoc = ::accept(soc_accept, (SOCKADDR *)&sa_client, (socklen_t*)&addr_len);

また configure の各種指定が 設定ファイル等に正しく反映されないようだ。 以下に従ってソース等を修正する必要がある。

とりあえず今日はインストールで終わった。

参考

• yamamoto 氏のページ POP,IMAP の SSL による暗号化

[Bench] Pentium4 3.06 GHz 等の SPEC CPU2000 値が公開

なかなか公開されないと気を揉んでいた Hyper-threading 対応の Pentium4 3.06 GHz 版だが、 DELL が Precision WorkStation 350 でのスコアを 公開してきた。 システムバスは 533MHz、メモリは RIMM PC1066-32。
int2000 は 1,130 の堂々 1位。 2位 以下のプロセッサは、 まだ 1,000 を越えていない独走体勢。
一方、 fp2000 は 1,103 で、 1,300 番台前後に集中している RISC の先頭集団に少し遅れた形だ。 キャッシュの容量に差がありすぎるので仕方がないかもしれない。

その他、 新しいところでは AMD Athlong MP 2800+(2000MHz)、 IBM POWER4 1450MHz が登場。 ここを 参照のこと。 それとプロセッサ自体は既発表ながら、 新しいマシンでのItanium2 の 900MHz と 1000MHz のスコアが Hewlette-Packard から公開された。 peak 値と base 値に違いがないのは相変わらずである。

[Work] **** 1.3.1 への並列 GC の移植作業が完了

この 1 週間かかりっきりだった、 **** 1.3.1、1.4.1 への並列 GC の移植が完了。
この数日、 8 時に起きて会社に行き 帰宅すると26時をまわっているという生活を続けていたので、 ようやく枕を高くして眠れる。
とりあえず明日は会社を休んで一日中寝よう。

追記：12/4

結局、会社に出ちまった。