I'm not sure it will ever become mainstream. It might remain small forever, e.g. like the haskell/fp community.
The best part is, there wouldn't be fragmentation of package maintenance between distros.
It’s about an ever expanding take-over of userspace by a single module, which is not the Unix way.
And about a high-handed project leader who is paid by Redhat to do it full time.
You confuse Systemd the init system with Systemd the project.
The Systemd project can be described as "GNU coreutils but for low-level system components". People hear about all the tools that the Systemd project maintains and think that all that functionality is built into the init system, when the reality it's >50 separate binaries, the majority of which (like systemd-boot or systemd-resolved) are completely optional and aren't even installed by most distributions.
And while I understand that some parts, like journald, are not so independent - it's still not "a single module" in a way that prevents it from being unix-y. The Unix philosophy is about separation of concerns, not having a bunch of interchangable options for low-level system components.
And you know what? It’s fantastic. The API is generally well-designed (if not without a few sharp corners) and the whole thing is incredibly well thought out. Sure, plain text logs let you use standard UNIX tools. But doing so sucks. God help you if there’s a newline in your logs or if you have to ensure that you iterate over all the logs even across restarts or if you need to parse logs back out from text into the underlying attributes.
And in 20 years, Red Hat will have finally finished re-inventing Windows NT on top of the Linux kernel.
Yes, I’ve used OpenBSD. It’s great, but not for me atm.
I absolutely _don't_ think that my init system should also be my bootloader.
It also shouldn't manage my network configuration, or be responsible for controlling the system clock.
And it shouldn't assert control of my home folders.
And it shouldn't be spidering its way into the Gnome login manager, which grew a systemd dependency a couple of years ago.
My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project.
If your service file is a tad more complicated, then you quickly discover that there's a scripting language masquerading behind key/value entries.
I have a hard time wrapping my head around dbus being the core component used for coordination among systemd components. dbus wasn't built for this use case, and having PID1 depend on a well behaved dbus for proper system operation sounds insane. systemd adds a lot of features, which means additional complexity. My understanding so far is that the tooling is not there yet to manage this complexity.
Another gripe I have with systemd is that it does parallel service start introduces non determinism at boot. Which means your setup could work very well most of time, but fail miserably 1 time out of 10. Not exactly what you'd want if you are rebooting a remote server for example. s6 [1] init doesn't appear to have this problem.
Good thing it's not?
systemd-boot is an entirely different binary, it's not even installed by default by any large distro I know of. The only commonality between them is that they are developed under the same broad project umbrella, just like "cp" and "ls" and "cat" are all part of the GNU coreutils umbrella.
This is a theme for an entire class of incorrect complaints about systemd -- the misconception that just because a tool is called systemd-$thing means it's part of the systemd init system, rather than "a tool developed by the systemd project".
The best thing about Linux is that you are free to pick and choose even low level components of the system as much as you'd like.
This could not be further from the truth.
Of course, since this hack solved the gnome bug, it was enabled by default by many, thus breaking applications like screen and tmux.
What should have been done is fix the issue in whatever offending application. Certainly not at systemd level. Because in that case, you need to do some insane things (IMO), like link tmux with libsystemd [1].
The backstory is actually enlightening to me. To me, RemainAfterExit just seemed like the obvious sane decision and I actually wondered why it ever was different. When a user logs out, I absolutely want everything cleaned up after them unless they explicitly want something like screen or tmux to linger.
> you need to do some insane things (IMO), like link tmux with libsystemd
That would probably be the easiest choice for the tmux devs. If they don't want to link libsystemd, they could have accessed logind's DBus interface directly (either by calling dbus-send(1) or via libdbus). Contrary to wide-spread belief, systemd does, in fact, present well-defined and documented interfaces that other daemons can implement as well (and they do, see elogind). libsystemd is not magical.
It's nice to know that libsystemd is not required in all cases, but I still have a problem with software having to be modified because systemd changes how libc's daemon() function behaves.
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221
gnome-shell used by the Gnome/Ubuntu login process also depends upon evolution-data-server!! See `apt-cache depends gnome-shell` for other dependencies...
Debian chose systemd instead of upstart because of licensing, not features, according to https://wiki.debian.org/Debate/initsystem/upstart
Kind of ironic when one of the oft touted complaints I recall about Linux vs the BSDs or virtually any historical Unix is how the userspace and kernel are not one integrated distribution.
This gets pulled out far too often. Systemd is a family of projects thast are largely modular and independent, not a single binary that takes over everything. Each part's goal is to do one thing, and you're free to take or leave each piece.
By this logic, Bell Labs should have never worked on UNIX or C - they were a telephone company!
Another smaller thing: /etc/os-release replacing the various /etc/*-release files.
Fictional Debian dev B: "That's how we've always done it. Plus if we touch it it might break some guy's script."
It may not be exactly cargo culting, but at least an adjacent concept.
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444678
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659891
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659853
I wonder how long it'll be before the contents of that file start resembling a user-agent string, complete with "Ubuntu-16.10/Compatible"
* http://jdebp.uk./FGA/run-levels-are-history.html
getty was obsolete in the System 5 world two years earlier than that, in 1988.
* http://jdebp.uk./FGA/inittab-getty-is-history.html
Whilst not peculiar to Linux, it after all having been created for Minix, the van Smoorenburg init+rc system did resurrect some things that were already years gone in the System 5 world. Calling them "sysv" has always been somewhat of a misnomer. They are Linux/Minux clones of old System 5 mechanisms that were out of date at the time.
I don't see any of these people making better contributions. It's easier to sit there and insult the project leader for being paid by RedHat - but let's face it. Without commercial sponsorship, Linux would be dead.
So quit your whining. If you all ready don't like systemd that much - why don't you implement a better alternative - as you all seem to have the answers.
Or,
Unlike children, who call other people names, the adult in the room rarely does?
In fact Guix System 1.1.0 was released a week or so ago.
NixOS and GuixSD being the next generation of distributions and people are calling it "neat project with some unique features, but it is more fun as an intellectual curiosity than as something practical" while arguing if a distribution should use Systemd or not...