[Python-Dev] Re: Planning to drop gzip compression for future
bac at OCF.Berkeley.EDU
Sat Sep 18 21:57:56 CEST 2004
damien morton wrote:
> Umm, gzip compression is also one of the possible http compression
> algorithms. bz2 isnt.
What does HTTP compression have to do with whether we have a gzipped release of
My personal take on all of this is that we make the release manager's job as
simple as possible. That means either ditch gzip files or ditch bzip2 files.
If we stick with gzip we basically eat the bandwidth cost. If we go with bzip2
we need to link to where to get the source to compile, if not host a copy of
the bzip2 source ourselves. But either way I completely sympathize with the
release managers and I am all for making people's lives easier at release time.
So I say we should go with bzip2. While we might get our bandwidth for free
thanks to the good graces of XS4ALL and Thomas, I don't think we should view it
as infinite since they are still footing the bill. If we can do something
easily that would reduce their cost enough to buy Thomas a soda I think we
should do it. If that means some people need to go download some free
software, then so be it. Considering Python has practically no required tools
beyond a C compiler we have rather low dependency requirements for UNIX in my eyes.
Hell, bzip2's source is less than the difference between 2.4's bzip2 source
package compared to the gzip one. We could have a copy of the latest bzip2 on
our server for people to download and we would still save on bandwidth even
when people need both Python and bzip2.
Plus, without starting a flame war, bzip2 is under a BSD license so it gets a
gold star from me. =)
More information about the Python-Dev