PA was force-pushed too early, systemd got it's own momentum. AFAIK PA suffered from external unsolvable forces, like hardware/driver giving inconsistent if not false data to PA, causing failures; I believe systemd is shielded from this. The benefits (sound dependency based state) already outbid the other issue one might have with it (less freeform scriptability as in SV).
I see a pattern here. What guarantees that in ten years the same claims won't be made about systemd being pushed in 2014 "while not ready", but by 2023 all issues are ironed out after the whole thing was rewritten three times and was responsible for more security breaches than bind and sendmail combined over their history?
In my opinion, there is no replacement for true modularity, simple, future-proof interfaces, and clear, human-readable and human-writable formats.
> I see a pattern here. What guarantees that in ten years the same claims won't be made about systemd being pushed in 2014 "while not ready", but by 2023 all issues are ironed out after the whole thing was rewritten three times and was responsible for more security breaches than bind and sendmail combined over their history?
I've been running systemd as my init system for at least a year. It's also used in Fedora. It is working pretty well by now.
> In my opinion, there is no replacement for true modularity
Systemd is an ecosystem. It contains a number of different binaries. They may be part of the same codebase, but so what?
>, simple, future-proof interfaces, and clear, human-readable and human-writable formats.
You mean, like systemd's unit file format, which is both more readable, and more specified, than the sysvinit boilerplate? If you mean journald, if you have rsyslog as well, you get your usual /var/log/syslog. Best of both worlds.
True interoperability does not produce "an ecosystem", it produces standards with (at least potentially) multiple implementations.
> It contains a number of different binaries. They may be part of the same codebase, but so what?
So it's contrary to the idea that modularity is achieved through clearly defined interfaces, so "the same codebase" is an unnecessary luxury for lazy designers.
I'm sorry, but you're not making any sense. If a closed system is a project you can fork on github, with ~ 260 contributors and libraries like python-systemd, I don't know how you define "closed".
> So it's contrary to the idea that modularity is achieved through clearly defined interfaces, so "the same codebase" is an unnecessary luxury for lazy designers.
Right. So, the systemd Debian package on my machine has 21 separate binaries. Who in their right mind would want to have 21 separate repositories to keep in sync?
As for "cleanly defined interfaces", I don't know how having several different systems in the same codebase prevents that. Which parts of systemd do you feel are not well-documented and prevents you from writing code to interact with it, or replace part of it?
systemd is already used and from what I've seen there's far less complaints than PA[1], even talks of admins suggesting to look into it. That's for the 'not ready' part. For the rest, I'd agree with you, but I think the gain in abstraction and correctness is quite worth it, even with it lacks some simplicity.
[1] never encountered a single issue with systemd since archlinux pushed it as default, even on hybrid sysvinit scripts and naked systemd installs, compared to PA which may crash far too regularly, but that's just me.
