Anything that is cool/unusual/noteworthy about it?

Filesystem enable age verification in pretty much the same way as systemd does: You can optionally store a user's birthday. That is such a ridiculous statement.

To be fair: None of the other inits cared for udev. None contributed or helped by providing features they wanted to improve udev. The systemd devs care for the lower level plumbing overall... and not just for the init system. So it is very natural for low level plumbing projects to land under the systemd umbrella today.

Systemds track record wrt. security flaws is actually pretty good. Not many went through the cracks,maven though some were indeed pretty ghastly. Hardly any was in the core functionality, most were in new code not widely used yet.

On the other hand, the service hardening that systemd enables has improved the overall security of a typical Linux system by quite a lot.

You are technically correct: Slint is free software. You can get Slint as GPL or commercial terms -- or the royalty free license. The latter lets you do whatever you want anywhere with the exception of "embedded" (this exception makes is not open source).

When you contribute to any MIT license project you are in the same situation: Your code will be redistributed by some company under different license terms. That's the point of MIT & Co. You contribute MIT code to a project, the project releases its code under MIT, and a company consumes the project and restricts its use. Slint is just cutting out the middle step here.

Disclaimer: I work for Slint and appreciate being paid for contributing to open source software. I also appreciate Slint being free software.

The same happens with any of the new immutable distributions. It's just less effort as you do not need to do the nix configuration dance anymore.

Governments triggered this entire discussion with their papers and plans to strengthen cyber defenses. The article states that some experts ask for our industry to be more regulated in this regard.

I am surprised that possible regulations are not even listed as a factor that in the decission to stay with C++ or move to something else.

Sure, COBOL is still around after decades, but nobody ever tried to pressure banks into replaceing that technology AFAICT.

Usig anything as root is a security risk.

Using any UI application as root is a bigger risk. That's because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.

So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.

Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.

Ideally you run the UI as a normal user and then use sudo to run individual commands as root.

Most of your examples are projects started by a company. The very few remaining are those 0.01% that got lucky.

My point stands: When you start an open source project, there is no need to worry about what companies might like or not. You will not get money from anyone.

Why? Slab sysv-init (or openrc or s6) and the gnu tools the onto it and you will hardly be able to tell the difference :-)

That is actually the thing I like about systemd: They expose a lot of linux-only features to admins and users, making the kernel shine.

An update is only truly done once no remnants of the old code is in memory. Code can stick around in the form of binaries (restart the binaries), libraries (restart all binaries that use this library) and the kernel (reboot or use kexec).

One very simple way to make sure no old code sticks around is to reboot:-)

The basics are all the same:. memory, cpus and caches in between ;-)

But rust does approach many things very differently from C or C++. Learning those new approaches takes time and practice.

No need to drag that BS from the archives. It was never correct nor convincing.

I did tick that, since I saw text boxes and went "give me everything" without reading:-)

Fixed. Thank you for pointing this out.