Fedora too cutting edge?

Fernando Pablo Lopez-Lezcano nando at ccrma.Stanford.EDU
Thu Jan 10 01:38:16 UTC 2008


On Wed, 9 Jan 2008, Hans de Goede wrote:
> Hi All,
>
> One of the few reasons why Fedora is my distro of choice is because its 
> usually cutting edge, and I like to be where the development is happening.
>
> However today I've had an encounter with Fedora which make me wonder if 
> sometimes we aren't a little too cutting edge. I tried to get an industrial 
> firewire camera to work with the stock Fedora kernel using the juju stack. 
> Long story short, it didn't work.
>
> Which after reading: http://wiki.linux1394.org/JujuMigration Isn't really 
> surprising, quoting that page: "Almost no support for IIDC cameras: Not 
> compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 
> which works with some luck on only a few OHCI 1.1 controllers. Improvements 
> are to be expected in Linux 2.6.25-rc1."
>
> Notice how a preliminary fix is expected for 2.6.25, which probably means 
> that this will still be broken in Fedora 9, notice that the breakage was 
> introduced in Fedora 7, so thats 18 months worth of broken firewire camera 
> support (iow most digital video cameras).

_and_ firewire audio interfaces as well.

Which forced me and others to return to the original stack in my realtime 
tuned kernels for Planet CCRMA. And unpatch the corresponding libraries. 
And keep track of the whole mess. A royal pain you know where. Planet 
CCRMA is about audio. Non working interfaces that were working before is 
not good.

If you ask me, 18 months is way too long. It is/was a failed experiment.

> Add to that that the above 
> referenced wiki page also says: "Regarding Linux 2.6.22 and 2.6.23, the best 
> advice to Linux distributors (kernel packagers) ... is: Build only the old 
> IEEE 1394 drivers."
>
> Does this mean that Fedora should not have shipped the new stack? No it 
> doesn't!

Ahem, sorry but no. It should not have in the condition it was.

> Getting code out there early into many hands for testing is a good 
> thing.

The balance between cutting edge and usability is subjective.

My opinion is that the new stack was not and still is not ready for 
inclusion in a mainstream distro. It just breaks too many things that 
people actually need to do work on the computer running that kernel.

> What IMHO we should have done is build both the new and the oldstack, which 
> is possible on the kernel side, and modify our patches to userspace to 
> support the juju stack, so that the userspace libs can work with either one. 
> On top of this we should then have written a small gui utility for easy 
> switching.

Yup. Or wait till the stack actually works. But then a big chorus will 
probably say if we don't ship it it will not get fixed or whatever. But it 
has been shipped for a long time and not fixed so I _don't_ buy that 
argument. Most probably it just makes real users migrate somewhere else. 
Frankly that kind of stuff makes _me_ wonder about Planet CCRMA and where 
it should go. The only thing that stops me from moving somewhere else is 
the realization that migration would be in the short term a lot lot more 
work than working around the issue. Maybe it would be smarter in the long 
term, who knows. Sigh.

> ---
>
> Another example of Fedora being to cutting edge is pulseaudio, for prove 
> click this URL:
> https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&component=pulseaudio&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=FAILS_QA&bug_status=POST&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=
>
> Again I think its good to be shipping this, and even that its good having it 
> on by default, but we should also provide a small gui utility for easily 
> turning ir off.
>
> ---
>
> Considering the current state of affairs with regards to both features, I 
> would even like to advocate to make them both optional for Fedora 9.

Agreed... At least firewire has been broken for too long (IMHO)

-- Fernando




More information about the fedora-devel-list mailing list