hunger

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.

Those evil companies block random users, just because their government made some laws about it.

I'd go for open source projects. They usually have bigger code bases and good practices, that they enforce on their contributors with code reviews and such.

It's a good way to get feedback on your code, something miss out on personal projects and get much less of in university and corporate projects.

Rustfmt is not very configurable. That is a wonderful thing: People don't waste time on discussing different formatting options and every bit of rust code looks pretty identical.

Why would they need to share ssh keys? Ssh will happily accept dozens of allowed keys.

It gets rid of one more SUID binary. That's always a win for security.

Sudo probably is way more comfortable to use and has way more configurable, too -- that usually does not help to make a tool secure either:-)

When I last checked (and that is a long time ago!) it ran everywhere, but did only sandbox the application on ubuntu -- while the website claimed cross distribution and secure.

That burned all the trust I had into snaps, I have not looked at them again. Flatpaks work great for me, there is no need to switch to a wannabe walled garden which may or may not work as advertised.

“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 a lot on how you define "correct C".

It is harder to write rust code than C code that the compiler will accept. It is IMHO easier to write rust code than to write correct C code, in the sense it only uses well defined constructs defined in the C standard.

The difference is that the rust compiler is much stricter, so you need to know a lot about details in the memory model, etc. to get your code past the compiler. In C you need the same knowledge to debug the program later.

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.

It's just a git repo, so it does not replace a forge. A forge provides a lot of services around the repo and makes the project discoverable for potential users. None of that is covered by this thing.

I frankly see little value wrapping a decentralized version control system into layers of cryptography that hides where the data is actually stored (and how long it is going to be stored). Just mirror the repo a couple of times and you have pretty good protection against the code going offline again and you are done. No cryptography needed, and you get a lot of extras, too.

If you do not like github: Use other forges. Self-host something, go to Codeberg or sourcehut, use something other than git like pijul or fossil, or whatever tickles your fancy. Unfortunately you will miss out on a lot of potential contributors and users there :-(

There is no regulation at this time. There may not be regulation ever. Before there is any regulation we will see nudging into the "right" direction. Suggesting that companies define a memory safety roadmap could be considered as the very first nudge, or maybe not:-)

All I wanted to say is that ignoring the possibility of regulation in such a text seems a bit short-sighted to me.