サーバーのsubversionを1.6.2にしたらtracで以下のエラーになった。

Warning: Can’t synchronize with the repository
(Unsupported version control system “svn”: “No module named svn”
). Look in the Trac log for more information.

ログを見たらmod_pythonモジュールがリポジトリと同期できないよ、
って言ってるみたい。

# cd /usr/local/src/subversion-1.6.2
# make swig-py
# make install-swig-py
# vim [site-packagesディレクトリ]/svn-python.pth
/usr/local/lib/svn-python
# ln -s /usr/local/lib/python2.6/site-packages/svn [site-packagesディレクトリ]
# ln -s /usr/local/lib/python2.6/site-packages/libsvn [site-packagesディレクトリ]

ベンチマークしてみるとPloneはやっぱり重たいです。

zopeのトップページをベンチマークすると秒間63くらい
リクエストをさばいてます。

# ab -n 100 -c 10 http://192.168.0.10:8080/
This is ApacheBench, Version 2.0.40-dev < $Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.0.10 (be patient)…..done

Server Software: Zope/(Zope
Server Hostname: 192.168.0.10
Server Port: 8080

Document Path: /
Document Length: 2717 bytes

Concurrency Level: 10
Time taken for tests: 1.575463 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 294000 bytes
HTML transferred: 271700 bytes
Requests per second: 63.47 [#/sec] (mean)
Time per request: 157.546 [ms] (mean)
Time per request: 15.755 [ms] (mean, across all concurrent requests)
Transfer rate: 182.17 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 21 147 37.7 152 301
Waiting: 7 138 38.7 142 292
Total: 21 147 37.7 152 301

Percentage of the requests served within a certain time (ms)
50% 152
66% 153
75% 153
80% 159
90% 168
95% 169
98% 298
99% 301
100% 301 (longest request)

ところがploneサイトをベンチマークすると秒間２リクエストくらい
しかさばけないようです。

# ab -n 100 -c 10 http://192.168.0.10:8080/
This is ApacheBench, Version 2.0.40-dev < $Revision: 1.146 $>
apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.0.10 (be patient)…..done

Server Software: Zope/(Zope
Server Hostname: 192.168.0.10
Server Port: 8080

Document Path: /demo1
Document Length: 20658 bytes

Concurrency Level: 10
Time taken for tests: 44.151914 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2093600 bytes
HTML transferred: 2065800 bytes
Requests per second: 2.26 [#/sec] (mean)
Time per request: 4415.191 [ms] (mean)
Time per request: 441.519 [ms] (mean, across all concurrent requests)
Transfer rate: 46.29 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 619 4214 7093.6 2820 44069
Waiting: 536 4207 7094.5 2815 44067
Total: 620 4214 7093.6 2820 44069

Percentage of the requests served within a certain time (ms)
50% 2820
66% 3551
75% 4113
80% 4259
90% 4532
95% 5713
98% 43913
99% 44069
100% 44069 (longest request)

Ploneは重たいですがZope自体は自前のWEBサーバを持っていることも
あり、予想以上に軽いことがわかりました。

久しぶりにploneの環境を作ってみた。
知らない間に3.0までバージョンが上がっている。

FreeBSDの場合はportsから最新のPythonを入れると2.5.1なので
/usr/opt/python24 にPython2.4.4を別途入れる。FreeBSDの
スレッドスタックはデフォルトで小さすぎるのでWANT_HUGE_STACK_SIZE
オプションを付けてmakeしないと、zopeのインスタンスホームに
python.coreができることになってしまうと INSTALL.txtに書いてある。

# ./configure –with-threads
# make WANT_HUGE_STACK_SIZE=yes
# make install

ところがこれではうまくいかなかった。スレッドのスタックが大きく
なっていないみたいだ。Pythonのソースをgrepしても
そのオプションは見つからない。

仕方ないのでportsのMakefileを見ると、HUGE_STACK_SIZE=yes だと
CFLAGに -DTHREAD_STACK_SIZE=0x100000 としている。どうもこっちの
方が確実そうなので、configureスクリプトが生成したMakefileの
OPTに-DTHREAD_STACK_SIZE=0x100000 を足してみた。そして普通に
make, make install 。今度は大丈夫そうだ。

スレッドスタックの大きさの確認方法は以下のとおり。
結果が1000ならたぶんうまくいく、ということらしい。
おそらくFreeBSD6.xなどでは初めから問題ないみたいなのだが、
サーバがFreeBSD4.11(古すぎ)なので問題がみたい。
「How can I make sure my BSD Python has enough stack?」

# python
Python 2.4.4 (#1, Sep 5 2007, 14:15:24)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type “help”, “copyright”, “credits” or “license” for more information.
>>> import sys
>>> sys.getrecursionlimit()
1000

Plone3.0を動かす場合に必要になるPythonライブラリを先に入れておく。

• PIL(Python Imaging Library) 1.1.5 or newer
• Python ElementTree

PloneはベースになるZopeのバージョンにうるさい。Plone3.0の場合は
Zopeは2.10.4以上でないと動かない。Zope2.11.x系列やZope3.0系列は
だめ。今回は /usr/opt/zope2.10.4 にインストールする。

# cd /usr/local/src
# wget http://www.zope.org/Products/Zope/2.10.4/Zope-2.10.4-final.tgz
# tar xvfz Zope-2.10.4-final.tgz
# cd Zope-2.10.4-final
# ./configure –prefix=/usr/opt/zope2.10.4
–with-python=/usr/opt/python24/bin/python
–optimize
# make
# make install

やっとPlone3.0のインストールだ。/usr/opt/Plone-3.0にインストール
することにした。Productsとlibの中身をそれぞれコピーしてもいいけど
たぶん将来見たときPloneのどのバージョンかわからなくなるので、
シンボリックリンクの方が好み。

# cd /usr/opt
# wget http://plone.googlecode.com/files/Plone-3.0.tar.gz
# tar xvfz Plone-3.0.tar.gz
# cd Plone-3.0

# ln -s /usr/opt/Plone-3.0/lib/python/*
/usr/opt/zope2.10.4/lib/python/

# ln -s /usr/opt/Plone-3.0/Products/*
/usr/opt/zope2.10.4/Products/

ここまで来たらZopeのインスタンスを作れる。

# /usr/opt/zope2.10.4/bin/mkzopeinstance.py

このままではアクセスするのにポート番号が必要になるので、
適当なホスト名をDNSに設定して、apache側でProxyPassディレクティブ
を使って、Proxy経由でアクセスできるようにした方がかっこいいかも。

http://192.168.0.10:8080/

httpd.conf

ServerName plonedemo.hogehoge.com
ProxyPass / http://localhost:8080/VirtualHostBase/http/plonedemo.hogehoge.com:80/V
irtualHostRoot/

で最初にアクセスするとなんだか30秒近く待たされる。重すぎだろ・・

でもそれ以降はまあまあサクサク動きます。

久し振りにFreeBSD4.11で構築しているサーバ上でportsからmakeしたら
なんだかエラーがたくさん出て構築できなくなっていた。2月に4系は
portsのサポートの切れたので、ぼちぼち6系に引っ越さないといけないな。

[root@sv]~# portsdb -Uu
Updating the ports index … Generating INDEX.tmp - please wait.."/usr/ports/audio/gstreamer-plugins-esound/../../
multimedia/gstreamer-plugins/Makefile.common”, line 392: Malformed conditional (${gst_${GST_PLUGIN}_GCONF_SCHEMAS}!="")
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 396: Malformed conditional (${gst_${GST_PLUGIN}_USE_SDL}!="")
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 398: if-less endif
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 398: Need an operator
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 419: if-less endif
“/usr/ports/audio/gstreamer-plugins-esound/../../multimedia/
gstreamer-plugins/Makefile.common”, line 419: Need an operator
make: fatal errors encountered – cannot continue
===> audio/gstreamer-plugins-esound failed
*** Error code 1
1 error

FreeBSDの4系ではこれらの変数が使われる時にはまだ初期化されて
いないようだ。

portsのメーリングリストにパッチが公開されていた。

ports/104500: [PATCH] multimedia/gstreamer-plugins/Makefile.common breaks make index

ruby on rails をFreeBSDで試したメモ。

rubyとgemがインストールされているシステムならばrailsの
インストールは簡単だ。gemがない場合はここからダウンロードする。

# gem install rails –remote –include-dependencies

これだけで依存関係を解決してインストールしてくれる。

データベースにはMySQLかPostgreSQLが良いだろう。今の時点では
SQLiteはマイグレーションに対応していない。ここではMySQL/Ruby
を試してみる。

# gem install mysql –with-mysql-dir=/usr/opt/mysql50

最初「gem install mysql」してハマった。MySQLのパスが
/usr/opt/mysql50と普通と違ったのでリンクがうまくいって
なかった。でも特にエラーが出なかったので気がつかなかった。
railsを実行してみると

その後、上記のコマンドで無事MySQL/Rubyがロードできるように
なった。

scaffoldを使ってすぐにおかしいと気がついたのはレコードの
削除ができないってこと。PostgreSQL8.1.4とSQLite3で試して
みたがやはり削除できない。エラーも出ないし、何も起こらない。
実はrailsでscaffoldで生成されたページからレコードを削除する
ためにはブラウザにJavaScriptが必要だった。FirefoxのNoScript
エクステンションがアダとなった形だ。

最初はWEBRickで簡単なアプリケーションを作ってみた。そして
ベンチマークしてみるとWEBrickだと僕のPC(AthronXP1500程度)で
秒間5回前後のリクエストに応えられた。apacheからXOOOPSを使う
よりも少し軽い感じ。

次にrailsをCGIとしてベンチマークしてみると予想通り使い物に
ならない重さで、秒間0.3回程度のリクエスト処理が限界だった。
そうなると1ページ出力するのに3秒以上かかるわけでストレスが
たまりまくりとなる。

仕方ないのでapache2にFastCGIを組み込んでみたら秒間5回前後の
リクエストを処理できるようになった。これならまあ使える。

仕事で関わっているあるAccess+MySQLのシステムのデータベースを
MySQL-3.23からMySQL-5.0.xへとアップグレードした。AccessとMySQL-
5.0.x系を使う際の問題点のまとめ。

問題１:Accessが頻繁に落ちるようになる
前回触れた問題だがまだ直っていない(もう直してもらえないかも？)

問題２：最新のMySQL ODBCドライバではMySQLのリンクテーブル(文字コード cp932)が不安定になる
普通に最新のMySQL ODBCドライバをインストールした状態で、Accessを
起動してテーブルビューでMySQLリンクテーブルを見ると、開けないもの
がある。

このシステムの文字コードがcp932であることも関係あるかもしれない。
おそらくMySQLに限らずShift_JIS系の文字コードは使うべきではないの
だろう。しかし「set names cp932;」などとしても問題は解決しない。

対策はmyodbc3.dll をsjis対応の古いものに差し替えるしかない。

上記の問題はあるものの解決可能なので、ストアドプロシージャや
VIEW、クライアントの文字コード指定(set names)などバージョン
アップでできることの幅が増えた。

blosxom/pyblosxom以外にもPHPで実装されたblosxom.phpというのがある。

あまり開発は活発ではないようだけどインストールして試してみた。

blosxom/pyblosxomと比較すると

+ まだプラグイン(moduleと呼んでる)があまりない
+ トラックバックを初期状態で含んでいる

○プラグインの実装
blosxom.phpのプラグインはちょっと変わっている。プラグインの
ファイルは「plugin.php」のような名前だ。(py)blosxomとは違って
プラグインはクラスやパッケージではなく、ただの関数をいくつか
定義するだけだ。

プラグインを登録するにはディレクトリ(modules）に入れるだけで
なく、設定ファイル(conf.php)の $modules という名前の配列に
登録しておかないといけない。

PHP自体をwikipediaと同じ手法である程度高速化することは
できたけど、さらに速くならないのかなとgoogleで調べると
「XOOPS 高速化」で最初に出てくるのが「おじさんの備忘録」
というサイトだ。

最初「ん？」と思ったのが、このサイトはMovableTypeでできている
ようだが、パーマリンクのURLを見ると .php で終わっている？
なんだか不思議だなと思った。

閑話休題。
そこで初めて知ったのはXOOPSのリダイレクト画面をなくすことで
高速化できるという記事。このhackはすごく良いアイデアだと思う。
このサイトのXOOPSにも導入してみた。

リダイレクトの画面がない分、体感的に明らかに速い。

blosxomで作っているサイトを軽くするためにCGIスクリプトの
呼び出しを極力減らそうと思って静的生成にしてみた。

設定自体はとても簡単だ。/home/me/public_html/blosxom が
blosxomのディレクトリだとすると別途、静的なページ用の
ディレクトリ(例えば /home/me/public_html/blog )を作り
以下のように設定するだけだ。

# — Static Rendering —–
$static_dir = ‘/home/me/public_html/blog’;
$static_password = “secret”;
@static_flavours = qw/html rss/;
$static_entries = 1;

○静的なページ生成の問題
しかしいきなり問題が発生した。デフォルト設定のままで $url
を自動設定(すなわち空文字)にしていたら、静的に生成したページの
カレンダやカテゴリ、アーカイブからエントリへのリンクがおかしい。
ホスト名がなぜか「localhost」になっている。

コードを見てると CGIモジュールのurl()関数でホスト名を
取得するんだけど、コマンドラインから静的なページを
生成するため、localhost が入ってしまう。

○$urlを直接指定したら？
それだと使い物にならないので $url を空文字列からディレクトリ
(静的なページを配置するディレクトリ)にしたら、静的なページ側
では問題なくなったけれど、今度は動的なblosxom.cgiの方で、
カレンダやカテゴリ、アーカイブからエントリへのリンクが
静的なページに向いてしまうので、これまた具合が悪い。

僕がやりたいのは、動的なディレクトリではすべてのリンクが
動的ページを指していて、別途公開用の静的なページでは
トラックバックやページ編集(WikiEditish)以外のページは
静的なページを指して欲しいのだ。

○結論：別の変数が必要だ
スクリプトの100行目付近で $static_or_dynamic という変数が
セットされるので、この中身によって$urlを変える必要がある。
$urlは空にして自動設定にしておいて、以下のようにする。

# コードの上の方で定義しておく
$static_url = “http://www.mysite.com/blog”; # 静的ページのURL

# $static_or_dynamic が定義された後、$urlが空ならば
# おかしくなるのは静的(static)の場合だけ
$url = $static_url if ($static_or_dynamic
eq “static” and $url =~ m!http://localhost!);

そしてフレーバー内では $url を使うことでなんとか動いてます。

でもかなり枯れてきているはずのblosxom2でこんな修正が必要とも
思えない。なんだか根本的な理解不足があるような気がしてならない。

MozillaでExtensionを管理する方法を
いろいろと探していたら見つけた。

「ExtensionManager」というExtensionを
インストールするとFirebirdみたいに
Extensionを管理できるようになった。

なんか最近、大量のトラックバックスパムが来るようになった。
wordpressのモジュール 0.3.xでは対処方法もなさそうだったので
0.5.x系列にバージョンアップした。

wordpressのモジュールをアップデートする方法はのぶのぶさんの
サイトの掲示板に情報があった。モジュールを入れ替えてアップ
デートするだけでいけるみたい。

しかし・・なぜか僕の環境ではうまくいかなかった。アップデートで
エラーになってしまった。さらにアップデート失敗時に configテーブル
のwp_関連の値が消えてしまい、中途半端な状態で入れることも消すこと
もできなくなってしまった。

この際なのでXOOPSを最新版でまっさらにして、wordpressを入れなおした。
それからwp_categoriesとwp_postsをmysqldumpでデータのみSQLにした
ものからインポートして、一部不整合になるフィールド(post_author
など)をコンソールから直してなんとか復旧した。

ちなみに0.5.xで使えるようになったブラックリストはかなり良さそう。
ほとんどのトラックバックスパムをはじいてくれるようになった。

MovableType3.2ja2を以前インストールしていて
久しぶりに動かしてみると、動作しない・・

SQLiteを3.2.5 —> 3.3.4へと何度かアップデート
しているうちに動作しなくなったようだ。

原因は PerlのDBD::SQLite自体が現在のSQLite3.3.4を
扱うことができないようだ。単純にselectするだけの
小さなスクリプトでさえエラーとなり動作しない。

blosxomを高速化したくて、perlのモジュールである
CGI::SpeedyCGIを導入したがページが壊れてしまうので
デバッグしてみた。

Since globals retain their values between runs, the best way to do this is to store the connection in a global variable, then check on each run to see if that variable is already defined.

CGI::SpeedyCGIのマニュアルによると、perlインタプリタを使い
まわすために、グローバル変数は保持される旨が書いてあった。

これを利用すればデータベースのコネクションを使いまわせると
いう話なんだけど、blosxomの出力がかぶるのも同じ原因だと
思われる。

そこでソースを見てみると、blosxomは出力をstaticか
dynamicか切り替えられるようになってるんだけど、
dynamicの場合には出力を貯める $output という変数が
初期化されていないことがわかった。通常のCGIであれば
これで問題ないんだけど、mod_perlやSpeedyCGIの場合は
ここでおかしくなる。mod_perlの場合はさらに制限がきついので
もっと修正が必要だと思われる(__DATA__とか使ってるし・・)

staticの場合にはちゃんと $output は初期化されている。

なのでスクリプト冒頭で $output が use vars される時に

$output = ‘’ if defined($output);

すればSpeedyCGIでも問題なく動くようになった。

早速ベンチしてみると、プラグインやフレーバーなしの
blosxomの場合、apacheからCGIとして起動すると
秒間３回程度のリクエストに応えられるのに比べて、
CGI::SpeedyCGIを利用した場合は１５回程度のリクエストを
こなせるようになった。

○XOOPSは素晴らしいけど、大きくて重たい
XOOPSが好きでモジュールのブログ「wordpress me」を愛用してる
んだけど、体感速度ではかなりレスポンスが悪い気がする。

ただデザパタの関係で細分化されたファイルが悪いわけでは
なさそうだ。なぜなら僕はFreeBSDを使っているので、ファイルは
ディスクキャッシュにほとんどが入るはずだけど、それでも重い。

小さくて軽いブログツールである blosxomとベンチマークをとって
比較してみると、驚いたことにサーバがこなしてるリクエストは
あまりかわらない。blosxomが平均して秒間1.5回くらいなのに対し、
XOOPSは1.8回程度なのだ。ただPHPはapacheのモジュールにしてるし、
perlはCGIから起動しているので単純に比較できないが、体感では
blosxomの方がはるかに軽い印象がある。

僕の使ってるPCでは通常のhtmlなどの静的なページならば秒間
700回以上のリクエストに応えることができることを考えると
いかにスクリプトが重たいかよくわかる。

○XOOPSのキャッシング機能を有効にしてみたら？
XOOPSはsmartyのキャッシュがもともと効いてるのに加えて、
モジュール毎にキャッシュを設定できるので、ブログを
キャッシングするように設定して計測すると大体秒間4回ほどの
リクエストをこなせるようになった。(約２倍の性能向上)

○apache1 + PHPモジュールの方で抜本的対策
XOOPSだけだとあまり高速化は望めないので、apacheに組み込む
PHPモジュール(libphp4.so)の方にキャッシングモジュールを
使って高速化してみよう。

現在、出回っているモジュールは以下のようなものだ。

• Zend Accelerator - Zendの純正。売り物。
• Turck MMCache for PHP - ロシア製。このサイトでも一年ほど前から使用。しかし開発は2003年で停止。php5はだめみたい。
• ionCube PHP Accelerator - フリー。たぶんZendを除けば最も高性能。しかし2005年12月時点ではphp5は動かない。
• EAccelerator - MMCacheからフォークしたらしい。これが今後最有力候補かと思ったけど、php5では「動いた」という報告があるけれど正式にはサポートされていない。米国Yahoo!で使われていることで有名。
• APC - オープンソース！ビルドはできるがまだちゃんと動かせない・・なぜだろう
• After Burner - オープンソース。しかしサイトごと消滅。
• PHP-Mix - 未踏ソフトウェアの助成で開発された国産みたいだけど、2002年で開発ストップ。PHPの一部しかサポートしないらしく、まったく使い物にならない。

このサーバでは前から Turck MMCacheを使っているんだけど、
これでベンチマークしてみる。全部動的なページにしても
XOOPSだと秒間3-4回のリクエストをこなすことができた。

なぜ Turck MMCacheが良いのか？それはwikipediaで使ってるから
というだけの理由なんです。興味のある人は「キャッシュ戦略」をご覧ください。

最近、ブログツール blosxom に凝っている。
別に負荷もたいしたことないサーバなので別にいいんだけど
一応、apache+CGIを高速化してみた。

まずblosxomにプラグインなしでフレーバーだけ入れた状態で
ベンチマークしてみると、平均で秒間1.3回程度しか
リクエストをこなせない。mod_perlにすればかなり改善
されるかもしれないが、Perl-CGIはあまり使わないので
apacheのプロセスが肥大するのはイヤだと思っていた。

2chのread.cgi再開発プロジェクトのページで CPANの
CGI::SpeedyCGI-2.22 というモジュールの存在を知った。

これは単純なキャッシングではなくて、Perlのインタプリタを
何度も使いまわすことが可能になる。

これは基本的なインストールではapacheに組み込む必要は
ない(小さなCで書かれたコードをapacheモジュールとして
組み込むこともできる)。

使い方は簡単で、スクリプトの先頭の

#!/usr/local/bin/perl

などの部分を以下のようにするだけでよい。

#!/usr/local/bin/speedy

blosxomでベンチマークしてみると、speedyを使うと
秒間で13?15回リクエストに応えられるようになった。
実に10倍以上の高速化が実現できたわけだ。

—-
2005年12月追記
blosxomは CGI::Speedyではおかしくなることが判明。
具体的にはページをロードするたびに余計な改行が増えたり、
ページが壊れてしまうようだ。ググってみたところ、blosxomは
mod_perlでもうまく動かないらしく、blosxomの高速化は失敗に
終わった。

pythonのテンプレート・エンジンをいくつか試してみた。

PHPの場合はsmartyが人気があるけど、それはシンプルさと、
やはりキャッシュによる高速性だろう。ところがPythonの
場合はもともとすべてのスクリプトは一度実行すると
コンパイル済の状態でキャッシュされる(pycファイル)ので、
そもそもテンプレートエンジンにはキャッシュの機能は不要だ。

一番有名なのは Cheetah だと思う。これはPython専用。
テンプレート側

<td><a href="mailto:$client.email">$client.email</a></td>

書式はベタに変数名を埋め込むような形式だ。

———————————————————–
clearsilverというのもある。これはかなり強力であり、
pythonはもちろん、C/C++,Perlなどでもテンプレート
として使える。書式も直感的にわかりやすい。言語に関係なく
テンプレートを共有できるのはすごいメリットだ。
PHPのsmartyや、PerlのHTML::Templateに書式が似たテンプレート
エンジンを探す必要はなくなる。

テンプレート側

< ?cs var:CGI.user.name ?>

スクリプト側

“CGI.user.name”, “yamada")

———————————————————–
PerlのHTML::Templateと同じ名前の htmltemplate という
テンプレートエンジンもある。

テンプレート側

<a href="" node="con:link">LINK</a>

これはちょっと複雑だ。ループを処理するためには自前で
renderTemplateという関数を定義する必要があったりする。

SQLiteの管理のためにSQLiteManager-1.1.1を使いたいと
思っていたが、SQLiteCheckOk関数でエラーとなり、
動かなかった。今日はちょっとその原因を調べてみた。

ソースを見て納得だが、この問題はFreeBSD上で、SQLite
Managerを使う人には100%起こる問題のはずだ。
理由は以下。

include/common.lib.php の90行目あたりに、

$SQL_SERVER_OS = strtoupper(substr(PHP_OS, 0, 3));
if($SQL_SERVER_OS == ‘WIN’) { $preffix= ‘php_’; $extName = ’sqlite’; $suffix = ‘.d
ll’; }
elseif(($SQL_SERVER_OS == ‘LIN’) || ($SQL_SERVER_OS == ‘DAR’)) { $preffix= ‘’; $ex
tName = ’sqlite’; $suffix = ‘.so’; }

こうゆうコードがある。FreeBSDでは、PHP_OS定数の値は「FreeBSD」
なので最初の三文字は「FRE」である。これでは条件にマッチしない。
条件にマッチせずしかもelseがないので、ここでエラーになる。

以下のように修正すれば、ちゃんと動いた。

$SQL_SERVER_OS = strtoupper(substr(PHP_OS, 0, 3));
if($SQL_SERVER_OS == ‘WIN’) {
$preffix= ‘php_’; $extName = ’sqlite’; $suffix = ‘.dll’;
} else {
$preffix= ‘’; $extName = ’sqlite’; $suffix = ‘.so’;
}

ここ数日、アクセスからMySQLを使おうとODBCドライバ経由で
テーブルをリンクしようとすると、Accessがクラッシュする
ことに気が付いた。全部の.mdbファイル共通の症状だ。

環境：
Windows2000SP4 + Microsoft Access2003 + MyODBC 3.51.06

問題が発生したため、Microsoft Office Access を終了します。ご不便をおかけして申し訳ありません。

マイクロソフトのドキュメントに[ACC2003] [HowTo] Windows 2000 オペレーティング システムで Access 2003 を実行した場合に発生する Access 2003 の致命的なシステム エラーのトラブルシューティング方法というそのものズバリのものがあるが解決には役立たなかった。

調べてみると原因はMySQL Bugsに報告されているのを見つけた。
http://bugs.mysql.com/bug.php?id=9932

原因：
MicrosoftのJet 4.0.9025.0 にバグがあるようだ。
MySQLやODBCドライバには罪はない。その証拠に直すのは
簡単だ。Access2003を最新版にしていたり、Access2000で
あってもJetエンジンを最新版(SP8)にするような人には
この現象が発生する。

対策：
msjet40.dllを検索して、バージョンを調べて１つ古いもの
(ハードディスクのどこかに保存されているはず)に
ダウングレードすればよい。

僕の場合は１つ古いmsjet40.dllが
C:WINNTsoftwareDistribution7ff485ee87cbb06315afe3 …
の下に見つかったので、これで

C:WINNTsystem32
C:WINNTsystem32dllcache

の中のmsjet40.dllを上書きしたら、すべての問題が解決した。

FreeBSD4.11にjdk1.5を使おうと思ったけど、

WARNING:
WARNING: This is ALPHA quality software, and suitable for testing ONLY!
WARNING:

まだアルファ程度の品質とのことだ。nativeに
動くようになって嬉しいけど、jdk1.5のインストールのためにはlinuxエミュレーションを有効にしておいて、linux版のjdk1.4もインストールする必要があった。

Microsoft Office Professional Edition 2003 日本語版は、kakaku.comの最安値でも 46500円。これがPC20台の事務所ならば90万円以上することになる。(実際にはボリューム・ライセンスで少しだけ安くなるかもしれないが・・)

それならば Office developer EditionについているAccessランタイム再配布権を使えば、どうだろうか？8万円くらいのdeveloper Editionを１つだけ買えば、あとはパッケージを作成して配布できる。クライアント側にはAccessはもちろん、Office自体が不要になるらしい。これはいい感じだが話しがうますぎるように思ったので、どんな制限があるのか調べてみた。

そうしたら、現在検討中のAccessアプリケーションの致命傷になる制限がやはりあった。それはランタイムでは「new Access.Application」や「CreateObject」を使って、新規インスタンスを生成できない。これは痛い。なぜならコアなフォームやレポートを複数のmdbで共有する仕様になっており、ランタイムを使うと全部のmdbにいちいちフォームやレポートが別途必要となり、共有できなくなってしまう。

単純な単体のmdb,mdeならば、ランタイムも検討の余地があるのだろうけど。

そういえば今日、ヒープ領域のバッファオーバーフローの脆弱性があることが発表された、我等が OpenOffice.org だけど、ver2のベータ版にはBaseというAccessのようなデータベース作成管理・アプリケーションが付属している。

今現在でも、テーブル、クエリ、フォーム、レポートは使うことができる。

テーブルについては、Accessのmdbはもちろん、MySQLやOracleなど10種類程度のデータベース形式を選択できるようになっている。

クエリについては、かなりAccessに似てる。

簡単なテーブルとクエリ、フォームを作ってみたが、Baseがあれば本当に・・本当にMS Office が不要になる日は近い、と感じた。