hunger

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.

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.

The quote above covered exactly what you just said: "yet were also more likely to rate their insecure answers as secure compared to those in our control group" at work :-)

That interface is let any random app take screenshots of anything running on the same server without any way for the user to know it happens.

I am so glad that interface is gone, especially when running proprietary apps.

Plugins are a code execution vulnerability by design;-) Especially with binary plugins you can call/access/inspect everything the program itself can. All UI toolkits make heavy use of plugins, so you can not avoid those with almost all UI applications.

There are non-UI applications with similar problems though.

Running anything with network access as root is an extra risk that effects UI and non-UI applications in the same way.

Usig anything as root is a security risk.

Using any UI application as root is a bigger risk. That's because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.

So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.

Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.

Ideally you run the UI as a normal user and then use sudo to run individual commands as root.

I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.

Oh, most companies will pay someone to maintain an internal fork, but hardly any will contribute back. Sometimes that's due to lazyness, sometimes it is the idea that nobody will care for the company internal stuff, but most of the time it is outright forbidden to share internal IP even when that comes in the form of patches to open source code.

In my experience it is safe to just ignore that case and not care about corporate convenience when starting any open source project.