hunger

Github login does not help much... devs are on github, not on random forgjo instances. That's where they see your project. Github is also where they put their fork of your project when they play with it. They will write comments using github markdown and won't care whether that renders correctly or not in your forge.

And it is where they will report issues and open a PR. It is annoying, but it is how it is. When you ask them to open the PR elsewhere they complain sinde they need to set up an account there and copy ssh key and similar things. You need a very dedicated contributor to go through with all that.... especially if it is just a few lines of drive-by fixes.

I never said that you can not run a project elsewhere, my point is that you will get way more interaction on github.

Try pushing your project to github and compare the interactions you get from both forges.

That unfortunately requires setting up email... I have not bothered doing so on my boxes in a very long time.

The biggest factor to me is developer attention. I had a project on gitlab and pushed a README.md with a link to the gitlab instance into github. I got about 10 times more reactions from github, incl. PRs (where the person had grabbed the code from gitlab and did a PR on github anyway) -- even in this setup. Mirroring a project to github tilts that even further.

Not being present on github means a lot less users and contributors. As long as that stays this way there is no way around github.

I hope federated forges can move some attention away from github, making other forges more visible... but I am not too optimistic :-(

The blocking certain countries is a US legal thing. It effects any forge in the US and probably in more areas close to the US. As soon as a forge gets big enough to show up on the radar of government orge they will need to do similar blocking.

You can not really blame github for that part.

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.