What are the pros and cons for desktops ? EDIT : Thanks all. I’ll try Silverblue, bazzite and more.
Been using nixos for a couple months now. It’s nice and I really enjoy having all my configuration in one place and able to be version controlled. The down side being installing and configuring things take a bit more time to read how nix does it. I have it on a laptop that I’ve been playing with and removed it and put rocky for something else but I am 100% confident I can go right back to the way i had it.
So far the cons I’m seeing is installing vscode plugins are a little annoying and setting up to do python development on existing projects not very easy.
Python development shouldn’t be that hard I think. You can just drop a
shell.nix
that imports yourpyproject.toml
and then you can runnix develop
and have all your dependencies installed seamlessly with poetry2nix.I’m using neovim so I can’t really help you with vscode, sorry.
Have you tried Erasing your darlings with NixOS?
nix flake init -t templates#python sets up a nice environment using poetry.
I use Fedora Silverblue and I love that my system is exactly the default out of the box distro, with just a couple diffs that are tracked in rom-ostree.
I’ve had frustrations in the past where I install packages to try something, then remove them and forever have something hanging around. Eventually one of those things inevitably breaks an upgrade or dependency resolve.
Installing apps as flatpacks is fine. I don’t love the duplication of system files, but do love that the apps aren’t tied to my distro version.
I also like that all updates happen silently in the background and I just reboot once a week or so. Never think about it.
I feel like the Fedora Atomic distros are great for people who mostly just want a working system and not to tinker endlessly. You can tinker, but it isn’t the default and it’s basically impossible to get into a bad state permanently.
How is gaming on it,? I recently haf an issue with steam flatpak and needed to switch it for deb verion.
I have been trying to understand this for a minute and I can’t seem to understand why you would use it on a personal workstation.
Like it makes sense for servers, and for deploying accross multiple systems in a corporate or public setting, but beyond that it seems like it is just adding unnecessary steps if you try to use it on your personal rig.
Maybe I’ll need to just give in and try it for a week to a month to see the appeal
It’s much harder to break if you’re prone to tinker. And there’s no configuration drift that naturally accumulates over time as you tweak a system, so it always runs like a fresh new installation.
I have learned much more on immutable OS because I’m no longer afraid to tinker around and try new things. I play in distrobox and can completely nuke the container without affecting my whole system.
honestly i feel exactly the opposite, I don’t think it’s really necessary for servers as tools like ansible are already well established in that space. Plus most servers are VMs these days which can be snapshotted easily. Also, lot of these “immutable distros” require a reboot to apply changes which is non ideal in a server, but a non issue for desktop as you can shut it down when you go to sleep.
I run fedora atomic on my desktop and laptop because i never have to worry about my system getting into a broken state, I can always roll back or even spot the problem and fix it before i reboot to apply the change. I know a lot of people say you can accomplish the same thing with btrfs snapshots, but that requires extra thought and effort on my part, where fedora atomic it happens automatically with every update.
Fascinating,
Again I haven’t actually tried it. I went to install fedora kinoite(?) On an extra laptop I have to try it out but apparently the memory isn’t seated correctly, so I will have to fix that real quick.
I also watched The Linux Experiment’s video on it and cleared up some confusion
With immutable distros you can try a silverblue and switch to kinoite with a reboot on an already running system and it will just work and run your flatpaks. The base image it runs does not get corrupted. You cannot make changes (easily) to the base to corrupt it. Your apps and files are just an overlay or mounts on top of the system. Your machine lights on fire, if you have a network backup, it will fire up on any hardware and be the same. It’s much cleaner and allows for easy os switching.
You could theoretically make windows work and be switchable.
Help me understand what I don’t then. Why would anyone wise ever trust someone they don’t know running closed source software of any kind on “their” computer?
I don’t trust that asshole. I know him enough to not trust him let alone make my computer follow his directions. Why use anything but FOSS?
All down votes but no answer. Suckers.
Whom you talking about in terms of “don’t trust someone” ? Also where is the connection between closed source and immutable distros?!
What’s closed source about an immutable distro? And who are you referring to?
I think you posted this in the wrong place
I can’t seem to understand why you would use it on a personal workstation.
Re that specifically.
Who is “he”? Who is “that asshole”?
Nobody is talking about non-FOSS software, so it’s kinda weird you brought it up. In the “old man yells at clouds” way.
I think I just misunderstood your post.
I’m pretty much immutable across the board on all of my servers and workstations (laptop included). Most my servers are openSUSE Leap Micro and MicroOS. Run MicroOS on the desktop side as well.
Honestly …haven’t had any issues and the maintenance of it is fairly hands off. Few of mine are k8s nodes so that combined with the reboot mgr + transactional-update has been awesome. I spend less time maintaining my homelabs / desktops and eases my focus in just getting work done.
I’ve only had to roll back a couple of times (mainly self-inflicted), so it’s nice having that capability. A lot of this though can be accomplished in a non-immutable world as well.
A note on “MicroOS on the desktop”: The Gnome variant is called OpenSUSE Aeon and the KDE variant OpenSUSE Kalpa. MicroOS branding is used only for server use due the confusing names. Quoting from https://news.opensuse.org/2023/05/31/microos-desktop-has-new-name/
Simply put? The microOS product namespace is getting crowded. And this is leading to a certain amount of confusion, and causing some support issues. At present, amongst the microOS “family” offered are: Server Products openSUSE MicroOS openSUSE Leap Micro SUSE Linux Enterprise Micro Desktop Products openSUSE MicroOS Desktop GNOME openSUSE MicroOS Desktop Plasma And I think we can all agree, when somebody joins a support forum of some sort, be it Matrix/Telegram/forums/IRC/etc, and says “I’m running microOS and I have a problem” then the inevitable question of “Which MicroOS?” has to be asked. And by their very nature, the Desktop offerings are quite different beasts, than the server offerings, and have quite different support needs. And typing out “openSUSE MicroOS Desktop GNOME” is just too darn long, every time you want to tell somebody what’s running on your machine.
I’m using Bluefin right now, but I was using bazzite before that. I’d say the biggest benefit is that it’s hard to break permanently. Sure, you can still mess up your home directory pretty bad, but system level stuff is nice and stable. The biggest problem is compatability and software instalation. Flatpak and toolbox/distrobox are nowhere near as good as the documentation makes them out to be. I’d suggest making sure you select a distribution with Nix pre-installed so it’s still possible to install stuff.
(Edit: There is apparently a workaround for the following issue, though I have not tried if yet.) Just be aware that some things are just plain impossible with atomic distos, and you can’t change it. Like the login screen. You can’t change that at all, whether it’s the background or the default zoom level. It’s part of the system packages and can’t be fixed.
The part about changing the login screen seems to be not entirely true. There is also this tool that claims to be able to generate rpm from sddm themes that you then can layer onto your system image. Take this with a grain of salt though, as I haven’t tried either method because I honestly don’t care how my login screen looks.
Thanks for the information! I’ll look into it!
Like the login screen. You can’t change that at all, whether it’s the background or the default zoom level, it’s part of the system packages and can’t be fixed.
in /etc/fstab (ublue-kinoite, ymmv):
# enable sddm write accesss and therefore good themes /var/sddm /usr/share/sddm none rbind 0 0
I’ve been trying Bazzite out for a few days, and it’s really neat. Coming from a standard distro, I like the idea that I can install pretty much anything with the combo of Flatpak, AppImages, and Distrobox. I was unable to install DaVinci Resolve on the Fedora Distrobox however, and the lack of Snaps - although I much prefer Flatpaks or AppImages - kinda sucks because it would be nice to have the Snap for Flutter…
I don’t like saying it but: Snap within a distrobox?
Haven’t tried it personally, but this might work: https://github.com/zelikos/davincibox
Basically, instead of creating a fedora distrobox and installing davinci resolve in there, this is a pre built image that has all the dependencies and such ready to go.
I’d just like to add that after using ubuntu (as a newbie), then arch for several years I recently switched to bazzite (atomic fedora with steam/gaming focus) on my daily driver.
It is SO NICE to have everything just work. And steam games that I never got working on other distros just run out of the box. Everything just works, and it doesn’t feel bloated at all like ubuntu.
Bazzite right now. I only use my PC for gaming and get limited play time, so I usually wake it up and straight into a game. Bazzite has worked extremely well for me to achieve that with virtually no maintenance so far (updates are automated).
I think the only thing holding me back from going for immutable Linux is desktop virtualisation. VirtualBox and VMware can’t be installed on an immutable distro AFAIK, and libvirt isn’t all there for Windows guests.
what issues have you had with libvirt and windows? Once you get the windows drivers installed, it works pretty much the same as other solutions. only thing thats still a pain in the ass still is shared folders.
Mainly GPU acceleration without passthrough from the last time I tested (Modern Windows is slow without it and passthrough might be an issue on immutable distros), but shared folders is something I use quite a bit on VMware. I remember trying virtiofs when I used passthrough, and it was suffering.
My system runs an immutable/stateless Linux and I also use virtualisation.
I’m running cleanroom: https://github.com/cleanroom-team/cleanroom
Depends on your criteria of immutable, but as far as I know you could use both on NixOS.
Hmm… I’m gonna keep tabs on that one then. Good call.
If you’re using gnome/kde, I see no reason not to run immutable, the advantages of not being immutable are that you can piece together your system, if you’re running i3/sway/whatever, being able to choose your panel, your launcher, etc actually has value.
The advantages of immutable are that you’ll never end up with a broken system, you can easily roll back to a not broken one if something does break, and the system is separate from your apps.
I was able to break fedora silverblue by messing file permissions in the home directory. Toolbx then stopped working, without which the distro is unusable.
You can also make chaneges in /etc and similarly ruin your system.
Just saying they aren’t quite as “unbreakable” as advertised.
all changes in etc are snapshotted with each update so you could just roll back to your previous version and it would fix it.
I assume you meant you messed up permissions in your home directory, and yes that is pretty much the only place you can permanently mess something up with silverblue.
Oh I didn’t know that, that’s good to know! thanks
Im sure I could break fedora silverblue too, just me use some gasoline and a match
Better resources usage when running all the apps as Flatpaks. Once you hit the close button, the zygote is killed, and you’re sure that web browser doesn’t run anything stupid in the background anymore.
Wait really? I had no idea flatpaks ran better on immutable systems
No, I think they meant that you get better resource usage when you install an app as a Flatpak instead of a system package. You get the same benefit in a traditional distro too, if you use Flatpaks, it’s just that immutable distros kind of force you to use them.
In order to avoid headaches I wouldn’t use one today. Instead I’d use a stable OS like Debian Stable or Ubuntu LTS, and use an immutable systems to get applications that are too old in the main repos. For example via Flatpak, Snap and Docker. Stable OSes eliminate most of the non-user caused breakage. The remainder is learning to not break it yourself, which isn’t horribly difficult. Once Debian or Ubuntu release an immutable desktop OS, I’d try it.
Debian stable broke for everyone literally a week ago. :/
If you want to tinker with the system, if you want to install multiple DEs, if you want to test and change things on your own, you may not like the rigidity of atomic systems.
If you don’t want to tinker with your system and you always want to have a working system, go for it.
In the future it will become easier to tinker with the system (I hope that it doesn’t take the path of android). I hope that more happens within containers and that it mature even more. Maybe the de within a distrobox? That would be awesome but I don’t no the downside of it.
Right now you are still an early adopter. It sounds like the future and for many it will be, but who know what’s next. Especially companies have an interest in fedora’s atomic distros with ostree.
Atomic desktops make all of that way easier though
How?
Because all changes are transactional so you can easily revert to a previous system state if you break anything
With fedora atomic, lets say i wanted to try out kde desktop for a while. i would first pin my current build so i can roll back to it if i dont end liking kde with
$ sudo ostree admin pin 0
Then i would rebase to the kde branch with
$ rpm-ostree rebase fedora:fedora/39/x86_64/kinoite
Then just reboot. That’s literally it and i would have a kde system with all my layered packages and i could roll back to my old system at anytime.
I’ve been using microos exactly because I like to tinker. Just the other day I installed plasma 6 to play around with the HDR implementation, then decided that it wasn’t worth it and rolled everything back. Worse case scenario I might have needed to reset kde configs in my home directory, but even that want necessary.
I tried Silverblue for about an hour. Got pretty sick of “Changes queued for next boot. Run ‘systemctl reboot’ to start a reboot” real quick. I don’t see how this is an improvement.
You should be installing software with stuff like flatpak, toolbox or distrobox. If you treat the immutable image as a mutable one there really isn’t an improvement except for less of a chance of instability of updating/changing software that’s running in memory already.
Git? Vim? Fdupes? A dozen other cli applications I install?
Yeah those don’t go on your host they go in containers.
So I use non-immutable distros in containers to make up for the failings of the immutable host OS?
You use containers for your tooling, you purposely don’t touch the host operating system, that’s the entire point.
I can do that in Ubuntu… I’ll admit I simply don’t see the point. Immutable distro users seem paranoid about “some random update messing up their base OS” for some reason and I guess this suits their purpose. I just don’t see that as a problem.
Most people aren’t system administrators and they end up with broken computers for the most basic tasks. It’s one of the major reasons why people hate using Linux desktops.
And even if you’re an experienced sysadmin you can’t account for the entropy that accumulates on traditional OSes. 18.04 -> 20.04 -> 22.04 doesn’t end up being the same as a 22.04 clean install. This is a huge problem, especially for people who don’t know how to manage linux systems. And the people who do manage systems at scale don’t want that behavior either.
I go over this in this video: https://www.youtube.com/watch?v=hn5xNLH-5eA
But day to day I’m in an ubuntu container and using “normal” package management, I just don’t do it on the host.
Are you saying you can’t use toolbox or distrobox for that?
So the solution to my problem is to create a container for a non-immutable distro?
Yes, though keep in mind containers aren’t like VMs so the hardware isn’t virtualized or anything. The root system and everything in it is still immutable as well. In usage, it doesn’t matter for the container but it isn’t changing the root since what is writable to the container is outside of the root.
Using containers this way is the way Silverblue was intended to be used for by the user and pretty much any other immutable distro of note.
Yeah - I’m quite familiar with containers. I just don’t see the value they’re adding here. Maybe for experimental things or “project-specific” stuff. but otherwise don’t you just end up maintaining a container same as you would your “host OS” in a non-immutable distro?
Your immutable OS stays stable. For example, running a sudo pacman -Syu with a bunch of stuff from AUR in your Arch container for example will not bring down your OS or otherwise make it unstable. The immutable image you first install has been tested and it is the same image as the testers – same with the upgrades and updates, so long as you don’t overlap the image with rpm-ostree in this case.
Immutability keeps your OS stable and if something does happen to go wrong, you just roll it back.
If that isn’t something you need/want then that’s not something you need/want.
You know you can apply live, I do it for when pretty much anything except a kernel update is queued, works fine even if it warns you when you do it
I do not know that. I’m still failing to see the point of this overly-complicated setup though.
apt install git
“just works.”A reproducible system, delivered in a working state where anything you add is overlayed on top without effecting that system. Branches you can move between Fedora numbered versions as well as going Kinoite to Silverblue, while keeping the same stuff you layered on it.
It’s truly git for your OS
I am using Fedora Kinoite and it has been incredibly stable. I like that I can always rollback to a previous state if an update breaks something. This was a huge issue for me a couple of years ago and I stopped using Linux for quite some time because of that. I haven’t had to roll back anything yet but without that feature I wouldn’t even consider making a Linux distro my daily driver. Installing software is for the most part pretty easy if you are happy using flatpak applications and toolbox. I like that all the packages that I need for my work or for messing around stay in the toolbox container and won’t affect the stability of my system. The only thing I find a bit annoying is that you have to reboot to apply updates. For me, going back to a ‘mutable’ distro is out of the question.