I doubt they were the first to built such a system. The idea is pretty obvious after all.

They just are the first to give reporters a guided tour of the system and test accounts to play with.

We said the same about memory safety: That's something a compiler can not solve. Now it does.

It is nice to see that sometines things do improve.

News at 11: Senior C++ committee member still does not understand what memory safe means.

Seriously: C++ does not "archive parity with other memory-safe languages" (emphasis mine) since it is not a memory safe language itself, even if profiles deliver on everything they promise today.

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.

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

That depends on how you decide which bucket something gets thrown into.

The C++ community values things like the RAII and other features that developers can use to prevent classes of bugs. When that is you yard-stick, then C and C++ are not in one bucket.

These papers are about memory safety guarantees and not much else. C and C++ are firmly in the same bucket according to this metric. So they get grouped together in these papers.

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.

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

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.

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.