On 20-01-2009 11:55:55 +0100, "C. Bergstr?m" wrote:
More details can be found here [1], but wanted to share some quick
numbers..
1.3M /usr/portage/packages/app-editors/vim-7.2.021.oxe
1.5M /usr/portage/packages/app-editors/vim-7.2.021.tbz2
time xar -xf /usr/portage/packages/app-editors/vim-7.2.021.oxe
0.15u 0.01s 0:00.18 88.8%
time gtar -xf /usr/portage/packages/app-editors/vim-7.2.021.tbz2
0.24u 0.02s 0:00.26 100.0%
I ran it more than once and overall it seemed pretty consistent.. So
what exactly is under the hood
.tbz2 == bzip2 compressed data, block size = 900k + xpak tagged on
after EOF so that metadata can be easily extracted..
.oxe == xar archive - version 1 + xz (lzma2) compressed and using xar's
built-in toc to store metadata (gzip)
More details can be found here [1], but wanted to share some quick
numbers..
1.3M /usr/portage/packages/app-editors/vim-7.2.021.oxe
1.5M /usr/portage/packages/app-editors/vim-7.2.021.tbz2
time xar -xf /usr/portage/packages/app-editors/vim-7.2.021.oxe
0.15u 0.01s 0:00.18 88.8%
time gtar -xf /usr/portage/packages/app-editors/vim-7.2.021.tbz2
0.24u 0.02s 0:00.26 100.0%
I ran it more than once and overall it seemed pretty consistent.. So
what exactly is under the hood
.tbz2 == bzip2 compressed data, block size = 900k + xpak tagged on
after EOF so that metadata can be easily extracted..
.oxe == xar archive - version 1 + xz (lzma2) compressed and using xar's
built-in toc to store metadata (gzip)
Gentoo's xpak can be done with lzma or gzip as well IMO. It's not
really an argument, but more like I think you should focus your decision
on the metadata part. Things like how easy it can be extracted
(with/without compression tools?), transparency, etc.
My 0.02 ${currency}.
I'll be ironing out metadata details a bit later today, but open to
suggestions. I'm initially including a qalevel in the metadata so that
a policy by administrators can be used to filter out packages not
meeting a certain level of assurance/testing. I have other ideas of how
to build in tools so that customizing different aspects of the OS are
policy based instead of requiring a reinstall. The bottom line for
administrators will be subscribing to "channels" which will have the
choice between things like kde vs gnome vs E vs something else or mysql
vs postgresql.. So if you have a custom postfix setup that's backed by
postgresql you'll have a full stack compiled just for that and not just
using the everything approach. Of course this won't fit everyone, but
making and maintaining custom channels should be fairly easy.
If you're good with python or C code I could use help to speed this up.
Once the items on the packaging TODO [1] are done I'll push for more
public testing and eventually ask for more community mirrors.
suggestions. I'm initially including a qalevel in the metadata so that
a policy by administrators can be used to filter out packages not
meeting a certain level of assurance/testing. I have other ideas of how
to build in tools so that customizing different aspects of the OS are
policy based instead of requiring a reinstall. The bottom line for
administrators will be subscribing to "channels" which will have the
choice between things like kde vs gnome vs E vs something else or mysql
vs postgresql.. So if you have a custom postfix setup that's backed by
postgresql you'll have a full stack compiled just for that and not just
using the everything approach. Of course this won't fit everyone, but
making and maintaining custom channels should be fairly easy.
If you're good with python or C code I could use help to speed this up.
Once the items on the packaging TODO [1] are done I'll push for more
public testing and eventually ask for more community mirrors.
--
Fabian Groffen
Gentoo on a different level
