Hey TJ!

> Steve, I'd like to ask you a question from a technical standpoint. I am
> not being sarcastic or condescending in any way whatsoever. If you, in
> your experience, think that perhaps systemd is an attempt to clone a
> Windows desktop, the server side of Linux be damned?
>

There are quite a few things in the systemd ecosystem that are very
specifically targeted at servers and not so much as desktops. Some are
even useful to an extent, but badly implemented. Some others are so bad for
servers I am positively shocked that serious admins will consider deploying
them. Of course, with systemd, you cannot really take a pick-and-mix
approach, as most components are interdependent.

I have run a few servers with the whole systemd collective by way of trial,
and was depressingly unsurprised at the outcome: unstable, difficult to
manage, almost impossible to troubleshoot when things go wrong.

The nice bits of systemd are also available in different packages, and
following the tried and tested (but apparently out of fashion) tradition of
"do one thing, and do it well", these different packages usually tend to be
superior in implementation. Socket activation, file/inotify implementation,
unit files, introspection, process supervision - these are all cool and
useful features. If I need any of these on any of my servers, I can choose
from multiple alternatives that will do the job well.

The not so nice bits of systemd (too many to list) as well as specific
systemd idiosyncrasies positively preclude me (or any other sane operator)
from running this for any kind of serious production use. systemd has
positioned itself too centrally to the overall environment architecture to
be able to take an incremental approach to implementation and deployment,
and systemd has way too many untested (or proven to be disastrous)
edge-cases where it will go off and make your server go down in flames.

The most touted benefit of systemd - 1 second boot times - is pretty much
irrelevant for servers. Firstly, you don't really want to reboot production
servers. Secondly, if for whatever reason you do need to reboot a machine,
there is a very high likelyhood that you are waiting many minutes for the
hardware to boot - having to wait a few seconds extra for the OS really
doesn't matter much (Most of my servers are VM's and will run a full reboot
cycle in about 30 seconds - works for me...). Thirdly, the majority of
workloads are moving to multi-host hypervisor environments (VMWare,
Openstack/Xen etc.) and the correct way to deal with host/hardware reboots
would be to "drain" the host, so you live-migrate (vmotion, etc) your
workloads to other hosts, and then you can take the now idle machine
offline for whatever you need to do on it. Same goes for containers,
although the process is a bit different, the idea is the same.

It isn't a case of "Servers be damned" - they really do want the servers
within the systemd Borg Cube. It's more of a case where serious server
admins think "hell no, not on my systems"

Martijn