Whiteのふりーとーく

2001年6月前半

About this Page |過去分一覧


原則匿名で公開・個人情報は送られません。必要に応じ御署名/非公開希望をお書き添え下さい。


_ 掲示板:YaPW 旧掲示板 SMIL Boston日本語訳(頓座)



6.1

@デバッグ中

謎掲示板こと仮称LLLL、てけとーにデバッグ中です。ときどきあれこれ動作がおかしくなったりもしますが、ログが吹き飛ぶ以外なら修復可能な状態です。そろそろぼちぼち本来の目的(野放図な議論)に使い出したいと思います。

なんかその前に(とっつき易さのために)普通の掲示板っぽい動作をする雑談板を付加したほうがいいのかもしれませんが。

@

そそ、今夜――時刻的には昨日ですが――、久方ぶりの人と呑んできました。いろいろあったらしくてお話ついでに近況など話して、やっぱり最後は話がモノ作りな話に行くのは性というべきか業というべきか。

微妙にやる気充填して、書く気力を取り戻してみたり。敵はLLLLのメンテ&バージョンアップが面白すぎることですか。

@ツっこまれる。

社会人が日づけ代わる時間にHP更新してるのはどうかと思う

大きなお世話です(笑) と、わざわざもっと遅い時間に更新してみるテスト。

@ Yet another,

なんかよくツっこまれる日というものはあるもので。

http://www.tightvnc.com はいかがです?(ってまだ試してませんが)

ふむ。会社-家の間で、SSH経由のVNCなら試してみましたのですけど。ベンチマークとかしたわけじゃないのですが、SSHの圧縮オプション(-C)の有無で、確かに体感速度が変わりました。通説では「体感速度の向上」には25-30%ぐらいのパフォーマンス向上が必要、とか言われてるみたいですけど。

TightVNCの場合、「フルカラー画面だったらJPEG圧縮(圧縮率は稼げるが表示は微妙に不正確)できるようにもする」予定だとか。VNCっぽい、適当に手を抜いた(けど効果的な)アプローチだと感じます。

@VMwareパフォーマンスチューニングTips

……なんかのどさくさに紛れて消失したらしいVMware Performance Tuning Tipsの(要点の)抄訳をもう一度掲載してみる。もとい、訳し直す。

なに、あれだ。自分で参照したくて検索書けたらすっぱりなかったことに気付いただけだ。

  • ゲストOSの選択は正しく
  • 割り当てメモリ量を増やす
  • デバッグモードには遅いので、ノーマルモードに切り替える
  • ゲストOSによるCD-ROMドライブの監視(polling)をやめさせる。あるいはVMwareの起動時のCD-ROMドライブ接続設定をdisconnectedにする。
  • VMware Toolsをインストールして、(仮想)IDEにDMAを使わせるようにする。
  • nonpersistentやundoableな仮想ディスクが、(普通は大丈夫だが)パフォーマンスの低下を引き起こす場合もある。
  • undoableな仮想ディスクについては、適当な頻度でcommitする。
  • plainでpersistentなディスクは、他のディスクよりも速い。
  • VMware for Linuxに関するチューニング項目
    • フルスクリーンモードを使う
    • VGAモードだと、もっと劇的にパフォーマンスが良くなる(画面表示にSVGAドライバを経由しないから)
    • システムタイマー(/dev/rtc)をdisconnectする。
  • VMware for Windows NT/2000に関するチューニング項目
    • プロセススケジューリング設定を変更する
    • 描画モード[Graphics mode]について、ゲストOSがWindows系の場合はGDIモードを、ゲストOSが(Linuxなどの)X Windows利用のものの場合はDirect Drawモードをそれぞれ選ぶ(ただし、Windows2000のDirect Drawモードにはいろいろ問題がある

@TightVNC

ということで、試してみましたTightVNC。結論:劇的に違います。

試したのはサーバ、クライアント共にUNIX版のTightVNC 1.1p9(VNC3.3.3r2ベース)+ Tightオプション。Xの設定は1024x768、256色。SSH圧縮 + VNCに比べて、明らかに体感できる向上がありました。ターミナルやエディタであれば、大きな問題もなく実用できるでしょう。

というのは会社―家間の話。今度は家にて、Windows版クライアントを使って各圧縮オプションの実験。

環境は、100Base-TXなLANで、サーバは先ほどと同じ、クライアントはTightVNC 1.1.p8c。Xの設定は同じく1024x768、256色。圧縮レベルはデフォルトの6。

_Tight
ちょっと反応がもたつく感じがある。
_ZlibHex(mix)
Tightよりも、一回り遅い。外ネットワーク経由とあまり変わらないような感じ。
_Hextile
小気味良いレスポンスをする。画面全体を描画し直す場合も、パッと動く。実機ほどとは行かないが、かなり満足できそうな動作。
_Zlib(pure)
ZlibHex(mix)よりも更に遅い。明らかにもたつく。
_CoRRE
小さ目のブロック(メニューのポップアップとか)の反応は良い。全画面など、大きな領域を再描画すると、転送が小単位なためか時間がかかる。
_RRE
やや反応は遅れるが、一気に描画される。反応までの遅れが気にならなければよいか。
_Raw
かなり反応が悪い。かなりあきらめてサボっている感じ。今回試した中では最悪のレスポンス。

という感じ。私の手元のLAN環境では、Hextileで使うのが一番よさそうな印象。

ただ、外から使うとなるとまた違った感じになるだろう。そのへんの検証は後日。


6.3

@レビューレビュー。

ゲーム批評7月号。P110のZ.O.Eのレビュー。参考に挙げるゲームが違います。ここは絶対に「オメガブースト[SCEI]」を挙げるべきです。オメガブーストの進化形として考えるなら、Z.O.Eはかなり出来がいいです。電脳戦記バーチャロン[SEGA](無印のほう)には勝ててないけど。


6.4

@TightVNCを試す・Internet経由篇。

微妙に仕事が手空きなのも手伝って、TightVNCで遊ぶ。sshのPort ForwardingでLANに飛ばして、そこから接続。

_Tight(ssh 圧縮なし)
LANでのRawぐらいには動く。リモートであることを考えれば、使えるレベル。
_Hextile(ssh 圧縮あり)
転送単位が小さいので、大きな書き直し時のレスポンスが特に悪い。全体としても、総じてレスポンスは良くない。コンソール的なアプリなら、許容できるか。
_CoRRE(ssh 圧縮あり)
Hextileと同様の問題を抱えているが、こちらの方がより遅い。不満。
_RRE(ssh 圧縮あり)
一気に来る感じは健在だが、描画までの遅れが結構気になる。
_Raw(ssh 圧縮あり)
遅い。

まーだいたい予想の通り、tightが一番使える印象。ということで、しばらくあれこれ使ってみたいと思いますです、はい。

@謎。

いくらなんでも無茶苦茶からは逃れたらしい。つーか、マジでびびった。やりすぎのトバしすぎ。今なお戦々恐々。


6.7

@見えてるけど、見えない。

Slashdot-jpより蛍光灯で無線LAN?元論文に目を通した感じでは、むしろ「見えるラジオ」とかの方が近い気がするけど、既存の施設を利用して構内情報の発信ができるのは面白いです。むしろ直接の敵はBluetoothかな? 帯域の心配とか、よそからの電波の干渉とかはあまり気にしないで済むし。

@Vmware-network with DHCP + NAT

なぜかお仕事でVMwareと戯れ。

VMwareで動く各マシンのネットワーク設定。要求こんな感じ。

  • 1: プライベートな(外部と干渉しない)IPを割り振って
  • 2: 外を見に行けるようにせねばならない
  • 3: しかもVMが究極的にいくつ動くものか不明

ということで、1よりVMwareのHost-Onlyネットワーク、2よりIP-Masquerade、3よりDHCP、の設定が必要ということになる。

ということで、設定のポイントはやはり3つ。

  • VMwareでVMを作る時に、Host-Onlyネットワーク設定にする。場合によってはvmware-config.plの再実行が必要かも。
  • ホストOSの側でIP-Masquerade設定をする。今回はカーネル2.2.18だったので、ipchainsでこれを設定。今回は、JFのLinux IP Masquerade mini HOWTOなど参考に。
  • vmnet用DHCPサーバの設定をいじって、仮想ネットワークに接続された各マシンが適切な情報を受けとれるようにする。具体的には、/etc/vmware/vmnet?/dhcpd/dhcpd.conf(rpmでインストールした場合)に、適当に以下の項目を設定。
    • option domain-name-servers
    • option routers

という感じで、なんとか目標達成。


6.8

@TeXで縦書きでコピー本で同人誌

――とかいう検索が、週に数度はやってくる今日この頃。ちうことで、簡単にノウハウなど。むろんTeX前提。

  • dvioutなど使うのは邪道です。というか、せっかくPostScript吐けるんだから、そっち経由の方があれこれと楽です。環境を立ち上げるまで苦労するかもしれませんが立ち上げてしまえば後はあれこれ自動化が利きますです。
  • ということで個人的にはdvipskでごー! なんですが、全フォントをPostScriptフォントにできるんならdvi to psの変換ツールでも問題ないです。面倒だけど、ちゃんと設定してやれば、綺麗で小さなPostScript & PDF を作ることもできます。こちらのページなど参考にどうぞ。
  • コピー本のために面付けをしたいなら、psutilsのpsbookを使うのが吉です。はっきり言って超楽勝に面子つけができます。あとはpsnupと組み合わせてあげればかなり幸せ。
  • ところで縦書きのときは、graphicsパッケージがよろしくない動作をしたりするかもしれません。対策は、「一時的に横書きモードで絵を張りこむこと」が安直かつ単純です。どういうことかはこのへん参考に。
  • あー、それからせっかくTeX使うのだし、PerlかRubyかawkぐらいは憶えましょう。ちゃんと使い方を憶えれば、よくある原稿ミスの修正(「はは」みたいに、助詞が重複してしまうとか)が簡単にできます。TeXのマクロも憶えると楽になりますが、あっちは微妙に敷居が高いので。
  • ところでスタイルオプションにtombowを指定すれば、トンボがついてくれたりするので、印刷屋さん持込にもそれなりに対応します。ちうか、TeXってもともとそういうツールやねんけどな。

難点は、どれもこれもそれなりに苦労することです。あまつさえ、望みどおりに動いてくれないことがままあります。そのへんは頑張って慣れてください。一度やりかた確立してしまえば、後は半自動で楽チンなので。

質問などは、ツッコミ用フォームからお気軽にどうぞ。役に立つかは知りませんが。


6.9

@強引

なんとなくPerl/Tk遊びなどしたくなって、家の機体に(当然)きっちり入ってるCygwinの上でインストールを試みる。――失敗

ライブラリ回りで文句を言われているらしい。X回りのライブラリがないとかなんとか。……そりゃあここはWindowsな環境だ。なくてもおかしくはないだろう。ということで対処法を検索。――失敗。有益な情報は私には発見できず。

最後の手段。ActivePerlをインストールして、ppmでTkモジュールをインストール。それからおもむろにCygwinのsetup.exeを起動して適当に先に進める。でもってパッケージ選択画面で右上のFull/Partボタンを押すと全パッケージの一覧が出るので、そこからPerlを発見してアンインストール。仕上げにCygwinを起動して、% ln -s _Active PerlのPerl.exe_ /usr/bin/perlとして、エイリアスを張って完了。

――で、疲れたので本日のPerl/Tk遊びはなしの模様(^^;


6.11

@意図。

昨日のコンフェデレーションズカップ決勝戦。

トップ下森島……はいいんだけどさぁ。なんで西沢ワントップなわけよ? 森島は絶対2トップの下の方が活きると思うんだけど。しかも守備的MFが3人? およそ守る気なんだろうけど、そしたら前線は西沢じゃないでしょ。――という感じで、相変わらず意図の見えない布陣で始まった試合。

がっつり引いて、がっつり守りますよー、と言われればそういう布陣なんだけど。でもでも左サイドの小野を高い位置に張らせて、守備的MFの一人が半ばサイドバックみたいなポジションを取れば面白いかもとかいう期待はあっさり外れ、見事に押し込まれて実質5バック体制に。こうなると、日本のサイドが利かないからますます攻められる。守備が最終ラインに依存せざるを得なくなって、ラインコントロールに失敗したところを攻め立てられる。GK川口が頑張るけど、彼が頑張ってる展開はダメなんだってば。

_ハーフタイムの交替にはいくらかは意図が見えた。稲本OUT、三浦(淳)IN。中盤、というかサイドを押し上げて、高い位置で勝負していきたいという感じ。ただ、やっぱり攻めるには中央の駒が足りない。波戸も三浦も中央に切れ込んでいくスタイルではない。それとも小野にタイミングの良い飛び出しを望むってか?

_後半14分。小野OUT、久保IN。――小野OUT!?いったいどこから攻める気ですか? 2トップにして前線が崩しやすくなるってのに、そこに的確なイメージでもってパスを配給するそのパサーを外すとは、どういう了見ですか?

とはいえフランスも疲れてきてて、わりと形はできたりする。できたりするだけに益々小野OUTが痛く感じる。

_後半28分。西沢OUT、中山IN。とにかく動く中山は、この時間には非常に嫌らしい。実際効果的で、これまでの時間以上に形を作れたけど。けど結局、形止まり。

で、負け。善戦とは言えるかもしれないけど、結局のところ負け。あっちを立てればこっちが立たず、こっちを立てればそっちが立たず。それを絶妙に立たせるのが作戦ってもんでしょ。

_やっぱり中盤を高く保つ意識が必要だし、それを補うためならフォーメーション(not システム)も変更されて然るべきだと思うのです。大事なのはなにをやるかであって、そのための手段に拘泥するのは本末転倒ではないかと。

@検索で検索

ここ数日のrefererより。「Perl 簡易検索」「シグネチャファイル 検索」「フリーソフト ベクタ変換」「perl バイナリデータ」「ストップワード 日本語」「シグネチャファイル 全文検索」「全文検索エンジン ひらがな カタカナ」――以前もぼつぼつは来てたのだけど、なんかそんな感じの言葉が急に増えた。アクセス元のサーバもあれこれと違うし、同一人物の検索というわけでもない。大学なホストさんもいくつかあるけど場所が散ってるからどこかの課題で出たというわけでもない。

全国的になぜか検索システム構築が流行だったりする? なじぇ?

@市松模様の恐怖

「どのピクセルが何番目」は、市松模様を渡されたときに死にませんか、と言っておくテスト。理由はちょっと考えればわかっていただけるかと思います。そんなん入力されない、と割り切るならそれでよいですが。

6.13

@地雷踏み

はいっ! ということで、本日何故かVMware + WeirdXにチャレンジなのです。それも何故だが会社のお仕事マシンでっ!(*1)

ともかくっ! jre-1.3.1を突っ込み、そいでもってWeirdXを起動、普通にターミナルとかが動くのは確認っ! それではいよいよ! VMwareですっ! なんかいろいろ文句言われるけど気にせずに! それっ! はいっ! 画面がマトモに出ませんっ! 以上、失敗っ!

――ってなわけで、VMwareってどーにもXFree86にめちゃめちゃ依存してるような雰囲気です。ちなみにVNC経由でチャレンジしたケースでは、色が凄いことになりました。

このぶんだとASTEC-X等のもろもろのWindows用Xサーバもダメっぽいなぁ。むぅん、残念。


*1一応業務の一環なので、純粋に遊んでいるわけではない。無論息抜きであることは否定しないけど(^^;

@

検索:「Linux+RPC+ソース」で飛んでこられた方へ。

おそらく該当するものは、glibcのソースの中にあると思います。適当なglibcのソースを拾ってきて展開すると、どっかにsunrpcとかいうディレクトリがあって、その中がまるまるSunRPCの(ライブラリ部分の)ソースです。


6.14

@本日の検索

_「ORACLEのバグ+クソ」
よほど腹に据えかねることがあったと見えます(笑)

@領域問題。

はて

私の日記を読んでて杉山で画像ツールというと、思いつくのは約一名いるのですが、確かに彼の言を思うに研究の方向はそんな感じだしたぶん間違いないんじゃないかな、でもでもいちおう違う可能性だってあるし、でもいいや公開コンテンツなんだから、ということで本人そうだと思うなら挙手っ!

ちなみに私の考えたということになってるアルゴリズムは、その筋のひとならもっとよい方法しってるんじゃないかしらと思うような、至って単純な代物です。たぶん誰かがとっくに思いついてて、名前もついてるんじゃないでしょうか。

ということでなにげなく同僚様方に相談。即座に「フーリエ変換」のお答え。あー、やっぱそっちかぁ。んでも、「基本的に劣化起こるもんから2値だとダメかも」だそうで。

ところでPhotoshopプラグインがあれならGimpのプラグインなりなんなりにすること提案。絶対にSDKタダだし。


6.15

@捕捉&修正

物欲日記三昧からの捕捉を確認しつつ、気がつくと+xビットが落ちててHEADでLast-Modifiedが取れなくなってたのを修正。

@乱雑系

sshd_configを書き換えても状況が変わらんなぁ、とよくよく調べるとLinux-PAMの存在を認知。そーいやそんなもんあったなぁ、と思いつつ格闘開始。つーか、ドキュメントわかりにくい。しかもこれは、再コンパイルしないと目標が完全達成されないっぽい?

まぁ、できる部分だけでも実用上は問題ない。ちうことで、そこで諦め。

_なんでこんなにあれこれ機構が錯綜してるのよー。ムカツクー! 便利なのはわかるけど、これじゃ見通し悪いじゃんかよー! 初心者のためとか汎用性のためとか言ってごてごて突っ込んでいくんじゃWindowsと一緒じゃんかよー!

ちうことで、あれこれのLinuxディストリビューションの見通しの悪さを再認識。トレードオフだというのはわかるのですけど、ね。


御意見・御感想の宛先white@niu.ne.jp