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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
