Fedora Atomic Desktops Born Out Of Fedora Silverblue Success

[user1]

Random power outages can mess up anything so that's not really a good excuse to not use something.

Well yeah, of course it can mess up anything, but still, it seems people don't understand why atomic updates can save your OS in such cases. In Fedora Silverblue, since updates are deployed as images, if a power outage strikes the unfinished update will be discarded and you'll be automatically booted into the last working image. It's similar with OpenSUSE Aeon, but instead of images it relies on btrfs snapshots. With non immutable distros on the other hand, a power outage can render your whole OS to an inconsistent state, which is why it'll most likely become unbootable.

And regarding UPS, well realistically most home users don't use it. At least in my country I haven't seen any home user using them.

[pWe00Iri3e7Z9lHOX2Qx]

Theyve built up significant brand recognition already for both of those. You wouldnt just rename EndevourOS as ArchLinux Complete DE Edition or something, so renaming Silverblue at this is counter productive

But they really haven't. Even most Linux nerds have no idea what SilverBlue is. And Kinioite has waaaay less recognition than Silverblue. You know what has a lot more brand recognition for them? "Fedora Workstation". And this effort isn't only about renaming the offerings. Another goal is to remove the need to understand how ostree works. Users shouldn't need to know dnf AND ostree. A good goal and worthwhile endeavor. But they should definitely fix the names for Silverblue and Kinioite, and I say that as someone who frequently plays with Kinioite and Universal Blue.

[Sustained]

Fedora Atomic desktops are better because that describes what they actually are... Atomic desktops. Silverblue is a good name as well because it is easily searchable and easy to remember. The rest of them... not so much. Kionite isn't a good name, but it is not terrible either. I forget whatever name they used for Sway and Budgie about 10 seconds after I see it. As they gain more Atomic desktops the naming problems are only going to get worse. So this is a good move.

As far as the benefit of immutable desktops are...

It really boils down to avoiding configuration drift and having consistent updates as well as read-only root. A bit better security, a bit better resiliency. But mostly just having something that is consistent between upgrades and doesn't drift away from the mainline distro release as the OS ages.

With a conventional Linux distribution like Debian or Arch... A person who installed Debian 3 years ago is going to have a different Debian then somebody that installed it yesterday even if they kept the defaults and didn't modify stuff much. Same thing with Arch or anything else. Having lots of minor and largely otherwise inconsequential differences makes it difficult to support and troubleshoot bugs as well as support users and the installation of applications. Especially third party applications.

This isn't that big of a deal on the desktop as most people are willing to put some time and effort into maintaining them. It is much bigger of a issue in server environments were you may have a team of 3 people managing thousands of installs. You don't have to worry about something that has been running for years drifting far from what you have now. The past approaches to trying to solve this issue involves configuration management systems, but they are bear to maintain and really can't do what is promised (maintain a consistent configuration) without a huge amount of work.

So it is less relevant on the desktop, but it is still nice to have.

The big win for users on the desktop is when immutable OS is combined with container-oriented applications. With this approach the applications are detached from the base OS and users have a lot more freedom on when/how they want things installed.

Traditional Linux distributions have several major usability and compatibility issues caused the dependencies used for the base OS and desktop environment are heavily intertwined with the applications. This isn't terrible if every application you want to use and the versions you want to use is provided by the distribution's native packaging. However trying to have each distribution package the entire planet's worth of Linux software is a rapidly loosing battle. It is hugely labor intensive and as of now only a fraction of available software is there for users.

So there are lots of cases of Linux users trying to install third party software and running into compatibility issues. Some applications have very specific versioning requirements for their dependencies. Installing specific versions of, say, python system-wide is likely to break some OS tools and desktop features. So you have to resort to setting up virtual environments and that itself has a number of usability issues. And that is just python. There is very long lists of problems like that.

For good OS design you want layers... Like in networking. In networking you have the physical layer, then layer 2 networking, then transport, and then applications. Each layer is distinct and well defined with interfaces that isolation the details of each layer from one another. Your web server doesn't need to know how to talk 802.11n in order to reach a website. The transport layer doesn't care if it's Eithernet or cable networking, or whatever. It should be the same for layers in a OS. Traditional Linux distributions have a very strong layer between the kernel and the application space... very well defined, very formally maintained. It frees up the kernel devs to do whatever they want without breaking the application space. But avoid that everything is just one gigantic mush. It isn't a spiderweb of dependencies it is a hairball the size of a small house worth of apis and IPCs and libraries... It is just not good design.

While it is a bit of a disaster in terms of disk space usage, the use of containers for applications decouples the applications from the OS.

With Fedora Silverblue you have the option of using podman for services, which can tightly couple with systemd if you want. You can use toolbox (I prefer distrobox), which runs on top of podman, to provide development and command line environments that integrate nicely into your desktop. You can use flatpak for normal applications. It is easy nowadays to run podman with a init in it to create container OSes like you see with LXC that is not tied to your base OS or sharing anything with your desktop environment.

I really like the combination of Fedora Silverblue with Arch Linux distrobox, for example.

With this approach I can go ahead and run "pip install" system-wide if I feel like it. I can do "make install" on whatever random software I happen to find off the internet. And none of it has any danger of breaking by web browser, killing some menu entries, or causing my system to not boot right.

All in all it is a big improvement.

[DumbFsck]

The problem is also how old snapshots don't get automatically removed even if you already have dozens of snapshots at a time. Someone said to me that they should get removed automatically, but it hasn't happened in my case.

Yes that sounds like a bug. If that didn't work for me I think I'd have done similar to what you did and jumped ship (if I weren't already running Tumbleweed on another machine).


Still, if this came up when I was provisioning some relative of mine for whom I'm tech support, I'd bite the bullet. "storage is cheap" etc

[pWe00Iri3e7Z9lHOX2Qx]

It is utterly baffling that SuSE's update system isn't the default for basically everything everywhere. No in-flight packages, no lengthy rollbacks if something broke, it's always in a known good state, or a quick reboot away. I hate having a windows work laptop that has to rollback updates every month for 1-2 hours, and having infrastructure for restoring server system images that one has to submit requests to and wait for hours. Make a subvolume, commit changes, reboot. If something went bad, you're out a minute of your time.

Yeah, I really don't get it. Especially for the "Easy Arch" distros like Manjaro or Endeavour OS, it's mind boggling that the default setup isn't btrfs + snapper + grub2-snapper. I think Garuda does that, but almost nobody uses that one.

[Estranged1906]

Hey, as long as Debian comes up with an apt-ostree so I'm not being yanked along by Fedora's eagerness to drop support for aging hardware and they hammer out a solution to Flatpak's design being so hostile to end-user patching of installed files (eg. a post-update hook), I'm all for it.

One of the big reasons I use an LTS+Flatpak combo is that I want to be easily and reliably able to rollback if an update introduces a bug (Flatpak) and, for the things I don't do that with, I want them to be "pinned at a version where I know what the bugs are and I'm used to working around them".

Having a non-containerized alternative to Flatpak without Snap's architectural misdesigns would mean I wouldn't be stuck on stale versions of things like Dolphin and Konsole with known bugs for years at a time (eg. the fix for "ejecting an optical drive can crash Dolphin" didn't make it into Kubuntu 22.04 LTS) because I consider it more acceptable than having to deal with updates I can't trivially roll back if I don't like them.

Sounds like you should use OpenSUSE Tumbleweed. It's rolling but with built-in snapshots & rollbacks. And of course it supports Flatpaks too.

[ssokolow]

Sounds like you should use OpenSUSE Tumbleweed. It's rolling but with built-in snapshots & rollbacks. And of course it supports Flatpaks too.

From what other people said, I get the impression they achieve snapshots and rollbacks via btrfs. Hard pass. I'll stick to my mix of ext4 and zfs until I feel I can trust btrfs.

(Yes, I'm aware of the ZFS send + native encryption bug. I don't use either of those features, let alone in combination... but I feel more able to keep up on the DOs and DON'Ts of ZFS than of btrfs.)