タイ，ノンタブリ県の田村です。
すが，これ以上，このテーマでMLのメンバーの皆様に退屈な思いを強いる
ことは心苦しい限りです。[knoppix:3005]で柘植さんがこれまでの経過を
退屈ということはないと思います。 むしろ、興味深くスレッドを追いかけて
いる人の方が多いと思います。 私は少なくとも、興味を持って追いかけていま
すので、 それだけが原因であれば、続けていただいて、まったく問題ないと思
います。
ありがとうございます。ちょっと本業の方で手が塞がっていて、即座にご返答
いたせませんでした。非礼をお詫び申し上げます。
最近の報告では、私がリマスタに使用しているハードディスクの容態を表示す
る数字ばかりの羅列となってしまい，事情をご存知の方以外には意味のないも
のになりつつあると感じていたのです。しかし，この事案に興味をお持ちでス
レッドを追っていらっしゃる方々が、いくらかでもいらっしゃるようですから，
最後に，投稿者本人の立場からまとめさせていただきたいと存じます。
この三日間ほど，これまでの経緯をもう一度反省してみました。その結果，次
のような考えに収まりつつあります。まず，簡単にこれまでの経緯を振り返り
ます。
事態は，KNOPPIX3.2(2003-07-25-EN)のリマスタ中に起きました。私が行った
主な変更点は；
1. 全てのゲーム類, OpenOffice.org1.0.2, TeTexをアンインストール。
2. OpenOffice.org1.1.0-enをインストール（パッケージではありません）。
3. Kochi-subst, タイ語TrueType, Anthy-jmodeのインストール。
4. J2REのインストール（-> 【注記】をお読みください）。
初めての経験だったので，/etc/skelの変更や45xsessionの編集などの要領を
なかなか得ず，何度もリマスタを繰り返していました。2月の初旬にほぼ完
成して最後に、まだ余裕があるからMozilla Firebird 0.7を/opt以下に加えた上で
cloopファイルに圧縮しようとしたところ，konquerorの表示する<source>
ダイレクトリーの総容量が2.2GBほどに肥大化していることに気が付きました。
block sizeは1024です。この場合，無闇に新規パッケージをインストールしな
い限り，通常は1.7~8GBに収まっているはずでした。追加したFirebird 0.7の
容量は27MBほどしかありませんから、一挙に400MB以上も増加したことに
狐につままれた思いでした。
今から考えてみれば，このkonquerorの表示を鵜呑みにしてしまったことが，
躓きの石であったと思います。じっとモニタを見つめて「これは本当だろうか」
と何度も確かめつつメモをとったので，勘違いではなかったと信じていますが，
こんな荒唐無稽な数字には実際，何の根拠もありません。それで「これは、
konquerorの計算違いだった」と考えることにしました。この数字よりも確実な
ものがあります。それは，問題を起こした<source>から作成したCDイメージ
の容量です。[knoppix:2912]でも触れましたように，何とか702MBに収まりま
したので、CDに焼くことができました。１月中旬に作成していたCDが680MB
でしたから、22MBの増量です。これには、新たに加えたFirebird 0.7も含まれて
います。そこで，Firebird 0.7だけをmkisofsで圧縮してみたところ，ちょうど
10MBになりました。したがって、原因不明の増量は、cloopファイル12MB分
だということが判明します。
その後，freedups.plを慎重にオプション"-d -f"付きで/lib, /usrに適用したところ，
<source>容量は1733.5MB，CDイメージの容量では684MBに減量しました。
18MBの減少です。このことをもう一度検証するために，実験用にコピーした
/mnt/hdb1/32origにfreedups.plを適用して，その減量の様子を観察しました。
実験では/usrだけに当てました。1回目はオプション"-d -f"を付けました。2回
目は、最大値の確認のためオプション無しで当てました。その結果，32orig
の容量と，そこから作成されるKNOPPIXファイルの容量は，次のようになり
ました：
- 初期状態 = 1869464 KB -> 724131 KB (707MB) !!
- option "-n -f" = 1814143 KB -> 706379 KB (690 MB): 17 MB 削減
- option無し = 1805569 KB -> 702218 KB (686 MB): 21 MB 削減
以上の結果から，マウントしたKNOPPIXからファイルをコピーして，それを
再びmkisofsで圧縮すると，絶対に容量オーバーになる，したがってオリジナル
からリマスタする際には必ずダイエットするか，freedupsなどを利用してハー
ドリンクを再建しないとならない，ということがはっきりとします。ですから，
リマスタの解説などには、必ずこの点を明記すべきだと感じました。私がこれ
までに読んだHOWTOには，残念ながら，この点に関する記述は一切ありませ
んでした。無用の混乱を避けるためにも，今後新しいHOWTOをお書きになろ
うとご計画の方には，是非この点をご考慮いただきたいと存じます。
それから，freedups.plを利用して/usr以下のハードリンクを再建すると17~18
MBほどKNOPPIXファイルの容量を削減できることも再確認することができま
した。ご関心をお持ちの方にも確認していただけるよう，この実験のときの
ログをhttp://briefcase.yahoo.co.jp/thainichi_thailandにアップしておきました
ので、ご覧ください。KNOPPIXフォルダには次の4つのファイルがあります；
- 01_hardlink_ls.list-KNOPPIX.txt.zip
- 02_freedups-usr.log.txt.zip
- 03_hardlink_ls.list-usr.txt.zip
- check_hardlink.sh
01...は、マウントされた/KNOPPIX/usrのハードリンクの状態を示しています。
02...は、/mnt/hdb1/32orig/KNOPPIX/usrに"freedups.pl -a -d -f"を当てた時のメッ
セージを記録したものです。そして03...は、それによって再建されたハードリン
クの状態を示すファイルです。01...と03...は、柘植さんに教えていただいたコマ
ンド(check_hardlink.sh)で作成いたしました。
問題を起こした私の<source>でも，"freedups.pl -a -d -f"で、18MBほどKNOPPIX
ファイルのダイエットに成功していましたが，この減量分は元々あった680MB分
が減ったのだと考えるのが相当ですから，Firebird 0.7の10MB分を除いた12MBの
増加が一体何の原因で生じたのか，未だに不明です。しかし，この程度の増減は
許容限度内として受け入れるべきなのでしょうか。結論としては，konquerorが
表示した"2.2 GB (2,354,543,472 bytes)"という数字は，やはり「幻の奇怪現象」
であったと言うしかありません。
なお，蛇足ではありますが，少し気になる点が2つほど残っています。まず，
http://www.knoppix.net/forum/viewtopic.php?t=4694でのgodber氏の発言なので
すが，彼は最後に；
"It will probably reduce the size of your image by about 30-60 MB.
I got a 33 MB reduction on the 3.3 9-24 disk"
と言っています。3.2を使った私の実験では，どんなに逆立ちをしてもせいぜい
21MB強しか削減できませんでした。一体どうやったら30-60MBも減らすことが
できるのでしょうか。
第2点は，上記投稿に引用されているクノッパーさんの発言です。CDイメージが
715MBになってしまい，CDに焼けないと泣きついてきた人に対してクノッパー
さんは；
"you are just victim of a kernel bug in the iso9660 filesystem."
と慰めているのですが，もし715MBへの容量増加（私の実験からも、それは裏
付けられています: KNOPPIX=707 MB）がバグのために必然的に生じる現象で
あるのなら、クノッパーさんは"we are just victims ..."と言うべきだったと思う
のです。それを"you are ..."云々と言ってしまったので，場合によって何か特殊
な現象が起きるのだ，と錯覚してしまいます。弁解めいてお見苦しいとは存じ
ますが，少なくとも、私はそう解釈しました。それとも，私の原因不明の12MB
のように，予想以上の増量を示す場合があるとでもいうのでしょうか。
〜〜〜〜〜【注記】〜〜〜〜〜
私はOpenOffice.org1.1.0の多言語サポートを確実にする目的で，J2REをイン
ストールしておこうと考えていました。OOo1.0.xの段階では，J2REを入れて
おかないと、多言語サポートが不完全でした。OOo1.1.0からはこの機能に関し
てはOOo本体に組み込まれたようで，J2REをインストールしておかなくても，
大丈夫のようです。しかし，この点に関する明確なアナウンスメントがありま
せんでしたので、念のためにインストールしておこうと判断したのです。
Javaの再配布ライセンスに関しては，宮脇さんが[knoppix:2957]でご報告の意
見書(http://plaza.rakuten.co.jp/miyawaki/diaryold/20040214/)に全面的に賛成い
たします。J2REに関するSunのLicense Agreementを読む限り，既に解禁して
いると判断して全く問題ないと考えます。但し，宮脇さんもご主張のように，
Live-CDの場合，CD編集者がエンドユーザの代理人として包括的に承諾した
ことを起動時に知らせ，エンドユーザの同意を確認する手続きを組み入れた方
がよいだろうと考えます。これに関連したことなのですが，KNOPPIXのリマス
タに関しても，オリジナルにどの程度手を入れてあるのか，それをエンドユー
ザに知らせるために，概括的でもいいですから、READMEやCHANGEに記載
して同梱しておいた方が，エンドユーザにとって親切かもしれないな，と感じ
ています。これはライセンスの問題ではなく，そこから更にリマスタする際の
便宜のためです。
なお，J2REをインストールして気が付いた点をお知らせします。例えばSunの
ダウンロードサイトからj2re-1_4_2_03-linux-i586.binをダウンロードしてきて，
これを解凍すると"j2re-1_4_2_03"というダイレクトリーが作られます。これを
どこに配置すればよいか、初め迷いました。そこでRedHat9を参照したところ
（ここではrpmパッケージでインストールしました）、/usr/java以下に配置され
ていたので、それと同様に，/usr/java/j2re-1_4_2_03としました。ところが、
この状態ではOOoから認識されないのです。私はリマスタ中，Xnestからkde
を立ち上げて，OpenOffice.org1.1.0/program/jvmsetupを何回も走らせ、その都
度このダイレクトリーを指定したのですが，もう一度jvmsetupを走らせると，
空白に戻っています。そこで，RedHat9の場合と良く見比べたところ，そこでは
/usr/java/j2re1.4.2となっています。ふと気が付いてKnoppixの方でも，ダイレク
トリー名を"j2re-1_4_2_03"から"j2re1.4.2"に変えたところ、やっとOOoから
正確に認識されるようになりました。これはOOoのバグなのでしょうか。いず
れにせよ、うまく認識すると，jvmsetupは/user/config/javarcというファイルを
書き込むようです。他にもっと良い方法があるのかもしれませんが，J2REのイ
ンストールをご計画中の方々，どうぞお気を付けください。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
今回の「奇怪現象」の件では，皆様方をたいへんお騒がせいたしました。心より
お詫び申し上げると同時に，たいへん有益なご助言・アドバイスをいただいた
柘植さんには，結びに当たり，重ねて感謝の意を表させていただきます。また
何事かでお手数をおかけすることもあろうかと存じますが，皆様，その節には
どうぞ宜しくお願い申し上げます。
2004年2月29日
田村志緒理
__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/
|
