Immutable distros are the future for everything. We just need to wait a for the people most heavily invested into the status quo to retire.

Any user can delete important OS files by turning their computer off while an upgrade is running in almost all traditional distros:-) Sure, you can disable updates, but that is not an option either.

First off, you do not need to know most of that stuff. Tooling around container-based development is really nice nowadays. It just works almost all the time – and way more often than in mutable setups.

As a beginner you can not really transfer docs from one distribution to another, so you look for docs on your distribution and ask in the official support channels. Those of bazzite are pretty responsive and will be able to help. The community is able to help way better than in a traditional system where every installation is almost but not exactly the same.

Nothing is as bad as accidentally removing some important OS files and not knowing how to restore them. That will just not happen in an immutable setup.

I have installed immutable distros on lots of computers and the users usually are happier than they were on traditional linux: Nothing breaks anymore, the setup is way more solid. Its great for me, too, as I need to support them less often.

Seriously, you should give this a try: Immutable OSes are a huge step forward. Takes a few days to get used to, but I am pretty sure you will not want to go back afterwards.

The OP has no experience with either immutable nor mutable linux. So let him go with the rubust version already installed over recommending some package-based, old-school distro, just because you are more familiar with those.

OP will need to learn things either way, let him learn the future proof stuff, not the outdated ways.

Actual developer and 30+ years Linux expert.

Don’t use anything but immutable distros for development work. Hands down.

Just develop in containers and have one container per project. Doing anything else will lead to broken projects as you can not properly control dependencies per project otherwise.

It is not harder to work in a container than on the real system.

It is unfortunately developing very slowly and it is impossible to interact with git repos… which nowadays is basically every repo:-(

Take a look at jj. It is not as ambitious, but develops faster and you can use it with any git repository out there (as long as it does not need git submodules that is).

As a user I definitely want flatpaks and use them over distribution packages whereever possible. First I can sandbox the flatpak, but not the native package. Why would my browser need to be able to read my ssh keys?

Secondly I just have seen too many distro packagers sabotaging packages in the most braindead ways possible. Debian removing almost all the random data during key generation because some static analysis tool did not like the code. To this day there are servers using one of the 32k keys debian could produce during that time (they are of course all brute forced by now). Fedora removing Codecs from a video encoder, dependencies that upstream knows are broken and listsmas such in its documentation being used anyway. Random patches being applied, or versions years out of date getting shipped…

If you find a reliable way to allow for people to use data without being able to copy it: Patent it right away, the entertainment industry will be paying big time for it.

Same for erasing the laptop: You can only erase something as long as you can talk to the machine in some way to instruct it to clean itself up. The guy with the machine in hand can just turn off wifi to stop it from receiving the message…

“They” did not go anywhere yet. This is a proposal, nothing more. It will take serious discussions over years to get this into C++.

Prominent figures already said they prefer safety profiles as a less intrusive and more C++ approach at conferences It will be fun to watch this and the other safety proposals going forward.

Well, its a brand new standard library. A fresh start.

Read the proposal: Lifetimes annotations, the rust standard library (incl. basic types like Vec, ARc, …), first class tuples, pattern matching, destructive moves, unsafe, it is all in there.

The proposal is really to bolt on Rust to the side of C++, with all the compatibility problems that brings by necessity.

Not only that: It protects your data. The Unix security model is unfortunately stuck in the 1970s: It protects users from each other. That is a wonderful property, but in todays world you also need to protect the users from the applications they are running: Anything running as your user has access to all your data. And on most computer systems the interesting data is the one the users out there: Cryptogrqphic keys, login information, financial information, … . Typically users are much more upset to loose their data than about some virus infecting the OS files, those are trivial to fix.

Running anything as anlther user stops that application from having access to most of your data.

The same happens with any of the new immutable distributions. It’s just less effort as you do not need to do the nix configuration dance anymore.

Any of the many immutable distros (vanilla os, fedora silverblue, bluefin, aeon, endless os, pure os, …) will all obviously work.

Most of your customizations will live in your home directory anyway, so the details of the host OS do not matter too much. As long as it comes with the UI you like, you will be mostly fine. And yku said you like gnome, that installs many apps from flathub anyway and they work just fine from there.

For development work you just set up a distrobox/toolbox container and are ready to go with everything you need. I much prefer that over working on the “real system” as I can have different environments for different projects and do not have to polute my system with all kinds of dependencies that are useless to the functionality of my system.

NixOS is ofmcourse also an option and is quasi-immutable, but it is also much more complicated to manage.

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.

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.