Just systemd as usual. The original systemd author is employed by Microsoft, though.
Damn, how could I forget.
What if he was secretly on M$ payroll for the whole decade?
This could explain systemd 
Silly!
No, it's just a case of him perfectly suited to the centralized approach used in Windows, and very poorly suited for the modular Unix philosophy –– I do believe he has publicly stated it is outright outdated concept that should be discarded anyway. So, no secret; just birds of a feather.
It is funny how people can ignore the historical precedent, and decide that now that they're in charge, designs that have always failed before (centralization and single-point failure problems) shall now magically succeed. Because everyone else who tried it before did it wrong.
If you start with the assumption that those that created and designed the things we still use and rely on were
smarter than we are now, understood things
more fully than we do, things start making sense. Scary thought, though.
I don't follow the drama, did things reach a point where people have their work blocked because it breaks Rust bindings? 
No, but he
posted this youtube link as "context", as if that was "nontechnical nonsense", which later bystanders commented as being horrific behaviour from Linux kernel developers that wouldn't be accepted anywhere where the commenters work.
Fact is, the Linux kernel changes constantly, at a rate that very few software project sees. At 30+ million lines of code, it is already so large no single human being, not even Linus himself –– and he openly admits this! –– can encompass it all. To keep doing what they are doing, subsystem maintainers and developers have to actively avoid adding to their maintenance burden; otherwise they will fail as a maintainer. And even then, the maintainers change; it's just
too much for a normal person. Normal people just don't understand the complexity and the cognitive load involved.
Fundamentally, because the kernel is written in C, it is the Rust bindings (and thus the Rust API) that have to keep up with the kernel innards, and this is what has offended so many, including tons of Google and Microsoft developers, plus a fuckton of commenters. Very few understand the real issue, and it is not that kernel devs are ossified and too stupid to learn Rust: it is that to do what they do now and want to do better in the future, they cannot afford wasting time on Rust, because just to
keep up with the kernel development they need to use all the brainpower they have.
That is the exact reason there are no fixed internal APIs in Linux, too: they need the freedom to find the solutions they want!
Adding to that load with a completely new set of complexity and issues –– the Rust bindings/API –– is just unrealistic. Try to do the job of
two kernel developers, and you will fail, no matter who the fuck you think you are. Telling those that refuse to do so are "nontechnical" and old refuseniks standing on past achievents or whatnot is idiotic, Poettering-level asshattery. Just subscribe to LKML for a month, drinking from that firehose, and
understand the issues discussed, and you'll be hit with the fifty-ton cluebat of what kind of environment it is. Go away for a month, and you'll likely spend six months catching up.
Home
Help
Search
Login
Register
