[plamo:22949] bzip2(Re: Re:不具合？報告)

[KOJIMA Mitsuhiro]

From: Shun-ichi TAHARA (田原 俊一) <jado@flowernet.gr.jp>
Subject: [plamo:22946] Re: 不具合？報告
Date: Fri, 11 Jun 2004 11:45:14 +0900 (JST)

> > KDEがどれくらいの容量かわからないんですけど、gzipからbzipにしたらそこそこ容
> > 量が
> > 下がると思うのですが、なぜパッケージ管理の圧縮がgzipのままなのか前々から少々
> > 疑問です。
> 
> CDの容量はlibcのバージョンアップやパッケージ数の増加に伴って、長期的に
> は緩やかな単調増加の傾向にあります。圧縮方法の変更は、一時しのぎにはな
> りますが根本的な解決にはなりません。
> 
> # 仮に 1GB 入るCDが現れたとしても、いつか溢れるだろう、ってことです。
> 
> > 機能やライセンス的な問題があるなら別ですけど、圧縮、伸張の時間も最近のCPUな
> > ら
> > 特に気にすることがないような気が。
> 
> 一番の問題は、インストーラからFDブートしたときにbzip2を入れる余裕があ
> るかどうか、ですね。ノート相手でも、USB CDブート以外は捨てていい、とい
> う時代が来れば、このへんの制約が一気になくなってくれるという期待が持て
> ます。

昔，Kernel ML でもこのあたりの議論はあって(bzImage は gzip 形式の圧縮
になっているけど，bzip2 にすればもっと小さくなるのでは，というのが始ま
りだったと思う)，結論として，「bzip2 を使えば数割程度は小さくなるけど，
メモリは gzip に比べてより大量に必要になるし，展開に gzip よりもはるか
に時間がかかるので，全体のトレードオフを考えると bzip2 化するメリット
はない」ということになっていたと思います．

また，ディストリビューションなんてのを作っていると「最近の CPU」だけを
対象にするわけにも行かない，という問題もありますね．

# 一方，古いマシンスペックに囚われすぎると新しいマシンへの対応が遅れる
# ので，そのあたりのバランスが難しいところ．

-------
こじま