Systemd and Fedora 14
Systemd and Fedora 14
Posted Aug 26, 2010 15:13 UTC (Thu) by vonbrand (subscriber, #4458)In reply to: Systemd and Fedora 14 by marcH
Parent article: Systemd and Fedora 14
If it is shipped experimental and broken in N, it won't be the default in N + 1. It might even not be in N + 1 at all. End of story.
BTW, there are experimental packages of systemd at least for OpenSUSE out, and some other distributions are considering it. To test it, it has to go out to users (sure, at first just die-hard masochists, but soon after you need to reach out to the others). Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time. And that is bad for developer morale (and focus), and probably damages the whole effort.
Posted Aug 26, 2010 20:04 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
Sorry but I totally miss the logic here.
And the solution to such a sample (and irrelevant?) situation would be to fast-track this supposedly broken piece of software? In other words, to burn the bridges?
> And that is bad for developer morale (and focus), and probably damages the whole effort.
Yes this is all about the balance between the vast majority of Fedora users, happy with a system that already works fine thank you very much, versus a few admittedly brilliant developers overexcited about a new fancy project.
Posted Aug 26, 2010 21:03 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
This is not "already works fine, thank you" but "works so-so with massive effort and tweaking, and won't survive the next round of hardware/software updates". Fedora isn't running SysVinit anymore, and upstart is clearly lacking (it is being used only as a SysVinit replacement). A rethink of the whole mess is mandatory (not least because you can't separate system vs user setup anymore for increasingly broader end user control over the machine). This is a concrete proposal to do so, and it mostly works today (with surprisinly little futzing around in daemons), and which has been greeted with enthusiasm by other distros (best example is that it is being considered by them, and experimental packages exist). Will it hurt? Yes. Will it be worth it? I believe so.
Posted Aug 28, 2010 0:12 UTC (Sat)
by Blaisorblade (guest, #25465)
[Link] (1 responses)
Hey, it's cool, but until the bug stream doesn't slow down, there's no chance that you can include it in a distribution. Not even in one as crappy as Fedora. We've suffered this style ever since RH 9's (IIRC) backport of NPTL.
> Dragging this out "so it gets more testing before making it for real" just won't get more testing overall, at most roughly the same amount but more drawn out in time.
Yes, at some point there won't be new bugs reported. Then it means you can end the beta-test phase, set up more stress-testing, get more packages to work with it, ship it, and fix the tons of bugs reports.
> And that is bad for developer morale (and focus), and probably damages the whole effort.
Hey, that's crap. If developers can't wait six months to replace the core component of a system, they should be fired. Now. Because they wouldn't be able to deal with much harder problems. I guess it does not matter, because it's just your idea.
Finally, reading one of the original Nottingham's comments linked from the article [2] is enlightening. He's teaching release management to Poettering. Which means that I don't trust him to care for a distribution. Sure, he's a great and brilliant developer, able to think different, but those guys are not good for ensuring stability.
[1] http://lwn.net/Articles/401901/
Posted Sep 2, 2010 8:29 UTC (Thu)
by renox (guest, #23785)
[Link]
Depends on the distribution!
"Leading the advancement of [cut] software" are nice "marketing" word for "bleeding edge", what is right for a distribution aimed at "non-technical users" or enterprise isn't necessarily right for a "bleeding edge" distribution..
Note that I'm not saying this as a criticism against Fedora, we need "bleeding edge" distributions to make rapid progress, and I applaud them to take (calculated) risks.
Systemd and Fedora 14
Systemd and Fedora 14
Systemd and Fedora 14
That argument is already barely sustainable for upstream kernels, and it's nonsense for a distribution.
Of course, I mean that first systemd should have a alpha-beta-stable set of releases, and then a distribution should test integration (over more than 6 months). Which means that Lennart's thinking in this mail [1] is broken.
I mean, yes, it's optional in the current Fedora, but it's not yet ready. Finish it, declare it bug-free, ship it as optional, and then watch testers report tons of bugs - because those testers are simply more masochistic machos with crazy configurations that you have to support.
I'm more concerned about concerns expressed in the article, like "Poettering has something of a reputation for waving away bugs as features" or the handling of noauto - I see the technical point in changing its handling, but I very much see that 99% of the users using noauto use it for good reasons which can go beyond boot-up time, and do so consciously, so changing the interpretation of noauto really questions the sanity of the developer. (Readers of The Art of Unix Programming from Raymond will also notice that choosing for users is very much against the Unix spirit in general, for the reasons I just discussed).
[2] http://lwn.net/Articles/401921/
Systemd and Fedora 14
> That argument is already barely sustainable for upstream kernels, and it's nonsense for a distribution.
Fedora's mission is this: "The Fedora Project is out front for you, leading the advancement of free, open software and content."
Now Ubuntu's early use of PulseAudio, the KDE4.0 mess, etc, on the other hand *sigh*..