デジカメ壊れてなかった, デジカメといえば以前壊れたと思っていたデジカメは、単に液晶ファインダーが off になってただけでした。気づくのに２ヶ月もかかった俺って…。
壊れた、と思ってたせいもあり、ちょっと最近のデジカメ事情をいろいろ調べていたりしました。
各社カメラのサンプルを見ていて、最近のカメラの中ではどうやら Panasonic のカメラの写り方が僕の好みっぽい。なんだか微妙にざらざらした質感が、妙にぺったり、ケバケバした写りのカメラが多いなかで僕には気持ちよく感じます。人によっては「ノイジー」と感じるかもですね。
本当は DMC-LC1 が一番気になるけど、大きさ、価格的に微妙なので、もし本当に買うなら DMC-FX１ かなぁ。買わないけど(笑。
「ヨコハマ買い出し紀行(11)」
ところでこのマンガもいわゆる「終末」、人類の黄昏を描いたものだと言うことになっていたと思います。最近、このタイプの「終末」話、「ナウシカ」なんかもそうですが、人類の力が衰退して徐々に自然に圧倒されていく話に、微妙な違和感を感じるのです。
今の僕には、このタイプの「終末」感には、自然に対する甘えがあるような気がしてならないんですよね。人類がいくら幼く未熟で傍若無人を働いた (その結果自ら滅びの道に入り込んだ) としても、自然はそれを全て受け止め、最終的には全てを元の通り癒してくれる、という虫の良い希望が含まれているように思うのです。「ナウシカ」の腐海や王蟲なんかは、思いっきりそういう、時に厳しく、時に優しい包容力のある存在として描かれていますよね。
でもそれって無邪気に期待できることでしょうか。自然、って、なんとなく一つの大きな主体のように感じてしまいがちですが、実際には小さな循環系、自己組織系の集まりです。そして当然ながら、人間もそこに組み込まれています。「人」とは別に「自然」という主体があるわけじゃなくて、人は自然の一部なわけです。当たり前ですけど。
人が自然の一部である以上、人の成した結果こそが自然の未来である、ということになるのではないでしょうか。自らの成していることをきちんと認識せずに、いたずらに多様性を奪ったり環境を変化させたりしていると、自然はそれを鏡のように反映するでしょう。「人間のやることなんて」という過小評価は、バタフライ効果によって否定されるでしょう。自然、いわゆる生物圏は完全なカオス系ではありませんが、かといって変化がすぐに静まってしまう秩序系でもありません。
もし人類にゆるやかな終末が訪れるとしても2、たぶんそれは「自然による救済」などではなく、それまでの業に真っ正面から向き合わされるものになるのではないか、それも腐海や王蟲のような慈愛に溢れたものではなく非常に冷酷な現実として、と僕は思うのです。
その後の Opteron, その後の PSXFedora Core 1 for x86_64 入れてみましたよ。さらにとんでもなく速くなった処理あり、かえって遅くなってしまったものあり。安定性なども含めてトータルで考えると 64bit Llinux の価値は現在のところまだ微妙ですね…1。
２回めのアップグレード後、ゲームを起動するタイミングや市販の DVD を見ようとするタイミングで、「しばらくお待ちください」と言いながら静かに電源が OFF になってしまうことがあるような。「あれ？」と思いながら電源再投入すると普通に動くんですけどね。
フラッシュ操作時や通常再生時にもごくまれに、再生が突っかかるようになった気も。こっちはそろそろ HDD が満タンになりそうなことと相関があるのかなぁ。
Opteron 速っ！, SuSE Linux, ハッブル壁紙集Opteron 248 (2.2GHz) ×2、というマシンの評価をする機会があったんですが、これがとんでもなく速い。比較用に使った Xeon 3.06GHz×2、というマシンと比べても (当然 Xeon マシンは HT enable です)、apache bench、pgbench (PostgreSQL)、Java による CPU 処理など一般的なサーバが行う処理についてはほぼ全勝、モノによっては倍くらい速いものも。しかもこれは Xeon マシンと同じ RedHat Enterprise Linux 3、つまり 32bit OS 上での結果なのですから、またびっくりです。Fedora Core 1 (x86_64) や SuSE Linux 9 (x86_64) のような 64bit 環境だとどうなっちゃうんだろう…。
サーバ用ハードウェアって単純に性能だけで決められないことも多いから、２倍の性能を持っていることがすぐにシェア拡大にはつながらないでしょうが、同じくらいの価格で倍くらいの性能が得られるとなると、徐々に稼働実績も出来てきたら、そのうち Opteron を選ばない手はない、って話になっても不思議じゃないなぁ。
カメレオン好きの僕としては最近 SuSE が気になっています1。Sun の Java Desktop System のベースも SuSE だそうで。もうすぐリリースの 9.1 では 2.6 Kernel も入るみたいだし、ちょっと使ってみようかなぁ…2。
ところであのカメレオンはかわいいと思うんだけど、KDE のデフォルトテーマが、全 Window の横っちょにカメレオンの顔がくっつくオリジナルなものなのはちょっと鬱陶しいと思うゾ。
K.Moriyama さんとこやひびきさんとこより。綺麗ですねぇ…。
風邪昨日くらいから風邪で全然声が出なくなってしまった。まともにしゃべれない、というのは結構ツライ。思わず電話に出た時とか、話が全然通じなくて切なくなります。
昨日までは声が出ないだけであんまり具合悪くはなかったんですが、今日になって下痢＋気持ち悪さが増大中。明日お休みしようかしら…。
集中力僕もあんまり集中力ない方で、自発的に集中状態に入れない時1って結構あるんですけど、状況によってはあえて脳味噌を停止して無理矢理集中状態に持っていかざるを得ないことがあります。
そういう時によく僕たち (僕やはかせ) が使っていた表現が「息を止めてコードを書く」。「今から息止めるから話しかけないでね」とか「ぷはーやっと息が出来るよ…」とか「とりあえず息止めて書いちゃって」という感じで使います。
僕にとっては感覚的にぴったんこな表現でした。
エイプリルフール, 「千石屋綺談」ネタ、思いつかんかった…。直球勝負人生だからして、ジョーク考えるのって苦手なんだよね＞SAK。
今年はあんまりいいネタがない気がするなぁ。Google のフリーメールサービス、「Gmail」のメールボックス容量が 1Gbytes、というニュースに驚いてたら、SAK が「エイプリルフールじゃない？」って言ったのが一番面白かったかも。
「いつになく苦い話を集めてしまったシリーズです」なんて作者の言葉に少し身構えてしまったんですが、それほど苦しい話というわけでもなく、少しホッとしたり。総じてこの人のいつものお話です。
「損得勘定がないの。そういう人は幸せになれるわ。」という言葉には、ありきたりながら我が身を振り返らずにはいられませんでした。
ICO 開発者の話, redraw ポリシー, XNA の思想, PSX アップグレード第二弾とても興味深かった。目指す「リアリティ」に到達できないフィーチャーはどんどん削っていく「サブトラクティング・デザイン」は、従来のソフトウェア開発現場から見るときっと目から鱗な話なんじゃないでしょうか。Unified Process を学んだ時にも、「ソフトウェアは自由度が非常に高いがゆえに、クライアントから次々湧いてくる要求をどう管理するかが非常に重要」という話があり、僕の経験上も開発期間中は主に機能を追加する方向にしか向かったことがないように思います1。
機能を削る方向へは、ソフトウェアをリリース後ある程度実働期間を経た後に、明らかに不必要な機能、冗長な機能などに対して行われることが多い気がしますが、「ICO」はたぶん、4年間という一本のゲーム開発としては長い期間の間に、何度か「擬似リリース」を繰り返し、内容を洗練させていったのではないかと想像します。
思い出してみると、ねおんさんはこの「サブトラクティング・デザイン」を結構意識されてたんじゃないかと思ったりして…。
他にも、節目節目でデモ・ムービーを製作し、自分達の目指す方向性を関係者に対して誤解のないよう継続的に示し続けた話などは、ゲームに限らずソフトウェア開発一般の話として、とても大事だと思いました。僕も今業務時間のほとんどを意識合わせのための資料作りに費やしていますが、「目指している方向性を継続的に資料化して関係者に示す」ことの重要性を日々実感している毎日です。
ところで、同じ GAME Watch のこちらの桜井氏の意見は、僕としてはイマイチ。クレヨンしんちゃんじゃないけど、「そーともゆー」って感じ(ワケワカ。
僕は普段、KDE 環境で生活しているんですが、KDE/QT 環境の redraw ポリシーって微妙にダサい。ふとした拍子にチラチラとフリッカーが見られます。個人的に、そのことがなんとなーく信用できない感じに繋がっているような気も。Konqueror は Explorer と (File Viewer として) ほとんど変わらない機能を持っているんですが、どうも積極的に使う気にならないのはその辺に理由があるような…。
あははははは。ねおんさんからのこのツッコミ、
XNAの彼は、ビジネスというものについてはイマイチなので、そのあたりの発言は許して上げるようにw
ねおんさんのつっこみより引用
は、個人的にとてもツボでした。まさにその点を突っ込もうかと思っていたので。
さて気を取り直して。僕もこの記事をとても興味深く読みました。この記事を読んで僕が思ったことは二つ。一つはねおんさんも指摘されているビジネス的な面、そしてもう一つは、やっぱり Microsoft はソフトウェアの会社であるのだなぁ、ということ。
この記事を読むと、Microsoft は、3/27 の僕の意見で言うところの「モデル規定者」の立場を明確に指向しているように見えます。現状、XNA について語られる言葉では、必要以上に「開発環境」というものが強調されているように僕は感じますが、その裏には「プログラミングモデル」自体を構築していこう、というソフト屋の意図がありありとうかがえます。
実は XNA の考え方は、Allard さんが Win32 API との対比を行っていることからも分かるように、Microsoft が昔から行ってきたことでもあるんですよね。かつて Microsoft は、Windows API (GDI やドライバモデル) を規定した上で、オープンな土俵でハードウェアベンダーに競争させることで、より最適化されたハードウェアの発展をドライブし、また DirectX によって同様に 3D グラフィックスハードウェアの発展をドライブしてきました。もちろん、彼らはそれぞれと並行して (それら下位レイヤーからのフィードバックを受けて) モデル自体のブラッシュアップも精力的に行ってきました。この手の物事の進め方についてはお手の物なのでしょうね。
さて、XNA のスコープにおける直接のライバル、SCEI の場合はどうか、というと、実はそういう「モデル発展のフィードバック」を作ることがすごく下手なんじゃないかと思うんですよね。PS の時は SGI という先行者がいたために、プログラミングモデル的には単にそれをなぞればよく、成功の要因は主にタイミングと思い切りのいいハードウェア設計、それに流通改革にありました。PS2 の時も基本的な方向性は PS のころと変えずに単にそれをスケールアップしただけで、PS2 ならではの新しい方向性の提案 (eDRAM による超広帯域 framebuffer とか、VU とか、ある種特異なメモリモデルとか) も、結果的に見るとどうもあさっての方向を向いていたようです。外し具合がたまたま致命的なものではなかったためになんとか成功している、という状況でしょう。
僕が気になるのは、Microsoft が PC の世界というオープンな環境で自らのモデルを提案し、日々ブラッシュアップしていっているのに対し、SCEI はそうしていないように見える点です。そのことは、基本的にオープンな DirectX ベースのプログラミングモデルが載せられることがはっきりしている Xbox2 と、IBM と共に完全な密室で作成していてどんなものになるのか見当もつかない次世代 PS (Cell マシン) の違いを見ても強く感じます。
プログラミングモデル、なんていうものは、「いかに多くの人に理解してもらい、使ってもらえるか」が勝負なわけで、開かれた環境で広く議論され、叩かれた方が良いものが出来ることは明らかだと思うんですが、SCEI にはそういった議論を起こそうという方向性は見えません。出て来るのはなんだか抽象的な話ばかりで、とても議論に耐えうるような情報ではありません。これはうまくない。
確かに、「モデルの実装」という世界ではパテントが全てを支配し秘密主義にも意味があるでしょう。しかし、こと「モデル」の構築を考えた時には、秘密主義は百害あって一利なしなように思えます。
その実装面にしても SCEI は分が悪い状況にあります。秘密主義を取っている SCEI は、全てのイノベーションを SCEI 内で起こす必要があります。ところが Microsoft は、自らの提示したモデルをもっとも良く実装したハードウェアベンダーの製品を選んで使うことが出来ます2。開発者の量が桁違いです。
そういう状況を考えると、次世代 PS が成功するには、そうとう天才的な人が現れて革新的なモデルを提案するか (Cell の伝えられている極めて特殊な構成を見るとこちらを期待したくなりますが、PS2 の時のように思いっきり外す可能性も高いよなぁ…)、または技術面とは全く別のところで相当うまく立ち回る必要があるんじゃないかなぁ、と悲観的になりますね。「PC の世界に深く入り込んでしまっているがゆえに見えなくなっている点」というのもなさそうだしなぁ。そういうモノがあったとしてもたまたま今はまだ注目されていないだけだろうし…。
ビジネス面について一点だけ。Allard さんの言う「開かれた開発環境」を実現するには、現在のコンシューマゲーム機におけるクローズドライセンスモデルではないものを考える必要がありますが、Microsoft はもうずいぶん前からもっと開かれたモデル、つまりオープンな規格の上で、他より価値の高いものを提供することで利益を得る、というよりシンプルなモデルを指向してきているように僕には思えます。ので Allard さんの今後の行方には結構期待!
p.s. マネージャとしてのご忠言、どうもありがとうございます。とても参考になりました。
今回はノーエラーで無事に終わりました。1.3倍再生はなかなか面白い。またしばらく様子を見てみます。
鬱陶しいログapache のログに、
xxx.xxx.xxx.xxx - - [26/Feb/2004:15:56:54 +0900] "SEARCH /\x90\x02\xb1...
で始まるアクセスがウチのサイトにしてはたくさん記録されてて (しかも１行が文字数にして 32806 文字もある)、おかげでログファイルの容量が先週分と今週分で 40Mbytes 超えてる。調べてみたら、上の時刻 (2004/02/26 15:56:54) くらいから始まってるみたい？先週から急に増えてる？といっても先週は一週間で500件くらいだけど…。今週は二日で既に 500 件超。
送信元がまちまちであるところからたぶん worm なんだと思うんだけど、イマイチ確たる情報が得られない。去年の4月に fix されてる IIS の穴が関係してる、という記述は見つかったんだけど…。
apache の名誉挽回, ゲームマシンのアーキテクチャ, ありえないイマイチ結果に納得できなかったので、
でも試してみたところ、小さなファイルでは全て一昨日の apache2 worker MPM とほぼ同等の性能が出ました1。やっぱり速いじゃん、apache。
ところで大きなファイルの場合は、手元でコンパイルしたデフォルト設定のものでも apache2 と apache1.3 の間には大きな差があり、大きなファイルの転送時の効率は apache2 の方が明らかに良さそうでした。
woody 標準の apache が遅い原因はまだちゃんと調べてませんが、考えてみたらバイナリは標準とはいえ、設定については name based virtual host の設定とかされてたりしてあんまり標準的ではないことに気がついたりして…。
ベンチマークは難しいね、やっぱり(汗。
マイクロソフトの「XNA」が発表になったりしましたが、次世代 PS 等将来のゲームマシン、というかエンタテインメントマシンのアーキテクチャについてふと考えてみました。
「エンタテインメント」2の本質が「体験を通して感情を動かすこと」だとすれば、物理デバイスと切り離されたファミコン以降のゲーム機が目指さなければならない方向のうち、もっとも計算量が必要な方向は「計算的に現実感を創出する」という方向です。ちなみにイノヴェイティブな手法でピンポイントにとんでもない「リアリティ」を生むことも可能なわけですけれども、そちらはマシン・アーキテクチャとの相関がそれほど高くない (必ずしも計算量を必要としない) のでとりあえず置いておきます。
「現実感創出」のための一つのピース、3D グラフィックスのクオリティ向上に向けては、昨今の PC ゲームの世界を見ていても、nVidia vs. ATI を始めとして各ソフトウェアベンダー間でも極めて競争が過酷なこともあり、相当スゴイ世界が繰り広げられていますが、もう一つのピース、物理シミュレーション系の話は、Half-Life2 など一部そういったことを売りにし始めているゲームも出てきているとはいえ、まだ 3D グラフィックスほどの盛り上がりが見られません。
将来のゲームマシンには、「物理シミュレーションを効率良く実行する」という特性がある種必須なのではないかと僕には思えるのですが、これって今の PC のアーキテクチャの延長線上で考えるのは難しいんじゃないかと思うんですよね。根拠はまったくなくて、強いて言えば「(将来構築される物理シミュレーションモデルはきっと) 並列度が極端に高い処理だろう」、と僕が想像しているからだけなんですけど。
えーとつまり、3D グラフィックスがシェーダモデルを構築しそれに最適化されたハードウェアを生み出してきたように、物理シミュレーションの世界でも何らかの計算モデルを構築し、それに最適化されたハードウェアを設計する…という流れが出て来るんじゃないかと想像しているわけです。
次世代 PS に搭載される予定の「Cell」が、そこまで考えられて作られているといいんだけど (例えば、順序は逆だけど初めから Cell に最適化された物理シミュレーションモデルが用意されている、とか…)、うーん、なんとなくビミョー(笑。
六本木ヒルズで起きた回転扉での死亡事故について、ドアに挟まれることを防止するセンサーに死角があった、との報道が。
もし本当だとしたらとんでもない話です。その「安全装置」の設計者は、何を守るべきかを全く理解できていなかったとしか思えない。
昨今の情報漏洩事件での漏洩させた当事者の弁に、「(もし情報漏洩させたことが注意義務違反に当たるなら) ガチガチのセキュリティをかけているごく一部の上場企業以外は、どこも個人情報を扱うことが困難になるのではないかとも思う。」なんて話が出ていて失笑したんですが、これも同じですよね。何を守るべきなのか、をきちんと理解していれば、(一部上場企業にしか賄えないほどの・笑) 無尽蔵にコストがかかることなんてなくて、現実的なレベルに落とし込むことが可能なはずです。
なんとなーく「安全装置が必要と言われたので付けました」とか「とりあえずよく分からないけど SSL にしましたから安心です」というレベルの認識で設計されている気がするなぁ。仮にもエンジニアなら、その「設計の意図」を胸を張って説明出来るくらいでいて欲しい。トレードオフに埋もれた現実も理解出来るけど、かといって本質を見失ってはどうしようもないよ…。