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