systemd and changes

[Matthew Miller]

On Mon, Aug 23, 2010 at 08:22:16PM +0200, Lennart Poettering wrote:
> > This is the second such surprise that I've come across -- "shutdown -r +1"
> > of course being the other. And of course before that, the long thread about
> > the chkconfig and service commands. I was positively impressed by your
> > responsiveness and flexibility on the shutdown delay issue, but I have to
> > say that the pattern here is making me worried. I don't mean it as a flame
> > or attack on either you or the project, but I wonder if things are moving
> > too fast for systemd to be a good choice for Fedora 14.
> That's quite a jump you are making there. First you say you are happy
> with the speed I processed your last issue with (and let's also note
> that this new issue is already fixed, too) and then you say it was too
> slow on F14.

I don't think it's a jump. I'm glad you're responsive to these concerns.
However, I don't want a Fedora release to ship with many more such concerns
unresolved. The place to address these things is in a development tree.


> And anyway, *2* "incidents" don't really make up a pattern, do they?

I actually count four that I've noticed so far:

  - chkconfig and service not working as expected
  - shutdown delay option destructively ignored
  - filesystems marked 'noauto' getting mounted automatically
  - runlevel 3 reporting itself as runlevel 4

Now, you have been good about providing a solution for these. But those are
just the things *I've* noticed, and let me assure you that I am quite far
from the _most_ crotchety set-in-his-or-her ways old-school sysadmin. The
pattern I see is that each time, you respond initially with (paraphrased)
"It's not broken -- we've made it better!" before implementing the fix.

So, I'm honestly asking: what are the odds that these few things are the
only improvements that cause a disruptive change to user interaction? I
don't think it's unreasonable to wonder if there are other changes which fit
this category.

> If you'd put the bar for some other package as high as you are putting
> it for systemd, then well, maybe the Linux kernel isn't ready for F14
> yet either? ;-)

If we were running some other kernel, and the Linux kernel came along and
made a whole bunch of changes to user interaction, yes, I would indeed say
that it's not ready yet.


> A little bit more optimism, please!

I don't want to be so optimistic that we, with our eyes on a beautiful
perfect future ahead, stroll right into tarpit without looking.


> Well, of course, systemd is magic and bug-free. Because I am Gandhi 2.0
> I also have the powers to make everybody happy. Yippieh!

Right, not askin' for that. 

> Nah, seriously. Every software has bugs. And systemd isn't
> sysvinit. Because of that it doesn't always behave like sysvinit. But
> that's expected. I could name you a couple of other things where we
> depart from sysvinit. (for example, we ignore the Sxx/Kxx priorities of
> the /etc/rcX.d symlinks by default if the LSB header includes ordering
> information anyway). Many of these differences shouldn't matter really,
> and we can often tell people that they are misusing things if they are
> relying on the old behaviour (i.e. because they apparently didn't use
> chkconfig in the example mentioned).

In a lot of cases, that's probably okay -- but we need to make sure that all
of these things make the release notes. And as we've seen, in many cases
what other people think matters turns out to surprise you. (Users -- so
strange and difficult to predict... both sysadmin work and software
development would be so nicer without 'em....)

> So, there'll be more stuff coming up, I am sure. I'd bet on it. There
> will be bugs. I'll bet on that too. But that's fine. That's OK. That's
> expected. Software has bugs. And first releases of software definitely
> have bugs. That's why we have all this alpha/beta process for Fedora in
> place, so that we can find them early.

This is such a substantial change, and the system so young, that I'm really
afraid that one such cycle isn't going to be enough. I don't think it would
be a failure to say that we should leave the system as optional for F14 and
aim to make it default for F15.


> That all said if you have a look on the number and quality of open bugs
> of systemd for F14 then it appears to be a lot stabler and more polished
> than probably most of the stuff in the current base system. It's
> definitely not a good metric, but I do believe if that even if the
> number increases to a healthy level comparable with other core packages
> we'd still be fine.
> So, breath deeply, and let's all be jolly!

I'm concerned there aren't enough eyeballs yet -- and people don't
necessarily no where to look, because the changes can be in unexpected
areas. It took me a few minutes to figure out that systemd was mounting my
noauto filesystem, for example.



-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences