Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] systemd explanations

On Thu, 18 Feb 2016 21:10:20 -0500
IngeGNUe <ingegnue at> wrote:

> On 02/18/16 20:46, Derek Martin wrote:
> > On Thu, Feb 18, 2016 at 11:46:33AM -0500, Rich Pieri wrote:  
> >> Which is not to say that I would be uncritical of systemd, just
> >> that my criticisms would be more focused on the technical
> >> aspects.  
> > 
> > =8^)
> >   
> From this discussion primer, I'm actually really looking forward to
> hearing the back and forth about technical aspects of systemd in the
> next presentation. :)
> Steve Litt makes a great point: one doesn't have to like sysvinit or
> upstart to be skeptical of systemd.
> IngeGNUe

And more than that, there are several inits that I consider better than
sysvinit and systemd. And many agree with me.

So if somebody gives a presentation and says "systemd is so much better
than the old way", stop them right there, and as "What about runit?
What about s6? What about Epoch? What about busybox init?"

And when they say those "are not ready for prime time", pin them down
on the exact technical meaning of this.

If they claim the other inits don't understand sysvinit init scripts
(which are atrocities, to be sure), inform them that runit and s6 run
scripts average less than ten intuitive lines, and Epoch config
sections are less than ten key->value pairs.

When they tout the efficiency of systemd, find out if they mean during
boot, or during uptime operation. If uptime operation, make them give
you the technical details and don't fall for any hocus pocus. Remember,
no service manager of well crafted and configured daemons keeps upping
and downing them often, so where's the time to be saved. If they're
talking about runit and s6 having a little executable to admin every
daemon, admit that's true and then have them prove that the ram or
other resource usage of these extras are important. If they start
talking about the number of procs, then you know they're talking about
a huge server (like Apache or something), and ask them if that's an
issue on most computers.

To the extent that it turns out they mean efficiency during boot, ask
them to prove the advantage for those of us not using the computer for
a television or having offering a .999999 uptime guarantee, or for some
reason rebooting over five times a day.

Last but not least, ask them whether they think that the binding of
dbus to systemd and lots of stuff to dbus, the welding of udev to
systemd, and systemd's numerous and gratuitous interdependencies create
a chilling effect on individuals who want to replace part or all of
systemd. Ask them whether there are use cases that would call for other

When you're at a systemd presentation, you need to hold the presenter's
feet to the fire, because most systemd presenters give a dog and pony
show of features, every once in a while asking "isn't this better than
the old way?", as if the old way was the only way. Hold their feet to
the fire: Make them earn your respect.

Steve Litt 
February 2016 featured book: The Key to Everyday Excellence

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /