トップをねらえ! と2! を一気に観た。すでに最終話が出て1年半以上経ちますが、思えば欝が悪化して4話まで観て止まってたんだな。

2!は最後のシーンは良かったものの、残念ながら初代ほど感動しませんでした。逆に初代は今でも私のつぼに嵌る。この差は何でしょうね。タシロ・タツミ艦長みたいなのが2!には居なかったのが、私には大きかったかもしれない。最終話で彼が搾り出す「頼む!」「すまん!」の二言は、ガンバスターが最後の望みであることを強力に印象付ける。

それに対し2!の最終話は途中からノノとラルクの世界になってしまって、他は蚊帳の外。ノノのノノリリに対する想い、ノノの孤独、ラルクの想い、地球を失おうとしている人類の苦悩、どれも表現が希薄。もっとノノの想いを掘り下げてくれれば、最後のシーンは感動できたと思うんだけどなぁ。

2!を擁護する考えもあります。元々初代は4話完結で作られたもの。その後6年間続編を出さなくてもいい状況にも拘らず、眠らせるにはあまりにももったいないシナリオができてしまったために5-6話が追加され名作となったわけです。製作条件から見ると2!の1-6話は初代の1-4話と比較されるべきで、その場合は2!の方が出来は良いと思う。というか、4話で終わる初代は凡作。

続編は前作の世界観を引き継ぐにせよ壊すにせよ、何らかの影響を受けるという難しさもあります。2!は最後をあのような形で締めてしまった以上、追加シナリオで初代のを超える変貌を遂げるのは難しそうですし。

以上、いまさらのトップをねらえ2!感想でしたｗ

去年は私 、今年は実家のほうの都合で。また新幹線のキャンセル料払ったぞｗ

欝はここ1ヶ月ほぼ症状が出ない。これが続けば、薬の服用も減らせる。1年で変わるものだなぁ。

さぁて秋葉原に行くような欲しいものもないし、実家で観ようと借りてきたトップをねらえ2! でも観ますかね・・・いつの間に劇場版なんてやってたんだ・・・

以前トラブってfsckがエラー吐きまくったサーバ ですが、600GBある/homeのfsckがなかなか終わらなかったため、システム復旧に時間がかかりました。

その反省を踏まえ、/homeの中でも容量食うくせに使用頻度の少ないディレクトリを別パーティションに分離、システム復旧時にはこれらのfsckは後回しにできるようにする変更を。

大きなデータが退去した/homeのパーティションは、そのままでは空き領域が大きすぎるので縮めることに。LinuxのLVM(Logical Volume Manager)で管理されたボリュームにあるので、GNU Parted とかQT Parted とかは使えず、コマンドラインからの操作となります。とはいえ、この手の情報は検索すれば大量にヒットしまして、シングルモードに移ってから、

# umount /home
# e2fsck -f /home
# resize2fs -p /dev/VolumeGruop1/home 500G
# lvresize -L 500G /dev/VolumeGruop1/home
# mount /home

などとすればOK。個人的にはresize2fsとlvresizeの500GBは同じ定義(1KBは1024Bか1000Bかというお話)かと心配でしたが、この二つのコマンドは同じ定義のようです。

さてこのサーバの立ち上げ時、私は/homeほか大容量のパーティションのファイルシステムをext3, xfs, reiserFS(そう言えば、Reiserさん有罪になっちゃった みたいですね)のどれにしようか迷いました。最初に候補落ちしたのはreiserFSで、SUSE Linux が将来性が不透明という理由で標準ファイルシステムをreiserFSからext3に変更したのが気になったから。

xfsを落とした理由は二つあります。

1. 縮小ができないこと
2. 大容量のパーティションで修理ができなくなる可能性があること

一番目は今回の変更でもやりましたが、縮小ができないということはせっかくのLVMによるディスク管理の柔軟性に制限をかけてしまうことになります。

もうひとつは意外と知られてないかもしれません。xfsでfsckに相当するxfsrepairコマンドは1GB当たり1～2MBのメモリを使用します。ファイルシステムのサイズが小さいうちはこれは問題にはなりませんが、2TBを超えるようになると必要メモリが4GB以上になります。

これ、メモリアドレス空間が4GBしかないi386では大問題です。メモリをどんなに付けようが、スワップファイルをどんなに割り当てようが、CPUの制限でOSは4GB以上の記憶容量は提供できません。つまりxfsファイルシステムに損傷が起きても、メモリ不足で修復できなくなってしまうのです。修復できなければマウントもできないので、生き残ったデータだけ吸い出すということもできません。

x86_64では広大なアドレス空間がありますので、時間がかかって良いならメモリが無くてもスワップファイルを追加、ごり押しで修復できる道が残されています。ならば修復のときだけx86_64のマシンにつないでやれば良いじゃないか、と私も考えたのですが、どうもxfsはi386とx86_64では互換性が無いらしく、この方法も使えず。

2年以上前の判断ですので今は改善されているといいのですが、もともとxfsは広大なアドレス空間を持つSilicon Graphicsのマシン用に開発されたもの、今更滅び行くi386に対応するよりx86_64に換えてくれということになってるのではないかと。

i386のLinuxで2TBを超えるxfsなんてことやらなければこんな問題気にしなくてすみますので、そのように運用すればいい話です。私の場合はx86_64のマシンが手に入らず、大容量でのパフォーマンスが売りのxfsで小容量の運用してもなぁと思い、ext3にしたわけです。

今年もグロい画像を掲載する日がやって来ました。健康診断です。胃カメラです。一年前の記憶 など頭に残っておらず､今年も飲み込む要領つかめず､3回ほどえづく。そういえば去年もこんな風に軽く意識が遠のいたことを思い出しながら､そんな状態で画面に映っている内容の説明されたって､まともに判断できやしないｗ

胃カメラの結果はいたって良好で､丸で囲んだ部分に潰瘍の後があるけど問題無しとのこと。しかしまた便検査で潜血が出てしまった。私は強度の便秘の上に便が固いので排便するとかなりの確率で出口を傷つけ出血するわけで、そのせいだと思うのだけど・・・また大腸内視鏡 か・・・・？

ひょんなことから12の82乗なんていうとんでもない計算をすることになったのですが、結果は10の82乗よりも大きいわけで、83桁以上なことは確実。64ビット浮動小数点 を越える計算、さてどうしたものかと思ったらこの手の計算は複数の言語でサポートされているらしい。

PerlではMath::BigIntクラスがそれにあたり、Perl 5.8からは標準で含まれる。それ以前のPerlでもCPANでインストール可能で

cpan -i Math::BigInt

でOK。で、以下のスクリプトを組んでめでたく89桁の結果を得ました。

bash-2.04$ cat test.pl
#!/usr/bin/perl

use Math::BigInt;

$x = Math::BigInt->new("12");
$x = $x ** 82;
print $x->bsstr()."¥n";

bash-2.04$ ./test.pl
31107289852948419532830210325169922767038593747425104848349825951609481990716300348882944e+0

玄箱 で1秒足らずで出力されましたが、もっと桁数の大きい計算を繰り返すには遅すぎるのでGMP とそれに対応するPerlライブラリMath::BigInt::GMPを使用すれば速くなるとのこと。小数を含む計算にはMath::BigFloat。

こういうこと経験すると、計算機って便利だなと思う次第。

[参考]

• Perl 5.8 Documentation
• まめめも
• GMP