I can’t imagine that’s any more free than bitwarden?

The big downside is that, for backwards compatibility, the default must still be unsafe code. Ideally this could be toggled with a compiler flag, rather than having to wrap most code in “safe” blocks (like rust, but backwards).

One potential upside that people don’t seem to be discussing is that the safe subset could also be the place to finally start cutting down the bloat of C++. We could encourage most developers to write exclusively in the safe subset, and aim to make that the “much smaller and cleaner language” trying to get out of C++.

Please somebody correct me if I’m wrong, but I really don’t find the “chip makers don’t have to pay licence fees” a compelling argument that RISC-V is good for the consumer. Theres only a few foundries capable of making CPUs, and the desktop market seems incredibly hard to break into.

I imagine it’s likely that the cost of ISA licencing isn’t what’s holding back competition in the CPU space, but rather its a good old fashioned duopoly combined with a generally high cost of entry.

Of course, more options is better IMO, and the Linux community’s focus on FOSS should make hopping architectures much easier than on Windows or MacOS. But I’d be surprised if we see a laptop/desktop CPU based on RISC-V competing with current options anytime soon.

In my experience it Just Works ™️. I spin up a distro/toolbox, compile some software (e.g. Emacs) then run the executable inside the container, and up pops the GUI window.

If you use distrobox, you can even distrobox-export desktop files, at which point a containerised gui application is practically indistinguishable from one installed on the host system