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

Wed Oct 22 18:22:12 UTC 2014

On Wed, Oct 22, 2014 at 12:35 PM, George Herbert
<george.herbert at gmail.com> wrote:
>
>
>
>
>> On Oct 22, 2014, at 9:30 AM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
>>
>> The people that like systemd (like myself) have wisely learned that
>> the people that hate systemd, hate it mostly because it's different
>> from what came before and don't want to change.  There's no way to
>> argue rationally with that.
>
> I think you are monumentally misreading the situation.
>
> A) Change is the constant in IT. Staying relevant and employable has put me through five or more generational shifts in enterprise OS, plus diversions to Mach, Plan 9, MacOS, etc.  Change is normal.

I agree with you about change, but there are a number of people that
vocally resist any kind of change, no matter what.  There's little
that can change their mind other than time.  It's a useful skill to be
able to recognize these people and not to let them get you down.

> B) Systemd and the Solaris SMF that it conceptually followed have a number of technical flaws, ranging from obscure interfaces (sometimes requiring source code to understand) to lack of human readable configs to (at least with SMF, and as far as I can tell systemd) a lack of ability to even print/dump out the current dependencies and ordering tree.

I have no experience with Solaris SMF so I can't comment on it
specifically, but in my opinion systemd:

1) has excellent documentation, especially when you compare it to
other open source documentation.
2) What's more readable than .ini files?  They even avoided the
temptation to use XML.  I can't tell you how much time I've wasted
reading shell script spaghetti trying to figure out exactly how a
service is started up.  Services implemented in Java and Ruby seem to
be especially bad at that.
3) systemctl list-dependencies, although since service start-up in
systemd is highly dynamic it's difficult to predict what order
services will start up.

> C) In both systemd and SMF a tremendous unpreparedness of training and documentation accompanied rollout.  These were not reasonably enterprise ready at launch, or now.

In 2010/2011 when systemd was first being integrated into Fedora (and
I believe SuSE) I would have agreed with you.  However this is four
years later and I couldn't disagree with you more.  More to the point,
Red Hat disagrees with you, given that they have put their money where
their mouth is and integrated systemd into RHEL7.

> D) The architectural case that the services adopted in systemd over time belong there or are safe there is not proven, and not that I see well argued or documented.  Conglomerated services are at least to be eyed skeptically.
>
> I did not closely follow systemd's development but it is evident from a distance that operator feedback in the community and to Sun regarding SMF flaws was somehow missed in systemd's development as they did the same wrong things.
>
> A change this big deserves architectural clarity and justification.

I don't follow systemd development closely either, but Lennart
Poettering, Kay Sievers, et. al. have made extraordinary attempts to
communicating about systemd.  They've appeared at numerous conferences
and given talks about systemd, written blog posts, documentation, etc.
I don't know what else they can do other than to be invited over to
everyone's home for tea and a systemd discussion.

> We get snide comments about change being good and core developers Linus  evidently feels are unsafe.

We also get snide comments about change being bad.  As for Linus,
other than the fact that he has an extraordinary amount of influence
over what goes into the kernel, I've learned to take his comments on
other matters with a very large grain of salt.  I have a lot of
respect for the guy, but his attitude and behavior towards other
people is appalling.

What's really surprising about some of Linus' comments WRT to systemd
is that one of systemd's main goals is to make it easier to use some
of the advanced functionality of the Linux kernel that were little
used or ignored before.

-- 
Jeff Ollie