Linux: concerns over systemd adoption and Debian's decision to switch
Jeffrey Ollie
jeff at ocjtech.us
Wed Oct 22 22:10:36 UTC 2014
On Wed, Oct 22, 2014 at 3:49 PM, Miles Fidelman
<mfidelman at meetinghouse.net> wrote:
>
> 1. Experimentation and learning curve take time. That's a real cost that's
> being imposed.
What makes systemd different from any other technology in that respect?
> It's not clear that the benefits outweigh the costs of the status quo.
Ultimately this is a very personal decision, but given the adoption
rate of systemd by distributions I don't think that it's going to be
that long before people (at least if you want to be employed managing
Linux systems) don't have a choice but to become at least passably
familiar with systemd. Even if Debian steps back from systemd,
Canonical and Red Hat have committed to systemd.
> 2. Assumes good documentation. Not a given with systemd, as it stands now.
Why does everyone assume that systemd doesn't have good documentation?
I personally have found the documentation to be excellent.
> 3. Assumes that problems are easy to track down. Harder to do with murky
> and monolithic code.
Statements that are equally valid for sysvinit.
> (I still shudder the first time udev did something
> completely counter-intuitive at 0-dark-30, and that's from the same cast of
> characters.
Udev predates systemd, by a long long time. If you have problems with
udev don't blame systemd.
> 4. More fundamentally, 0-dark-30 events are almost always unexpected (other
> than in the sense of Murphy's Law), and tricky to resolve - one has
> hopefully prepared for the expected. Hence, it's not completely clear that
> one CAN familiarize oneself in a meaningful way - particularly when talking
> about something as monolithic as systemd. That's one of the major reasons
> for keeping things modular, and keeping modules simple.
This really has nothing to do with systemd. I believe that systemd
has made things better in this respect, but you're welcome to believe
that the pile of shell scripts in /etc/init.d is better. <sarcasm>I
mean really, what could go wrong when we configure boot-up with a
Turing complete language?</sarcasm> Really... I know of several
instances a poorly-written init script caused boot-up to fail because
they had infinite loops in them.
--
Jeff Ollie
More information about the NANOG
mailing list