What it means that Ubuntu is using Rust

Some of these non-system programmers are ex-system programmers, coding since the mid-80's that foundly remember the days when C and C++ compilers had rich frameworks that would compete in features with what .NET and Java later came to be.

Unfortunelly too many modern system programmers never lived in that era, and are completly off on how nice the whole development experience could be like.

With permissive licenses you often run into the following situation:

You buy something physical from a company, say a humanoid unitree robot, a robot actuator or Arm SBC. These pieces of hardware come with their own proprietary SDK that they sell for a significant fee or a proprietary GPU driver without any hope of updates. The SDK heavily uses MIT licensed code and there is no possibility of modifying or inspecting the code for debugging.

From the perspective of the user, the system might as well be 100% proprietary and his freedoms are maximally restricted. You could say that this is fine since it doesn't detract from the original open source project, but you have to remember that these companies would ordinarily have to pay significant development fees to build the same level of functionality and they have no obligation to help or support your project financially. You as the open source developer will then have to beg them to hire you, so you can do paid work that is unrelated to the original project to finally work on your project in your spare time, purely because it is possible to charge for hardware but not the software that the hardware depends on.

What I'm trying to get at here is that this means full vertical integration is the only way. The problem is that most hardware companies are hardware companies first and they don't care about software. They concentrate on making hardware, because each sale brings in money. They don't spend money on software, because it appears to be optional. You can just tell the customer or an open source community to bring their own software. The money that is needed to pay for open source projects flows through the very companies that refuse to spend money on software.

If you want to write open source software, you must be a hardware company so you are customer facing and have access to customer money that can be diverted to the development of the software.

systemd won because of politics, and absolutely nothing more. Debian, the root of the most used tree of Linux distros, only adopted systemd due to pressure from Redhat/Gnome, and threats that if it didn't?

Gnome would no longer work on Debian.

Understand, that many of the issues "resolved" by systemd, were redhat issues. And further, not even init issues.

For example, the most predominant being "predictable NIC names", which were already a thing with Debian. Or bootup times, of which Debian had excellent parallelization and boot times of a similar scope to how "fast" systemd was.

There's really nothing good, from a technical perspective, when something is enlarged 1000x the requirement. If you look at the code for sysvinit, it's maybe 10k lines. Systemd is > 1M lines of code, likely approaching 1.5M by now. So I suppose, 100x the size.

It needs to be understood that the more code you have, the more bugs. It's just the way it is. There have been more security issues in core systemd yearly, than sysvinit in its entire lifespan. That's not even systemd's fault, it's just a simple fact, you have more code, you have more bugs.

And when you say "systemd", you're likely referring to all the inane nonsense it does? How broken it is managing mounts, which really isn't an init's job anyhow? Or the absurd nature of having shutdown and startup identical, with automatic ordering, so you end up in all sorts of ridiculous edge cases?

Why would anyone presume that start and stop MUST be mirror images of each other. The very logic is broken, and shows an immense lack of comprehension of how the real world works.

And you speak of "it won" for superior this and that? At the start, it didn't even have an easy way to extend stop time. Hell, even now it just sends SIGTERM and a nanosecond later SIGKILL, as if shutting down a box FAST FAST NOW NOW is more important that data integrity or properly closed tcp connections or processes doing any form of proper cleanup.

The number of mysql/database issues caused by this behaviour in the early days was insane.

Look, I get you like systemd. But it's provided no real value, and certainly, even if there is some? The detractors outweigh it as the sun turns meat to leather.

They did survive, Qt, VCL, FireMonkey, POCO, but the dark energy of the Electron force it too mighty.

Also in the 2010's we had the rise of scripting languages, thus we have a whole generation that never used compiled languages and are now re-discovering systems programming via Rust, Zig and co.

A history lesson, before OOP, there was Yourdon Structured Method, and plenty of C enterprise architects jumped into it.

The GoF book used Smalltalk and C++, predating Java by a couple of years.

The Booch Method used C++, and predates Java for a decade.

Ah and there was that whole operating system written in an OOP C dialect, including its drivers, NeXTSTEP, which also survives to this day, with more consumer deployments than the Year of Desktop Linux.

> There's really nothing good, from a technical perspective, when something is enlarged 1000x the requirement. If you look at the code for sysvinit, it's maybe 10k lines. Systemd is > 1M lines of code, likely approaching 1.5M by now. So I suppose, 100x the size.

The systemd repo is a mono repo for other tools in addition to the init system.

I've heard from many sysadmins and distribution maintainers that systemd has been amazing. We went from ad hoc shell scripts to declarative plain text files. I think that's a huge win.