If there ever was a "red herring" in a discussion of Linux distributions, it's the init system.
The distro maintainers package the software for their system. It's therefore also their responsibility to make sure a service can be started/stopped and have its status checked.
It does not matter what kind of init system a distro has. A single Linux distribution is an Operating System independent of all others. There is no one true portable Linux way, much less for non-Linux-based Operating Systems. You have to treat them all as separate because to do otherwise would not only add complexity to a monolithic "portability" system, it would eventually get so complex you'd have to split it up anyway.
Portable software makes 3rd-party software developers' lives easier. But the init system is not managed by 3rd-party developers. It is managed by the OS maintainers. So it does not matter what method they use.
Furthermore, it's fucking Debian, the second-oldest distribution still in release. The oldest (Slackware) holds onto the old ways for as long as technically possible, and they're still going strong. So why the hell they care about being "modern" and "remaining relevant" is anyone's guess.
(disclaimer: I wrote my own init system for my own Linux distribution, and have modified most others)
All that's true of init systems that follow the traditional Unix approach, where each part of the system has one task to do and does it well. The point of systemd is to break from that approach. So systemd isn't just an init system, it also creates device nodes, handles system-wide logging, manages both desktop and console login sessions, replaces inetd (but with support for Unix sockets and DBus), provides resource management functionality for virtualised containers, and a bunch of other stuff I've forgotten. Making full use of these features requires changes to a large number of other applications.
Holy shit, that sounds horrible. As an application developer who already knows how to make programs work for Linux, and a distribution maintainer who can take care of all that crap without a new framework, and a systems administrator who can edit it all on the fly using just shell scripting, I struggle to understand why this system is necessary at all, or why anyone would push for its adoption.
You don't actually need to use all the different parts of systemd, though. They are a suite of different binaries. You could just use the /sbin/init replacement at /usr/bin/systemd, under consideration it will require a rewrite of your services, etc. But logind and journald are optional dependencies, you could redirect journald output to a syslog.
The purpose of a lot of systemd was to say "there are these old utilities based on shell script hacks that would be better served in a Linux-specific framework" like power management, device plugging handling, etc. So they put them under one project. Same way under the Linux kernel is hundreds of megs of device drivers, and a lot of features end up in kernel space (rendering interfaces, networking stacks, filesystems, virtualization) yet nobody calls the kernel anti-unix (some might call it bloated, though).
Not to get too side-tracked, but Unix-like kernels aren't very Unix-y. They're big monolithic beasts that are difficult to configure and impossible to modify on-the-fly, save for the few modules that can be unloaded, recompiled, re-inserted and configured. In general it was thought of as bad design, and still is by many "experts".
I'm not sure why our system management tools/frameworks have historically been interpreted scripts. It could be due to the low barrier to entry. Or the dynamic way it can be modified - even on embedded systems - without any tools other than a text editor. Perhaps relying on the infinite possible combinations of simple tools just gave us more power than we could ever get from trying to make libraries for every possible need. Or maybe it was just way simpler to manage.
I'm not anti-systemd, mainly because I haven't used it. But any time someone says "let's replace the old system wholesale" without really REALLY good reasons, I suspect it's premature. It seems really useful for tightly integrated embedded systems, but hell for general admin use.
I used Debian for a year before moving to Ubuntu and eventually Arch. I've tried all 3 flavors of init, and I vastly prefer systemd :
1. It is noticeably faster.
2. It is braindead easy and intuitive to write service files, and you can write service files or a surrogate for almost any system function from hot swap behavior to load balancing.
3. The entire systemd execution model is fs based, and you have a large library of services to run at your discretion.
4. powerctl is supremely more robust in its usability than pm-utils and shell scripts around suspend / shutdown states.
Only thing that really bugs me is the binary log. I want to pipe it and manipulate it and read it outside a terminal in say, kate, but I have to install syslog on top to do that.
1. Legacy init systems were never tuned for performance. Just look at 'grep sleep -r /etc/init* /etc/rc*' as an example.
2. Easier is nice, but you could write scripts for all those system things using hotplug, udev, and a variety of other things (remember devfs?) I never bothered to learn because they just worked.
3. I'm not sure what you mean here; what execution model is not fs-based in some way? If you mean scripts would execute other scripts based on a filesystem hirearchy, yes, all the old systems did that too.
4. That's nice, but it's kind of irrelevant to how your system initialization/service management works. Different purposes and all.
And yeah, binary logs are dumb without a tool to manage them, but relying on syslog is smart. It's an industry standard. It's the only industry standard for collecting and managing logs from every kind of device, other than maybe snmp (yuck).
systemd contains a lot of different bits, each with a different task. Much like e.g. coreutils. Coreutils contains a lot of different utilities. If systemd is somehow bad for Linux, coreutils is as well.
The distro maintainers package the software for their system. It's therefore also their responsibility to make sure a service can be started/stopped and have its status checked.
It does not matter what kind of init system a distro has. A single Linux distribution is an Operating System independent of all others. There is no one true portable Linux way, much less for non-Linux-based Operating Systems. You have to treat them all as separate because to do otherwise would not only add complexity to a monolithic "portability" system, it would eventually get so complex you'd have to split it up anyway.
Portable software makes 3rd-party software developers' lives easier. But the init system is not managed by 3rd-party developers. It is managed by the OS maintainers. So it does not matter what method they use.
Furthermore, it's fucking Debian, the second-oldest distribution still in release. The oldest (Slackware) holds onto the old ways for as long as technically possible, and they're still going strong. So why the hell they care about being "modern" and "remaining relevant" is anyone's guess.
(disclaimer: I wrote my own init system for my own Linux distribution, and have modified most others)