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.
A Slint fanboy from Berlin.
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.
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.
Why don’t you download the latest release/nightly from github and unpack it somewhere?
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.
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.