jcm's blog

Recent discussion on Fedora devel about systemd got my pulse racing, so I thought I’d share a few thoughts here. This is all my own personal opinion and is not an attack on Lennart. He’s a great guy who takes on tough problems and is at most guilty of being overly optimistic that problems won’t arise in the adoption of new technology.

Firstly, let me note that the systemd idea is a good one, in the longer term. Other Operating Systems have tried this approach (perhaps the closest obvious example is OSX) to starting services when an attempt is made to talk to them, and there is a lot of merit to doing this as an automatic dependency-driven way of avoiding cruft, speeding up boot times, etc. Now I should note that none of you really actually care about boot times (you just think you do) because you suspend/resume for daily use, and if you’re doing hard-core plumbing or kernel work then you don’t have a lot of other cruft installed in the first place. So let’s just throw that “but but but…boottimes!” out of the window and admit to ourselves that’s just for fun. Good. Now, the fundamental approach to systemd is still a good one or others wouldn’t have tried this kind of thing in the past.

Secondly, Linux is not OSX. Scott had a tough enough time with upstart already (and wouldn’t it be nice if we could all just get along…but that’s another topic), things take time to change. Attempting to adopt a new technology late in a release just because it’s shiny and useful to Desktop users is in my personal opinion, unwise. The existing boot process works well – albeit it is not perfection, but then there are many other more pressing issues – and can certainly see us through another release of Fedora while systemd stabilizes, commitments to interfaces are thrashed out, and we figure out how to agree on stuff like what “noauto” even means anyway. You’d think that was standardized, but perhaps not. And if it’s not, this just shows how this can of worms opens up a ton of other stuff to be poking at at the same time.

But maybe I’m just hating on this because of my PulseAudio experience? Not at all. It’s true that I find PA frustrating, and none of the “killer app” features over raw ALSA have yet sold me on it. Playing to my “Air Tunes” device (RAOP) is skippy, grabs the device and won’t let go until PA is killed, playing from virtual machines is buggy, getting sound to come out of the right speakers is a challenge at the best of times (and the GNOME mixer app progressively becomes something so dumbed down it’s no longer useful to me), and I haven’t yet had the courage to try using Bluetooth speaker support. But these aren’t personal failings of Lennart. He’s just a talented guy who likes to take on tough projects that are complex and have a lot of dependencies. And sometimes there are dependencies on kernel changes, or other stuff that is tough for one guy to get done. I’m not hating on systemd, I’m saying that very talented people are still faced with the reality of glitches, bugs, and user adoption.

It comes down to this: most users would prefer to have some reliable sound than the best bells and whistles, and most of those same users (and I mean other than the handful who discuss stuff regularly on the Fedora “devel” list) would similarly prefer no init glitches over a technically better one. Pulseaudio has matured a lot. It’s still not perfect, but I generally let it stay installed these days (whereas I used to remove it immediately), except when I’m trying to do audio recording. I would say that systemd will mature nicely over the next 6 months or so at the present rate, at which time it can be considered for inclusion in Fedora as the optional or default init. But to include it now (in F14) is really – in my opinion – an exercise in forcing users to do testing without giving them a choice to opt into it. Let the experts try it first.

Jon.

There’s been a lot of talk recently about Fedora’s policy (or lack thereof) for shipping updates to existing stable releases. Rather than keep repeating the same points on the mailing lists ad nauseam, let me give my own $0.02 here. Keep in mind that these are my own personal opinions, and nobody else’s.

First off, I know in using Fedora that I am not using an “Enterprise” distribution that is intended to remain rock solid and stable for a long time without substantive changes. I’m ok with having to upgrade every 6 or 12 months, and I’m willing to deal with fixing breakage when that happens (though obviously in a perfect world the upgrade would be entirely seemless). What I am not ok with is updates shipping that cause any breakage or behavioral changes to my perfectly working system when I have not asked to perform a major upgrade. I expect that, if I upgrade my laptop system ten minutes before a meeting, then it will still work exactly as it did before. I don’t want to have to delay doing any updates – as I do now – for fear of the result.

Since time doesn’t stand still following a release, and bugs and regressions are found – and security issues are raised – a flow of updates to a “stable” release is both necessary and healthy to any distribution. But updates should be just that: updates. And also “necessary”. To me, an “update” is not shipping a major version bump on an existing piece of software, or replacing an entire stack (complete with all manner of behavioral changes – no matter how “small”: it does matter if that menu item moves around mid-release) – after the release. That’s called a new release. Or rawhide. Or whatever. The point is that a release has to have some kind of meaning for it to even be worth having a release. Otherwise, you may as well just call it “Forever Rawhide”.

Now I’m not saying there can’t be flexibility. For example, I don’t personally care at all about KDE update frequency. I’m sure the people who work on it (many of whom I have met over the years) are very nice people, and I know they do good work. But I don’t use KDE (other than a few specific pieces of software, such as k3b), and I haven’t for years. So if KDE is updated ten times a day, I’m not going to even notice. I’d rather, for the sake of the users have a consistent policy, but perhaps that stack could be excluded since its maintainers are quite vocal about being able to make a lot of updates. I would rather an exemption were made for their specific stack rather than have the rest of the distribution need to following the same rolling update trend.

What I am going to notice, however, is if any of the critical path components that I rely upon is broken, has a behavioral change, or is needlessly updated way too often to make any real sense. Needless includes pulling in some minor upstream bits that aren’t materially warrented by actual or likely bug reports. Those things are best done in rawhide where they belong, and where those who are more than willing to test as they go will happily help shake out issues. I myself run rawhide also, but on dedicated real or virtual machines that are only for testing and not intended to be used or relied upon for daily work. Even in the case of rawhide, I think things should be at least reasonably tested on a standalone system (more than just compile tested) before pushing if they stand a chance of breaking something fundamental in the distribution.

Think about it this way. The Fedora development cycle is about 6 months. If you are a user and really, badly need some major new feature, you might have to wait an average of 3 months. Even if that’s hardware enablement that makes the distribution otherwise inaccesible to you, I would rather that you have to wait 3 months for the new version (during which time you are free to try the pre-releases, alphas, betas, etc.) than ship an intrusive update that may negatively affect other users who already have working systems that can already make full use of what they have available. It’s simply not worth inconveniencing existing users of a stable release for the possible benefit of those who are not already using it and can wait until the next time.

Anyway. I think Fedora needs an update policy, and it needs a strong one. If you know me, you know I am far from a conservative guy, but I do think that stable Fedora updates should have a fairly conservative update policy for at least all critical path components. Those should never be updated unless necessary to fix specific bugs, and only in a fashion not likely to cause regressions for other users not affected by those bugs, or who rely upon specific behavior not to change (i.e. not a whole major version bump). The components not in the critical path can have more wiggle room if necessary, but I would still like to see far fewer updates in the stable releases.

Jon.