基本的に落書き帳/メモ帳/備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。
Request=GetServer MAC-Address=************ Addl-MAC-Address= Node-Type=Workstationだそうで。 ずばり Altiris で当たりらしい。 MS-Windows で、 複数の計算機に同じソフトウェアを一斉にインストールして管理したり、 複数の計算機で同じ環境を共用したり、 するソフトウェアらしい。 ……。 HP の計算機は、 リカバリやアップデートに Altiris を使っているっぽい記述がある……、 そちらか?、 MAC も HP の計算機だし。
cannot set up thread-local storage: cannot set up LDT for thread-local storageとか、 compat.linux.osrelease を古くすると
cannot set up thread-local storage: kernel too old for thread-local storage supportとか、 出て拒絶される。 てきとーに検索した結果によると、 FreeBSD 6系列の BSD/Linux (amd64) では、TLS(SSLではない)非対応らしい。 他のディストロでも、kernel 2.4系だと非対応らしい。 ja-acroread7 に戻すしかないらしい。 Sat,25 Oct,2008に続く。
Pango-WARNING **: failed to create cairo scaled font, expect ugly output. the offending font is 'Sazanami Gothic 11' Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Sazanami Gothic 11', text='A' Pango-WARNING **: pango_font_get_glyph_extents called with null font argument, expect ugly outputとか出て、一部の字体(漣)の文字全部が豆腐になるか、 Firefox だと 「漣フォントが使えないから代替フォントを適当に探して使うよ」 とか言う感じのメッセージがでて違うフォントで表示された。
fc-cache -fvとかやっても、治らない。 web で検索しても、 Ubuntu系 mailing-list で「fc-cache やったか?(原文は英語)」 と言う記事しか見つからない。 手がかりが見つからないまま2時間後、突然閃いた。 ${HOME}/.fonts.cache-1 を消したら治った。 どうやら、昨日クラッシュした時に、 壊れていた(書き込み領域の確保だけした状態に戻った)らしい。 ……、fontconfig/Xft2 がらみの状態は、fc-list で確認できるらしい。
ガンヴァルケンを検索している時に見つけた、
GUN ARMS を動かしてみた。
擬似3D表示(モデリング計算はフル3Dの様ですが)の
横ビュー全方位任意スクロールのシューティングゲーム。
コンセプトやゲームシステムは、こういうの大好き。
MS-Windows XP 以降だと DEP 保護違反が出るので、
DEP 無視リストに登録しなければならない。
逆アセンブルして見た感じでは、
圧縮か、あるいは改造に対するプロテクトか暗号化か、
もしくはインタプリタ処理用の何か、が入っているらしく、
ランチャ起動後に
本体バイナリをデータセグメントに読み込んで変換処理?を行い、
データセグメント上のバイナリコードを実行している模様。
DEP違反が出て当たり前な、行儀の悪い構造。
……。
もしかして HSP - Hot Soup Processor で書かれている?。
……。
ファイル構成からすると、
HSP2 と Forsythia3D と dsoundex を使って書かれているっぽい
(確証無し)。
となると、DEP違反とか後述の痛いバグとかはどれも、HSP2 の問題か……。
コンティニューが保存できず、コンティニュー回数も2回まで。
時々、MS-Windows を巻き添えにクラッシュしてブルーバックになり、
ディスククラッシュする……、
コンティニューが保存できないから、また1面の先頭からやりなおし。
時々、壁にめり込んだり、床下に突き抜けて無限に落下し続けたりして、
ゲームの終了以外、何もできなくなる……、
ゲーム終了すると、
コンティニューが保存できないから、また1面の先頭からやりなおし。
落下と横ブーストを同時に行うと、特に壁にめり込みやすい気がする。
あと、壁に張り付いた状態で爆風をガードすると、
これまた壁にめり込みやすい。
何だかんだ言って、1面の先頭からやりなおしさせられてばっかり。
と、言うわけで、全面クリアするには、
アクションゲームの腕だけでなく、
数多のバグに当たらないというリアルラックまで必要になる……、
まぁ、コンティニュー一切無しでできるぐらいの凄腕なら
問題無いんでしょうけれど。
キーカスタマイズができないので、キーボードでやっていると、
入力できない操作がある
(指が届かないとか、
ダイオード無しキーボード使っているから
キーボードのせいで3つ以上の同時押しが無視されるとか)。
防御(ガード)と滞空時のモード切り替えの操作が同じキー/ボタンなので、
防御しようとして滞空モードになってしまうとか、
ガード中に敵の弾を受けて空中に吹き飛ばされて
(斜面に立って攻撃を受けるとしばしば発生する。特に5面と7面)
勝手に滞空モードになってしまうとか、
タコ殴りされる事が多い。
多くの敵に囲まれると、ガード解除すると瞬殺され、
解除しないとそのままハメ状態で動けない、になるのは、下手だからか?。
下手だからだろうなぁ。
防御状態だと、射撃方向の上下操作すらできなくなるので、
一瞬だけ防御解除して射撃してすぐ防御、と言う戦法を取る場合、
本格的に射撃を行う前に、
一瞬だけ防御解除して射撃方向をずらして防御して、
を延々繰り返さなければならない。
3面のボスステージは、ゲームバランスが悪い気がする。
5面やそれ以降は、たどり着いた事が無い
(たどり着く前に MS-Windows ごとクラッシュするか、
コンティニュー回数を使い切って1面に戻されるか、
してしまう)ので不明。
何かと悪い面ばかり目についてしまったが、
画面解像度やテクスチャ辺りを最低ランクに設定すれば、
AthlonXP や Pentium4 辺りの 3000+/3.0GHz クラスのマシンでも、
スピード感ある感じで(バグの件を除けば)快適にプレイできると思う……、
今時はその程度のスペックは当然なのか?……、
元々このゲームの作られ始めた時期を考えると……。
Sun,06 Sep,2009 追記:
1回のプレイに2時間近く消費する(バグ等でやり直しした場合を除く)ので、
プレイ時間を確保するのがきつい。
ちまちまやっていって、面を覚えて、攻略法を覚えて、
ようやく全クリ。
Gun Arms の全面クリア後の、面セレクトが可能になっているスコアデータ。
ボス面のセレクトはできない。
武装のセレクトもできない。
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000030 00 00 00 00 01 13 08 06 00 00 00 00 00 00 00 00 |................|
攻略法:
6面につくまでノーコンティニューが基本。駄目ならやり直し。
私の場合、全面クリアに2時間かかる。
1面:
ブーストを使った高速機動
(注意:「機動」は、的確に目的地に移動する、の意)が上手ならば、
パイルバンカーを取得後は、残り全てを無視してボスまで直行可能。
ゲージが半分くらいまで減るかもしれないが、余裕でボスを倒せる。
2段目末端の箱にあるショットガン?を取っておくと、ボス戦が楽になる。
ブーストが苦手ならば、地上敵は出現直後にパイルバンカーで瞬殺、
空中敵は1機出現毎に、ガードをしつつ迎撃して確実に撃墜、
していけば、クリア。
1面ボス:
ガードして行動パターンを見ていれば、
いつ、こちらから安全に攻撃できるのかすぐ判るので、
あとはガードと攻撃を適切に行えば問題無し。
ただし、爆風の強い攻撃を受ける際にマップの端にいると、
吹き飛ばされて壁の中か床下に埋められてしまい、
違う意味で終わるので注意。
2面:
列車から落ちると、いきなりゲームオーバーなので注意。
これも、ブーストを使った高速機動で、雑魚全部無視してボス直行可能。
中間地点くらいにあるショットガン?と救急箱?を取っておくと、
ボス戦が楽。
ブースト苦手なら、敵が1機出現する毎に必ず潰していけば、
クリア。
2面ボス:
これもガードして行動パターンを見ていれば、
いつ、こちらから安全に攻撃できるのかすぐ判るので、
あとはガードと攻撃を適切に行えば問題無し。
注意が必要なのは、空中機雷?みたいな奴。
触れるとかなり痛いので、これだけは空中ブーストで避ける必要がある。
迎撃で破壊は、多分、間に合わない。
3面:
ダッシュ不可。落ちても死なない。
地道に、敵が1機出現する毎に必ず潰していくしかないと思われる。
分岐は、上が楽。落ちると空中機雷?地獄。
最後に箱が3つあり、レーザー?、救急箱?、フレイムランチャー?、
だったと思う。救急箱?は必須として、レーザー?を取ると、
ボス戦序盤が楽。
3面ボス:
ダッシュ可能。
最初のミサイル/ガトリング/ガトリングのコンボは、
ガードしつつ、敵の攻撃の隙間でレーザー攻撃。
レーザー砲は、画面ギリギリからレーザー攻撃で破壊。
この辺でレーザーの弾切れになる。
5連装砲塔の2連続だか3連続は、
敵が攻撃して来ない圏外ギリギリから、横ダッシュで一気に崖下に入り込み、
敵の攻撃の隙で砲身を攻撃、攻撃が来たらガード。
爆風で崖下から離れた場合、敵の攻撃の隙が無くなるので、
あとはガードしっぱなしで、爆風で吹き飛ばされて、
敵の攻撃圏外に出るまで待つのが楽。
またレーザー砲があるので、ジャンプとブーストで崖っぷちの上側に迫り、
ガードしていると、敵の攻撃が頭上を通りすぎる位置まで押し返されるので、
あとはミサイルだけはガードしつつ連射して破壊。
そのままミサイルだけはガードしつつ連射していれば、
ミサイル/ガトリング/ガトリングのコンボのうち、
ミサイルとトリング1つまでは壊せる。
あとは敵の攻撃の隙間でダッシュ&攻撃、敵のガトリングが来たらガード、
で、ガトリングを破壊。
残りはメインブリッジとミサイル砲台3基だが、
面倒なので、ダッシュしてメインブリッジに密着、
ミサイルはガードしてあとは連射してブリッジだけ破壊すればクリア。
4面:
ダッシュしながら敵や防壁の出現直後に撃破、
していれば楽に 1/3 くらいまで到達。
破壊不能物の上にいる爆弾?バラまいている奴は、
攻撃方向を前方ちょっとだけ斜め上に固定しつつ、
ジャンプ&滞空モードで頭と砲口だけ上に出せば、撃破できる。
階段状部分のミサイラーも同様。
2/3 くらいで縦穴を落ちるが、機雷だらけ。左端に密着していれば、
当たらなかったと思う。
縦穴を落ちた直後の箱の内、左端はレールガン?なので、ボス戦に取っておき、
ミサイルとフレイムランチャー?で残敵と空中敵を1機ずつ撃破。
掃討完了後に一旦戻ってレールガン?を取って、ボス戦へ。
4面ボス:
毎度お馴染み、基本はガード、隙が出来たら攻撃。
ただし、爆風の強い攻撃を受ける際にマップの端にいると、
吹き飛ばされて壁の中か床下に埋められてしまい、
違う意味で終わるので注意。
5面:
強制横スクロール面。
平坦部では延々ガード。
斜面に入ると、
狙ってくるタイプの敵の攻撃が外れやすくなるので、
隙を見て狙い撃ち。
以下、全5回ループ。
但し、平坦部にある小さな台地状の部分?は、
台地状の部分から降りる側で敵の攻撃をガードで受けると、
滞空モードになってしまってダメージ食らいまくりになる事が有るので
注意。
5面ボス:
初っ端にミサイラーヘリ?が1〜5機くらい出現する事が有る。
邪魔なので、取り敢えずボスは無視して潰した方が良いかも。
ボスの攻撃は単調なので、
毎度お馴染み、基本はガード、隙が出来たら攻撃。
歩行器みたいな奴は、どうやら無敵らしい。
慣れると、5面ボス戦終了まで 30〜45分。
6面:
空中面。落ちたら即ゲームオーバー。
敵を全滅させると、最終ゲートが破壊可能になる。
敵出現位置は固定。
機雷は数に入るので必ず破壊。
アイテム箱と障害物の箱は、敵の数に入っていない気がする。
つまるところ、面覚えゲー。
前半部では数回連続ジャンプすると空中敵が出現してくる事が有る。
背景が壁に変わった直後、機雷?が有る縦穴は、
下に落ちるともう1個機雷が有る。これも破壊する必要が有る。
この機雷を破壊した直後に右にブーストすると、足場が有るので乗る。
足場に乗り損ねて落ちると即ゲームオーバー。
足場からジャンプした所にも足場が有り敵がいる。
下の足場から右にブーストして行くと、また足場があり、
敵がてきとーに居て、上にあがっていくと、
箱組みたいな足場になる。ここを左にいくと、先程降りた縦穴に着く。
この辺の地帯を抜ければ、あとは落ちても下が床になっているので安心。
左側の細い隙間の下に、機雷が2機と箱が1つ。
右側の細い隙間の下に、ミサイラーと箱が1つ。
さらに右は、大きな箱状の足場で段々になっており、
爆弾をばらまいているやつが数機いる。
避け損なうと痛い。
この地帯は、最下部から最上部まで敵がいる。
敵を全滅させれば、右端下端のゲートが破壊できる様になる。
6面クリアだけで 30分前後。
6面ボス:
ボスは左端から右端に移動し続ける。
それからボスの左側の黒い所は無敵で、弾も通り抜けない。
黒い部分の中央と上下の黒い部分の隙間は、たまに弾が通り抜ける。
足場は、下、上、下、上、と交互に無限に続く。
ここで連続ジャンプで高く上がると、
高確率でブルーバックになって MS-Windows ごと落ちた。
まぁ、この面に着く以前でも、
十回か二十回くらいはブルーバックで落ちたけど。
ボスのミサイル発射装置の下半分は、
最初の下の足場から右方向に撃ち続けていれば、そのうち壊れる。
何とかして空中機動を行い、上の足場に移動すると、
またボスが右方向に移動していってしまう。
ボスのミサイル発射装置の上半分は、
この上の足場から右方向に撃ち続けていれば、そのうち壊れる。
これで、ボスはミサイルを撃ってこなくなり、
機雷とガトリング?だけになる。
あとは、
上の足場から次の上の足場まで横空中ブースト移動を繰り返してボスを追い越し、
ボスを追い越した状態のまま、
射撃方向を左下に固定したまま撃ちっ放しにし、
上の足場から次の上の足場まで横空中ブースト移動、
を繰り返せば、そのうち撃破できる。
空中機動が上手ければ、敵中枢に接近してパイルバンカー、で、
楽に破壊出来るかもしれないけれど。
6面ボス戦クリアだけで 30分前後。
慣れたり、速攻をかけたりすれば、もっと速いかもしれませんが。
7面その1:
一旦、左に行くと、救急箱?。
あとは、右方向に斜面を登ったり降ったりしながら、
敵が1機出現する毎に必ず破壊、をしていけば、クリア。
途中に破壊可能な防御壁?が何度が出現するので、
ダッシュして突破は多分無理。
7面その2:
最初に左に行くと、そのまま無限落下して、違う意味でゲーム終了。
右に行って、階段状の部分を登りながら、
空中敵や待ち伏せしている地上敵を破壊しながら登頂を目指す。
射撃方向を斜め上に固定し、ジャンプ/滞空移動で足場の下側に張り付くと、
砲口が足場の上に出て、いきなり敵に射撃やパイルバンカーが当てられる。
7面クリアに 30分前後。慣れれば、もっと速いかもしれませんが。
7面ボス:
敵のコアみたいな奴の台座に登ってしまうと、
敵の攻撃をガードしてもコアのビーム?連射で空中に吹き飛ばされて
滞空になってしまい、ゲージを 1/3 だか 1/2 だか削られる。
中央付近でうろうろしていると、上と下から猛攻撃を食らい、
ガードが解除できなくなる。
敵のコアみたいな奴の台座の足元に張り付き、
斜め上に砲口を向けて射撃すると、コアに弾が当たる。
あとは、敵の攻撃パターンを覚えて、攻撃が来る時はガードする。
これで楽勝。
あるいは、左端からガードしつつ狙い撃ちでも、楽勝かも。
5分もかからずクリアしたと思う。
エンディング:
このゲームの醍醐味は、
ゲーム本編のダッシュ・ブースト機動とか、
弾撃ちまくりとか、
3D描画なメカとか、
です。
エンディングに期待しない様に。
% sudo env CPUTYPE=prescott LD_LIBRARY_PATH=/usr/RELENG_7/root/lib /usr/RELENG_7/root/usr/sbin/config ULEして、 /usr/RELENG_7/src/sys/i386/compile/ULE で
% sudo env CPUTYPE=prescott WITH_GCC3=yes make -m /usr/RELENG_7/root/usr/share/mk cleandepend % sudo env CPUTYPE=prescott WITH_GCC3=yes make -m /usr/RELENG_7/root/usr/share/mk depend % sudo env CPUTYPE=prescott WITH_GCC3=yes make -m /usr/RELENG_7/root/usr/share/mkしてみたら、なんか足りないとか言われた。 cvsup で src-sys-crypto が別配布らしい。 追加して cvsup からやり直してみたら、 今度は kern/sched_ule.c のコンパイルでこけた。 inline 関数の定義場所が悪いらしい。 前に移動したらコンパイル通った。
% sudo env CPUTYPE=prescott WITH_GCC3=yes make -m /usr/RELENG_7/root/usr/share/mk KODIR=/boot/testkernel installで、インストールまではいけた。 カーネルが 7.0-RC1、残りは全部 6.3-RELEASE、で起動したら、 IPF と kldload/kldstat/kldunload と ACPI 回りが使えなくなった。 残りは普通に動いているみたい。
% qemu-img create -f raw dummy 1 % qemu -localtime -k ja -m 512m -soundhw pcspk,es1370 -net nic,model=rtl8139 -net user -hda dummy -kernel vmlinuz -initrd initrd.img -append "ramdisk_size=131072 initrd=initrd.img ip=dhcp root=/dev/ram0"したら、
Kernel panic: No init found. Try passing init= option to kernel.になった。 あれ、qemu の Linux起動モード?で、 ramfs をルートファイルシステムにした起動って、できないんだっけ?。 でも、ramfs のマウントまではできているっぽいメッセージが出ているのだが。 ……。 qemu総本山を見たら、ちょうど先日の1月に、 「前述の起動方法まるごと」に対応したらしい……、
+ _ETHER=trunk0 + _BRIDGE=bridge0 + [ ] + BRIDGE=bridge0 + [ ] + ETHER=trunk0 + id -u + test 0 -ne 0 + echo Initializing tun0.. Initializing tun0.. + ifconfig tun0 link0 up + ifconfig tun0 group tun + ifconfig bridge0 create + brconfig bridge0 rule block in on trunk0 dst 33:33:0:0:0:12 brconfig: bridge0: No such file or directory + brconfig bridge0 rule block in on trunk0 dst 01:00:5e:00:00:12 brconfig: bridge0: No such file or directory + ifconfig bridge + sed -n /^bridge[0-9]*/{s/:.*$//;p;} + read brif + brconfig bridge0 del trunk0 + brconfig bridge0 del tun0 + read brif + brconfig bridge0 add trunk0 up brconfig: bridge0: trunk0: No such file or directory + brconfig bridge0 add tun0 up(trunk0は実機のNICのifに置き換える) して、
tun0: flags=9943に、なるらしい。 FreeBSD だと、Layer2 は tap、Layer3 は tun、だけれども、 OpenBSD だと、どちらも tun で、link0 指定すると Layer2、無指定だと Layer3、 らしい。 その block している MAC は、何だろう?。 dst 01:00:5e:00:00:12 と src 00:00:5e:00:01:mtu 1500 lladdr xx:xx:xx:xx:xx:xx groups: tun inet6 fe80::2xx:xxff:fexx:xxxx%tun0 prefixlen 64 scopeid 0x7 bridge0: flags=41 mtu 1500 groups: bridge
mount: RPC: Authentication error; why = Client credential too weakになる。 読んだまんま。NFS クライアントを、権限の無いユーザが使おうとしている。 qemu を動かしている一般ユーザには NFS クライアントを使う権限が無い。 例えゲストOS上では root 権限であっても、 それは仮想内の話であって、実機では一般ユーザだし。 実機の NFS サーバで、mountd -n して許可してしまえば通る様になる。 どうせ LAN 内に適当な計算機つながれちゃったら、 IPsec とか kerberos とか使っていない NFS なんぞ、 好き勝手にいじられちゃうんだし。
RPC: garbage, exit EIO mount: hoge:/export: can't read superblockとか出る。 NFS の superblock って何だろう……、 RPC の通信ができない場合に、そう言ってくるらしい。 NFS サーバ側でみてみると、
localhost.***** > localhost.nfsd: xid 0x******** (NFSv3) 104 fsinfo [|nfs] (ttl 64, id *****, len 132) localhost.nfsd > localhost.*****: xid 0x******** reply ERR 24 fsinfo [|nfs] (ttl 64, id *****, len 52) localhost.***** > localhost.nfsd: xid 0x******** (NFSv3) 104 getattr [|nfs] (ttl 64, id *****, len 132) localhost.nfsd > localhost.*****: xid 0x******** reply ERR 20 getattr [|nfs] (ttl 64, id *****, len 48)mountd で許可しても、まだ nfsd が許可されていないらしい。 OpenBSD 3.1 で、nfsd は well known port を要求しない仕様に変わった、 となっているのだけれども、なんで?……。
ifconfig bridge0 create ifconfig tun0 link0 inet 10.0.2.2 netmask 255.255.255.0 up brconfig bridge0 add bge0 brconfig bridge0 add tun0 brconfig bridge0 rule pass in on tun0 brconfig bridge0 rule pass out on tun0 brconfig bridge0 rule pass in on bge0 brconfig bridge0 rule pass out on bge0 brconfig bridge0 upnet.inet.ip.forwarding=1 とか net.inet6.ip6.forwarding=1 とか 忘れると、 tun0 の LAN からホストへはアクセスできるのに、 tun0 の LAN から bge0 の LAN へは出て行けない、 と言う状態になるので注意。 あと、 パケットフィルタ(ファイヤーウォール)を入れている場合は、 tun0 のぶんのルールも記述しないと蹴られる。 LAN の構成によっては tun0 → bge0 の nat ルールも必要。
% sudo qemu -localtime -k ja -m 512m -net nic,model=rtl8139 -net tap,ifname=tun0,script=no -hda dummy -kernel vmlinuz -initrd initrd.img -append "ramdisk_size=65535 nfsaddrs=10.0.2.15:192.168.1.2:10.0.2.2:255.255.255.0:qemu:eth0:none root=100 1" 10.0.2.15 my-ip 192.168.1.2 serv-ip 10.0.2.2 gw-ip 255.255.255.0 netmask qemu name eth0 dev none auto domain, nis-domain, rootpath が設定できない。で、動く。 この状態で、ゲストOSからホストOSにアクセスすると、 ホストOSからは 10.0.2.15 からアクセスされている様に見える。 実機の LAN のアドレスとは違うので注意。
tp-s2-c12r32.router.hinet.net.28418 > tc-c12r2.router.hinet.net.5001: udp 45 [tos 0x4] 210.65.200.22.28418 > 210.65.200.21.5001: [udp sum ok] udp 45 [tos 0x4] (ttl 64, id 0, len 73)とか言うパケットが見えるのだが、なんなのだろう?。
locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directoryとか言う様になった。 locale -a してみたら、POSIX と C しか知らん、とか言ってくる。 locale-gen したら治った。
PermitRootLogin forced-commands-only PermitTunnel ethernet AllowGroups sshusers usersを追加、 login.access に
+:root:client.example.jpを追加、 ~root/.ssh/authorized_keys2 に
command="sleep 1" ssh-dss SSHクライアント側の公開鍵 user@client.example.jpを追加。 ssh クライアント側の ~user/.ssh/config に
Host vpn HostName server.example.jp Port 22 HostKeyAlias server.example.jp ForwardX11 no PasswordAuthentication no CheckHostIP yes Protocol 2 User root Tunnel ethernet TunnelDevice 0:0 PermitLocalCommand yes LocalCommand sleep 1 Compression yes #VersionAddendumを追加して、ssh クライアント側から
% sudo ssh -F ~user/.ssh/config -i ~user/.ssh/id_dsa vpnする。 この時、ssh の portforward を使うと、 login.access で root ログインを許可する計算機を local に限定できるので、ちょっと安心できる……、 その場合は、 ssh サーバ側の login.access に追加する内容を
+:root:LOCALとし、 ssh クライアント側の ~user/.ssh/config に
Host portforward-vpn HostName server.example.jp Port 12345 HostKeyAlias server.example.jp ForwardX11 no PasswordAuthentication no CheckHostIP yes Protocol 2 User root Tunnel ethernet TunnelDevice 0:0 PermitLocalCommand yes LocalCommand sleep 1 Compression yes #VersionAddendumを追加して、 一旦 ssh サーバ側から ssh クライアント側に
% ssh -R 12345:127.0.0.1:22 user@client.example.jpしてから、ssh クライアント側で
% sudo ssh -F ~user/.ssh/config -i ~user/.ssh/id_dsa portforward-vpnする。 qemu の仮想マシンのルートファイルシステムが、 OpenSSH の向こう側にある NFS サーバをとする様な、 ディスクレス仮想マシンの起動ができた。 ただし、当然ながらレスポンスが悪い、 NFS の応答が返ってくるまで3秒くらいかかる。 でも、非常用には使えるかな……。 あと、icmp が通らない気がする。 Fri,15 Feb,2008に続く。 Thu,07 Feb,2008、 Fri,22 Dec,2006に関連。
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4001c000) libm.so.6 => /lib/libm.so.6 (0x400d6000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400f8000) libc.so.6 => /lib/libc.so.6 (0x40101000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)で、 NPTL 時は、
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4001c000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x400d6000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400f9000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40102000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)。 libc と libm が optimize された物になっている。
.if !defined(CPUTYPE) . if ${.CURDIR} == "/usr/src/sys/compile/HOGE" CPUTYPE=k7 . elif ${.CURDIR} == "/usr/src/sys/compile/MOGE" CPUTYPE=p3 . endif .endifとかやっていたものが、 FreeBSD 6では使えなかった。 よく見たら、ディレクトリが変わっていた。 結局、
.if !defined(CPUTYPE) . if !empty(.CURDIR:M/usr/src/sys/amd64/compile/HOGE*) || !empty(KERNBUILDDIR:M/usr/src/sys/amd64/compile/HOGE*) CPUTYPE=athlon64 . elif !empty(.CURDIR:M/usr/src/sys/i386/compile/MOGE*) || !empty(KERNBUILDDIR:M/usr/src/sys/amd64/compile/MOGE*) CPUTYPE=core . endif .endifするのが良いらしい。
cloned_interfaces="tap0 bridge0" autobridge_interfaces="bridge0" ifconfig_tap0="inet 192.168.255.2 netmask 0xffffff00" autobridge_bridge0="tap0" defaultrouter="192.168.2.1" static_routes="vpn" route_vpn="-net 192.168.1.0/24 192.168.255.1"と追加するらしい。 あと、VPN と、tap な qemu を連結させる場合、 qemu 用の LAN が 192.168.254.0/24、 qemu用LANのサーバが 192.168.254.1、 qemu が 192.168.254.2、 の場合、
cloned_interfaces="tap0 bridge0 tap1 bridge1" autobridge_interfaces="bridge0 bridge1" ifconfig_tap0="inet 192.168.255.2 netmask 0xffffff00" autobridge_bridge0="tap0" ifconfig_tap1="inet 192.168.254.1 netmask 0xffffff00" autobridge_bridge1="tap1" defaultrouter="192.168.2.1" static_routes="vpn" route_vpn="-net 192.168.1.0/24 192.168.255.1"qemu 用の tap1 を作り、 別途、アドレスを割り当ててルーティングしないといけないらしい。 qemu を tap0 に割り当てようとしたら、 使用中の tap に重複割り当てはできない、 とエラーが出たし、 qemu を tap1 に割り当てたまま 192.168.255.3 とか割り振ったら、 パケットがどことも通らなかった。
% ln -s /dev/tun0 /dev/tap0しておかないといけないらしい。
usb2: host controller process error usb2: host controller haltedとか出て、USBが死ぬ事が多い……。 2ヶ月以上前は、USBデバイスを使っていなかったから、 6.2-RELEASE では問題無かったのかどうかは不明。
portupgrade -M DISABLE_VULNERABILITIES=yesらしい。
-12345X@PJLとか
-12345X@PJL RESETの様に、ゴミとして印刷されてしまうので、ppd に
*JCLBegin: "" *JCLEnd: ""が必要らしい。 それから、一部のプリンターでは、gs -dPARANOIDSAFER 指定で 日本語フォントを見つけられなくなる問題があるらしい、 この場合は env GS_FONTPATH=/usr/local/share/fonts/TrueType gs -dPARANOIDSAFER するらしい。 あとは、プリンタメーカーか www.openprinting.org あたりから、 使用するプリンタ用の ppd ファイルを持ってきて、 cups から追加登録すれば、印刷できるらしい……、 古めの ppd だと「cupsomatic が無い」とかエラーが出るが、 これは foomatic-rip に置換する。
% convert logo.gif test.ps ← ImageMagick 付属の画像コンバータ % gs -r300 -sDEVICE=lp9000b -sOutputFile=test.out test.ps ← foomatic-rip の変換のコア部分のみの処理 % /usr/bin/lpr -Plps6500 test.out ← BSD-lpr。cups を一切使わずに出力。しても、見事に失敗 (画像が横に3倍くらいに拡大されつつ、元のサイズと同じ大きさ分だけ印刷) した。 gs に -r300 とか -r600x600 とか付けても駄目。 縦方向は問題無い辺り、わけがわからない。 試しに、
% convert logo.gif test.ps % gs -r300 -sDEVICE=psmono -sOutputFile=test2.ps test.ps % gs -r300 -sDEVICE=lp9000b -sOutputFile=test.out test2.ps % /usr/bin/lpr -Plps6500 test.outとかやると、今度は正常に(グレイスケールで)印刷された……、 但し、印刷スプールの消費量と印刷時間が3倍くらいになった。 psmono を psrgb にして、lp9000b を lp9000c にすると、カラーで印刷された……、 但し、印刷スプールの消費量と印刷時間が10倍くらいになった。 試しに psmono を pswrite にしてみたら、駄目だった。 Ghostscript の変換の問題なのか?。
gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=lp9000c %A%Z -sOutputFile=- -と記述すると、
gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=lp9000c -dCasset=-1 -r600x600 -dNumCopies=1 -sOutputFile=- -になった。
unit iconv; {*******************************} { iconv wrapper } { Wed,27 Feb,2008 } {*******************************} {example: uses unixtype,iconv; Function NewConvUni( const pmsg: PChar ): PWord; const WCLen = 512; var src_len, dst_len: size_t; pdst: PChar; psrc_tmp, pdst_tmp: PChar; iconv_result: size_t; begin pdst := StrAlloc( WCLen ); src_len := Length(pmsg); dst_len := WCLen - 2; psrc_tmp := pmsg; pdst_tmp := pdst; iconv_result := iconv.iconv( iconv_enc2utf16, @psrc_tmp, @src_len, @pdst_tmp, @dst_len ); iconv_result := iconv.iconv( iconv_enc2utf16, NIL, NIL, @pdst_tmp, @dst_len ); pdst_tmp[0] := #0; pdst_tmp[1] := #0; NewConvUni := PWord(pdst); end; } {*******************************} {$MODE FPC} interface uses {$IFDEF UNIX} pthreads, baseunix, unix, unixtype {$ENDIF} {$IFDEF Windows} windows, jwawintype {$ENDIF Windows} ; const {$IFDEF UNIX} {$IFDEF LIBC_ICONV} libiconvname='c'; {$DEFINE _LIBICONVNAME_} {$ELSE} libiconvname='iconv'; {$DEFINE _LIBICONVNAME_} {$ENDIF} {$ENDIF UNIX} {$IFDEF Windows} libiconvname='iconv.dll'; {$DEFINE _LIBICONVNAME_} {$ENDIF Windows} {$IFNDEF _LIBICONVNAME_} libiconvname='iconv'; {$ENDIF} {$IFDEF LIBICONV_PLUG} libiconv_functionname_iconv_open = 'iconv_open'; libiconv_functionname_iconv = 'iconv'; libiconv_functionname_iconv_close = 'iconv_close'; {$ELSE LIBICONV_PLUG} libiconv_functionname_iconv_open = 'libiconv_open'; libiconv_functionname_iconv = 'libiconv'; libiconv_functionname_iconv_close = 'libiconv_close'; {$ENDIF LIBICONV_PLUG} {$IFDEF ENCODING_EUC} {$IFDEF ENCODING_EUCJP} SYSTEM_ENCODING = 'EUCJP'; {$DEFINE _SYSTEM_ENCODING_} {$ENDIF} {$IFDEF ENCODING_EUCKR} SYSTEM_ENCODING = 'EUCKR'; {$DEFINE _SYSTEM_ENCODING_} {$ENDIF} {$IFDEF ENCODING_EUCCN} SYSTEM_ENCODING = 'EUCCN'; {$DEFINE _SYSTEM_ENCODING_} {$ENDIF} {$IFDEF ENCODING_EUCTW} SYSTEM_ENCODING = 'EUCTW'; {$DEFINE _SYSTEM_ENCODING_} {$ENDIF} {$IFNDEF _SYSTEM_ENCODING_} SYSTEM_ENCODING = 'EUCJP'; {$ENDIF} {$ENDIF} {$IFDEF ENCODING_UTF8} SYSTEM_ENCODING = 'UTF-8'; {$ENDIF} {$IFDEF ENCODING_SJIS} {$IFDEF Windows} SYSTEM_ENCODING = 'CP932'; {$DEFINE _SYSTEM_ENCODING_} {$ENDIF} {$IFNDEF _SYSTEM_ENCODING_} SYSTEM_ENCODING = 'SJIS'; {$ENDIF} {$ENDIF} UNICODE_CODESET = 'UTF-16LE'; type {{$IFDEF WIN32}} { Psize_t = ^size_t;} { size_t = LongWord;} {{$ENDIF WIN32}} {{$IFDEF WIN64}} { Psize_t = ^size_t;} { size_t = QWord;} {{$ENDIF WIN64}} Piconv_t = ^iconv_t; iconv_t = pointer; var { Conversion table for SDL_TTF.TTF_RenderUnicode_Solid() } iconv_enc2utf16: iconv_t; iconv_utf16toenc: iconv_t; function iconv_open( __tocode: Pchar; __fromcode: Pchar ): iconv_t; cdecl; external libiconvname name libiconv_functionname_iconv_open; function iconv( __cd: iconv_t; __inbuf: PPchar; __inbytesleft: Psize_t; __outbuf: PPchar; __outbytesleft: Psize_t ): size_t; cdecl; external libiconvname name libiconv_functionname_iconv; function iconv_close( __cd: iconv_t ): longint; cdecl; external libiconvname name libiconv_functionname_iconv_close; implementation Procedure Init_workarea(); begin { Initialize conversion tables. } iconv_enc2utf16 := iconv_open( UNICODE_CODESET, SYSTEM_ENCODING ); iconv_utf16toenc := iconv_open( SYSTEM_ENCODING, UNICODE_CODESET ); if (iconv_t(-1) = iconv_enc2utf16) or (iconv_t(-1) = iconv_utf16toenc) then begin Writeln('iconv initialization failed. (system encoding "' + SYSTEM_ENCODING + '", unicode encoding "' + UNICODE_CODESET + '")'); halt(-1); end; end; initialization begin Init_workarea(); end; finalization begin iconv_close( iconv_utf16toenc ); iconv_close( iconv_enc2utf16 ); end; end.こんなんでいいらしい。 サンプルの NewConvUni() は、 変換後の文字列を SDL_ttf の TTF_RenderUnicode系(TTF_RenderUnicode_Solidとか) に突っ込むための物なので、 PUInt16 にキャストしている上に、終端文字が多くなっている、 あと使い終わったら Dispose() が必要。
% ln -sf J /etc/malloc.confすれば、 malloc() や free() で (内部的には new と delete と new[] と delete[] も包括される)、 自動的にゼロクリア(ゼロじゃないけれど)される。 但し、当然ながら、遅くなる。 Wed,28 May,2008、 Thu,29 May,2008、 Fri,30 May,2008に続く。 Tue,04 Mar,2008、 Sat,31 May,2008に関連。
非常に枯れた(注意:「枯れた」は褒め言葉)システムなので、 BSD系やGNU/Linux系だけでなくUnix系全般で使える、 でもMS-Windows は駄目らしい。
ファイル単位で暗号化するので、 ファイルの数とサイズとタイムスタンプは隠せない。
プロトコルスタックが深いので遅くて重い。
NFS と同じスキーム。
ベンチマーク結果(blowfish-Key:128): 実ディスク上で 5784251, 5833988, 5698622 B/s
CFS の理念を fusefs に実装した物 (そんな内容の事を著者自身が言ってる)。
シンプルで速い(そんな内容の事を著者自身が言ってる)。
GNU/Linux系で発祥して FreeBSDの ports にも入っている。 でも OpenBSD は駄目。 MS-Windows も駄目(EncFS for Windows が見つからない)。
ファイル単位で暗号化するので、 ファイルの数とサイズとタイムスタンプは隠せない。
暗号化には OpenSSL を使用。
ベンチマーク結果(blowfish-Key:128-block:512): 実ディスク上で 17710278, 17902435, 17438566 B/s。 CFS の約3倍。
MS-Windows と MacOS のみ対応。 BSD系と GNU/Linux は駄目。
現在は商用化。
非オープンソース。
ボリューム丸ごと暗号化する。
カーネル空間で動作する。
MS-Windows と GNU/Linux のみ対応。
BSD系は駄目。
FreeBSD は「隠れ対応」状態だが動作可能。
NetBSD, OpenBSD は駄目らしい。
ボリューム丸ごと暗号化する。
カーネル空間で動作する。
暗号化に関しては Sun,15 Oct,2006、 Sun,09 Sep,2007に関連の話。 FreeBSD で TrueCrypt を使う件は Tue,25 Mar,2008、 Fri,13 Mar,2009、 Tue,17 Mar,2009に続く。
ベンチマーク結果(FAT16, blocksize 512B, AES, RIPEMD-160): 実ディスク上で 3702149, 3805488, 3858609 B/s。 CFS の半分〜6割の速度(TrueCrypt の方が遅い)。
FreeBSD のみ。
ボリューム丸ごと暗号化する。
カーネル空間で動作する。
ベンチマーク結果(blowfish-128): 9527998, 9523685, 9531886 B/s。 CFS の約2倍に届かないくらいで、 encfs の7〜8割くらい。
ベンチマーク結果(3des-192): 4197293, 4152649, 4197926 B/s。 やっぱり遅い。
ベンチマーク結果(aes-128): 12192249, 14852500, 14857844 B/s。 blowfish より速いのが意外。
ベンチマーク結果(openssl speed):
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 24520.43k 25277.06k 25462.16k 25533.50k 25551.19k des ede3 7798.12k 7929.08k 7965.49k 7985.28k 7987.33k blowfish cbc 34951.55k 37334.97k 37875.87k 37937.57k 38056.96k
NetBSD のみ。
ボリューム丸ごと暗号化する。
カーネル空間で動作する。
OpenBSD のみ。
ボリューム丸ごと暗号化する。
カーネル空間で動作する。
基本的には GNU/Linux系のみだが、 MS-Windows でも FreeOTFE 使えば一応使える。
ボリューム丸ごと暗号化する。
カーネル空間で動作する。
ありとあらゆる OS で使える。
ファイル単位に個別に暗号化する。 読み書き毎に変換が必要。
信頼性が最も高い。
通常はユーザーランドで動作する(ルート権限で盗み見可能)。
ベンチマーク結果 (Symmetric AES256+SHA512+NoCompress): 実ディスク上で 11275011, 11397565, 11037642 B/s。 (PKI AES256+SHA512+NoCompress): 実ディスク上で 10082462, 9986438, 9986438 B/s。
ベンチマーク結果(入力ファイルは /dev/random) (Symmetric AES256+SHA512+bzip2-level9): 実ディスク上で 1054905, 1095690, 1095691 B/s。 (PKI AES256+SHA512+bzip2-level9): 実ディスク上で 1079893, 1081006, 1082122 B/s。
.if !empty(.CURDIR:M/usr/ports/audio/sdl_mixer*) CONFIGURE_ARGS+= --enable-music-ogg --enable-music-mp3 --disable-music-ogg-shared --disable-music-mp3-shared .endif .if !empty(.CURDIR:M/usr/ports/devel/sdl12*) CONFIGURE_ARGS+= --disable-loadso --disable-alsa-shared --disable-esd-shared --disable-arts-shared --disable-x11-shared --disable-osmesa-shared --disable-threads .endifを追加すればOK。 (Thu,06 Mar,2008 追記: SDL のスレッド制御機能を有効にすると、非常に不安定になるので、 --disable-threads を追加)
% cd /usr/src % make build32 % make install32 % ldconfig -32すれば、いちいち make world せずとも、 互換ライブラリだけ更新されるらしい。 Fri,07 Mar,2008と Thu,06 Mar,2008に関連、 Wed,21 May,2008に続く。
grep: Memory exhaustedとか言ってきた。
#0 in strlcpy () from /lib/libc.so.6 #1 in UTF8_Locale::utf8_to_native_str at ../../xim/locale.cpp:285 #2 in XimIM::utf8_to_native_str at ../../xim/ximim.cpp:485 #3 in ConvdispOv::layoutCharEnt at ../../xim/convdisp.cpp:1461 (以下略)malloc.conf を JZ した場合は落ちなくなったが、 J するとやっぱり落ちる。 ……、strlcpy() のソース側引数に、 明示的に終端文字を付けていないオチだろうな。 ……。 ソースの xim/locale.cpp 見てみた。 当たり。 iconv() の呼び出し方を間違えていて、終端文字が付いていない。 今まで落ちなかったのは、 単なる偶然(多分、どこかでゼロクリアしている奴がいる)。 ……。 uim-1.4.2 出てるし。 Google code とか言う所に移転してた。 ……。 iconv 回りのバグ、気付いていないみたい。 ……。 Google code の使い方が判らん……。 Bugzilla の使い方も判らん……。 ……。 なんとか送信できたみたい。
% export LD_32_LIBRARY_PATH='/usr/lib32:/usr/local32/lib' % export CC='/usr/local/bin/ccache gcc -B/usr/lib32' % export CFLAGS='-g3 -O3 -m32 -march=pentium-mmx -I/usr/obj/usr/src/lib32/usr/include -fno-omit-frame-pointer -pthread -I/usr/local32/include -I/usr/local/include' % export CXXFLAGS=${CFLAGS} % export LDFLAGS='-g3 -O3 -m32 -march=pentium-mmx -L/usr/lib32 -B/usr/lib32 -Wl,-rpath,/usr/local32/lib'libtool は、*FLAGS の -B オプションを消してしまうので、CC側に書く。
% mkdir build % cd buildloadso と threads を無効にする以外、 FreeBSD の ports と同じ設定にするならば、以下。
% ../configure --disable-loadso --disable-alsa-shared --disable-esd-shared --disable-arts-shared --disable-x11-shared --disable-osmesa-shared --enable-video-vgl --enable-video-ggi --enable-video-opengl --enable-video-aalib --enable-video-svga --disable-arts --x-libraries=/usr/local32/lib --x-includes=/usr/local/include --prefix=/usr/local32 --mandir=/usr/local/man --infodir=/usr/local/info/ --build=i386-portbld-freebsd6.3 --with-esd-exec-prefix=/usr/local32 --disable-threadsGearHead に必要な最低限の設定にするならば、以下。
% ../configure --disable-loadso --disable-alsa-shared --disable-esd-shared --disable-arts-shared --disable-x11-shared --disable-osmesa-shared --enable-video-vgl --enable-video-ggi --enable-video-opengl --enable-video-aalib --enable-video-svga --disable-arts --x-libraries=/usr/local32/lib --x-includes=/usr/local/include --prefix=/usr/local32 --mandir=/usr/local/man --infodir=/usr/local/info/ --build=i386-portbld-freebsd6.3 --with-esd-exec-prefix=/usr/local32 --disable-threads --disable-cpuinfo --disable-joystick --disable-cdrom --disable-audio --disable-oss --disable-nas --disable-arts --disable-video-opengl --disable-video-dga --disable-video-aalib --disable-video-ggi --disable-video-svga --disable-video-vgl
var dst: PChar; begin dst := StrAlloc( 512 ); StrPCopy( dst, '12345' ); if Ord('a') = dst[6] then dst[6] := 'A'; if Ord('a') = dst[5] then dst[5] := 'A'; end;dst[6] は終端文字より後なのでアクセスするのはおかしいのだが、 確保されたメモリ内に収まっている。 dst[5] は終端文字を破壊している。 この手のタイプのオーバーランは、それだけでは絶対に発見できないし、 dst[512] とかそれ以降にアクセスしない限り発覚しないんだよね。 当たり前だけれど。
2#10111 2進数 8#76543 8進数 16#fd9c 16進数 32#zmlx3 32進数らしいが……。
fg_color = #000000 bg_color = #f5f5f5 fontsize = 14 use_bidi=false iso88591_font_for_usascii=true use_anti_alias = false use_cp932_ucs_for_xft=false not_use_unicode_font=true #only_use_unicode_font=true use_combining=true use_dynamic_comb=true use_xim=true input_method=ximfg_color は文字の表示色、bg_color は背景色。
ISO8859_1=-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1:100; JISX0201_ROMAN=-sazanami-gothic-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0:100; JISX0201_KATA=-sazanami-gothic-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0:100; JISX0208_1983=-misc-fixed-medium-r-normal--14-130-75-75-c-140-jisx0208.1983-0:100; JISX0212_1990=-misc-osaka_unicode-medium-r-normal--0-0-0-0-p-0-jisx0212.1990-0:100; ISO10646_UCS4_1=-misc-osaka_unicode-medium-r-normal--0-0-0-0-p-0-iso10646-1:100;ISO8859 は 7x14、 JISX0208 は k14、 JISX0201 は漣で、 JISX0212 と ISO10646 はダミー。
black = #202020 blue = #0000cc green = #00bb00 cyan = #00cccc red = #cc0000 magenta = #bb00bb yellow = #ffd700 white = #a0a0a0 hl_black = #404040 hl_blue = #0000ff hl_green = #00ff00 hl_cyan = #00ffff hl_red = #ff0000 hl_magenta = #ff00ff hl_yellow = #ffff00 hl_white = #ffffffblack は terminfo だかで黒が指定された時、 white も terminfo だかで白が指定された時、使われる……、 通常の文字の色や背景の色は、main の fg_color と bg_color が使われる。 と言う感じに書くらしい。
for (Hoge* ptr = start; ptr; ptr = ptr-<next) delete ptr;Hoge は、適当な単方向なり双方向なりのリンクリスト型。 別バージョンで、
for (Hoge* ptr = start; ptr; ptr = ptr-<prev) delete ptr;こんなのもある。 これが含まれている関数の付近に問題がある事までは判っていたのだけれども、 具体的な箇所が見つからないでいた。 /etc/mallo.conf を J して、ようやく見つけた。
{$IFDEF Windows} var ConsoleInitialized: Boolean = False; {$IFDEF USE_WINDOWS_WRITECONSOLE} tb: Handle; dw: LongWord; {$ENDIF USE_WINDOWS_WRITECONSOLE} {$ENDIF Windows} {$IFDEF Windows} Function InitializeConsole(): Boolean; begin InitializeConsole := False; if not(ConsoleInitialized) then begin ConsoleInitialized := True; if Windows.AllocConsole() then begin {$IFDEF USE_WINDOWS_WRITECONSOLE} tb := Windows.GetStdHandle(STD_OUTPUT_HANDLE); {$ELSE USE_WINDOWS_WRITECONSOLE} {$IFDEF FPC} System.IsConsole:=true; System.SysInitStdIO(); {$ENDIF FPC} {$ENDIF USE_WINDOWS_WRITECONSOLE} InitializeConsole := True; end; end; end; {$ENDIF Windows}こんなんしておけば、あとは
{$IFDEF Windows} StrPCopy( cmsg, msg ); Windows.OutputDebugString( cmsg ); InitializeConsole(); {$IFDEF USE_WINDOWS_WRITECONSOLE} StrPCopy( cmsg, msg + #$0a ); Windows.WriteConsole(tb,@cmsg,Length(msg),dw,NIL); {$ELSE USE_WINDOWS_WRITECONSOLE} Writeln( stderr, msg ); {$ENDIF USE_WINDOWS_WRITECONSOLE} {$ELSE Windows} Writeln( stderr, msg ); {$ENDIF Windows}すれば表示できた。楽ちん。 まぁ、UNIX系みたいに、 何も考えずにいきなり Writeln( stderr, msg ); で済むと一番簡単だが。
var Console_HWND: Windows.HWND; begin repeat Windows.sleep(0); { In MS-Windows, the order of sleep is mili-second, not second. } Console_HWND := Windows.FindWindow( NIL, cmsg ); until Console_HWND <> 0; end;としなければならなかった。
Anthy の学習辞書の話、 Sun,02 Sep,2007〜 Thu,18 Oct,2007の続き。 「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
半年間の累計学習量のデータが貯まったので、グラフにしてみた。
Anthy 累計学習量の変化 (62KiB)。
グラフの左端が開始時、右端が約半年経過後。
横軸の数値は当方での管理番号で、日数ではない。
UNKNOWN_WORD の動きはよく判らん。
SUFFIX_HISTORY と INDEPPAIR が、
4ヶ月経過で飽和の傾向が見え始めた感じがする。
EXPANDPAIR と CAND_HISTORY と PREDICTION は、
ここままいけば飽和しそうな感じではあるが。
OCHAIRE は飽和しそうな気配が全く感じられない。
last-record1 のサイズは、OCHAIRE の量に引きずられていると思われる。
ELF binary type "0" not known.とか出て動かない。
% brandelf -t Linux hogeとかやってから無理矢理動かすと、
ELF interpreter /usr/lib/libc.so.1 not foundとかすっとぼけた事を言ってくる。 どうやら、リンクする時には ダイナミックリンカ名を省略してはいけないらしい……。