“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.

Serious question: What is the point?

Just push into half a dozen mirrors and you are pretty censorship resident without the crypto voodoo put on top of git.

Github has one huge value: Discoverability of a project. This is even worse than hiding your project in one of the smaller forges... nobody can remember the mess of letters you need for this.

The one thing you can learn from sysv init isnthat asking devs to pitncode into their programs or into starter scripts does not work. They will not bother: Those will notmworkmcross platform.

So you need to cebtralize that task. You can either write a wrapper program that sandboxes starts applications in a sandbox or do that whereever the programs as are started anyway.

A separate sandboxing app that starts services complicates configuration: You basically need to configure two things the starter and the service. On the up-side you have the sandboxing code separate. Merging the sandboxing into the program starting the service makes configuration simple but adds moremcode into the the starter program.

So it is basically a decision on what you value more. Systemd decided to favor simpler configuration. The cost for adding the sandboxing is small anyway: It's all Linux kernel functionality that does need a bit of configuration to get rolling, with much of that code being in the systemd-init anyway: It uses similar functionality to actually separate the processes it starts from each other to avoid getting confused by programs restarted and thusnchanging PIDs -- something still a thing in many other inits.

I am convinced that making sandboxing easy does a lot formits adoption. No admin will change the entire startup configuration to add a sandboxing wrapper around the actual service. It is way more likely for them to drop in a override file with a couple of lines and without any problems when upstream changes command line options.

Yes, wayland by design does not let random applications grab events intended for other applications nor does it let random applications take screenshots at any point in time showing other applications screens. This requires applications to do screen sharing differently, and it indeed breaks random applications sending events to random other applications. That is basically all you wail about and an absolutely necessary property of any sensible system and it is very embarrassing that it took so long to get this.

Removing dump stuff to keep a community relevant, on topic and with a good signal to noise ratio is not censorship. Claiming so is just dumb.

The idea behind TPM-locked boot is that you can boot into your system unattended, but it stops booting into any other system. Typically no password is needed, but you can also assign an additional (non-user) password if you want.

This is nice if you trust your system to be basically secure. Nothing else can access its filesystems, so no external tool can be used to break into it. Rescue disks can not access any data without knowing a special rescue key -- so make sure to set one up! A nice side effiect is that the key is only available while setting up disks in the initrd and totally inaccessible at any other time. That makes it very hard to extract the password once the system is running.

You can encrypt the home directories of users using other services like systemd-homed. That will prevent anyone from accessing any data in the user's directory while that user is logged out. Homed will basically use your password to unlock your disk and if that works, then the password is accepted. So you do not need that user to be listed in the traditional /etc/passwd file, which is useful as you can just copy the users homedir image file onto another system to move a user account over.

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:-(

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.

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.

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.