[log in to unmask]">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.

[log in to unmask]">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.

[log in to unmask]">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.

[log in to unmask]">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.

[log in to unmask]">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.