> That's also not a pile of hate. You could say it's not polite, but the implied message that I pick up on here is that Gentoo will need to implement alternatives to systemd technologies if they
> want to continue to benefit from other software projects that use systemd.
The you missed something in earlier lines in that post. Gentoo already maintains its own udev fork, eudev, so that's not the issue. He spoke of moving kernel event signalling from netlink to kdbus, which "breaks userspace" at a much more fundamental level, not just Gentoo's eudev.
I put "breaks userspace" in quotes, because the statement of simply changing interfaces like that breaks normal kernel practices, like keeping published APIs around for years of non-use before removing them. I've no problem with a kernel config switch that says something like "netlink or bus1 for event signalling", that's fine, breaking currently in-use and in-development software isn't. This betrays either a lack of familiarity or lack of regard for normal practices, neither of which belongs in a piece of infrastructure as important as systemd has become.
> That's great, but I didn't see any technical arguments from you. Maybe I missed them.
You didn't. I've mentioned technical or software philosophy several times, and this is the first time in this thread that anyone has picked up on it, or expressed any interest.
1 - PID1 is critical. If it crashes, the whole system crashes. I know that everything in systemd is not PID1, but it's still got a big one. Every line of code may someday translate into a bug or a crash. Proof, look at the bug history of IEFBR14 some time - that really is quite literally a one-liner, that managed to accumulate multiple bugs. My hair is grey, I used to use IEFBR14 all the time.
From what I've seen the functionality of systemd's PID1 could have readily been separated into a much smaller PID1 that did less, and one or more helpers that PID1 could restart as needed. That would have also allowed updating systemd without rebooting the system, as long as the PID1 portion hadn't changed, and being much smaller, that would have been more likely.
2 - Unix philosophy - small pieces each of which does one job and does it well. Then tie them together to do bigger things. In other discussions on this topic, I've been told that the Unix philosophy is obsolete, but I disagree. It has kept Unix running for some 40 years, through orders of magnitude of change in every aspect of computing. I'd be hesitant about throwing it out that quickly.
3 - I like initscripts written in a Turing-complete shell script language. You don't always need it, but when you do, you've got it. I've never written an initscript from scratch, but I have so heavily modified some that they practically end up from-scratch. From what I've ready, systemd has a decent configuration language for service units, but it's not Turing complete, and if they did, why not just use something that already exists and is well-debugged - shell script?
4 - Right now systemd is one package, even though it has many parts. That means that a bug in its logger requires a complete sytemd update... Or a bug in its new resolver subsystem, etc, etc. If the packaging were split, kind of the way the old functions that systemd has been subsuming were, then such updates would be simpler. Don't forget that a systemd update requires rebooting.
I could go on, but that's a few.
By the way, when attempting to make technical arguments like this, I've been called quite a few names, along the names I've been called when calling for network transparency out of Wayland. I try to let it roll off my back, but it can get to you after a while, especially when technical arguments are answered with insults and name-calling, rather than counter technical arguments.