[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B773B31.1020802@lougher.demon.co.uk>
Date: Sat, 13 Feb 2010 23:52:17 +0000
From: Phillip Lougher <phillip@...gher.demon.co.uk>
To: Jean Delvare <khali@...ux-fr.org>
CC: Pavel Machek <pavel@....cz>, lasse.collin@...aani.org,
mirrors@...nel.org, linux-kernel <linux-kernel@...r.kernel.org>,
"FTPAdmin Kernel.org" <ftpadmin@...nel.org>, users@...nel.org
Subject: Re: [kernel.org users] XZ Migration discussion
Jean Delvare wrote:
>
> Compared to bz2, gz saves... 2% on the overall time. As a conclusion, I
> think we can plain discard the argument "I need .gz because my machine
> is slow" from now on. It simply doesn't hold.
>
I agree, but, IMHO the main argument for keeping .gz is cross-platform
availability and wide language support, not hardware limitations. Doing
a quick google brings up .gz interfaces for every language you can think
of (C, Java, Perl, Python, TCL etc.), not to mention complete separate
implementations in Java and Pascal (not just wrappers on top of the zlib
library), and probably more.
With xz you have just one C/C++ implementation with a single library with
an undocumented API for C/C++ programmers.
It may be a slight stretch of the imagination, but with with .gz you can
conceive programmers writing programs to download a .gz from kernel.org and
decompressing/searching it, in almost any language of choice. With the JAVA
implementation .gz is genuinely cross platform and you don't need glibc/
C++ compilers, just a Java VM. Contrast with xz, where if the xz utility
isn't available, or doesn't do what you want, you're stuck with programming
in C/C++ with all the baggage that entails.
Phillip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists