perl
の Date::Calc
もぢゅーるなければ,
そもそもぎょーむ日誌とか更新できなかったり.
で,
Vine 3.1 の perl-**.rpm
系は腐れぎみだ.
しょうがないので
sudo perl -MCPAN -e shell
で
install Date::Calc
などとしてみる
……
がそもそも libnet
がおかしいので,
まずはこれを手動でインストール,
とか.
ぢりぢりと復旧する.
X
起動したら一瞬で死んだ.
やはりダメか
……
しかし,
この異常挙動は修理工場で再現が難しいというか,
「異常ナシでした」
とつっかえされそうな気がする.
sudo /etc/init.d/httpd restart
から 24 時間以上が経過してるのに問題なく
データやりとりできている.
不思議だ.
しかも CGIwrap
無視した方式でも CGI プログラムよびだせる.
うーむ
……
いまいち挙動が把握できてないんだけど,
昨日までの相違といえば,
現在は
mod_perl.c
つかってない,
というぐらいしか思いつかないんだが.
これって「挙動の時間差」に何か関係あるはずだ,
ということで使うのやめてみたんだけどね.
Note that it's impossible to run suEXEC and cgiwrap extensions under mod_perl 1.0.とのこと (ただし腐れ TurboLinux Appliance Server 1 が使ってるのは
mod_perl-1.26-4
だ
……
これは mod_perl 1.0
系,
とみなされる?).
cgiwrap
と suid
の関係をもうちょい調べる.
おそらくいま実験に使ってるユーザーアカウントは
/etc/group
で少し権限を強めてやったから
(8/11 の記録),
.../cgiwrapDir/cgiwrap/...
かませなくても CGI プログラムが呼び出せてるんではないかな.
X
など動かしたりすると 1. にもどる
pairs()
してみる.
下の図は
(ここに転載するため)
縮小しすぎてるんで何がなんだかわけわかんないけど.
optim()
とか使えばパラメーターの最尤推定できる.
ここまでは,
ぢつはそれほど難しくない.
難しいのはこの推定システムにおいて
モデル選択とかてぎわよくやらせるプログラム作りなんだよね
……
いつもながら.
glm()
悪用ワザのさらに応用篇である.