How does systemd dare to provide useful functionality? It should be just as useless as all the other inits that nobody ever felt the need to depend on, simply because they do nothing interesting.
You can just build a way more functional and secure system with all the cool features systemd provides.
The security theater is strong in this one.
"Nothing on this page asks for your faith.", immediently followed by a whole list of "trust me" (to manage the keys correctly, that the person notices the keys getting stolen, that she manage the entire signing process correctly, ...). No HW is used that could make it harder to steal keys, just some offline USB storage and a password manager. Every mainstream distro does way better than this, incl. Void linux this is based on.
No systemd with all the security improvements that brings either, but I guess that will bring in a small fan base:-)
I doubt they were the first to built such a system. The idea is pretty obvious after all.
They just are the first to give reporters a guided tour of the system and test accounts to play with.
You said Lennart is obnoxious and there is nothing like a big "that is not my problem" to not get your project adopted.
IMHO he does manage to get his projects widely adopted. His personality does not seem to have the effect you claim it has.
Systemd said on its first website that its a system management daemon. That is where the name came from. It was never supposed to be just an init system.
No need to buy out udevd, considering the guy doing that was on board with systemd from the start and made sure that systemd-init can make maximum use of udev and the other way around... you typically do want to start stuff in response to hardware appearing and disappearing. Now they can do that safely by just asking systemd-init to manage the services. They needed to run stuff thenselves before, which pretty often ended up blocking the udev daemon from recognizing new events... a quality of live improvement for everybody involved:-)
The rest has similar stories (only run network services when the network is up, start services only after the system clock has a sane value over starting the service and then adjusting the time at some later point (which some services handle really poorly), ... . There are some damn good reasons for the stuff systemd does. That bootloader is a pretty central piece in the image by the way.
Oh, and did I mention that anyone using or talking about non-systemd methods of doing things tends to get painted as "oh that's OLD and OUTDATED and OBSOLETE, just use the systemd way it's Modern™ and good"?
That is pretty much the only thing I can agree with:-) And that is because the systemd ways are ofentimes way more robust and able to deal with corner cases way better.
Considering how widely Lennarts code got adopted: You must be missing something.
Either you build a tool that works well with one OS or you build one that works poorly with several.
And it is not as if those other OSes are waiting for new cross-OS init tools: They either seem to be happy with what they got or want something tailored to their own features.
Read the proposal: Lifetimes annotations, the rust standard library (incl. basic types like Vec, ARc, ...), first class tuples, pattern matching, destructive moves, unsafe, it is all in there.
The proposal is really to bolt on Rust to the side of C++, with all the compatibility problems that brings by necessity.
Rustfmt is not very configurable. That is a wonderful thing: People don't waste time on discussing different formatting options and every bit of rust code looks pretty identical.
To be fair: snaps can work for all kinds of things all over the stack from the kernel to individual applications, while flatpak just does applications. Canonical is building a lot around those abilities to handle lower level things, so I guess it makes sense for them.
IMHO flatpak does the applications better and more reliably and those are what I personally care for, so I personally stay away from snaps.
I am looking forward to follow up articles like "woodworking as a career isent right for me", "bookkeeping as a career isent right for me" and the really enlightening "any job sucks when your boss is shit".
These comparisons assume the systems do the same thing, resulting in a comparable system once everything is up and running.
That is just not the case. Systemd does a ton more wrt. security, hardening and reliability. E.g. it has udev integrated and not running "stand-alone" since it tends to lock itself up when it needs to start long-running services in response to HW showing up. Yes that happens rarely but there is nothing you can do about it. Logind locks down permissions to HW way more tightly than the "forks" that have the same problems that the pre-logind system had -- and that led to logind getting developed in the first place. Lots of sandboxing options are built into systemd and widely used tomrun services (I rarely saw any sandboxing elsewhere so far outnofmthenbox), measured boot is pretty much a systemd-only thing at this time, ... .