SquashFS?

[Jeremy Katz]

On Fri, 2005-10-21 at 14:00 -0700, Toshio Kuratomi wrote:
> On Fri, 2005-10-21 at 16:13 -0400, Jeremy Katz wrote:
> > On Thu, 2005-10-20 at 18:35 -0700, Toshio Kuratomi wrote:
> > > On Thu, 2005-10-20 at 13:20 -0500, Rex Dieter wrote:
> > > > Darko Ilic wrote:
> > > > > I wanted to ask what are the opinions on the subject, and is there any chance 
> > > > > for SquashFS to make it's way into Fedora kernel by FC5? I`ve heard it was 
> > > > > submitted to LKML recently and there was some discussions surrounding that 
> > > > > and that it is a likely candidate for the upstream kernel.
> > > > 
> > > > If it makes it upstream, then most likely, yes.
> > > 
> > > I'd like to see a quality Fedora LiveCD.  At my day job we're evaluating
> > > livecds for kiosks, recovery, and lab installs.  What has struck me in
> > > recent days is that they're _all_ Debian based.  If we want this to
> > > change, we need to create liveCDs that 
> > 
> > I think a lot of people want to see a live CD and there's something of a
> > push to get all of the pieces in place for in the FC5 timeframe.
> > 
> > > squashfs and unionfs are both kernel modules that are pretty standard
> > > fare in the liveCD world but are not part of the mainline kernel.  We
> > > need to include them in Fedora in order to advance our reputation in the
> > > liveCD arena.
> > 
> > And the answer to this, at least traditionally, is that the answer is to
> > get the modules integrated upstream.
> > 
> > Personally, I don't even think this is the biggest area that needs work
> > for a real, compelling live CD.  Rather, various pieces of the stateless
> > infrastructure need to be finished and integrated into the core.
> 
> I won't dispute that stateless will definitely add value.  But stateless
> is, as you point out, a big area of work.  These filesystems which are
> already being integrated into other livecds are a low hanging fruit in
> comparison.

Without the work occurring, a live CD is _always_ going to be playing
catch-up with the rest of the system.  And there are a lot of things
which end up having to be hacked around or duplicated, cf the
mklivecd_initrd stuff.

> > > There are three alternatives here.  1) We don't care about LiveCDs.  If
> > > you want to make a serious LiveCD based on Fedora, you have to fork and
> > > maintain some packages outside of the Fedora arena.  
> > 
> > Come on, it's not that you _can't_ do a live cd without them.
> > 
> True :-)  But I'm talking about gaining live-cd market share.
> A LiveCD without squashfs and unionfs and other goodies might help to
> encourage Fedora installs, but to help make the Fedora LiveCD the liveCD
> of choice means we need technologies that are relevant to that area.

There are always going to be multiple live cds, just like there are
multiple distributions.  And I think we get much bigger wins from having
the technology done properly than with filesystems... at the end of the
day, the filesystem used is not what you decide on a technology on[1]

> > > 3) We integrate these modules in Extras.
> > 
> > We're working on module packaging for Extras.  This could potentially be
> > a way to get people who really want squashfs and unionfs but aren't
> > willing to try to push upstream...
> 
> It seems to me that pushing upstream has to be spearheaded by the kernel
> module developers, not the people who want to use the modules.  Most of
> the time packagers are technically-competent consumers -- I want to use
> this functionality and I can do so in such a way that others can have an
> easier time using it as well.  This means that we can try prodding
> upstream into doing our bidding but the means of effecting change are
> out of our hands.

Education can go a long way... also, letting an upstream know "we'd
really like to use this, but we can really only depend on things in the
upstream kernel" has positive effects a lot of the time.  Has anyone
even talked with the upstream developers of unionfs and squashfs about
moving to the upstream kernel?  They could even have a good reason :)

> My major point is that a LiveCD has needs that Fedora Core does not.
> Because of the route we're travelling with Kadischi we have to think of
> some way to satisfy those needs that fits comfortably with the rest of
> the Fedora development philosophy and infrastructure.

After some investigation, I really don't feel the needs are that
different.  

Jeremy