KNOPPIXでgparted
う〜む、領域のresizeは失敗。Ubuntuでテスト中。
Ubuntuでやったらうまくいった。DISK使用率が90%から29%に減った。最後のリビルド中。これが終われば、完了かな。
無事完了。って、まだ終わってなかった。古いDISKを捨てる前に内容消去。最初は、fdisk -luで、セクタ数を調べておいて、
dd if=/dev/zero of=/dev/xxx bs=512 count=sector数
したんだけど、ddは、書き込みでセクタエラーが起きると、そこでやめてしまう。読み込みエラーをスキップするオプションはあるんだけど、書き込みエラーをスキップするオプションが無いんで、あきらめてshredを使用。
shred -n 3 -v xxx
こちらは、今のところ止まってないので、エラーはスキップしているのかな。
マウスボタン交換
居間で使用しているパソコンのマウスは、電池交換とか面倒だし、有線式のMX320にしていた。ちょっとセンタボタンが硬いものの、レーザセンサなので、結構トラッキング性能も良く、値段も手頃で重宝していた。
しかし、あっという間にスイッチがチャタリングするように。マイクロスイッチを外して久しぶりに秋葉原に探しに行ってみた。ラジオデパートとラジオセンタを回って、見つからず。あとはヒロセと千石あたりを見て、無ければあきらめようかと思っていたところ、ヒロセで丁度いいのを発見。
上が元から付いていたマイクロスイッチ、下が買ったもの。型番もほとんどいっしょだ。値段は100円強だったんで4つほど買っておいた。早速付けかえて復活。マウスは裏面のシール3箇所を外してネジを外せば、簡単に分解できる。ずっと探していた半田吸い取り器の加熱芯用クリーナも発見でき、今日はなかなかの収穫だった。
RAIDに思うこと
結局ミラーリングしていた両方のDISKにセクタエラーがあった。両方同時に壊れるなんて、まずあり得ないだろうとか思っていたんだけど、そうじゃないんだな。RAIDと言えども読み出してみてエラー検知しなければ、壊れているって分からないわけで、普段アクセスしない部分にエラーが発生していくと、いつまでも気付かないということになる。
毎日フルバックアップをテープになんて運用をしていれば、気付くんだろうけど、そこまでやる気は無いし。とりあえずcronで夜中に1回、ddで全セクタを/dev/nullに書き出すようにしておけばいいのかな。いずれにせよRAIDにしとけば、それだけで安全とは、全く言えないわけだ。市販のRAID NASなんかも、実は普段アクセスしないファイルに久し振りにアクセスしてみたら、両DISKにエラーで読み出せないなんてことが起きそうだな。
リビルド失敗
むむ。仕方ないのでddでセクタコピー中。
コピー完了。なんか立ち上がらないなと思ったら。conv=syncを付けてなかったのが原因。エラーの時に0埋めするという説明を流し読みして、いらないなと判断したんだけど、これが無いとエラーのセクタがあると、そこがコピーされずに次のセクタの内容が1セクタ分詰めて前にずれてしまうのか。だからsyncってオプション名なんだね。そりゃ付けなきゃだめだな。というわけで、やっとさきほどコピーが終わった。200GBで、3時間ほど。
dd if=/dev/hde of=/dev/hdf bs=512 conv=noerror,sync
RAIDのマニュアルをダラダラ見ていたら、リビルド中のセクタコピーでエラーがあったら、スキップなんてDIP設定を見つけた。orz
今度は、コピー成功したので、立ち上げ。現在リビルド中。あとはリビルド完了したところで外して、GNU partedでresizeに挑戦予定。
ディスク買ってきた。
もう普通に、IDEの方がS-ATAより高くなっちゃっているようで。日立の500GBが2k円くらい違った。まとめて4台確保。
うちのRAIDは安い、ホットスワップ出来ないやつなんで、一回電源を落とさないといけないんだけど、そのまま正常なやつも、シリンドルが回らなくなりそうな悪寒がするので、とりあえずネットワーク経由で、バックアップを開始。
RubyのFloat
doubleという触れ込みなんだけど、Ubuntu 64bit版だと、
shanai@shanai-laptop:/tmp$ irb -v irb 0.9.5(05/04/13) shanai@shanai-laptop:/tmp$ irb irb(main):001:0> 1e300 => NaN
Windowsだと(ASR 1.8.7)
C:\Program Files\ruby-1.8\bin>irb -v irb 0.9.5(05/04/13) C:\Program Files\ruby-1.8\bin>irb irb(main):001:0> 1e300 => 1.0e+300
なんで、UbuntuだとNaNになっちゃうんだろう...
ベートーベン ピアノソナタ 第16番
ベートーベン ピアノソナタ 第16番 作品31 第1
Beethoven Piano Sonata No16 Op31 No1
第二楽章を入力。結局イタリアングランドよりもベーゼンドルファの方が好みだったんで、また戻してしまった。作品27から31あたりまでは、どうもベートーベンの中では「幻想曲風」がはやりだったらしい。
JBossかGlassfishか。
そろそろ、家のサーバもEJB3が動くやつにしようかと思って、JBossを色々と試してみたんだけど、SunのJavaEE TutorialにあるConverterのサンプルが動かない。EJB3をルックアップするところで見つからないようだ。Seamじゃないとだめなのかなぁ。とりあえずGlassfishでは、問題なかったんで、明日はGlassfishを色々と試してみよう。
三島へ
6/17は、創立記念日だったので、三島へ行ってきた。
お目あての、うなぎ屋へ
おいしかったけど、ちょっとごはんが多いかな。食べきれなかった。
湯河原の、さつきの郷へ。もう季節は終わっていたけど、残りの花でも、結構きれい。
スーパー牛さんパワー
aptitudeのヘルプを表示したら、
...
-S <ファイル名> : <ファイル名> から aptitude の拡張状態情報を読み込みます。
-u : 起動時に新しいパッケージ一覧をダウンロードします。
-i : 起動時にインストールを行います。
この aptitude にはスーパー牛さんパワーなどはありません。
「スーパー牛さんパワー」って何？ と思ったら、これのことのようだ。
[備忘録] Emacsで、エンコーディングを指定して読み直す。
自動判定が失敗した場合。C-x RET cして、エンコーディングを入力すると、コマンドをど〜ぞと言われるので、C-x C-vで読み直す。
Google Browser Syncはディスコンだそうだ。
スラドの記事で知ったんだけど、Google Browser Syncはディスコンだそうだ。
で、スラドのスレッドを見ているとWeaveというのが、いいらしいので入れてみた。Google Browser Syncと同様に、ブックマーク、クッキ、パスワード、フォームデータの同期ができるみたい。しかし、まだバージョン0.1だし、パスワードやクッキを預けるのは、ちょっと怖いか。とりあえずブックマークだけ同期してみることにする。
地デジ受信機支給へ 生活保護１０７万世帯に
いよいよデジタル移行が、危うくなってきたんで、税金投入か。「テレビ放送は生活に必要な情報を提供しており」ってめちゃくちゃだなぁ。テレビなんて無くても、生活には困らないよ。同じ税金を生活保護世帯に使うなら、最近の食料品値上げを鑑みて、食料品しか買えないフードスタンプを配るとか、そういうことに使って欲しい。
Google gadget
Linux版が出たので、試してみた。最初は、リンクの段階でR_X86_64_32の指定はダメだから、-fPICを指定してね。と言われて失敗。調べてみたところ、どうやらzlibのコンパイルが良くなかった模様。Google gadgetをコンパイルするには、zlibが必要で、ここからソースをダウンロードしてコンパイルすればいいんだけど、普通にconfigure makeすると、後でGoogle gadgetのリンクの際に、zlib.aのリンクに失敗する(多分64bit版のみの問題)。zlibのコンパイルには、configureしてから、make CFLAGS=fPICを指定し、最後にmake installでインストールしておく。
あとは、Ubuntu forumに書いてあった方法でできた。
ただマルチディスプレイ環境だと、左側のディスプレイにしかサイドバーを配置できないみたい(サイドバーからアンドックすればガジェット自体は、動かせる)。「自動的に隠す」が無いと、ちょっと使う気にはならないかな。
Boyer Moore
久し振りにBoyer Moore Searchなぞ、実装してみた。まずは、通常の逐次検索。
public class NormalSearch {
public static int indexof(String from, String str) {
int len = from.length() - str.length();
for (int i = 0; i <= len; ++i) {
int j;
for (j = 0; j < str.length(); ++j) {
if (from.charAt(i + j) != str.charAt(j)) break;
}
if (j == str.length()) return i;
}
return -1;
}
}
Boyer Moore Searchの場合、高速化のために、探索文字列のテーブルを作るのが一般的だけど、この生成コストがバカにならないので、同じ文字列を検索する場合には、同じテーブルを使い回せるようにしてみる。Unicodeだと、このテーブルに256k Byte必要になってしまうのがつらいけど、Mapとか使うと、遅くなりそうなんで、今回は無視。
public class BMSearch {
final String searchStr;
final Table table;
public BMSearch(String searchStr) {
if (searchStr == null) throw new NullPointerException();
this.searchStr = searchStr;
table = new Table(searchStr);
}
static class Table {
int[] tbl = new int[Character.MAX_VALUE + 1];
Table(String str) {
Arrays.fill(tbl, -1);
for (int i = 0; i < str.length(); ++i) {
tbl[str.charAt(i)] = i;
}
}
int lastIndexOf(char c) {
return tbl[c];
}
}
public int indexof(String str) {
int strLen = str.length();
int str2Len = searchStr.length();
for (int i = 0; i <= strLen - str2Len; ++i) {
int j;
for (j = str2Len - 1; j >= 0; --j) {
if (str.charAt(i + j) != searchStr.charAt(j)) break;
}
if (j == -1) return i;
int idx = table.lastIndexOf(str.charAt(i + str2Len - 1));
if (idx == -1) i += str2Len - 1;
else {
int offset = str2Len - idx - 2;
if (offset > 0) i += offset;
}
}
return -1;
}
}
さて、速度を計ってみる。
Core 2 Duo E8400(3.7GHz overclocked) Ubuntu 8.04 64bit版 IBM JDK: java full version "JRE 1.6.0 IBM Linux build pxa6460sr1-20080416_01 (SR1) "
まずは、こんなテストを用意
long start = System.currentTimeMillis();
String from = "The quick fox jumps over the lazy dog";
String str = "jumps";
final int N = 1000000;
for (int i = 0; i < N; ++i) {
NormalSearch.indexof(from, str);
}
System.out.printf("Normal search(short): %,dms%n", System.currentTimeMillis() - start);
start = System.currentTimeMillis();
BMSearch bm = new BMSearch(str);
for (int i = 0; i < N; ++i) {
bm.indexof(from);
}
System.out.printf("BM search(short): %,dms%n", System.currentTimeMillis() - start);
Normal search(short): 198ms BM search(short): 439ms Normal search(short): 183ms BM search(short): 434ms Normal search(short): 191ms BM search(short): 414ms
あれ？ 正直、目を疑った。確かにBoyer Moore法は、テーブルの生成にコストがかかるんで、注意して適用しないと逆効果になることがある。でも、今回のテストはテーブル生成をループの外に出してある。なのに、単純な逐次探索の方が2倍くらい速いのだ。くやしいので、もっと極端な例にしてみる。
long start = System.currentTimeMillis();
String from = "The quick fox jumps over the lazy dog";
String str = "ABCDEFG";
final int L = 100000;
StringBuilder buf = new StringBuilder(from.length() * L + str.length());
for (int i = 0; i < L; ++i) buf.append(from);
buf.append(str);
from = buf.toString();
final int N = 10;
for (int i = 0; i < N; ++i) {
NormalSearch.indexof(from, str);
}
System.out.printf("Normal search(long): %,dms%n", System.currentTimeMillis() - start);
start = System.currentTimeMillis();
BMSearch bm = new BMSearch(str);
for (int i = 0; i < N; ++i) {
bm.indexof(from);
}
System.out.printf("BM search(long): %,dms%n", System.currentTimeMillis() - start);
Normal search(long): 156ms BM search(long): 33ms Normal search(long): 156ms BM search(long): 32ms Normal search(long): 152ms BM search(long): 31ms
さすがに、ここまで来ると5倍くらいになっている。検索対象が7文字だから、まぁ、だいたいは目論見通りか。念のためSunのJavaで、最初のやつを追試。
Normal search(short): 70ms BM search(short): 43ms Normal search(short): 72ms BM search(short): 50ms Normal search(short): 72ms BM search(short): 47ms
う、Sunさん、速いっすね。これだと2倍程度とはいえ、Boyer Mooreの方が速いな。じゃあ、後者のテストの方はというと、
Normal search(long): 163ms BM search(long): 38ms Normal search(long): 186ms BM search(long): 37ms Normal search(long): 169ms BM search(long): 37ms
IBM版との差は無くなった。実行時コンパイルの特性の違いなのかな。
テーブル作成コストとか、検索文字列の長さとか、本当にBoyer Mooreの方が速くなるのかどうかは、慎重な判断が必要になりそうだ。
Thinkpad R61とシステムクロック
どうも変だ。ネットワークがつながっていれば、ntpで合うんだけど、ネットワークが切れていると、GMT時間になってしまう。Linuxのバグかと思ったら、WindowsXPでも同じだった。むぅ、BIOSのバグなのかなぁ。
923SHは、ちょっと欲しいかも。
ソフトバンク、ワンセグ追っかけ再生など'08年 携帯 夏モデル
「ずいぶん努力もしたけれど、ソフトバンクの携帯電話はGPSやワンセグなど、機能がメインで、どちらかというと男性ユーザーが多いイメージがあった」
そうかなぁ、最近の機種ってGPSのってるの、ほとんどなかったじゃん。いいかげん別のキャリアに変えようかと思っていたよ。でもandroidが載った実機が出てきたら、乗り替えちゃうかも。
大先輩がdisられているようなので、一言、言っておくか。
「昔の言語は、誰が書いても同じようなコードになる。」
自分の感覚では、全く逆だよ。昔は、1バイト、1マイクロ秒に、しのぎを削る時代だから、まさに職人芸だよ。むしろ人に読めないような職人芸プログラミングが横行した暗黒時代。いわば、今のケータイゲームプログラミングに通じるんじゃないかな。今の方がまだマシなのは、ケータイと言えども、クロス開発があたり前だから、開発環境は、PCで、ふんだんなコンピュータ資源が使えるでしょ。昔の汎用機時代は、ケータイのプログラムを、ケータイ上で作るようなもの。しかもケータイのCPUには、秒あたり、いくらで課金される時代。まちがって無限ループなんて作ろうものなら、本気で殴られる時代だよ。
「コピペが横行してた」
「横行」という言葉からは、「良くないこと」というニュアンスが感じられるけど、そんなのは、現在の常識を過去にあてはめているだけの話だよ。良く過去の常識で、現在の事柄を判断するなと言われるけど、もちろんその通りだけど、逆もまた真だよ。コンピュータ資源がとてつもなく高くて、コンパイルにも、テストにも、とてつもなくコンピュータ使用料金がかかる時代の常識と、現在の常識は違うんだよ。
あと当時だって、「構造化」という考えはあったし、昔のCOBOLプログラムのJavaに機械コンバートされたものを見る限り、今とくらべて「横行」ってほどヒドいとも思えない。
実際、今50代くらいのエンジニア（元エンジニアでも結構）と、腹をわって話すと、とっても面白いよ。もちろん彼らの言葉（つまり、PL/I、COBOL、FORTRANってこと）で話す必要はあるけどね。むしろ深刻なのは40代くらいじゃないの？ 彼らは富豪プログラミングが当たり前になって、会社から「実装なんてどうでもいいから、PMかアーキテクトになってね」と言われて、素直に従ってきた優等生だから。そういう意味では、むしろ被害者でもある。
え？ 老害の老は40代？ それは認めん！ 絶対(笑)
