[chiglug] systemd

[Steve Litt]

On Mon, 9 Nov 2015 09:01:01 -0600
sten <me at sud0.com> wrote:

> Hey,
> 
> So I'm trying to put together a presentation about systemd for people
> who have decided they have some sort of problem with systemd. I'd
> love for it to be conversational styled - me and someone (or
> someones) who wants to talk in front of people in favor of sysvinit
> or a different alternative.
> 
> I talked to a couple folks 2 meetings ago, but I may have been overly
> confrontational about it, and I really want to hear what objections
> still remain.
> 
> Drop me a note on- or off-list, let's see if we can come up with
> something together.
> 
> -sten

First, you need to reach a decision: Do you really want to discuss all
the facts, or do you want talking-point propaganda to promote adoption??

If the latter, you have hundreds of excellent examples all over the
web, including Pid Eins itself. So I'll address only the former.

First, don't disrespect your audience's intelligence, like so many
systemd promoters tend to do. The minute you call systemd "better than
init scripts" or "better than sysvinit or Upstart", you've already lost
your intelligent audience, because they know about excellent init
systems Epoch, Runit, s6, s6-rc, perp, OpenRC, nosh, busybox init, and
even Suckless Init plus daemontools-encore plus an ordering system (I
made an ordering system called "LittKit". Be able to intelligently
discuss all of those alternatives: Run as many as you can: Understand
their architecture. I have several examples on Troubleshooters.Com to
make it easier to do so.

Again about respecting your audience's intelligence, don't use boot
time/efficiency as an argument for typical use cases. Nobody reboots
every hour, and we all know that. I seriously doubt that systemd has
any noticeable performance advantage once boot is over, and if I'm
wrong, you need to prove it quantifiably in such a way that we
understand the percentage improvement. Most of your audience knows
about things like bottleneck analysis, the point of diminishing
returns, and profiling.

To preach to the choir and organize your base, there's nothing better
than characterizing systemd refusers as "neckbeards", "afraid of
change", "too lazy to learn the new way", "demotivating", "spammers",
or "conspiracy theorists", just to name a few of the epithets usually
thrown. This is great to electrify your base, but it causes systemd
refusers to dig in harder and prove your wrong.

Speaking about proving you wrong, you'd better get some evidence that
systemd initted systems are universally, in every use case, better than
alternatives such as Gentoo, Funtoo, Void Linux, Devuan, *BSD, just to
name a few. Or you'll be proven wrong by the alternatives.

Be sure that when you present this, you understand what a traditional
init system is (trivial startup code that forks a process supervisor
and then hangs around handling zombies and signals to PID1, and one way
or another performs a clean shutdown). Understand how dramatically this
differs from what systemd is. Understand that most systemd refusers
have nothing against the init system/process supervisor part of systemd:
They object to the thick and almost impenetrable layer of other stuff,
equipped with test and adjustment console called systemctl, and they
object to the fact that console might as well be bolted on with
no-unscrew screws with big labels saying "no serviceable parts inside."
Whether or not that's your view of systemd, it's the view of most of
the people you mentioned you're trying to get through to.

Don't imply any "agenda" to the systemd refusers. To do so would open
the door for them to imply an agenda to Red Hat and its functionaries
and unpaid salesmen, and the guys you're trying to get through to are
pretty efficient at making that point.

Don't try to shout down the systemd refusers, or allow your audience to
shouting them down. The systemd advocates have used the downshouting
technique for four years, and most of what they achieved is the
creation of Devuan, Void Linux dropping systemd in favor of Runit,
loads of people publicizing how to replace it with other init systems,
and at least for Debian, loss of a lot of their best talent. You might
want to briefly familiarize yourself with the 2014 Debian Civil War,
including the process by which they decided to switch to systemd.

Be aware of how cruel "if you don't like it, roll your own" is under
the circumstances of systemd having its tentacles in more and more
programs, making for less and less choice of applications as a whole.
And know nothing pisses off systemd refusers more than implications that
if they don't like it, they should step out of the way and code their
own. If for no other reason than that's exactly what they do, and they
publicize it far and wide.

If you really want to get through to the systemd refusers, start by
going where no other systemd advocate has gone before: Start by saying
that different use cases require different init systems: Systemd isn't
for every situation just like Runit isn't for every situation. Who in
their right mind wouldn't use systemd for a situation where a 2 second
boot is necessary (99.999% uptime and devices needing to start up in
less than 7 seconds come to mind). We've all used systemd: We all know
their claims of a fast boot aren't bullshit. Just make sure you don't
promote fast boot for use cases where boot takes place every four
months, and there's plenty of time for a cup of coffee.

You can mention that, *for people who don't know the Unix Way*,
systemctl is probably easier to learn than the collection of commands I
use. So if you need lots of employees who are less than well trained in
Unix, systemd might be an advantage.

And mention that for DIY or a personal computer or server, systemd is a
suboptimal choice for a person who knows Linux as it existed in 2013.
You should probably even mention the distros that are sans-systemd. Your
recognition of the fact that the best init system for the job depends
on the use case will gain you more credibility, with those not using
systemd, than all the technical knowledge in the world.

HTH,

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques