Switching to systemd broke _my_ entire Arch _experience_. Before systemd I knew exactly what gets executed, when and why -- which is exact reason why I switched to Arch many years ago. I don't know the same thing after systemd introduction.
I understand what you mean. I had the same awe when I first started on Arch and really got to know all the bits and pieces. When I transitioned to systemd, I had to go through that again. It was actually very similar to what I did the first time around and I suggest you give it a shot too. systemd, while seemingly monolithic is actually a really cool suite of tools. The thing we need to keep in mind is that it's _not_ sysvinit, and it's not trying to be. It's trying to be a project that does more than that and does it transparently on all systems. You might like it :)
As a general point for everyone: Just because it's _also_ an init system doesn't mean it's not allowed to provide the binaries for doing a whole lot of other stuff. :)
The problem is that it's a suite of tools that are all developed under the same umbrella, by the same people, with the same ideas, and the same gatekeepers. It's rather difficult to fully replace parts of it, especially as the formal API to it is defined by systemd, and we're seeing more and more tools integrate with all that.
Why can't we have an independent organisation that defines a spec for all the relevant APIs and tools for managing a system, and systemd just be one implementation of that spec? Actually, it could be a suite of specs, so people could pick and choose which ones solve their problems, and build alternatives for others.
Hmmm... I pondered this for a bit, and I arrived here:
> [...] by the same people, with the same ideas, and the same gatekeepers [...]
Isn't this exactly what made the Linux Kernel great? A consistent vision.
I agree with you on a few points though, the systemd team should be more cooperative and start being conservative on the API changes. If the API is defined clearly, it shouldn't be hard to make proper replacements for parts of it.
I disagree strongly that there should be an independent Organisation to define that spec, because that would quickly be overrun by bikeshedding and all the other problems stemming from design by comittee. Very often in the Open Source world, specs have been defined by the first people arriving at the scene, so to speak. It all works over dbus, no? That is a fairly simple protocol to implement. I think it's an elegant IPC solution.
> Isn't this exactly what made the Linux Kernel great? A consistent vision.
Sure, but even today, the Linux kernel has competition. I can run most things on Windows or OSX or FreeBSD or Solaris, even if the technical details are different. I worry about a monoculture forming around systemd, as seems to be happening now; I can't find a modern distro that uses anything else (aside from Gentoo, which I can't take seriously for production work), and it's starting to be assumed that systemd is the only init system that anybody will use.
and look at its contents. It is not that hard. It changed everyone's experience. Some people just hate change. Others deal with it.
While it did make desktop / laptop users experience a little bit more complicated, from what I have read it makes things much easier on the sysadmins who are working with lots of daemons on the servers.
It's not that bad. rc.conf had its own problems. Remember the archaic format of specifying your network setup in rc.conf, and how it required tons of special utilities to do things like intelligently connecting to available wifi points? Yuck.
Feed "systemd-analyze dot" to Graphviz and you get a dependency graph of the current boot.
Also try the other options to systemd-analyze, such as "critical-chain", as well as systemd-cgls to get a view of how the currently running processes relate to specific service files.
Together it should give you a view of what gets executed when (to the fraction of a second) and why.
> Before systemd I knew exactly what gets executed, when and why -- which is exact reason why I switched to Arch many years ago. I don't know the same thing after systemd introduction.
Funny thing. For me systemd has turned that around. I had no idea what was going on in my system, but systemd allows me to easily visualize it, control it and optimize it.
systemd may not be the ultimate init system which all Unix/Linux versions will end up using, but I have no doubt a future init-systems will take a queue from all these things which systemd has done well.
Switching to systemd broke _my_ entire Arch _experience_. Before systemd I knew exactly what gets executed, when and why -- which is exact reason why I switched to Arch many years ago. I don't know the same thing after systemd introduction.