原則匿名で公開・個人情報は送られません。必要に応じ御署名/非公開希望をお書き添え下さい。
_ 掲示板:YaPW 旧掲示板 SMIL Boston日本語訳(頓座)
謎掲示板こと仮称LLLL、てけとーにデバッグ中です。ときどきあれこれ動作がおかしくなったりもしますが、ログが吹き飛ぶ以外なら修復可能な状態です。そろそろぼちぼち本来の目的(野放図な議論)に使い出したいと思います。
なんかその前に(とっつき易さのために)普通の掲示板っぽい動作をする雑談板を付加したほうがいいのかもしれませんが。
そそ、今夜――時刻的には昨日ですが――、久方ぶりの人と呑んできました。いろいろあったらしくてお話ついでに近況など話して、やっぱり最後は話がモノ作りな話に行くのは性というべきか業というべきか。
微妙にやる気充填して、書く気力を取り戻してみたり。敵はLLLLのメンテ&バージョンアップが面白すぎることですか。
社会人が日づけ代わる時間にHP更新してるのはどうかと思う
大きなお世話です(笑) と、わざわざもっと遅い時間に更新してみるテスト。
なんかよくツっこまれる日というものはあるもので。
http://www.tightvnc.com はいかがです?(ってまだ試してませんが)
ふむ。会社-家の間で、SSH経由のVNCなら試してみましたのですけど。ベンチマークとかしたわけじゃないのですが、SSHの圧縮オプション(-C)の有無で、確かに体感速度が変わりました。通説では「体感速度の向上」には25-30%ぐらいのパフォーマンス向上が必要、とか言われてるみたいですけど。
TightVNCの場合、「フルカラー画面だったらJPEG圧縮(圧縮率は稼げるが表示は微妙に不正確)できるようにもする」予定だとか。VNCっぽい、適当に手を抜いた(けど効果的な)アプローチだと感じます。
……なんかのどさくさに紛れて消失したらしいVMware Performance Tuning Tipsの(要点の)抄訳をもう一度掲載してみる。もとい、訳し直す。
なに、あれだ。自分で参照したくて検索書けたらすっぱりなかったことに気付いただけだ。
ということで、試してみました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。
という感じ。私の手元のLAN環境では、Hextileで使うのが一番よさそうな印象。
ただ、外から使うとなるとまた違った感じになるだろう。そのへんの検証は後日。
ゲーム批評7月号。P110のZ.O.Eのレビュー。参考に挙げるゲームが違います。ここは絶対に「オメガブースト[SCEI]」を挙げるべきです。オメガブーストの進化形として考えるなら、Z.O.Eはかなり出来がいいです。電脳戦記バーチャロン[SEGA](無印のほう)には勝ててないけど。
微妙に仕事が手空きなのも手伝って、TightVNCで遊ぶ。sshのPort ForwardingでLANに飛ばして、そこから接続。
まーだいたい予想の通り、tightが一番使える印象。ということで、しばらくあれこれ使ってみたいと思いますです、はい。
いくらなんでも無茶苦茶からは逃れたらしい。つーか、マジでびびった。やりすぎのトバしすぎ。今なお戦々恐々。
なぜかお仕事でVMwareと戯れ。
VMwareで動く各マシンのネットワーク設定。要求こんな感じ。
ということで、1よりVMwareのHost-Onlyネットワーク、2よりIP-Masquerade、3よりDHCP、の設定が必要ということになる。
ということで、設定のポイントはやはり3つ。
という感じで、なんとか目標達成。
――とかいう検索が、週に数度はやってくる今日この頃。ちうことで、簡単にノウハウなど。むろんTeX前提。
難点は、どれもこれもそれなりに苦労することです。あまつさえ、望みどおりに動いてくれないことがままあります。そのへんは頑張って慣れてください。一度やりかた確立してしまえば、後は半自動で楽チンなので。
質問などは、ツッコミ用フォームからお気軽にどうぞ。役に立つかは知りませんが。
なんとなく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遊びはなしの模様(^^;
昨日のコンフェデレーションズカップ決勝戦。
トップ下森島……はいいんだけどさぁ。なんで西沢ワントップなわけよ? 森島は絶対2トップの下の方が活きると思うんだけど。しかも守備的MFが3人? およそ守る気なんだろうけど、そしたら前線は西沢じゃないでしょ。――という感じで、相変わらず意図の見えない布陣で始まった試合。
がっつり引いて、がっつり守りますよー、と言われればそういう布陣なんだけど。でもでも左サイドの小野を高い位置に張らせて、守備的MFの一人が半ばサイドバックみたいなポジションを取れば面白いかもとかいう期待はあっさり外れ、見事に押し込まれて実質5バック体制に。こうなると、日本のサイドが利かないからますます攻められる。守備が最終ラインに依存せざるを得なくなって、ラインコントロールに失敗したところを攻め立てられる。GK川口が頑張るけど、彼が頑張ってる展開はダメなんだってば。
_ハーフタイムの交替にはいくらかは意図が見えた。稲本OUT、三浦(淳)IN。中盤、というかサイドを押し上げて、高い位置で勝負していきたいという感じ。ただ、やっぱり攻めるには中央の駒が足りない。波戸も三浦も中央に切れ込んでいくスタイルではない。それとも小野にタイミングの良い飛び出しを望むってか?
_後半14分。小野OUT、久保IN。――小野OUT!?いったいどこから攻める気ですか? 2トップにして前線が崩しやすくなるってのに、そこに的確なイメージでもってパスを配給するそのパサーを外すとは、どういう了見ですか?
とはいえフランスも疲れてきてて、わりと形はできたりする。できたりするだけに益々小野OUTが痛く感じる。
_後半28分。西沢OUT、中山IN。とにかく動く中山は、この時間には非常に嫌らしい。実際効果的で、これまでの時間以上に形を作れたけど。けど結局、形止まり。
で、負け。善戦とは言えるかもしれないけど、結局のところ負け。あっちを立てればこっちが立たず、こっちを立てればそっちが立たず。それを絶妙に立たせるのが作戦ってもんでしょ。
_やっぱり中盤を高く保つ意識が必要だし、それを補うためならフォーメーション(not システム)も変更されて然るべきだと思うのです。大事なのはなにをやるかであって、そのための手段に拘泥するのは本末転倒ではないかと。
ここ数日のrefererより。「Perl 簡易検索」「シグネチャファイル 検索」「フリーソフト ベクタ変換」「perl バイナリデータ」「ストップワード 日本語」「シグネチャファイル 全文検索」「全文検索エンジン ひらがな カタカナ」――以前もぼつぼつは来てたのだけど、なんかそんな感じの言葉が急に増えた。アクセス元のサーバもあれこれと違うし、同一人物の検索というわけでもない。大学なホストさんもいくつかあるけど場所が散ってるからどこかの課題で出たというわけでもない。
全国的になぜか検索システム構築が流行だったりする? なじぇ?
はいっ! ということで、本日何故かVMware + WeirdXにチャレンジなのです。それも何故だが会社のお仕事マシンでっ!(*1)
ともかくっ! jre-1.3.1を突っ込み、そいでもってWeirdXを起動、普通にターミナルとかが動くのは確認っ! それではいよいよ! VMwareですっ! なんかいろいろ文句言われるけど気にせずに! それっ! はいっ! 画面がマトモに出ませんっ! 以上、失敗っ!
――ってなわけで、VMwareってどーにもXFree86にめちゃめちゃ依存してるような雰囲気です。ちなみにVNC経由でチャレンジしたケースでは、色が凄いことになりました。
このぶんだとASTEC-X等のもろもろのWindows用Xサーバもダメっぽいなぁ。むぅん、残念。
検索:「Linux+RPC+ソース」で飛んでこられた方へ。
おそらく該当するものは、glibcのソースの中にあると思います。適当なglibcのソースを拾ってきて展開すると、どっかにsunrpcとかいうディレクトリがあって、その中がまるまるSunRPCの(ライブラリ部分の)ソースです。
私の日記を読んでて杉山で画像ツールというと、思いつくのは約一名いるのですが、確かに彼の言を思うに研究の方向はそんな感じだしたぶん間違いないんじゃないかな、でもでもいちおう違う可能性だってあるし、でもいいや公開コンテンツなんだから、ということで本人そうだと思うなら挙手っ!
ちなみに私の考えたということになってるアルゴリズムは、その筋のひとならもっとよい方法しってるんじゃないかしらと思うような、至って単純な代物です。たぶん誰かがとっくに思いついてて、名前もついてるんじゃないでしょうか。
ということでなにげなく同僚様方に相談。即座に「フーリエ変換」のお答え。あー、やっぱそっちかぁ。んでも、「基本的に劣化起こるもんから2値だとダメかも」だそうで。
ところでPhotoshopプラグインがあれならGimpのプラグインなりなんなりにすること提案。絶対にSDKタダだし。
sshd_configを書き換えても状況が変わらんなぁ、とよくよく調べるとLinux-PAMの存在を認知。そーいやそんなもんあったなぁ、と思いつつ格闘開始。つーか、ドキュメントわかりにくい。しかもこれは、再コンパイルしないと目標が完全達成されないっぽい?
まぁ、できる部分だけでも実用上は問題ない。ちうことで、そこで諦め。
_なんでこんなにあれこれ機構が錯綜してるのよー。ムカツクー! 便利なのはわかるけど、これじゃ見通し悪いじゃんかよー! 初心者のためとか汎用性のためとか言ってごてごて突っ込んでいくんじゃWindowsと一緒じゃんかよー!
ちうことで、あれこれのLinuxディストリビューションの見通しの悪さを再認識。トレードオフだというのはわかるのですけど、ね。