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.

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.

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

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.

Governments triggered this entire discussion with their papers and plans to strengthen cyber defenses. The article states that some experts ask for our industry to be more regulated in this regard.

I am surprised that possible regulations are not even listed as a factor that in the decission to stay with C++ or move to something else.

Sure, COBOL is still around after decades, but nobody ever tried to pressure banks into replaceing that technology AFAICT.

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

To be fair: snaps can work for all kinds of things all over the stack from the kernel to individual applications, while flatpak just does applications. Canonical is building a lot around those abilities to handle lower level things, so I guess it makes sense for them.

IMHO flatpak does the applications better and more reliably and those are what I personally care for, so I personally stay away from snaps.

I am looking forward to follow up articles like “woodworking as a career isent right for me”, “bookkeeping as a career isent right for me” and the really enlightening “any job sucks when your boss is shit”.

One more reason to run the steam flatpak: At least I can sandbox away things steam does not need to concern itself with.

The point of using the TPM is that it does not unlock the drive unless it has a certain set of software is loaded in a certain sequence on the machine with that specific TPM chip.

So if somebody breaks grub and makes it load a shell, then that results in different software loaded (or at least loaded in a different sequence) and will prevent the TPM to unlock the system. The same is true if somebody boots from a rescue disk (different software loaded) or when you try to unlock the disk in an unexpected phase of the boot process (same software but different sequence of things loaded, e.g. after boot up to send the key to some server on thr network. The key is locked to one TPM, so removing the drive and booting it in a different machine also does not work.

The TPM-locked disk is pretty secure, even more so than that USB idea of yours – if the system you boot into is secure. It basically stops any attacker from bringing extra tools to help them in their attack. All they have available is what your system has installed. Do not use auto-login or run some root shell in some console somewhere…

But if the key is fully wrench-safe inside the TPM. You do not know it, you can not get convinced to give it up – even after repeated wrench use.

Of course the recovery key that typically goes with it and you logging password is not wrench safe, so that does not protect the system fully, while getting you a matching set of broken kneecaps.

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.

Add a /var partition, boot from some live system, copy over the data, delete it in the root partition after making sure it was copied ok and add the new filesystem to fstab. /var is the only place we that will grow significantly(especially when younuse flatpaks).

Last time I tried it was an apt install followed by a reboot. If your distribution claims to support several inits and it is harder than that: Your distribution did a poor job.