If you could reliably write memory safe code in C++, why do devs put memory safety issues intontheir code bases then?

Even highly paid (and probably skilled) devs in the IT industry manage to mess that up pretty regularly. Even if it was: devs using memory safe languages make much fewer mistakes wrt. managing memory... so that tooling does seem to help them at least more than the C++ tooling helps the C++ devs.

sigh

All build tools are simple as long as nobody uses it. Even CMake was simple before KDE and Co. started to rely on it.

A build tool can be simple, if you use conventions over configuration. Unfortunately that ship has sailed for the C and C++ eco system decades ago... Every project is widely different from every other project out there. Heck, we can not even agree on file extensions for c++ files, let alone a directory structure for project source code to live in or the tooling we want to be available.

So you need to have every little detail configurable... and since all projects are so very different, users will need to tweak all those settings... as the first bigger project adopting abcs will dictate their defaults into your code (where you have not gone with your defaults before).

Seriously, you need a language leadership team that considers tooling as important from the very start or you will not have a simple build tool ever. See rust: There the leaders pushed for tooling from the start. Every rust project looks basically the same because of that. These strong conventions enable the language to have a simple build tool.

C++ is on thenfar side of that. Even in 2020 when introducing modules the committee choose not to mandate even the most basic interoperability features like file extensions. The cmake people had to get several compiler developers to add things to make modules toolable. And even with that effort the meson people seem to say c++ modules are entirely untoolable still.

“I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees,”

My impression is that they are very aware of the state of C++ and the efforts to provide strong safety guarantees. That's why they keep raising the pressure.

Systemd-networkd (not systemd the init system) defaulted to the google DNS servers when:

• the admin did not change the configuration
• the user did not configure anything
• the network did not announce anything
• the packagers had not changed it as they were asked to do
• the distribution actually decided to switch to networkd. Few have done somtomthis day.

That is indeed a serious issue worth bringing up decades later.

Works for me on arch linux. No hickups or anything and I am using it since it was first announced.

The problem is that you lose out on dev attention when moving away from github.

I moved my projects into github when placeholder projects literally containing a README with a link to the real repo only got way more interaction on github than in the real repository: More stars, more views, more issue reports and even more PRs (where the devs have obviously Cloned the repo from the actual repository but could not be arsed to push there as well).

If you want your project to be visible, it needs to be on github at this point in time:-(

X11 probably has only a few years before development stops

Development has stopped. The only things that see updates still are those that are needed to run X11 apps on Wayland transparently.

That comparison is bad on several levels:

First off, systemd-the-repo does contain way more than an init system. But yes, I am pretty sure systemd-the-init is slightly bigger than runit.

Secondly: Systemd-init does set up some useful linux kernel features for the processes it manages in an easy and consistent way. That's why other services started to depend on systemd-the-init by the way: Systemd does linux-specific things developers find so useful that they prefer adding a dependency on systemd over not having the functionality.

Runit does not support any linux kernel specific features at all to stay portable to other unixes. Other alternative inits made the same design choice.

Thirdly: The overall attack surface of the system without systemd is bigger than a typical systemd system. That's because so much code run by the init system is way more locked down as systemd provides easy ways to lock down services in a cross-distribution way. Note that the lockdown functionality is 100% linux kernel features, so it involves little code in the init itself. Users of other inits can of course add the same lockdown features as service-specific startup code into the init scripts. We saw how well that works across distributions with sysv-init...

Finally lots of security features implemented outside systemd-the-init require a systemd system as they need the lockdown features offered by the systemd-init. One example is systemd-logind: That depends on systemd-init to be secure where the pre-systemd attempts all failed to archive that goal. Logind makes sure only the user sitting at a screen/keyboard can actually interact with the device interfaces of the kernel device files managing that hardware, so no other user but you can see ehat you type and take screenshots of your screen. Contrast that to devuans approach: Add all users allowed to start the UI to a group and make the devices controllable by that group. Much simpler, KISS and the Unix way... but it also allowes all users on the system that ssh into the machine somebody sits on can log what other users can type. Apparently that is not a problem, since no system ever will have more than one user in the age of personal laptops and desktops. That seriously isvtheir answer... and they even rejected to maintain the ubuntu-before-systemd logind replacement when canonical asked them, because such functionality is not needed im Devuan.

https://docs.rs/document-features/latest/document_features/ helps to document features.

But yes, features are under-documented.

Where are those alternatives? I have not seen anything that is Baustoff convincing yet...

It is not a project owned by redhat... the lead guy not even works there anymore. So the more interesting question is: What happens if Microsoft closes down the project? The answer: It will be forked.

Same reason as for all those years these old people are holding a grudge for...

It is not Unix philosophy (nothing is these days), it does not solve any problem they ever had (it does), it is no improvement over what we had before (it is) and even makes some broken and moronic things harder (it does), it is insecure (it improves overall system security), and it is one monolithic blob (it is not). Before systemd nothing depended on the init system (true, but then it did nothing useful that made having such a dependency worthwhile), and before systemd we were all free to use other init systems and distributions did not pick one for their users (they always did, offering additional inits only as unsupported iption just likenthey do now).

That's the typical list you get.

Oh, and it was shoved down all our throats by the mighty Lennart himself, backed by several multi billion dollar companies that brided thousands of distribution developers to destroy Linux (it was not).

Funnily enough it is pretty much the same BS we had when that monster of complexity called sysv init was introduced into distributions, replacing a simple script with a forest of symlinks. Of course the community was much smaller then and so we had a loser number of idiots to shout at everybody else.

Slint fits the bill: We have a demo running on a line-buffer in a microcontroller with <300KiB of RAM. Framebuffers are of course supported as well, as is GPU-accelerated rendering.