12:20 a.m.
On Thu, Jun 10, 2010 at 9:51 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
> Introducing the option to compress without kernel support is a
big
> mistake I believe
> especially when the only gain is for people who are using slower,
> non-multiple core processors
Why do you think only those people benefit. I would expect in many cases
accessing the data is limited by disk I/O bandwidth and in that case lots
of people could benefit.
I am not sure of the current benchmarks of disk I/O related data
which depicts any significant advantage over mksquashfs using zlib or
mksquashfs using lzma.
Do you have some benchmarks you can throw our way?
> where they gain speed in creation of the ISO, but are not likely
to be playing
> those same games from that CD on that computer anyways, because gamers
> don't use first generation pentiums
> running at 1GHz.
>
> I think you are just jumping the gun and we need to focus on larger
> problems related to livecd-tools than satisfying a small niche of
> gamers by making 10% extra space and a handful of extra games
You are free to focus on what is important to you. I plan to focus at
least some of my resources on what is important to me.
400 MB is an insignificant gain in space saving to livecd-creator
target images, and you fail to
provide the actual uncompressed original sizes and final size using
mksquashfs w/ lzma.
This is insignificant and cannot be readily applied to any single scenario.
Just so you understand what I am getting at, a target ISO of 60MB
of a custom LiveCD I built, only shrank 10MB to 50MB using mksquashfs w/ lzma.
This is using the most minimal set of packages one could.
Where are you getting 400MB from? Because, that is not what I revealed
in my testing.
60 to 50MB is more than 10%, so you are saying the larger it gets the
worse space savings you get..
that is totally outrageous that you believe this is beneficial but not
something like adding 924K syslinux to the base DVD which benefits
many many people when they want to build a LiveCD with just the base
DVD as a repository source. Interesting that we are so enveloped in
ourselves we only see importance in what is as you said
You are free to focus on what is important to you. I plan to focus
at
least some of my resources on what is important to me.
Try that more. 400MB is worse than 50 to 60MB, at more than 10%.
mksquashfs w/lzma makes the gain worse, when the targets get larger.
It will in fact allow a few more well known games to be included in
the
games spin. That is mostly a marketting tool, bur being able to show off
some more games is nice. It also effects people who want to run live usb
images and want to limit the amount of space they use.
The amount of space is
already limited, it;s already a SquashFS with
no more than 10% savings.
> Maybe someone will disagree or perhaps some gamers will comment
on
> your post instead.
It's really not a gamer issue. It is an enhancement in to the capabilities
of live images, in that people will have the option to save additional
space if they want. Probably lzma will be best to enable by default, but
that will require most testing to see.
I think you're wasting your time trying
this because it will be a
while before SquashFS w/ lzma is introduced
upstream for general use, and possibly longer before Fedora enables it
or puts it into stock.
Have fun.
12:58 a.m.
New subject: livecd-creator proposal for compression option
On Thu, Jun 10, 2010 at 22:20:33 -0700,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
I am not sure of the current benchmarks of disk I/O related data
which depicts any significant advantage over mksquashfs using zlib or
mksquashfs using lzma.
Do you have some benchmarks you can throw our way?
Not yet. I would expect it to be better because of the better compression.
But whether that really helps or not depends on typcial access patterns.
400 MB is an insignificant gain in space saving to livecd-creator
target images, and you fail to
provide the actual uncompressed original sizes and final size using
mksquashfs w/ lzma.
This is insignificant and cannot be readily applied to any single scenario.
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.)
Just so you understand what I am getting at, a target ISO of 60MB
of a custom LiveCD I built, only shrank 10MB to 50MB using mksquashfs w/ lzma.
This is using the most minimal set of packages one could.
At least one of the livecd images was pretty tight. 50 MB of compressed
space can be important in that case. For the spins that fit easily on
their target media, it isn't a big deal.
Where are you getting 400MB from? Because, that is not what I
revealed
in my testing.
60 to 50MB is more than 10%, so you are saying the larger it gets the
worse space savings you get..
The games spin is just under 4 GB. A 10% savings there is approximately
400 MB.
that is totally outrageous that you believe this is beneficial but
not
something like adding 924K syslinux to the base DVD which benefits
many many people when they want to build a LiveCD with just the base
DVD as a repository source. Interesting that we are so enveloped in
I didn't say it was important to some people, just not to me (compared to
other things I can work on). I use large custom usb live images and maintain
the games spin, and space savings are important to me, so I am willing to work
on that.
ourselves we only see importance in what is as you said
> You are free to focus on what is important to you. I plan to focus at
> least some of my resources on what is important to me.
Try that more. 400MB is worse than 50 to 60MB, at more than 10%.
mksquashfs w/lzma makes the gain worse, when the targets get larger.
The above statement makes no sense. Please try rewriting it if you want to
persue that argument.
> It will in fact allow a few more well known games to be included
in the
> games spin. That is mostly a marketting tool, bur being able to show off
> some more games is nice. It also effects people who want to run live usb
> images and want to limit the amount of space they use.
The amount of space is already limited, it;s already a SquashFS with
no more than 10% savings.
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.
>> Maybe someone will disagree or perhaps some gamers will
comment on
>> your post instead.
>
> It's really not a gamer issue. It is an enhancement in to the capabilities
> of live images, in that people will have the option to save additional
> space if they want. Probably lzma will be best to enable by default, but
> that will require most testing to see.
I think you're wasting your time trying this because it will be a
while before SquashFS w/ lzma is introduced
upstream for general use, and possibly longer before Fedora enables it
or puts it into stock.
Have fun.
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.
1:26 a.m.
New subject: livecd-creator proposal for compression option
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.
At least one of the livecd images was pretty tight. 50 MB of
compressed
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.
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.
Did you mean Games-something-else cause it isn't a LiveCD with games at 4GB
uncompressed.
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
I haven't played nethack, bzflag and foobillards in quite a while and
the gang load of USB drives
are the perfect tool for using with some games.
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.
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.
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.
1:55 a.m.
New subject: livecd-creator proposal for compression option
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.
2:28 a.m.
New subject: livecd-creator proposal for compression option
> 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.
Yes 924K which is the size of syslinux package, is less than a single
MB, which you stated on my thread
would be too much in your opinion to put on the base DVD ISO for
Fedora, but here where it is something that matters
to you, it is an insignificant amount of space. Very interesting.
Please explain your logic on the issue regarding mksquashfs w/ lzma
being a significant savings..
your opinion of insignificant being 1MB or 10MB, and the fact that you
said in the already 3.2GB large DVD ISO
that adding syslinux which is in the range of insignificant size in
your opinion would take up too much space
where 3.2GB is 800 MB less than as large as it will get within
specification, which is twice as large as the
_really significant amount_ of space you will save using mksquashfs w/
lzma at 400MB.
I really want to read your response on this one.
> > The games spin is just under 4 GB. A 10% savings there is
approximately
> > 400 MB.
You must really really like games, because 4GB of compressed games
uncompressed to about 7GB or more.
8 GB probably which would have me playing games so long I wouldn't
even have time to play
the extra games which you include in 400MB with your squashfs w/ lzma,
another useless feature
games no one would have time to play, excellent.
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.)
I am not focused on development of livecd-creator nor any part of
livecd-tools which taregt Windows
users, livecd-creator does not run on Windows, or at least I don't
think it does.
In any event, I am not concerned with this reasoning.
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.
Sounds like a patch set that will exist on your machine, as I stated a
simple corner case.
Submitting these patches to the list or committing them will do you no
good if you expect feedback.
You would be the only person with that patch set and specific
configuration in a whole fiasco of pretzel
code so you can put 400MB of games on a games spin. Seems unreasonably useless.
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.
What gives you the idea that your testing locally at your location
will produce a significant difference
than the performance on a final ISO, are you using a Pentium 486 with
a recompiled Fedora kernel to support
that chip? If not I see no reason why you would expect or even want to
test this aspect of the
mksquashfs w/ lzma.
These games spins don't need to run on a Cisco router, and a Intel i7
8 core machine.
> 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.
Again, you are purposely ignoring the comment, I cannot use just a DVD
ISO of Fedora 13
to do simple _testing, even if I wanted to because I do not enjoy
needing to have to download
ridiculous amounts of data over the network when simply putting the
syslinux package on teh base DVD ISO
for Fedora alleviates this problem.
LiveDVD images DO NOT WORK, using livecd-creator and a DVD ISO as a
configured repository
due to the requirement on syslinux package.
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.
Now
you're being obtuse, and that is all.
To test the mksquashfs w/ lzma I don't need to create DVD sized images.
Once real technical and important bugs are fixed is when I would move
on to creating large DVD
images which are spins with livecd-creator. To test a kernel and
squashfs-tools I don't need to install more than maybe 200 packages
which do not come close to nearly even not fitting on a CD, let alone
a DVD.
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.
You have no real reason to care what I am doing about the syslinux
situation, you have already
stated it isn't important to you and I sincerely believe you.
You state that it would provide no significant advantage since the DVD
ISO installer image
is already up to it's gills at 3.2GB and adding a 1MB package to
alleviate all the issues I present regarding this,
is not worth the space which needs to be conserved in your opinion,
which will make the DVD too large by specifications not even set in
stone, nor created by you.
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.
I still think you're wasting your time. Nobody cares about mksquashfs
w/ lzma unless
it provides some significant advantage, and 400MB on a games spin is
not a high priority to anyone except
yourself.
Perhaps this is just some idea you had in mind to work on, but good luck.
3:35 a.m.
New subject: livecd-creator proposal for compression option
This is all getting rather acrimonious and unbecoming.
I am firmly of the opinion that 10% is a very significant saving. I
often put custom live cd images together, and I have had many a time
where I've come up against the limits of the device (CD, DVD or USB
stick). Being able to get 10% more content would have made a big
difference. The circumstances have varied considerably, but it's never
been games-related--it's a much more general issue.
The two counter-arguments seem to be:
(1) that syslinux was rejected, which is small;
(2) that it might introduce unnecessary bugs.
I haven't followed the thread of (1), but it's a separate issue as to
whether syslinux is worth the extra space, even if it's small. In any
case, custom builds are always free to include or not include syslinux.
If you don't like what's on the base DVD, build your own--that's the
whole point of this list.
I don't accept (2). Obviously any change needs thorough testing, but
there are procedures for that, that's what rawhide is for, and we even
have a list (this one) where people can get additional help. Like
anything else, it won't see the light of day (stable repos) if it
doesn't work properly.
James
On Fri, 2010-06-11 at 08:28 +0100, Jasper Hartline wrote:
>> 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.
Yes 924K which is the size of syslinux package, is less than a single
MB, which you stated on my thread
would be too much in your opinion to put on the base DVD ISO for
Fedora, but here where it is something that matters
to you, it is an insignificant amount of space. Very interesting.
Please explain your logic on the issue regarding mksquashfs w/ lzma
being a significant savings..
your opinion of insignificant being 1MB or 10MB, and the fact that you
said in the already 3.2GB large DVD ISO
that adding syslinux which is in the range of insignificant size in
your opinion would take up too much space
where 3.2GB is 800 MB less than as large as it will get within
specification, which is twice as large as the
_really significant amount_ of space you will save using mksquashfs w/
lzma at 400MB.
I really want to read your response on this one.
>> > The games spin is just under 4 GB. A 10% savings there is approximately
>> > 400 MB.
You must really really like games, because 4GB of compressed games
uncompressed to about 7GB or more.
8 GB probably which would have me playing games so long I wouldn't
even have time to play
the extra games which you include in 400MB with your squashfs w/ lzma,
another useless feature
games no one would have time to play, excellent.
> 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.)
I am not focused on development of livecd-creator nor any part of
livecd-tools which taregt Windows
users, livecd-creator does not run on Windows, or at least I don't
think it does.
In any event, I am not concerned with this reasoning.
> 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.
Sounds like a patch set that will exist on your machine, as I stated a
simple corner case.
Submitting these patches to the list or committing them will do you no
good if you expect feedback.
You would be the only person with that patch set and specific
configuration in a whole fiasco of pretzel
code so you can put 400MB of games on a games spin. Seems unreasonably useless.
> 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.
What gives you the idea that your testing locally at your location
will produce a significant difference
than the performance on a final ISO, are you using a Pentium 486 with
a recompiled Fedora kernel to support
that chip? If not I see no reason why you would expect or even want to
test this aspect of the
mksquashfs w/ lzma.
These games spins don't need to run on a Cisco router, and a Intel i7
8 core machine.
>> 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.
Again, you are purposely ignoring the comment, I cannot use just a DVD
ISO of Fedora 13
to do simple _testing, even if I wanted to because I do not enjoy
needing to have to download
ridiculous amounts of data over the network when simply putting the
syslinux package on teh base DVD ISO
for Fedora alleviates this problem.
LiveDVD images DO NOT WORK, using livecd-creator and a DVD ISO as a
configured repository
due to the requirement on syslinux package.
>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.
Now you're being obtuse, and that is all.
To test the mksquashfs w/ lzma I don't need to create DVD sized images.
Once real technical and important bugs are fixed is when I would move
on to creating large DVD
images which are spins with livecd-creator. To test a kernel and
squashfs-tools I don't need to install more than maybe 200 packages
which do not come close to nearly even not fitting on a CD, let alone
a DVD.
> 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.
You have no real reason to care what I am doing about the syslinux
situation, you have already
stated it isn't important to you and I sincerely believe you.
You state that it would provide no significant advantage since the DVD
ISO installer image
is already up to it's gills at 3.2GB and adding a 1MB package to
alleviate all the issues I present regarding this,
is not worth the space which needs to be conserved in your opinion,
which will make the DVD too large by specifications not even set in
stone, nor created by you.
> 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.
I still think you're wasting your time. Nobody cares about mksquashfs
w/ lzma unless
it provides some significant advantage, and 400MB on a games spin is
not a high priority to anyone except
yourself.
Perhaps this is just some idea you had in mind to work on, but good luck.
--
livecd mailing list
livecd(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/livecd
5:34 a.m.
New subject: livecd-creator proposal for compression option
On Fri, Jun 11, 2010 at 1:35 AM, James Heather <j.heather(a)surrey.ac.uk> wrote:
The two counter-arguments seem to be:
(1) that syslinux was rejected, which is small;
(2) that it might introduce unnecessary bugs.
I haven't followed the thread of (1), but it's a separate issue as to
whether syslinux is worth the extra space, even if it's small. In any case,
custom builds are always free to include or not include syslinux. If you
don't like what's on the base DVD, build your own--that's the whole point of
this list.
Yes, thank you for showing how exactly not concerned you are about the
requirement on network
and not being able to use the DVD ISO for Fedora livecd-tools testing is to you.
I am glad you and Bruno both see the syslinux issue to be an issue
which I can rectify myself if I woanted.
I know I can, the fact it it would benefit many other people.
You guys need to get over yourselves.
I don't accept (2). Obviously any change needs thorough testing,
but there
are procedures for that, that's what rawhide is for, and we even have a list
(this one) where people can get additional help. Like anything else, it
won't see the light of day (stable repos) if it doesn't work properly.
livecd-tools doesn't work properly already, and it is in stable repositories.
Try again.
5:52 a.m.
New subject: livecd-creator proposal for compression option
Also, for your information, nothing about syslinux was rejected.
It is simply not part of the base DVD which livecd-creator requires to
be in the target package payload to build
a live image. Since this is the case, one cannot even do repetitive
testing via scripting methods
without using --cache or having a network configured.
Bruno mentioned it is not important to him, and likewise, since we are
talking about space
I figured I would mention the opinion he gave on syslinux.
Try researching before you assume you know what anyone is talking about.
This is my original message to the list:
http://lists.fedoraproject.org/pipermail/livecd/2010-May/005828.html
Since Bruno feels it is only an issue which I face and you both seem
to think I cannot do for myself
what you keep suggesting, you are simply enveloped in your own ideas
of what you think livecd-creator should be, or
what this list is for, or even why I'm posting the message.
Read this again: _Anyone_ who builds a LiveCD or LiveDVD with livecd-creator
will be required to have a network repository or a local mirror in
place to do even the simplest of
repetitive testing. Read this again: Anyone_. That means you too, and
Bruno, even if that makes 2
people of the several billion on the planet who don't give a flying
chicken limb about it.
So guess what? I am free to post my opinions on why adding squash with
lzma is a bad idea, and yes I am glad you like to generalize it to
"omgz instability" which also shows me how much you fail to read or
understand simple things like more fundamental problems than 10%
savings on a media. You said it yourself.
You would like it if you could have gained 10%, guess what, who cares!!
I got DVDRW discs out the ying yang, and my network bandwidth at home
is plenty!!
Look further ahead next time when making comments on my posts.
The two counter-arguments seem to be:
(1) that syslinux was rejected, which is small;
9:49 a.m.
New subject: livecd-creator proposal for compression option
On Fri, Jun 11, 2010 at 00:28:11 -0700,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
Yes 924K which is the size of syslinux package, is less than a single
MB, which you stated on my thread
would be too much in your opinion to put on the base DVD ISO for
Fedora, but here where it is something that matters
to you, it is an insignificant amount of space. Very interesting.
I don't see how it belongs in the live base ks file. It is not required for
using an image. If you want it, on say the desktop image, then you need to
convince the desktop team that it helps with rebuilding images enough that
its worth including. If they go back to targetting 1 GB USB devices, they
might be more inclined to include it despite what appears to be a pretty
narrow use case.
As far as the space being insignificant to the games spin, what that means
to me, is that if it gets included in the desktop spin, I am very unlikely
to bother putting in a rule to remove it to save about 1 MB. However, I
am not going to just throw it on the games spin, because it isn't a game
nor supports playing games.
your opinion of insignificant being 1MB or 10MB, and the fact that
you
said in the already 3.2GB large DVD ISO
If 3.2 GB is supposed to be the current size of the games spin, that is
incorrect. It is currently over 4.1 GB.
2:16 p.m.
New subject: livecd-creator proposal for compression option
On Fri, Jun 11, 2010 at 7:49 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Fri, Jun 11, 2010 at 00:28:11 -0700,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
>
> Yes 924K which is the size of syslinux package, is less than a single
> MB, which you stated on my thread
> would be too much in your opinion to put on the base DVD ISO for
> Fedora, but here where it is something that matters
> to you, it is an insignificant amount of space. Very interesting.
I don't see how it belongs in the live base ks file. It is not required for
using an image.
livecd-creator expects syslinux to be available in the package repository.
Apparently you have misunderstood in some way what that thread was
about, but decided to comment
on it as if you knew what I was even talking about. If you try to run
livecd-creator
without syslinux package available, it will fail. It is an absolute requirement.
It also is very required, syslinux contains the files which make the
CD boot, known as ISOLINUX.
If you want it, on say the desktop image, then you need to
convince the desktop team that it helps with rebuilding images enough that
its worth including.
I can see clearly now this is some sort of joke to you, or you seriously believe
when I say "DVD ISO" this reads to you "LIVEDVD ISO" They are two
different things.
Don't comment on my posts when you don't have a full understanding of
the issue at hand.
As far as the space being insignificant to the games spin, what that
means
to me, is that if it gets included in the desktop spin, I am very unlikely
to bother putting in a rule to remove it to save about 1 MB. However, I
am not going to just throw it on the games spin, because it isn't a game
nor supports playing games.
You should drink less alcoholic beverages when reading this mailing list.
> your opinion of insignificant being 1MB or 10MB, and the fact
that you
> said in the already 3.2GB large DVD ISO
If 3.2 GB is supposed to be the current size of the games spin, that is
incorrect. It is currently over 4.1 GB.
3.2 GB is the SIZE OF THE FEDORA DVD DISC IMAGE ISO9660 INSTALLER IMAGE.
QUIT COMMENTING ON MY THREADS WHEN YOU ARE CLEARLY CONFUSED.
2:27 p.m.
New subject: livecd-creator proposal for compression option
In any event, besides your common ability to misunderstand simple things
I will leave you with my opinion, your patches won't be useful to the list
nor to the head repository until everything is in place for using
mksquashfs w/ lzma
and the kernel has support for it. Use your time wiser and fix some
real bugs, not
introduce patches on top of an already broken system with 56 or so more
bugs where some of them deal with more fundamental functionality
than just some size increase, sure you can use it for the official
media, it will
be useless however in livecd-tools until it is supported in teh
underlying system.
If you are again confused about what I am saying.. the code on your
machine with your patches
could only be used by you, you would be the single sole-tester for your own
code patches since you would also have some patches kernel and patched
squashfs-tools.
Nobody else would, the patches are useless for livecd-creator or livecd-tools.
Simple special case of yoru own, why not patch your own stuff and make
your own spins to
save 10% on your own games spins? Why introduce patches to a system which could
use real manpower patching and fixing things the tools do already
which may have bugs?
Ah yes because you don't understand simple things like this, I forgot
already pardon me.
Since you would be the only one able to test your patches before
committing them to livecd-tools
or sending them to the list to be committed, you are wasting your time.
mksquashfs w/ lzma isn't ready in the distribution, it is not ready in
the kernel which means it is not ready
for the user level software either.
That is my opinion.
On Fri, Jun 11, 2010 at 7:49 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Fri, Jun 11, 2010 at 00:28:11 -0700,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
5075
days inactive
5075
days old
livecd@lists.fedoraproject.org
10 comments
3 participants
participants (3)
-
Bruno Wolff III -
James Heather -
Jasper Hartline