le Tour と overdrive

ドーピング騒動で有力選手が消えまくりの Tour だけれど、
それでもかなり面白い感じになってきた。山岳が楽しみだ。
本屋で、少年コミックで連載中の Overdrive というマンガを買ってきた。
シャカリキ、と同じくらい熱いロードレース漫画な感じ。
読みながらいろんなことを考えちゃったよ。
日本にも若手選手が育ちますように。
ああもう、峠いきてぇよ!
とりあえず筋トレ。

diskless

Intel の Ethernet カードに載っている PXE とやらを使って、FreeBSD を diskless で使う環境を作ってみた。 /boot/pxeboot とかいうのが最初からあるので、- TFTP の設定をする- DHCP (BOOTP でも) の設定をする- NFS root な環境を作る- おしまいな感じ。

Intel の Ethernet カードに載っている PXE とやらを使って、FreeBSD を diskless で使う環境を作ってみた。
/boot/pxeboot とかいうのが最初からあるので、
– TFTP の設定をする
– DHCP (BOOTP でも) の設定をする
– NFS root な環境を作る
– おしまい
な感じ。けっこうラクだ。ローカルにディスクを持っているマシンは、そこを swap として使えるように細工してみた。
/tmp とか /var/run, /var/log あたりは別々にしたいのだが、どうしたらいいだろう…

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 なら扱えるんでしょうか??)
くそー、暗室ほしいなあ。
あと、カメラクラブの後輩が、美大のひととかと一緒にやってる、カリフラフープというグループの展示会にいってきた。写真展ではなくて、いろんな作品展が一緒になった感があり、しかし空間デザインの人とかもいるらしくて非常に不思議な一体感をもった展示に仕上がっており、いい感じだった。若いっていいなー… と思った次第。
次も見に行くよ。