這篇真的和 gcin 有關，請耐心看下去…XD

之前的印象一直是 xz -9 得吃很多 RAM, 所以不愛用。

後來發現 user 端解壓 xz 其實不太耗記憶體，而且解壓速度比 bzip2 快，直逼 gzip，tarball 壓縮效果又常常比 bzip2 好（若單純只有文字，bzip2 往往比 xz 好），其實很適合用於 tarball release。

偶然注意到 xz 有個 --extreme 選項，可以用 low level compress 就達到很讚的壓縮效果（視 data 內容而定）。

經過實測 -0e (-0 加上 --extreme) 就可以讓 evilvte tarball 達到最小，比用 -9 -8 -7 什麼的都強多了，而且 -0e 在 user 端解壓縮只需要 1MiB 記憶體，輕量得讓人難以想象是 xz 壓縮啊！

用暴力 script 在 ramdisk 實測 gcin 1.6.5 tarball 使用各種 xz 參數，目前的結果是用 -7e 最好，user 端解壓縮只需要 17 MiB 記憶體，在這連手機都上 1GiB 的年代，17 MiB 簡直可以忽略不計了。

以下是暴力實測 gcin 的「filesize 參數」結果：

如果嫌 -7e 對 end-user 負擔還太重，可以考慮像 -2e ，檔案沒大多少，解壓只需要 3 MiB 記憶體。

2612268 7e.xz (62% of bz2, 94% of xz -2e)
2612268 8e.xz
2612268 9e.xz
2618224 8.xz
2618224 9.xz
2618292 7.xz
2631128 6e.xz
2631952 5e.xz
2637592 6.xz
2643656 5.xz
2711392 4e.xz
2713588 3e.xz
2765428 2e.xz (66% of bz2)
2766156 4.xz
3101152 1e.xz
3126504 3.xz
3191480 2.xz
3342288 0e.xz
3612660 1.xz
3891588 0.xz
4206394 gcin-1.6.5.tar.bz2

壓縮率是不錯，問題是下游 packager 能不能接受 xz，有人開始用了嗎？

glibc 等 upstream 很早就開始固定 release xz tarball 了。

slackware / arch / fedora 已經把 binary package 全面換到 xz 好幾個月了。

ubuntu binary package 已經有不少內定都用 xz 。

debian 近日正式從 source 到 binary 到 official archive system 都支援 xz (目前只有 essential binary package 為了相容 stable release 升級等因素，暫不可用 xz)

tar 的完整 argument ？