Have you ever worked with RedHat? This is just how they are, across the board. (And maybe now we should be saying the way IBM is, who's history is even worse...)
> And systemd is controversial in that a vocal minority says it was a disaster.
Not a minority, and some of the loudest voices are the experts whos opinions matter most.
I am one such expert. Most technical people I speak with about systemd are largely ignorant as to the design considerations.
Yeah, no. Most actual experts very much prefer systemd due to it actually solving the problems inherent in booting up a system with all the services, and resolving the dependencies between them, instead of just being hacky bash scripts that only work on a single machine (if at all).
The only people who have problem with systemd is “old-timers” that just refuse to learn anything new, and just blindly believe that the old status quo was better.
That's the kind of attitude I often see from people who have never spent time debugging a dependency resolution issue in startup actions. People who do not have significant experience in running large scale, reliable systems. People with a desktop focus, who know little about systems internals.
Engineering reliable systems often means reducing complexity. A major unaddressed complaint regarding systemd is that there actually isn't a need for dependency resolution during startup, at all. Dependency resolution is very complex and introducing it makes testing changes far more difficult. It is not a desirable feature for most server applications where reducing complexity and increasing operational visibility take precedence.
> The only people who have problem with systemd is “old-timers”
You may be confusing experience with age. The two are related but they are not the same.
> that just refuse to learn anything new, and just blindly believe that the old status quo was better.
This is just silly. There are all sorts of wonderful features related to containerization, cgroups for job control, structured invocation for processes, etc.
The primary issue with systemd isn't that any of these features are bad. The issue is that they have been conflated in a mostly unspecified, monolithic system which discourages composition, inspection, and simplified operation.
It's a big ball of mud architecture. You can't use the service invocation components standalone. You can't use the RC components standalone. You can't use the init components standalone. All of these things should be possible, but aren't, and that is the core issue.
Thanks for the level-headed answer, I’m sorry I lost my cool there, but all too often one can run into Wayland/systemd-haters who are like absolutely unreasonable.
What I compare systemd to is the previous iterations of linux init systems, and compared to them it is a huge positive change in my, and most of the linux world’s opinion (it was voted on multiple times in probably the most democratic process at debian, was decided independently at several other distro). It solves real problems (e.g. pre-disk mount logging) in a relatively modular way, and I think we should cut some slack here, because often times in complex problem domains a monolith is the correct choice. Multiple different tools will actually result in more complexity due to coordination, and I would go as far as that was part of the problem with previous init systems.
May I ask you what would be your preferred solution in place of dependency resolution at runtime then? I do agree that it is “one more moving part”, I just fail to see how else could it work.
I wouldn't do dependency resolution at runtime at all on servers. I would do it at install time and generate a static set of ordered steps. This has a few desirable effects:
* It ensures changes can be audited, observed and tracked (or caught and prohibited). Explicit change control points are key.
* It provides an interface and an option, divorcing the dependency tool from the system which invokes the ordering
* Ordered sequential steps takes longer, but adds determinism. It enormously simplifies the startup process, including auditing where things go wrong in logs after the fact. For servers, this is far more important than lower start times.
Most systems end up with a distro/systemd controlled base and a custom application on top. Often there's all kinds of special harness around the application, far beyond what can be fit into systemd. So there's always necessary duplication and struggles around interfacing different kinds of systems.
For custom applications, I tend to advise that the development team first come up with the success criteria for their app. What conditions would they page on, and what runtime dependencies does their app need? (Databases, up to date feeds, kill switches/feature flags, etc). I suggest that they re-use their monitoring code to also control orchestration of service startup. For example, not starting a front-end app unless a connection check to a backend SQL server passes. In these cases, the orchestration may be significantly more complex than what can be performed inside of systemd -- and this is part of why a clean and extensible interface is so important.
> And systemd is controversial in that a vocal minority says it was a disaster.
Not a minority, and some of the loudest voices are the experts whos opinions matter most.
I am one such expert. Most technical people I speak with about systemd are largely ignorant as to the design considerations.