On Thu, Jun 10, 2010 at 23:26:23 -0700, Jasper Hartline <[email protected]> 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. -- livecd mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/livecd
