On Thu, Jun 10, 2010 at 23:26:23 -0700,
Jasper Hartline <jasper.hartline(a)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.