yppasswdd

ひさしぶりに NIS サーバなんか立ち上げましたよ。 FreeBSD 6.1.yppasswdd に、-a をつけてやらないと、サーバの root がユーザのパスワードを変更することができないんだな。

ひさしぶりに NIS サーバなんか立ち上げましたよ。FreeBSD 6.1.
yppasswdd に、-a をつけてやらないと、サーバの root がユーザのパスワードを変更することができないんだな。

SQLite さらにその後

MacOS 10.4 についてる SQLite のライブラリは 32bit 専用でした。… MySQL は 64bit PPC 用のバイナリがあるので、次はこれをためしてみよう。

MacOS 10.4 についてる SQLite のライブラリは 32bit 専用でした。
しょんぼりです。
MySQL は 64bit PPC 用のバイナリがあるので、次はこれをためしてみよう。

SQLite その後

API もわかりやすくて、いい感じだ。 ただ、INT 型とかでデータベースに保存されているデータを、Query で引っかけたときに、いちいち atoi() とか使って文字列から変換して変数に放り込むのは面倒だし遅そうなので、なんとかならないのだろうか?

SQLite を使って若干コードを書いてみた。けっこう速いぞ。
API もわかりやすくて、いい感じだ。SQL をちょっと知っているならば、API の説明についているサンプルコードと、web で見つけた何かを読めばすぐ書ける (せっかくなので、そのうちサンプルコードを載せよう…)。
ただ、INT 型とかでデータベースに保存されているデータを、Query で引っかけたときに、いちいち atoi() とか使って文字列から変換して変数に放り込むのは面倒だし遅そうなので、なんとかならないのだろうか? (どうやら、これはなんともならない、という話だが…)
INSERT INTO の前後には暗黙の BEGIN/COMMIT が付くらしいので、ひたすらデータを放り込み続ける場合は、大量の INSERT INTO の前後に 明示的に BEGIN/COMMIT を付けてやるのがよさそうで、かつ、最初は書き込みしかしない、というのであれば、それが終わってから CREATE INDEX すると検索が速くなる。
いま書いているプログラムは、最初に数十分あるいは数時間にわたって、ひたすらテーブルを作りまくるので、最初に CREATE INDEX してしまうと、インデックスを保持しながらテーブルを拡大していかねばならず、これが凶悪なまでに性能を劣化させる。しかし、最後の 1/3 か 1/4 では結局、読んだり書いたりの繰り返しになるので、ここが性能上の問題なのだが…
結局のところ、SQLite はかなり速い、という感じなのだが、PostgreSQL とか MySQL にしたら、もうすこし速くなるだろうか? DBMS と自分のアプリケーションが別のプロセスになるから、dual processor なマシンであれば良いかもしれない。
普段開発で使っているマシンは Power Macintosh G5 (2.0GHz x 2) で、多少激しくディスクをアクセスしても、アプリケーションとは別のプロセッサで OS がファイルシステムをメンテしてくれるようで、アプリケーションの CPU 使用率は 90% 以上を維持することができ(ただし、最初にインデックスを作ったりするとえらいことになり、昨日は 13 時間走らせてユーザプロセスに割り当てられた CPU time はたったの1時間だった)、けっこういい感じなのだが、シングルプロセッサな FreeBSD のシステムで走らせたら、CPU 使用率が 5% とかになってしまってびっくり。理想的には、4プロセッサくらいのシステムで OS の kernel + DBMS + アプリケーションを並列実行できる環境かな、と思う。しかし、DBMS が別のマシンで走っていたりすると、きっとネットワークがボトルネックになってダメだな。

Overworkload

SPARCstation (SS20 と SS5) が部屋に転がってるんだが、SS20 だけ残して SS5 は棄てようと思う。… MS-DOS 3.3D のパッケージなんかもあるぞ。

働き過ぎですよ、とまたいわれてしまった。
土日ずっとプログラム書いてたもんなぁ。
しかし、これは違うんだよ、梅雨でチャリ乗れないから、他にやることないんだよ。
休日に一日中筋トレしてるわけにもいかないしな。そんなことしたら死ぬ。
土曜はだいぶコードを書いたが、部屋の片付けもした。SPARCstation (SS20 と SS5) が部屋に転がってるんだが、SS20 だけ残して SS5 は棄てようと思う。いや、バチが当たるっていわれればそれまでなんだけど、うちには置き場がないのです。
あと、PC-9801 用のソフト類もけっこう出てきた。MS-DOS 3.3D のパッケージなんかもあるぞ。MS-DOS はさすがに取っておくとして、すこし整理するか…
レミングス、とか懐かしいのだけれど、いま 98 を動かせる環境にない。モニタが…
そういえば、MEGDOS ってありましたよね!

写真とか

マジで写真オリエンタルの印画紙が手に入らなかったらどうしよう。 フジクロームが手に入らなかったらどうしよう。

慶應150周年写真展、というのに出すことにした。
出展料が高かったですよ。うひー。
で、実は締め切りに間に合わなかったので、直接部室まで出しにいったら、1年生とかがいて、いろいろ聞かれた。またそのうちまとめて技術的な話をする時間をつくるけんのう、いまは簡単な説明で勘弁してや。
最近全然暗室作業とかしてないんですが、まだ印画紙とかは普通に売ってるらしい。
マジで写真撮る気になったときに、オリエンタルの印画紙が手に入らなかったらどうしよう。
フジクロームが手に入らなかったらどうしよう。
コダックの白黒フィルム、は、当分なくならない気がするので、あんまり心配してませんが。
あれですよ、フィルムをそこそこの画質でスキャンできる機材なんかはもっているわけですが、暗室で仕上げられるプリントのクオリティには及ぶべくもないです。やっぱり。だって、白黒の場合はデジタルだと 256 諧調しかないんだぜ? (スキャナ的にも、Mac 的にも 16bit/channel のデータが作れるのだが、これって Gimp じゃなくて Photoshop なら扱えるんでしょうか??)
くそー、暗室ほしいなあ。
あと、カメラクラブの後輩が、美大のひととかと一緒にやってる、カリフラフープというグループの展示会にいってきた。写真展ではなくて、いろんな作品展が一緒になった感があり、しかし空間デザインの人とかもいるらしくて非常に不思議な一体感をもった展示に仕上がっており、いい感じだった。若いっていいなー… と思った次第。
次も見に行くよ。

パイプカッター

自転車生活をしてると、たまにフォークコラムを切りたいとかシートポスト切りたいとか、そういう欲求が発生するわけで、しかし円形のパイプをきれいにノコギリで切るというのはなかなか難しい。 フォークコラムは精度が重要なのでちょっとアレだが、シートポストなんかは長すぎるなら適当に切っちまえばいいのだから、これくらいは自分で何とかしたい。

パイプカッター買った。安物で、840円とかだった。
自転車生活をしてると、たまにフォークコラムを切りたいとかシートポスト切りたいとか、そういう欲求が発生するわけで、しかし円形のパイプをきれいにノコギリで切るというのはなかなか難しい。
フォークコラムは精度が重要なのでちょっとアレだが、シートポストなんかは長すぎるなら適当に切っちまえばいいのだから、これくらいは自分で何とかしたい。なにしろ、いまの自転車はプロの手を一切借りずに組み上げてるからな。
で、パイプカッターというのはつまり、ローラーのついた万力みたいな仕掛けになっていて、パイプを挟んでぐるぐる回せるようになっているところに、これまた回転する円形の刃がついていて、ちょっとずつ締め込みながらパイプをぐるぐる回していけば、パイプを剪断することができる、というツールである。これは、ノコギリみたいに切りシロが必要にならないうえに、安物でも比較的よい精度でぐるぐる回していけば、切断面が曲がったりすることなくきれいに仕上がるという点で非常に優れている。ただし、剪断加工であるが故に多少の変形は免れないのであり、ぐるぐる回しているから変に歪むことはないものの、切断面の直径がじゃっかん膨らんだりする。これがフォークコラムを切るにはふさわしくない、という理由であり、逆に言うと適当にヤスリかなんかで削ってやれば済むシートポストの場合にはこれでいいってことだ。
家に余っていた、Tioga のアルミのシートポストはきれいに切れたので、シマノか日東あたりのシートポストを買ってきて、こいつで切って使おうと思う。ていうか、いまは普通のホリゾンタルなフレームに 350mm のシートポストがささってるんですよ。脚短いから 200mm もあれば充分なのに、あほですね。

買うより直した方がずっと安いし、なにより修理は楽しい。 で、パイプカッター買いにいった折に、撥水スプレーを500円くらいで売ってたので、吹いてみた。

別にいい傘を使っているわけではないのだが、祖父からもらった奴で、
昔のもので、けっこう丈夫にできており、なかなか壊れない。
まあ、一カ所ホネが折れたりしたが、そんなもんは直せばいいわけで。
買うより直した方がずっと安いし、なにより修理は楽しい。
で、パイプカッター買いにいった折に、撥水スプレーを500円くらいで売ってたので、吹いてみた。アクリル・シリコン系で、フッ素系ではないので、新品の傘みたく、雨水が玉になって転がる、というほどではないのだが、キレの部分に水がしみこまなくなり、振れば水が切れるので、折りたたんでカバンに放り込む場合には非常にいい感じだ。
傘のシャフトが伸びた状態でロックするための爪の引っかかり具合が悪いので、次はこれをなんとかしようと思う。

SQLite3

研究で、大量のデータをテーブルに保存する必要があり、しばらくは STL の multiset みたいなやつを、自分で memory conservative な実装に書き直してメモリ上に展開していたのだけれど、いよいよメモリの容量がしんどくなってきた。 具体的にどれくらいしんどいかというと、32bit な環境では到底ダメで、64bit な環境で 16GB メモリを積んでも、ぎりぎり足りるか足りないかな感じ。

研究で、大量のデータをテーブルに保存する必要があり、しばらくは STL の multiset みたいなやつを、自分で memory conservative な実装に書き直してメモリ上に展開していたのだけれど、いよいよメモリの容量がしんどくなってきた。具体的にどれくらいしんどいかというと、32bit な環境では到底ダメで、64bit な環境で 16GB メモリを積んでも、ぎりぎり足りるか足りないかな感じ。これからもっとデータセットを大きくしたいので、もうメモリじゃ無理だ。
まあ、そんなわけで、最初は小さいデータセットをディスク上に展開することを考えてみた。で、Key:Value な表がひとつあればそれだけで幸せなので、こういうので一番簡単そう、というかよく知っているのはBerkeley DB なのだが、こいつは全然ダメだった。後から考えると、もしかしたら index を付ける方法があるのかもしれないのだが、それがよくわからず、結局のところ検索がうんざりするほど遅くて、実用には耐えないという判断。Berkeley DB を採用した理由は、API が簡単、というのはもちろんなのだが、PostgreSQL だとか MySQL のような RDBMS のように、データの実体は DBMS が管理していてユーザが直接ファイルを消したり移動したりできない、という状況がイヤだったので。こういう場合、DBMS への充分なアクセス権がないユーザは table を作ることさえできないしね。
で、いろいろ調べていたら、SQLite というのがあることを思い出した。こいつは、Berkeley DB と同じく、任意のところにファイルを作ってそいつをデータベースの実体にすることができるし、ライブラリをリンクしてやれば自分のプログラムが DBMS になる、という形式の SQL engine だ。しかも、性能はそれなりに良いらしく、少なくともテーブルの規模がそこそこならば MySQL とあんまりかわんない、というベンチマークも Web に落ちていた。こりゃいけそうだ。しかも、最近の MacOS X の /usr/{include,lib} にはこいつが最初から入ってるんですよ!
というわけで、いまテスト中。ほぼ完全に SQL92 Compliant で、index も定義できるし、けっこういい感じだ。

Fumy

全日本で別府史之が勝った。

全日本で別府史之が勝った。圧勝。
Discovery Channel に、日本のナショナルチームのジャージを着た選手が入るんですよ。
すっげえぜ!
Team Vang の活躍も目覚ましいし、
欧州ロードレース界に対する強烈なアピールになりますね!

あうー

梅雨の間にガンガン仕事するので、梅雨が明けたら休みください、ボス。… 梅雨が明ける前にぶっ倒れそうですが。

峠へ行きたいぜ。
梅雨の間にガンガン仕事するので、梅雨が明けたら休みください、ボス。
… 梅雨が明ける前にぶっ倒れそうですが。