[HEADS-UP] systemd for F14 - the next steps

[Lennart Poettering]

On Wed, 21.07.10 13:29, Chris Adams (cmadams at hiwaay.net) wrote:

> Once upon a time, drago01 <drago01 at gmail.com> said:
> > And when I say/here admin I'd expect to be talking about a human (not
> > some kind of robot that has hardwired commands and can't adapt to
> > changes).
> 
> If you only have to manage one system, good for you.  I have to manage a
> bunch, and everything that is different _for_no_good_reason_ between
> them is a PITA.  Yes, management scripts can be adapted, but now they
> have to handle systems A-Z one way, systems AA-ZZ another (but
> apparently not for all services, try to guess which?).  That makes an
> admin unhappy and less likely to deploy any more of systems type AA-ZZ.

BTW, you are emphasizing that that there was no reason for the stfuf we
do. But you are wrong. There actually is. The reason why we came up with
systemd-install as a counterpart of chkconfig instead of patching
chkconfig is that it actually works very very differently from
it. i.e. beyond the fact that both create symlinks, one in
/etc/systemd/system, the other in /etc/rcN.d/ they have very little in
common. One cares about priorities, the other doesn't. One knows only 6
runelvels, the other knows arbitrary numbers of targets. One can hook
stuff into runlevels and runlevels only; the other can hook stuff into
any unit. One can actually make the changes effetive immediately, the
other doesn't do that; one can handle sockets and mounts and other kind
of units, the other cannot; and so on and so on.

Yes, they are counterparts in some way, but they nevertheless are very
differnt in what they do. Which is why we chose not to hack the old tool
to make the it half work on the new system, but came up with a new tool.

Of course, there's a solution between "transparently" and "different
tool", which is to warn the user loudly and make suggestions what to do
instead if he uses the old tool, and possibly even execute the
suggestion right away if the semantics for that one call are close
enough to what the user intended. And that's what I added to my todo
list and Jef thankfully offered to implement.

We are trying to find a way here between radical new designs, and
staunch interface conservatism. i.e. we innovate and carefully try to
select the stuff we want to keep around and leave out the stuff whose
end has come. That naturally means that we do things on middle grounds,
not on extremes. We won't do 100% compat with sysv, but we won't do 0%
either. And that being the way it is I can only ask people to be a bit
more conisderate in their positions. i.e. people whining on the mailing
list that they will leave Fedora just because chkconfig might be not as
100% supported as they wish it was don't really help and don't see the
big picture. Because the big picture will tell you that we keep
incomparably more stuff in then we remove. For example, we provide
compatibility with /dev/initctl, with sysv init scripts, with LSB init
script headers, with chkconfig init script headers, with the various
sysv client tools, with the kernel command line options, with the
signals we take, with /etc/fstab and more. 

So, please, when Jef finishes his work, or I find the time to, we will
provide chkconfig compat too (at least to a certain degree). However,
doing this is actually just the cherry on top of the topping of our
delicous cake. But even without the cherry it still would be very yummy
and still have topping.

Or in short: extremism sucks. Please acknoweledge that we try to find a
middle ground, and that we are open for suggestions. Because we are. I
already fixed a couple of issues that were discussed on this mailing
list and added a couple more to my todo list. I won't make everybody
happy, but you have a bigger chance to get your suggestion heard if you
don't take extremist positions, declare sysv the holy grail and say
you'll abandon Fedora if we depart from that. 

Yes, I guess being a developer who develops new stuff I like innovation
in interfaces more than administrators who then might end up using
this. But it doesn't really help claiming we had no idea what admins
want and consistently ignore their wishes. Because we actually do have a
pretty good idea. We don't fully share all opinions, but we are aware more
often than not.

Also, one last thing: there's so much in systemd that admins should
really love. It would be great to sometimes look on the bright side of
things. One small and random example, just to make a point: Look how
awesome the output of "systemctl status avahi-daemon.service" is:

<snip>
avahi-daemon.service - Avahi mDNS/DNS-SD Stack
	  Loaded: loaded (/lib/systemd/system/avahi-daemon.service)
	  Active: active (running)
	    Main: 6841 (avahi-daemon)
	  Status: "Server startup complete. Host name is lambda.local. Local service cookie is 813782141."
	  CGroup: name=systemd:/systemd-1/avahi-daemon.service
		  ├ 6841 avahi-daemon: running [lambda.local]
		  └ 6842 avahi-daemon: chroot helper
</snip>

It shows you all processes that belong to a service (in a tree
actually), something that was previously impossible to figure out. It
gives you a nice status string of the daemon. It tells you the
cgroup. It tells you that everything is OK. When it fails, it weill tell
you the exit code/status and stuff. It's just really really handy for
administrative work, and it
gives you a lot of information that was previously lost entirely:
processes could just vanish from sight and their exit codes were
completely lost. Now, tell me, as an admin, wouldn't you agree that it
is kinda amazing that for so long you managed to survive without all
that information? And that we now offer this to you is long long
overdue? 

Solaris SMF had something like this for a long time, and much like for
ZFS and dtrace those Solaris admins always made fun of us Linux folks
that we still lacked all these toys. And now finally we provide
something equally useful. So as an admin you should really love systemd,
-- not hate it just because it does a few things differently.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.