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. > > 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. > > 2) We get these > > integrated into Core despite the fact that they aren't upstream > > [Example: GFS] > > And you'll note that GFS is gone again in the development due to the > problems that were had... > Woo hoo! Err... I mean, all the better to encourage thinking on the out of mainline but we need to include it issues :-) > > 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. 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. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
