[Fedora-livecd-list] livecd-creator proposal for compression option

[Bruno Wolff III]

On Thu, Jun 10, 2010 at 23:26:23 -0700,
  Jasper Hartline <jasper.hartline at gmail.com> wrote:
> > 400 megabytes is not insignificant. I had to drop a rtelatively popular
> > first person shooter from the games spin because I needed about 150 megabytes.
> > (There was a lot of tweaking near the end of the desktop spin which the
> > games spin derives from, so the amount I was short varied at the end of
> > the cycle. But I can tell you that 400 megabytes is enough to include at
> > least two relatively large games on the spin.)
> 
> Ok. So -in your opinion- 400MB is not insignificant.
> Go ahead and enlighten me on what is an insignificant value of space
> in your opinion.

For the games spin, probably about 1 MB. Even 10 MB can be useful, but
there is some variability due to changes in packages, so you can't cut
the image size to close to the 4 GiB limit (by Spins SIG policy that's
the limit, not 4.7 GB) or the spin might break just before the release.

> > space can be important in that case. For the spins that fit easily on
> > their target media, it isn't a big deal.
> 
> Yes exactly, which means you are going to introduce broken features
> into tools which are already
> broken and need more solid patches added which deal with more
> fundamental issues than
> a 10% size savings, to accomodate the only thing that is important to
> you, which is a "games spin".
> As I said this benefits nobody but a small niche of Linux gamers, and
> in your corner case..
> I have yet to actually see another user on this list mention anything
> about games.

It isn't specifically about games, but the fact that the games spin is
near the image size limit, and more related packages can be included
if there is better compression. Some of the other spins also could make
use of more space.

> > The games spin is just under 4 GB. A 10% savings there is approximately
> > 400 MB.
> 
> Really insignificant. 4GB won't fit on a CD which holds a maximum of
> 850MB even with
> my testing showing SquashFS 4.0 w/ lzma nor zlib.

The games spin is a DVD image. The same code is used, it just targets a
different media size. (Actually the limit is 4 GiB so that windows users
can download the images in most cases.)

> > The above statement makes no sense. Please try rewriting it if you want to
> > persue that argument.
> 
>  The space you save with mksquashfs w/ lzma gets worse when the
> targets get larger in size.
> e.g you start saving less, not more.

> > And that extra 10% let's me put a couple of more relatively large games
> > on the games spin. It also helps with making custom spins with even more
> > games targetting an 8GB usb drive.
> 
> Yes I didn't notice I had a box of 8GB USB drives in my closet, thank
> you for reminding me

Well I did have a dozen of them last Christmas that I gave out as presents
with live Fedora images on them.

> > It's my time to waste.
> >
> > If lzma support for squashfs gets into the 2.6.36 kernel it will be supported
> > in Fedora. (Though maybe not at the F14 release.) Whether or not it gets
> > included in 2.6.36 is iffy. Phillip needs some time to rework his previous
> > patches into a form acceptible to Linus. He actually has patches in his
> > own git branch, but I have tested them. Nor do I know if they are improved
> > or if they are just the patches that were rejected.
> 
> The benefits or lack thereof for squashfs w/lzma is the issue we are
> discussing, the not being supported currently nor anytime in the
> future to be able to do the testing, is just another issue which
> apparently only I thought of.

The next merge window will be in August. The patches might even show up
before then. It just depends on whether or not Phillip gets to work on them.
I don't need to wait for those patches to land to test the 4.1 version
of squashfs-tools to make sure it works with zlib and to see if there
are obvious performance issues with mksquashfs. I can also test changes
to livecd-creator to make sure that the changes to allow for specifying
lmza compression don't break things for zlib compression. And if I want to
get some idea if the live image performance is going to have problems I
can build a kernel with the developmental patches the Phillip has sitting
in his git repo now. The latter won't be real high priority, as they
may perform a lot differently than the final version.

> Also nobody can test something simple like squashfs w/ lzma
> compression and a kernel with this support without
> having a local, Everything synced repository mirror or access to a
> network with one.. due to syslinux not being available on the DVD ISO
> nor livecd-creator honoring repo directives with teh --cost specified.

This makes no sense. Live DVD images work.
If you want to use specific repos, you can specify them in your kickstart
files. But certainly if you are going to be doing a lot of DVD sized
composes it makes sense to have a local copy of the repos you want to use.

> I understand already, it isn't important to you, but to me.. it surely
> is, and it is important to me because it is beneficial to many members
> of the community, not just my local Linux gamers LUG who I am
> spokesman of, or whatever it is
> the benefit to the games spin you think this brings without breaking
> something already broken.

So what are you doing about getting it to happen? You can't really think
that trying to persuade me to not work on lzma compression for live images
is going to get me to work on adding syslinux (in addition to or instead
of isolinux) to live images. I already have enough Fedora stuff I can work
on to keep me busy full time, if I had that much time to do it.