Redhat is the main force that created systemd. And so their heavy-handedness into Wayland isn't surprising.
And systemd is controversial in that a vocal minority says it was a disaster. I don't think it is, definitely not compared to Wayland.
> 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.
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.
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.
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.
* 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.
Talk is easy, building something that works for the majority is hard. And one thing for sure is that not everyone will be pleased