Fedora Atomic Desktops
fedoramagazine.org
fedoramagazine.org
There's a community offshoot called Universal Blue (after the original Atomic image Silverblue). It uses the standards set for containerization to make userland configuration reproducible as well. There's a manifest (Containerfile) that enumerates all the modifications, which means an upgrade is bump the version of the base image and replay all the modifications from the manifest. It's also meant to limit `sudo` usage, so you're not in the habit of giving root to random software you downloaded from the internet.
Their most famous image is Bazzite, which will replicate the SteamOS experience on generic hardware. They also have Bluefin for software developers.
I haven't used it myself, but I find the concept fascinating. I expect Jorge and Kyle from that project will find their way to these comments.
Is the containerfile syntax and reproducibility as good as configuration.nix / NixOS?
I love NixOS but it’s a very acquired taste, to the point where even I occasionally wish I was running something bog-standard. If this is similar to NixOS but closer to regular Linux, that’d be nice to recommend to friends.
I'm currently setting up a Bazzite machine by using a GitHub actions to build every day an image from Bazzite's image and adding/removing packages and files on top. I have the DE, login manager and all its customizations in the image and for the CLI utilities and thing like that I use home manager.
I like this setup because you just need to know Linux to customize the image, Containerfile's are just series of commands or file copies from the repo, compared to nix it's easier.
AS incomprehensible && \
as nix can be && \
i would take it && \
any day over && \
configuring a desktop OS && \
with the horrible && \
Dockerfile syntaxI might hit limits soon as I rice my neovim install.
In general Project Bluefin is newer, but seems to be trying to get into gaming too.
Likewise, Bazzite is considering developer images also. So I might switch to those.
But it's so easy to switch. I currently use Bazzite + Nix + HomeManager + Flatpaks and it has been fantastic. I only layer Tailscale and a few minor things that need be system level to operate right.
"the fragility that can happen when the default way to use software in Linux is `sudo apt-get install`"
And as a long-time Fedora user, I don't think I've seen such conflicts with the moral equivalent yum/dnf command. But, I am somewhat rigid about not adding third party repos or RPMs to my systems. The only two exceptions I've come to accept are repos from rpmfusion.org and postgresql.org.
While I have certainly seen some bugs in Fedora over the decades, I don't see how some "atomic" solution helps here unless it means reorganizing the community QA resources to test some "minor releases" which batch together a set of package updates, versus trying to support continuous integration where each package can update individually. That would actually worry me though, as my own career experiences cause me to prefer continuous-integration approaches like the traditional Fedora distribution.
This is the reason why packages seem so stable, you're deliberately staying within a well-tested ecosystem.
Fedora release upgrades probably go well for you also!
Packages themselves are a perfectly fine distribution method [under the same guidance].
Once you start mixing packaging spec guidelines; packages of varying quality, you end up wanting compartmentalization like containers/bubblewrap
Off the cuff example: Fedora makes heavy use of macros in their RPM specs. Most third party packages don't.
What fragility is that?
Is it something outlined in https://wiki.debian.org/DontBreakDebian ?
Yes, indeed it is
There is a use case for immutable distributions, just as there is one for those distributions which are not immutable.
It is dishonest to attribute fragility as a basic flaw in apt, when system fragility is a consequence of ignorance.
People gotta install from “random repositories” because shit they need is not in official repos, further showcasing the shortcomings of the entire setup and its reliance on maintainers. This derogatory statement only works against your argument, rather than supporting it.
But, there was definitely pains with this kind of desktop when I tried it last time. Regular old software I want to install via dnf is painful to install - you have to layer it on top of the base image, and then that makes it "nonstandard" basically from then on. I know they push you toward flatpaks, but the vast majority of apps I use don't have it (or I don't prefer using the Flatpak version).
Can anyone give a more recent perspective? It's been about two years - I probably used Fedora Atomic 35/36.
I then add JetPack's devbox which is another nix porcelain and use it with direnv to install custom packages for each of my projects.
And I have a few distrobox's (toolbox on generic Silverblue) to do things like build Debian packages.
Also Bazzite has an issue open to make `-dx` images.
It seems both are trying to do it all with a different main focus. Bazzite is Gaming but can do other stuff just as well. Bluefin is Dev but can do others.
I personally find Bazzite more diverse and capable.
I had a problem with some Flatpak applications (like Steam and Discord) and brew because brew puts its folder in the $PATH before the default ones (/usr/bin ...) and those Flatpak applications tried to use SSL keys from brew instead of the system ones. I just changed the order of the $PATH to make brew bin path to be after ther system ones.
For VSCode I'm not using the Flatpak I'm using the tarball one I just extract in ~/applications and symlink the code binary in the ~/.local/bin. It's working well, I don't have problem with VSCode not executing LSPs and lint things. The only problem is VSCode from tarball cannot updates itself, so I need to download the newer version and extract to ~/applications. There is this VSCode CLI version (https://code.visualstudio.com/docs/?dv=linux64cli) but I was not able to make it use the wayland backend.
Deleted older versions? That sounds severe. I hope you filed a bug report if there wasn't one already.
Did you change your installonly_limit?
The largest pain points for me:
- Any kernel modules. I know Ublue has images but I wish Red Hat would just have an official solution that doesn’t require hacky RPMs and such.
- Kernel cmdline args or any initramfs changes: can’t package in image and need to be applied manually. Maybe it’s possible to build a custom initramfs to distribute?
- Secure boot and enrolling moks is very annoying. My current workstation just uses sbctl to sign a UKI against custom keys and everything “just works”. This is part of why kernel modules are a pain in Silverblue too.
If you don’t care about kernel modules with secure boot it’s quite nice though. Practically zero maintenance.
I'm using systemd nspawn with my host root as a lowerdir overlay. In this container I install some packages not present on the host. The overlay upperdir now includes the new packages and the new package database. I upgrade my host, and now the nspawn package database is wildly out of date because overlay doesn't track line-level file changes.
OverlayFS is really handy but it causes a ton of churn from rebuilding everything.
It’s a lot closer to the right way to manage this stuff, for desktop systems, than traditional Linux package management approaches. That approach is painful to go back to, after getting used to this. I’ll have to give this a try next time I poke my head into Linux-land.
Keeping Silverblue makes sense to me with that in mind. I feel like Fedora Kinoite should be renamed though. The one "halo" distro can use a distinct name but everything else should follow the new pattern IMO.
Beyond the naming change, I'm really excited about those projects. I strongly belive that atomicity is the way to go and believe that eventually many distributions will evolve in that direction. Right now I think the tradeoffs are already worth it, but there may be a ways to go before I'd recommend it as the default for new users. (Even if they might in particular profit from easy error recovery.)
EDIT: I want to add that the easy error recoverability that atomicity provides isn't just important for errors upstream that break one of your upgrades, it also enables much more experimentation. I have learned a lot more Linux systems because I was able to fearlessly tinker with many integral parts that I would never have touched in a traditional system for fear of having to reinstall. After all, if I broke it, all I had to to was to reboot to unbreak it!
I’ve seen people say that immutable is the future of Linux, can someone explain that if they can?
Does that mean one day all versions of Fedora will be immutable? Is it a security benefit?
Am I right in saying that kind of development environment would be hard to use and maintain in Silverblue?
I started using Silverblue in October 2022 and now I've been using Sericea for the past 2 months.
Long story short, immutable is the future of Linux.
Or indeed, the past. Happy nixos user since ~2016 here.
Nix ultimately made me feel like I was running Gentoo. Excellent build system, but I could not invest the time in learning ebuilds, and I could not invest the time in using Nix's language to manage its packages. It was just a huge time sink and baggage to maintain.
rpm-ostree is lowering the barrier to entry greatly to produce layered [open container] images that we can rebase off of. That is the future among all this atomic stuff. It would be entirely possible to /someday/ build a system with the nix toolset, then commit the image through rpm-ostree, and have others rebase from it. Best of both.
In the future, with immutable systems, it probably also means being able to have those very robust update systems in place like Chromebooks where you update and switch to partition B with the new image, while having the fallback on partition A. It would also probably make it easier to verify and sign these images for secure boot purposes so then enabling secure boot on Linux becomes easier/convenient, and the secure default.
I still think the Nix language is yet another language I don't see the value in. I'm not learning this, or becoming comfortable in this language, or convincing myself it's a comfortable language to use ...just to maintain my 2-3 laptops when I don't use Nix anywhere else.
Time sink. But a very solid system.
PS: I want them to layer everything on Fedora CoreOS. Make CoreOS the secure thin base, then create all these atomic "Spins" as a derivation of CoreOS.
That said, I could have gotten away with significantly less and I'm really not sure what you're referring to with having to remake your Flake. I'm not aware that the output schema changed over the last years. Could you provide an example of what caused you to rewrite your configuration?
I'm not doubting your experience, the documentation situation is not great and I could absolutely see someone getting stuck in a situation where they felt they needed to start over. I'd just like to know what the community could do to avoid these pitfalls.
Their website contains plenty of examples to copy/paste and since the distro is already prett old, chatgpt can easily help too.
Ok so perhaps my config isn't the prettiest but who cares. It works and it's a record of what my system is.
I'm happy in the sense that its simple enough that I can install programs and do all the other usual desktop stuff with minimal knowledge. But I'm unhappy in the sense that when I started with nixos I wanted to replace docker and docker-compose. I still haven't accomplished that.
But all-in-all I'm very happy with Nixos for desktop use. No crashes, no bugs. Its the reason I was able to permanently drop Windows.
Granted, I'm not running Nixos on my main laptop, because I have had a hell of a time getting me 2020 Macbook to get Linux running stably, but I do use Nix as my sole package manager within MacOS, and I do run NixOS on my server and use Flakes heavily there.
And it certainly is a great feeling, but I'm not yet sure it's really "worth it". Of course the effect is great, but it was also an enormous amount of work to get there.
NixOS has some good ideas, but also some seemingly boneheaded or impractical ones.
Consider modifying NixOS to remove the requirement that the long hex id in the name of a package in /nix/store/ is a cryptographic hash of (among other things) the hashes of every package the package depends on (thereby eliminating the need to upgrade every package on the system every time the libc packages is updated). I am pretty sure you can do that while retaining the property that it is easy to have multiple versions of something installed that don't conflict with each other. I have not actually done that (I have not actually modified NixOS in that way, then tested the result, e.g., by making it my daily driver for a while) which is why I'm using qualifiers like "I am pretty sure", but I'm confident enough it can be done that I consider it worth bringing up in online conversations about NixOS. The cryptographic hash gives you a guarantee that a binary package you got from the NixOS package servers has not been adulterated in some way on its way to you--a guarantee that you can check without your having to go through the trouble of building the package yourself, but IIUC that guarantee is not actually used anywhere to make the supply chain any more secure.
In general NixOS seems to be bad at security or not to care about security: for example https://news.ycombinator.com/item?id=36268776
Again there are good ideas in NixOS (including ideas that seem like they could be used to meaningfully increase security) and I hope anyone creating a new distro studies NixOS, but as a distro to be actually used in anger in the present day I am not impressed.
If I didn't want my computer to change I would simply not turn it on!
A Fedora Cinnamon Atomic would be a wet dream for me. I'm surprised that wasnt prioritized. Budgie Desktop looks interesting.
Try setting "max_parallel_downloads = 20" in "/etc/dnf/dnf.conf" the next time you try (the default is 3 which often doesn't saturate the network and is just slowing things down).
I tried Silverblue a couple years ago and found myself rpm-ostree layering some basic tools like Fish shell and Mosh. Is layering still the preferred method for installing these types of tools or do you have "generic" container (made with toolbox/distrobox) that you jump into for generic shell work in like ssh'ing around and file management?
Also, how do you handle things like custom services? For example, Nebula overlay network doesn't really have an installer. Its just a single binary. I manually put that in /usr/local/bin, put the configs in /etc/nebula, chmod those configs to hide them, update selinux, and create a service file for it. How would I do that in an immutable system?
I'm using Prompt, it's a new terminal designed to make the toolbox/distrobox flow much nicer: https://gitlab.gnome.org/chergert/prompt
It's still relatively new so it isn't on flathub yet but it makes everything mostly seamless.
You can always create containers with init if that's how you want to do that though. Some distros publish images that come that way: https://github.com/89luca89/distrobox/blob/main/docs/useful_...
What does this mean?
never had any issues so far for those use cases
its definitely something I'd install for my parents
GUI applications work fine from a distrobox and it makes the integration very painless (eg. VSCodium extensions). You can export them with a built-in command and it will even create a regular desktop entry for them.
You don't update the kernel separately from, say, the core user land, the way you'd update linux-kernel and binutils as separate packages on a linux distribution.
BSD doesn't use the term "atomic" but as near as I can tell it's the same idea.