On 24/01/2021 02:52, Lamar Owen wrote:
> Straight SysV init does not meet the needs of many server setups,
> especially server setups that need to dynamically change the daemon
> mix that is currently running.  Virtualization hosts, software-defined
> networking setups, and what is typically called 'cloud' services are
> use cases for things systemd does well.  The antiquated concept of
> runlevels works fine for relatively static workloads; not so much for
> more dynamic workloads on the server side.

This is undoubtedly the case but of course it doesn't necessarily follow
that SystemD is the correct solution. And that's where the controversy
arises.

> Difficult?  That is the understatement of the decade.  I prefer to
> honestly evaluate new technologies with a bit more pragmatism; do I
> like having to learn a different way of doing things?  Not really; but
> after Debian adopted systemd I took more notice.

The thing is, one cannot wisely evaluate something on *purely* technical
grounds because its function in reality may not be entirely or purely
technical. Issues of politics and control of industry and/or mindshare
are relevant too.

And, even on purely technical grounds, one of the key criticism of
SystemD is *NOT* the need to learn something new; the criticism is about
how SystemD is structured and its ongoing bloat and growth. Learning new
stuff is part and parcel of working in any capacity with computers and I
have seen no one seriously complain about learning anything new in
relation to SystemD. It is what they have learned that has concerned
them and led them to be critical.

> but the potential vulnerability footprint is much smaller

To say the least: This is a view that is not necessarily globally
shared. ;-)

It's different, sure. But not necessarily smaller and not necessarily
more visible, more manageable, more identifiable, or more fixable.

> But even then virtually every systemd installation will happily run a
> SysVInit-style initscript (and will log to /var/messages in plain
> text), just like Upstart before did in EL 6 (well enough that people
> forget that EL 6 didn't run a straight SysV Init anymore).

As ever, the fact that SystemD can run SysV scripts is not the problem
and does not solve its problems as many people see it.

It is the structure and overall design of SystemD (and, in many people's
views, its political/social/industrial context) that are the problems
that many people see with SystemD.

Very few people mind a new init system. That's why people seem to have
forgotten about Upstart. What people clearly do mind is how a certain
init system is designed and implemented and how it seems to be growing
beyond being an init system.

In other words, SystemD specifically is the problem as many people see
it, *not* new init systems in general.

> SysV Init was a substantial upgrade from what came before (I remember
> those days, running Xenix V7 and System III), but in today's
> containerized, virtualized, dynamic server world it simply isn't
> sufficient for a large enough percentage of real-world server workloads.

Sure. I think it safe to say that the majority of those who are critical
of SystemD would not disagree with you on this.

BUT... the fact that SysVInit is seen as outdated is NOT a reason in and
of itself to support SystemD. There may have been and, in many people's
opinion, there were and are better init systems to replace SysVInit than
SystemD. "Better" being both a technical and a
political/social/industrial construct.