Re: Linux: concerns over systemd adoption and Debian's decision to switch

[Jeffrey Ollie <jeff () ocjtech us>]

On Wed, Oct 22, 2014 at 3:49 PM, Miles Fidelman
<mfidelman () 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