But IMHO, I think is a good idea to release an immutable core that has low package number, and easy to maintain. Then use this as a base, and activities based groups. Better to choose, then keep the iterations. Believe me, if the townsfolk would be out on the streets with pitch-forks, if the configuration can be switched between easily, nobody will care if that Spins mess (*buntu = choose a 26 letter front of the word) is gone, or “Nuked”. If Atomic will mean fully customizable setup - not just untouchable presets - that will change everything. If you can define your groups, and relations between packages, then the groups, and rebase can work on groups, setups - that has no dependency hell…
1 Like
The biggest thing with switching from Workstation to Atomic Workstation is going to be the paradigm shift of workflow for power users. The question may need to be asked from a different perspective though. The criteria are spelled out in the change proposal (yet to be made) that initiates the vote then decision. Behind that, the infra for building the images is/needs to be updated to handle the task, and really for context of the project, you need to read this stuff Fedora Cloud — Edition, not an Edition, and the future
(EDIT: I’m being coy, it’s just an artifact, this part doesn’t need to change)
The only suggestion I have is to ditch confusing terms like Silverblue, Kinoite and others.
Fedora should rebrand the project to Fedora Atomic Workstation, Fedora Atomic KDE, Fedora Atomic XFCE etc.
5 Likes
Fedora atomic spins work mostly fine. As a general default which provides the same possibilities both for users and developers as now, we need:
- Working Fedora flatpak ecosystem.
- Working toolbox/distrobox default setups.
(Layering is a workaround, not a solution.)
A lot has been said about flatpaks already. They have to be the prime source for user apps meeting Fedora quality standards. (They are not there yet - hopefully the new tooling makes it easy for packagers.)
Toolbox/distrobox should be the solution for developers to
- test rpm packaging
- isolate different environments for testing.
They are also an easy way for users to install rpms when flatpaks are missing. But the box tools are not there yet - they have rough edges and make isolation difficult. Both can be worked around with different settings, writing your own dot files which distinguish between box modes, using podman commands when box commands are missing. But all of this has to work out of the box (ha!) when atomic is the default.
Btw: I could even envisage two box variants by default, let’s say for example toolbox and distrobox, where one focuses on well integrated tools (same .config, env etc as the host) whereas the other focuses on well isolated containers (separate .config, env etc for each) which still integrate enough to be useful (X/Wayland etc). They can even use the same backend and images (I know they do already …).
1 Like
While this may or may not be a good addition to Toolbox, it’s not something that there exists a solution for on Workstation that is better than what you can do now in Silverblue, so I don’t think it belongs in this conversation.
Do VPN’s still not work OOTB on Silverblue? Are there other applications that do not work do to some issues with Immutable environments?
Technically, that statement is false. Layering was always an intention with rpm-ostree. I find it is a perception of many, but it is largely based in false lines. Silverblue/Fedora Atomic was never meant to be NixOS.
I think Wireguard on Silverblue has been easily setup for awhile now.
1 Like
Thanks for all the feedback! I say keep it coming.
The common thread seems to be that two areas need to be developed further before more people feel confident in making Fedora Atomic the default experience. First, we need more applications to be available as flatpaks, especially for non-technical users. Second, we need Toolbx/Distrobox to be easier to work with for technical and even non-technical users where possible. What both of these needs have in common is that they relate to software availability. We need to bridge the gap between traditional Fedora and Fedora Atomic when it comes to available software and the ease with which we can get and use it.
3 Likes
I don’t know what NixOS has to do with this, or what it even should stand for in this context. I guess this remark is for NixOS users.
Layering slows down ostree updates because with every new image tree, the layers have to be rebuilt on top of it locally, on the users’ machine. It works around the immutability of the image. Besides slowing down the process, it also breaks two advantages of immutability:
- the fact that every “atomic x” user runs the same system, which helps reproducing problems etc.
- the fact that the update which is about to be applied has been assembled (and possibly tested) in its entirety before
Once users can configure and build their images easily, at least the second point will be possible.
Now, technically you are correct that a workaround is a solution. I guess that pun was lost.
1 Like
Origins of the atomic concept, and declarative system setup, are shared I was under the impression of. Not really thinking or saying you’re a NixOS user in this case though. Plus NixOS uses LibOstree I thought.
Again I don’t agree with this as being a problem since rpm-ostree was created specifically for that purpose of providing local flexibility, otherwise you just use libostree/ostree and not layer —> NixOS (again). Or in my case GuixSD.
I never found it to be an issue WRT it happens while I am using the device and I choose when to reboot. It is pretty much like Workstation in that respect, with the caveat that you have to reboot to have the changes take affect. That is Gnome Software’s interaction with it aside.
This too is possible, but I would agree the average user (to use what I feel is a misnomer) doesn’t want to dig that far into the weeds normally. But it is a declarative way of creating an OS, so forking the Silverblue or other atomic variant repo and building locally your preferred core image is quite do-able and some are doing it now. But I would like to see the web based installer that is being worked on currently be given the ability to allow for such. Maybe done in the same way guix handles it’s packages, where you either build the package from the source on the host or if someone else has done it use the already built package already built on the host, thus speeding up portions of the local build. Just done for core images. However, this I think would increase the projects build hardware by multiples that would be beyond it’s ability to support. Maybe an OCI image would be lighter.
No, what I mean is the project in it’s inception planned to have rpm-ostree and layering, so therefore it is not technically a work around but a tool for the users use. I think it is a game changer in the delivery of an atomic system that is declarative and provides some pretty excellent anti-hysterisis.
1 Like
I think for Flatpaks to make sense in the end, the core OS should become some kind of hypervisor.
Currently, its not very efficient. It works, but there is sooo much duplication of libraries.
Also, I agree that Distrobox / Toolbox is not a good way in general to install CLI stuff. It takes too long to load, maybe preloading it when the system starts?
So Atomic Distros will never be for people that want to hack together their systems, change files, etc. But thanks to ublue we can often make our own images for our taste. Not to say that this is environmentally friendly to do for every person, but you can still do some changes locally.
Maybe Nix could help here, or Homebrew. Also cool stuff ublue is doing 
2 Likes
There is a potential improvement to that problem that I think is “in the works”. Namely, RPM CoW.
Excerpt from API improvement to accommodate for RPM CoW (emphasis added):
… Under a typical case, it saves at least 1 IO (1 read when reading the compressed RPM, 1 write when copying files to disk). This becomes more valuable when servers are running container workload, or CI workload (think mock builders) as the same package are installed multiple times from the same cached file. Data is now reflinked (O(1)) instead of being decompressed and copied, saving both IOs and disk space. …
I think they should ditch the whole idea of making /usr read-only. Instead, it should be made a subvolume and force-reverted before updating or if a user needs to “reset” their system (i.e. something akin to running “git reset --hard” to undo local changes before running “git pull”). It’s always been the case that changing files under /usr could be overwritten by RPM updates and if /usr weren’t read-only, you wouldn’t have to reboot to install things (which has always been the hallmark of Linux).
I won’t use the Atomic editions until/unless significant design changes are made.
2 Likes
That’s an interesting point to me. I use GuixSD on one of my old laptops. I don’t have to reboot for any change, I just hash guix afterwards, and I’m good to go.
I use Fedora Atomic Desktops as my main development OS. Installing apps with flatpak, and development tools/libs with Homebrew works well! For my use case, they’re ready for prime-time.
3 Likes
I think that, at least for a while, Fedora Atomic is a distro where you have to adapt to the model it’s using, similar to how folks choose to adapt to how chromeOS works to make it happen. If you’re someone who wants access to the parts of the OS that are read-only and don’t like updates coming to you atomically, then it’s just not for you.
But then we have to ask ourselves, if we want this to be the default experience then are we willing to change the workflow and expectations we pitch to our users such that we align with what Fedora Atomic is? Or do we want to pitch both models? If we want to pitch both models then the path forward for Fedora Atomic is still to be easier to use, but without the pressure of having to do things that go against the model it’s designed around.
You don’t need to reboot to install or update things. For example, you can install a package on a live system by running rpm-ostree install package -A. The reason it doesn’t install or update packages on a live system is for reliability. Updating libraries or apps that are in use may cause crashes or bugs.
3 Likes
As far as I understood traditional package managers would just terminate that one process and not all. But I am sure this doesnt work for everything.
To the point of allowing changes to the root filesystem: it would be pretty handy to have a mutable shell that allows to create, move etc. files into those directories. The changes monitores by rpm-ostree and resettable.
The current alternative would be some fancy macro capture tool, you enter what you want to do and it builds an RPM for that (like sddm2rpm) and layers it.
+1
… until yesterday, I had not run a Linux desktop in 30 years.
Now, with a used laptop and Kinoite, I’m fighting back tears of joy.
The quality and consistency of flatpaks, layers and containers will be life changing for IT staff and academic computing IMHO.
The messaging to newcomers needs some work, we need to be less reliant on specific product/project names and refer to their corresponding functions.
The SilverBlue User Guide is excellent to get started.
I’m super grateful that they used Tailscale as the example for adding external package repositories because that was literally the next thing I needed to do after my installation.
So, additional “day 2” scenarios would be good to include.
FWIW, I would argue in favor of more relaxed criteria for Atomic Desktop as the “default” because it’s easier to realize you don’t need the training wheels than it is to keep falling over because you didn’t know that training wheels existed.
8 Likes