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.

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.

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.

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.

Why don’t you download the latest release/nightly from github and unpack it somewhere?

Yeap, -O3 is mostly voodoo. Berger has some measurements.

Spoiler: He found your username has a bigger effect on performance than most compiler flags:-)

Ansible must examine the state of a system, detect that it is not in the desired state and then modify the current state to get it to the desired state. That is inheritently more complex than building a immutable system that is in the desired state by construction and can not get out of the desired state.

It’s fine as ,one as you use other people’s rules for ansible and just configure those, but it gets tricky fast when you start to write your own. Reliably discovering the state of a running system is surprisingly tricky.

It is all about whos freedom you care for: GPL protects the freedom of end users, MIT and other permissive licenses focus on the freedoms of developers instead.

GPL defines freedoms end users of software have. It has to limit the freedoms of developers between the GPL project and the end user so that those developers can not strip out any of the freedoms the GPL wants end users to have. The hope is to build a better society by enabling everybody to understand the machines they own.

MIT and other permissive license care for the freedoms of people using the project directly, granting freedoms to those users only. Those people are free to forward the same rights to their own users or to remove them as they see fit. Thatbis way simpler for developers to work with: Basically do whatever you want.

Guess which option is more popular with developers and the companies that employ many of those developers?