Your "wish" is not "correct"

Project DOUBT のような事をしていると、よくいろんな人から
「Linux に問題があるらしいけど、じゃあどうLinuxを使えばいいの?」
と聞かれる。で、実際のところ
「どうしようもありません」
という事実を伝えると
「無責任だ」
となじってくる人が結構多い。

いや、無責任といわれても。そもそも、Open Source OS は Linuxだけじゃない。それを Linux に限定したのは私ではない。あんたらだ。

私が Linux を作ったというのなら無責任といわれてもしょうがないが、ありゃ私が作ったものではない。

おまけに、その Linux をろくなテストもせずに採用したのに至っては、あんたらがやったことじゃないか。私じゃないぞ?!?!! なぜ 私が 無責任なんだか言って見やがれっ!!!!


さらに、この手の人は「自分の希望が正しい」と思い込んでいる。たとえば NFSv2 や v3 では同期的整合性は保てない。のに、同期的整合性を前提とする要求を平然と出してくる。同期しないんだから「いつデータが反映されるかなんか何の保障も無い」と言っても
「いやいやいや、むつかしくてわかんない。」
とくる。ばか者。「むつかしい」んじゃなくて、自分の望みと違うだけだろうが。それは幼稚園児がおもちゃ売り場の前で手足をばたばたさせて泣き叫んでるのと同じことだ。


というわけで、私の説明を聞いて、「難しい」といいたくなったら、それはあなたが無責任な要望を出そうとしているのだ、と考えなさい。常に。

私の説明は「簡単・明瞭・簡潔・丁寧」に決まっているんだから。

Am I lucky? or Unlucky

12/19は、東急田園都市線にとって厄日だった。
7:30 頃、二子玉川の辺りで車輌故障が発生。8:00に再開するも全線各駅停車。しかも、その運行さえ前後の車輌間隔のせいでものすごく遅かったのだ。

おかげで普段より10分も早く駅に着いたのに、会社に着いたのは普段よりも40分も遅れてのことだった…。


さて、このちんたらした電車の中で、時間をつぶすために「AI麻雀」for PSPをやっていた。そうしたらなんと。緑一色をあがることができた…。

さて、今日、私は lucky? それとも unlucky?

Have they requested for BINARY interface? or Source Level interface?

When we talk about device driver interface, there should be three styles, not two:

1. Source code level interface.
2. Binary code level interface.
3. interface for user process device driver interface.

According to what I believe, 1 is usually good idea. Having 1 with full GPL, will prevent non-open device driver availability, and help device driver programmer for they do not have to re-write driver whenever internal interface changes.

2, on other hand, is somewhat little bit more disgusting. You can make it from 1, if you designed the interface. But usually not necessary.


3, lastly, I belive, is something we SHOULD have. This interface will give driver programmer to do debugging at user space, can test long run test to see for memory leak, etc.

Since user process device drivers performance are usually terrible due to lots of system calls required, if proprietary device drivers are being released in binary-only user process style, there shall be only three cases:

1) user choose different HW, for it performs terrible in Linux
2) HW vender will give up, and make program open
3) they decide Linux not to be their market

Any case seems OK to me.... I mean, it's really TRAP for those who do not make device driver source code open. Once they choose 3 for solution, Marketing and Sales persons will start helping community, by forcing development section to SPEED UP the device driver.


If source code could not be open due to BUSINESS reason, we should give them the reason why it is better. Not by giving ideal, broad view. By showing concrete vantage.

What was the problem behind?

Greg,
I do wish to know about "what was the reason behind their problem."
# because it lacks subject, it might be of NFH's reason, but might be of open source side.
# what were you trying to say?

I do have one point of sympathy about NFH's opinion having "Abstraction Layer."

When people outside the HW vendor tries to write device driver, they ether reverse engineer, or read manual. Anyway, HW is already fixed, and solid. Solid enough so that reverse engineering do works. Solid enough so that people can write manual about it.


This is not so for programmer INSIDE the HW vender. HW is not solid, the interface ( and the timing of interfaces ) changes very rapidly. I even experenced interface changing 3times within a week. I see many peoples not believing this, but it does.

How can they change so rapidly? Didn't creating new mask for chips takes about several million dollors? Easy. Because the changes are being caused by micro code, the software.

Hard Coded chips are already there, with plenty of bugs (most of them are still not being found yet ). HW venders do not have extra budget to re-design a chip again. How do we fix HW bugs? with micro code, and if we can't? we call it spec, and device driver have to handle it. Because micro code is under development, they change. The change speed of under development microcode is even faster than kernel interface, and bug list grows like ... like ... I think it's the fastest growing stuffs in the universe...

But on the other hand, many vender wish to have their driver on newest kernel as well. As result, device driver programmer have to take care of two changes at once. One from micro code, and other from kernel internal interface change. This will kill device driver programmer.


How can we help device driver programmers from dying? Fix the interface of kernel to solid state, so that programmers can concentrate on interface change of HW. At least, you can't blame people who came up with this idea, no matter how stupid it may be.

I don't know if this idea is good or bad. But I do have sympathy with people working inside HW vender, trying to struggle for device driver, and those who trys to ease their works by defining Abstraction Layer.

Also, I do know that in old days, well designed Abstraction Layer did last for 10 years without change, and did scale. I don't know if we can say same thing for next 10 years, or even 5 years. But it did in past. How can you blame if people next to hell dreamed of new design lasting for next decade...


If Abstraction Layer is bad, we should not simply give them a reason why it's bad, but also how to solve their problem. How to ease their device driver programmer, without telling them to look for a change within kernel every week, nor month.

Not writing a driver till HW is solid, is not the answer. That's for sure.

The most powerful subwoofer on the planet

これはすごい。

これ、何だと思いますか?
扇風機じゃありません。換気扇でもありません。

重低音用サブウーハーですよ。

Eminent Tech TRW 17 というこいつは、WebPageによると、ファンが左右に回転して「送吸風」を発生させ、それによって 1Hz の波を作り出すのだそうだ。

ま、確かに。旧来のコーン紙を動かす方式では1Hzのスピーカーを作るのは至難の業だわな。
普通のコーン型のスピーカーだと100Hz出すのに片道最大3cmぐらい移動できるように出来ている。同じ速度でコーン紙を動かすと、1Hzだと片道300cm…3mだ。3m! もはやそれはスピーカーとかではなく「棒」である。

いや、まぁ、それにしたってさ。原理はわかるけど、誰? これを「造ろう」って言った人は。

Press Enter ....

まずはこれを見てほしい。なかなかのスクリーンショットでしょう?


じゃぁ、今度はこれ。もう少しロングから：


見慣れている人はもう判ったでしょうか?

こ れは2005年10月22日に、 JAL 780便のエコノミークラス 18-Dで、自席についているモニターを撮影したものです。本来ならば、ビデオとかオーディオとかが楽しめるシステムなんですが、こいつを interactive モードにして『映画』を選択し、画面になかなか映画一覧が出てこないので思わず6連射をぶちかましたら出てきた画面がこれです。

たぶんベースは Monta Vista なんじゃないかなぁ、と思います。/rhs73/lib/の下にあるのが何なのか本当のところは判りませんが、ゲームか何かを実装する際に Red Hatのライブラリでも使ったのでしょう。


いや、何も飛行機の娯楽施設にLinuxが使われるようになったことを喜びたいわけでも、嘆きたいわけでもありません。今回得られた経験値はちょっと違うところにあります。


最初のほうの画像の最下段にはこうあります：

Please press Enter to activate this console.

しかし、「Enter キー」なんてありません。手元のコントローラーには。いや、もちろん、組み合わせもいろいろ試しましたとも。でも駄目です。どうしようもありません。

はっきり言いましょう。ものすごいストレスです。イライラします。要因は2つです。

1つめの要因は、『本来使えるはずの娯楽施設が使えない。回復させるための操作も出来ない』という事から来る、不自由感に基づいた不快感です。リブートさせれば直ると判っているわけですから、一刻もはやくそのような操作をして環境を回復したいのに出来ない不快感。これはこのような画面を見せられたユーザー誰もが感じることでしょう。

でも、そんなのは2つ目の要因に比べれば些細なことです。
『目の前にバグがあり、
勝手知ったる世界であり、
かつソースコードへのアクセスが阻害されている』
この不愉快さ。Richard Stallman が FSF を作るに至った不快感と本質的に同等な不快感です。
これを検出した瞬間に、GPL2.0では駄目だ!! と思いました。

GPL2.0では、結局GPLで配布されているバイナリの持ち主が、「ソースもくれ」と言えば、ソースコードがもらえる、という制約しかありません。今回バグを出したプログラムがGPLで公開されていたとしても、2つも問題があるのです。

1. ソースをくれと言って、ソースが手元に到着したころには飛行機は目的地に着いている
2. ソースをもらっても、キーボードがない環境ではデバッグも出来ないし、システムへの再インストールもできない
   

どちらも、「そりゃそうだ」としか言いようがない話に過ぎないように見えますが、これらはようするに

• GPL2.0 ではソースコードへのアクセス時定数という側面を考慮していない。
  つまり、ソースコードは「いつかは」手に入るだろうが、「それがいつになるのか」の保証がない、という事です。
• GPL2.0 ではソースコードへのアクセサビリティの保障という側面を考慮していない。
  つまりソースコードは得られるかもしれないが、それは、このジャンボジェットの座席システムのように著しくアクセサビリティの悪い環境でしか参照できないように細工されたメディアかもしれないのです。

という事なのです。

GPLに対して LGPL があるように、GPL3.0では是非、コントロールレベルを複数存在させてほしい。その中にはこれらのアクセサビリティ問題についても

「常にソースコードを参照し、
常にソースコードを変更できる環境を
ユーザーに提供しなくてはいけない」

などという一見非常識なほどの制約をかけたものも用意してほしい。そして、それを選ぶ自由を、プログラマに与えてほしい。


そんな思いが去来したのが、最大の成果でした。


なお、JALの名誉のために言っておきますと、離陸5分後にはリセットをかけていただきましたし、その後はちゃんと動作していました(6連射はやっていませんが)。周囲の座席への影響もなかったようです。

ただ、そのように復旧してしまったコンソールはただひたすらに退屈なものに過ぎず、私は映画も見ずに眠ってしまったのでした…。

OSDLのF2F、金曜日は万里の長城と明墓観光ツアーです。その万里の長城でのこと。

坂の下のほうにある巨大な駐車場に、人民軍のものと思しきトラックが何台も停まっています。何だろうと思いつつバスは坂を登っていきます。と、なんと膨大な人民軍の皆さんが。

この写真は車から降りた後、撮影したものですが、後ろから来るわ来るわ、すごい数です。しかも機関銃を持ってます。

そして、駆け足で我々を追い抜いていきます。元気あるなぁ。

彼らは長城の中でもハードな方を登って行きました。
隊長のような人が定期的に何かを叫び、そのたびに皆さん、駆け足になるのですが、一瞬だけです。万里の長城を駆け足で登るなんて無理だって。

で、このようにずらーーーっと並んで、何かを大声で叫んでいる所を、本格的な機材で撮影している人達がいました。この右の写真を撮影している傍でもプロ用のデジタルカメラを数台使っていましたから、何かの撮影だったんでしょう。

私はというと、このシーンを撮るために簡単な側を負けないぐらいの速度で駆け上っていました(いや、足が死ぬかと思った)。

で、撮影が終わったのでしょう。ものの30分ほどで彼らは帰っていきました。


たぶん、彼らは本物の人民軍でしょう。そして機関銃も本物でしょう。偽者を作る理由はありません。人民軍を雇うほうがコストが安いですし、偽の機関銃をいちいち用意するより、官給品から弾丸を抜いたほうが手っ取り早いでしょうから。

しかし、これに付き合わされて、空とはいえ機関銃もって万里の長城を登らされる側の身にも…。
だって右の写真を見てください。人の身長と壁面のブロック2つ分の高さ、おおよそ同じですよ。

しかも、この部分、全体的に見ると局所的に緩やかな部分です(右上のほうの斜面が急になっている部分と比較すればわかります)。とんでもない急斜面で、撮影は実質5分足らず…。

たぶん、これ、鍛錬の一環として扱われるんだろうなぁ。

OSDL F2F 1日目:あるいは今回の頭痛の種

今回のお仕事で一番頭痛の種なのが実はこの人。
Andrew Tridgel 君。そう。Samba の開発者だ。

いや、何が頭痛の種かって、この人黙んないんだわ。喋る、喋る。まぁ、ペラペラペラペラ、よく口が回るなというぐらい喋る。他人の言うことなんざ聞いちゃいねぇ。

「OSDL オーストラリア代表」とか冗談をかましていたが、冗談抜きでオーストラリア全部の人たちの分まで喋る気じゃなかろうかというぐらい…。

自分が興味のあることだけをぶちかます、という意味では一番厄介で、逆に言うとこれを Linus にぶつけるのが一番丁度よいかもしれない、というそんな人物。

と、人物評ばっかりしてもしょうがないので、Samba 4 の話を少しだけすると。

Samba 4 は Samba 3 からは 根こそぎ 変更したものだそうだ。もう、根本構造から入れ替えて、一種のプロトコルコンバータとして成立させるらしい。すると、IDL で記述しやすくなるので、大半を IDL で書き直すそうだ。この結果、Samba 3 から Samba 4 へはコードシェアの分量が圧倒的に少なくなるらしい。

これに関してはよい点と悪い点。
よい点は IDL を使って記述するので、テストが自動生成しやすくなる、という点。
悪い点は Samba 2 で入れて、Samba 3 で蹴飛ばされたのでもう一度力で押し込んだ(しかも、Samba-JP の成果を自社だけの成果のように主張している会社がいるが実はそれは大間違いな) あの、MS-Kanji ⇔UTF-16 変換コードが、また落っこちる可能性が高い、という事だ。当人は、
「高橋基信 が作ったテストコードを通すから大丈夫だ」
と言っているが、さて。IDLで書き直してテストも入れ替えるのであれば、当然このテストに通すのを忘れる公算は高い罠。

と言うわけで、Samba4 は一から評価しなおす必要があるようだ。

ちなみに人物評に戻ると、この人はその口の回転速度以外は基本的に田舎者です。つまり、人柄的には悪い人じゃない。が、普通はその口の回転速度はオバチャンの独壇場だと思うのだが…。

Cool, yet Dangerous guy

中国、北京に来ています。お仕事です。
OSDLの全体合同ミーティングに出席するためです。

さて、会場のホテルでかっこいいものを見つけました。ガラスと金属ばねで出来た渋いやつ。左右対称形がきらりと光っています。

しかし、これは危険な奴です。体重計です。
ちょっと油が切れている感じがしているので、表示体重は若干少ない目に出るのがサービスかもしれませんが、まじめにメンテナンスするといい感じな数字が出てしまいます。

しかも場所は中国。ご飯が美味しい場所です。これからしばらく、こいつと同室する必要がある、というのが悩みの種…。

Book Stores were closed on Shibuya

渋谷へ行ってきた。ロットリング純正のコンバーターが欲しかったのだ。が、渋谷では手に入らなかった。それは良いとしよう。

問題は、渋谷の

• 旭屋書店
• 大盛堂

が両方とも閉店。楽しみが半減してしまった。

もう渋谷は駄目かもしれない。なのに、そのうち仕事場が豊洲だと?! 大手町も通らなくなるのか!?!
却下だ、却下。関東で丸善と紀伊国屋と神保町と秋葉原の最低限3箇所へ10分以内に到着できないところに、技術系の会社が開発部隊をおいちゃいかん！

「優先順位」は「優先順位」

万年筆、それも無印良品のそれについてのページをいろいろ探していたら面白いことを言っている人がいた。ので、これに反論してみたい。(あぁ、天邪鬼だ)

世に出回っている「仕事の仕方」指南書的なものによく書いてある
「優先順位をつけて優先順位の高いものからやる」
という仕事のやり方には、アルゴリズム的に考えて2つのポイントがある。

1. ソートの概念がある
つまり、仕事Aと仕事Bには、1次元的な価値基準で分類できる、という事だ。もしこれが直行する2次元、たとえば「Aは背が高い、Bは体重が重い」のような事を言われたら、比較できない。

2. 比較関数は「お金に換算しての優劣」をベースにしている
ぶっちゃけた話、あの手の本に書いている事を要約すると、ある仕事AとBでは、Aの方が「金になるから」優先するのである。一見似たような収入の仕事A, Bの場合も「A を先にやらないと、損害額がでかくなる」からAを優先する。つまり、収入期待値を使っているのだ。

さて。もうお判りだろう。このページの著者は、実は 1 については何も言っていない。むしろ同意している。2 が「収入期待値」じゃなく「自分がやりたい興味」にしたい、と言っているだけなのだ。

でも考えて欲しい。「優先順位をつける」のは別に「収入期待値でソートしなくてはいけない」という意味ではない。単に企業で働いている人の大半は収入期待値でソートしてくれないとたまったものではないから、その例を出しているのに過ぎない。し、またその説明を受けてそれ以外の発想が出てこない人は、それで十分なはずだ。だって仕事は「お金を得るために」やってるはずだからね、大半の人は。

じゃぁ、そうじゃない人は? つまり、比較関数を収入期待値以外にしたい人は どうすればいいのか?簡単だ。そのために「研究員」などの肩書きが存在する。この肩書きの分捕り合戦に勝てばよいのだ。そして、上記のように「ソートアル ゴリズムの存在」と「比較関数」のような考え方が出来れば、研究員程度の肩書きはどうにかちょろまかすことは可能なことだろう(おいおい)。

何のことはない。「自分の興味」を『優先』規則にできると思いつける人は、そういう職に就ける、というだけの話だ。残念ながら、研究員なら自分の興味を常 に優先できるとは限らない、というより実はそれ嘘、普通の開発の人たちの方がよほど自由よ、と話は続いてしまうのだがそれはさておくことにしよう。

壊れたファイルシステムは元に戻らない

１：１ Hot Standby型のシステムがある。サービスを提供するマシンAと、その双子マシンBで出来ていて、Aが何らかの理由で倒れたらBが take over する、というものだ。

AとBはSAN経由でディスクを共有している。とはいえ、A が動いている最中にBが同じディスクをマウントしてしまうとディスク上のイメージに矛盾が発生する。そこで、A が動いている最中はAだけがこのディスクをマウントし、AがこけたらBがマウントするようにしたい。

問題はこうだ。Aがこけた。当然、Aがマウントしていたディスクは適切な umount 処理を経ずに倒れている。Bが mount しようとすれば、当然「適切に umount していない」ことは検出される。Bはこのディスクを mount する前に何をすればよいだろうか?

この問題、意外と面倒くさい。まず、Journal FS 以外の場合、無条件に fsck が動く。がfsckが動いて ファイルシステムが正常になるかというと、そんな保証はない。fsckは矛盾を検出して矛盾を解消するだけであって、その解消方法が2通り以上合った場合、正しい解消方法を選ぶ保証はない。つまり、fsckは破壊を確定的にする危険性があるのだ。

Journal FS であれば、Journal を apply すれば大丈夫だろうって? そんなことはない。
そもそも Journal に記録されているメタデータ更新が「必要十分」とは限らない。indirect block更新をユーザーデータ更新だと言い張るファイルシステムは存在するし、この場合、fsckを動かさないと indirect block上にある矛盾は検出しない。

Journalに書かれている通りにメタデータを更新したらメタデータが壊れた、何てこともざらにある。ext3なんかこのバグの温床だ。理由は３つ。
1) Journalのフォーマットがあまりにも高密度すぎて、Journal なのか「前回 journal を書いた際の忘れ形見」なのか区別がつかないJournalが発生してしまうこと。
2) Metadataの更新順序がそもそも間違って Journal に記録されている場合があること
3) Journal block の更新順序が正しくない場合がある(Journalはlogなので、先頭から順に書き込まれる必要がある。これが守られていない場合がある。シークに対するａｃｃｅｓｓ最適化がかかってしまっている場合にこれが生じる)

最後に、Journal をいくら apply しても bad sector 検出にはならない。理由は簡単で、bad sector は head 退避中に生じるかもしれないからだ。本来書き込むはずのない sector が bad sector を起こしている場合、これの検出は全sectorチェックしかない。fsckでフルセットのチェックをかけるしかないのだ。


A->Bの一回目の切り替えの際に障害が起こっている可能性は低いと思う。でも、だからと言って、チェックを怠れば、A->B->A->B->A->B ぐらいの切り替えで、赤字のタイミングで生じた障害が、顔を出す危険性がある。あまりにも遠い過去に生じた破壊によって生まれた障害は、もうバックアップ をどこまで戻せばよいのかも、そこからどうやって復旧すればよいのかも、判らない状態に陥るだろう。もう、ホットスタンバイどころの話ではない。

fsckで障害が検出された場合、修復できる保障ができるチャンスは低い。しかし、fsckで障害が検出されない、というのはサービスを継続するべきかどうかの判断には重要なのだ。

fsckは、非正常切り替え時には毎回行うべきである。自分が致命傷を負ったのか、まだ大丈夫だったのか、判定できるのは fsck だけなのだから。

その意味で言うと、Journal FS にしたからといって、何かを速くしてよいわけではないのだ。

The HichHiker's Guide to the GALAXY

見に行ってしまいました。

これはもう傑作でした。原作はC級(ベースストーリーが公共事業でダム湖の下に沈む村から抗議に出かけた若者の話だった辺りが、クラスを大幅に下げているんだが)だったのに、映像化したらA-ぐらいまでクラスアップしてたよ。恐るべし、ビジュアライゼーション。

特にポイントはオープニングのイルカさん達。彼らの歌は秀逸でございました。もう、あれだけで掴みはオッケーみたいな。

馬鹿話を見たければ、是非お勧めです。見る見るうちに脳みそが溶けて、ヘラヘラ状態に陥ること請け合い。

Bug in template

I found a bug in template of this blog.
Information about this template was as follow:

Blogger Template Style
Name: Thisaway (Rose)
Designer: Dan Rubin
URL: www.superfluousbanter.org
Date: 29 Feb 2004

In this template, there was line that look like following:

<head>
  <title><$BlogPageTitle$></title>
  <$BlogMetaData$>

This part was at very beginning.

This works fine for Thunderbird, but did not work fine for IE.
The reason was pretty simple. It's because I was using non-ascii character on title. I'm using UTF-8.

As you might notice, UTF-8 and ASCII are compatible for first 128 characters.
Therefore, even if header parts are like above, as long as blogger are using ascii base characters for it's title, no problem arise. But what will happen if I used characters like ... Kanji, for example.

Since HTML assume default character set to be ASCII, HTML Brouser have right to assume non-ascii character to be what they BELIEVE. IE on Windoes XP-SP1 Japanese edition, assumed characters to be Shift JIS. And as result, views were all messed up.

Solutions were pretty simple. What we needed was the following line before the title:

  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

This line was generated by <$BlogMetaData$> line at the beginning. This line needed to be before <title><$BlogPageTitle$></title> the title line.

So comes the solution. Change the template from

<head>
  <title><$BlogPageTitle$></title>
  <$BlogMetaData$>

to

<head>
  <$BlogMetaData$>
  <title><$BlogPageTitle$></title>

And you'll have happy life.

mantis

A Mantis I shot several days ago.
Cool.

スケジュールすでに破綻予定

大変由々しき事態が発生した。2つの重要なイベントがぶつかったのだ。

• Black Hat Japan(http://www.blackhat.com/html/bh-japan-05/bh-jp-05-jp-index.html)
• OSDL F2F in Baijing

どちらも同じ10/17の週である。しかも 10/18からの F2F と 10/18 までの BHJ、場所は東京と北京、どうあがいても無理だ。

あぁ、どうしてくれよう。こんなことなら、BHご本家に行っておけばよかった。
日本で火が吹いてようが何しようが、私のプロジェクトではなかったのだから。

空軍は土木業でもある

ジェリー・パーネルの混沌の館にてを読みはじめた。積読リストから偶発的にpopされたのだ。
ここに書いてあった、目からうろこの内容がタイトル。

確かに考えてみれば、空軍は土木業なしには成立しない。
航空機は全て離着陸基地を必要とする。永遠に飛び続ける飛行機は無い。船は一旦就航したらそのほとんどの時間を海の上で過ごせるが、飛行機はほとんどの時間を地上ですごすのだ。当然、そのための基地を設計し、製造し、管理運営していかなくてはいけない。

金持ち父さんだったか…にも同じような話があった。マクドナルドはハンバーガー販売業で儲けているのではない。ショッピングモールなどの作成を手がけ、そこへ集客するためにハンバーガー販売業を営んでいるのであって、実質的には土地の価値を上げて、賃金を稼ぐ不動産業なのだそうだ。

こういう本質論は、まだまだどこかに落ちていそうだ。

FFVII AC

DVD 買いましたよ。
いきなり、見ましたよ。
おぉ、ゲームのときと全然違う。見栄えが違う。
あのつるつるお肌はどうしたんだ、ユフィ。
そうかその上着はジーンズをピンクに染めたものだったんだな、エアリス。
そしてティファ、設定であったはずの揺れる胸はどうしたんだ。揺れてないぞ…

それはともかく、モデルが違うとここまで見栄えが違うのか、と驚き。
これはPS3最初のゲームとして是非、FF-VII again を作って欲しいものだ。
当然今回のDVD用モデリングデータで。

first try

let's see what will happen.
さ、どうなるか見てみよう。