非常に遅いマシンのアップグレードを現在行っています。数年前の Intel Atom です。ビデオを観たり XBMC を使用したりするには最適ですが、数百のアップデートを解凍するにはかなりの時間がかかります (リリース アップグレードのように)。このアップグレードが完了したら、もう一度アップグレードを行う必要があります。
今日、一般チャット ルームで、リクエストをプロキシし、パッケージを解凍して渡すことができるより高速なローカル サーバーを介して、パッケージのダウンロードをプロキシできたらすばらしいのに、と考えていました。
まだ計画中ですが、いくつか質問があります。
- 圧縮されていない deb パッケージを使用することは可能ですか?
- deb から圧縮を解除するにはどうすればいいですか?
- 圧縮を削除するとチェックサムが壊れますか? もし壊れる場合、どのように修正すればよいですか?
答え1
1) 実際にはそうではありません。理論的には、deb のビルド時に最低レベルの圧縮を使用できますが、Ubuntu ビルダーはこれを行いません。遅い部分はおそらく解凍ではなく、ファイルの解凍とディスクへの書き込みです。ここでは、BIOS 設定、ドライブの回転速度、ドライブの種類など、いくつかの要因がディスク I/O 時間に影響する可能性があります。理論的には、deb 内にデータ アーカイブを配置できますが、data.tarそれでも若干の圧縮 (または膨張) があり、ディスクへの書き込み速度には役立ちません。
2) 1)を参照。
3) はい、バイナリ deb を取得してdata.tar.gzその内部を置き換えると、サイズ、タイムスタンプなどが変わります。何かを行うには、deb パッケージのビルド時に行う必要があります。
一方、前述したように、速度の問題はおそらくディスクへの書き込みにあります。BIOS をチェックして、ディスクの設定を変更することができます。SATA ディスクを使用していて、BIOS が IDE/ATAPI として通信するように設定されている場合、読み取り/書き込み速度は非常に遅くなります。設定がAHCI可能な場合は変更してください。SSD を使用していない場合のもう 1 つの一般的な問題は、ディスク RPM です。使用しているディスクのサイズや RPM を指定していませんが、2.5 インチ 4500～5400 RPM ディスクは、7200～15000 RPM の 3.5 インチ ディスクよりも遅くなります。また、SATA I (1.5Gbps) ディスクは、SATA II (3.0 Gbps) または III (6.0 Gbps) ディスクよりも遅くなります。ディスク キャッシュ サイズもここでは重要な役割を果たします。また、使用している Atom の種類や RAM の容量については言及していませんが、思ったほど遅くはありません。これらは最高級の i7 ではありませんが、deb パッケージで使用される圧縮の量は、通常、問題にはなりません。
答え2
圧縮を解除するために、私が思いついた方法は次のとおりです (これは決して他のことに答えるものではありません)。
ar vx debianutils_4.3.4_amd64.deb
gunzip data.tar.gz
ar d debianutils_4.3.4_amd64.deb data.tar.gz
ar q debianutils_4.3.4_amd64.deb data.tar
パッケージは大きくなりました。チェックサムは完全に間違っています... しかし、圧縮されていないので、まだ有効なパッケージです。