Criteria for making Fedora Atomic the default desktop experience

For as long as I’ve known about Silverblue and friends I’ve heard the idea that one day they will become the default way of consuming Fedora on desktop. There has been uncertainty about timing for just as long!

What do the atomic spins need to have to be considered ready to be the new defaults?

5 Likes

Flatpak has to work

  • native messaging
  • drag& drop
  • more upstream adoption, less duplicate runtimes!
  • best: special seccomp filter allowing browsers to create usernamespace sandboxes

If Fedora really wants to stick with Fedora Flatpaks, then a special Firefox Flatpak Extension is needed to add nonfree stuff. Maybe even Firefox itself, like with DRM. This would need to be hosted like rpmfusion.

GUI integration is done, but it sucks

  • rpm-ostree slows down the stores
  • updates should be automatic
  • changelogs are not displayed well (removal of base apps, NVIDIA upgrades, kmod upgrades)

So: a better method for auto-updates is needed

  • use less peak resources
  • respect battery charge level
  • respect charging state
  • detect metered/unmetered network

this needs to be accompanied by an opt-out of always defining the state of a network. I.e. a user has to click “unmetered” or “metered” on every new network, by default everything is unmetered, also your phone hotspot

KDE: sddm has its themes in the wrong directory, needs ugly workarounds

1 Like

There is so much customization that can be done with rpm/ansible it would be great to gain atomic update capabilities too. Something like image builder for fedora using native containers that are bootable. That way a custom fedora can be defined and using the fedora image builder it can be built on fedora infrastructure then all my os instances can retrieve these atomic images from fedora infrastructure. Once atomic allows for this flexibility making it the default for fedora anything seems to make sense.

Flatpak is a whole other topic but since many atomic variants expect gui applications to be install as Flatpaks it warrants inclusion. Flatpak has been an enormous flop from many perspectives. It exposes the user to many unfamiliar software supply chains that have not had necessary scrutiny. The supplier of the flatpak decides what kind of security they want to deploy to the user with no review from the fedora community. The portals that are required are enormous in scope of what they pull into the local package set. Many developers and users are happy with giving up what was so hard to gain over the years for the ease of deployment. Users should be aware that this situations exists and not just trust flatpaks like they would a fedora project rpm.

Maybe flatpak is just the best man can accomplish with his intellect and limited resources. Thankfully there are users and developers that are willing to struggle through security, privacy, safety and human health topics in spite of the current situation. Some are more honorable in their intentions than others. Confidential computing, some of the over-the-top privacy scenes and various research groups may still impact our current situation positively. I am sure any discoveries that get proposed in the fedora community will be considered in a friendly manner.

This is assuming everyone is running Fedora on a laptop, they aren’t. For laptops and all systems really, this should be a part of the power management in general, but Linux has pretty lacklustre support for it at the moment, I don’t think it’s Fedora specific and it definitely is not caused by the OS being atomic. These are therefore not really a stumbling block to adopting the Atomic variants as the official release offered.

They are, or were the last time I ran Silverblue. They never were on FCOS since it is server oriented and there is an expectation the system administrator is aware of what and when to update.

So rpm-ostree status isn’t enough info for you?

A lot of this is actually what’s currently being explored in the Universal Blue project with the cloud native model. They’re doing what you describe of working with stock Fedora atomic images, making custom images, and then supporting client devices from cloud infrastructure (GitHub in their case).

I am also watching what happened with Image Builder, but I think the more powerful feature will be the fact that you can edit containerfiles for the atomic images. From that point, anyone will be able to provide a place to edit and build images, not just Fedora/RH through Image Builder.

2 Likes

I have been keeping my eye on CentOS bootc. The tier1 manifest is really small and the tier0 is tiny. With these as a starting point just about any package set can be put together as a bootable container with atomic updates. centos-bootc should be suitable for everything from containers to iot to edge to coreos to server to workstation. Project sagano (centos-bootc predecessor) initially was tied to rawhide and also talked about uploading the images to the user’s gitlab. But uploading to a fedoraproject image service would be even better.

From what I found looking at universal blue the starting point is an already overbloated set of packages without the means of starting at a much lighter definition. The ability to push the built images and use them is great and necessary as far as I am concerned as I do not have the inclination to build all the infrastructure myself nor to maintain it all. I will have to learn more to see how all the customizations that can be performed with ansible can be accommodated.

There are so many applications that simply do not have feature parity in flatpak that it’s too many to count. To echo @boredsquirrel 's post :

Flatpak really needs xdg-desktop-Portals to be fully fleshed out or we have nothing. Currently Flatpaks ship with tons of permissions or none at all depending on the developer. Portals would fix a lot of this, while also fixing cross application Flatpak communication. Browsers cannot properly use Native Messaging, Password Managers can’t talk to Browsers if both are Flatpaks. Blender can’t launch other applications, Krita can’t move files over to Blender . . . There’s a lot more to say.

As for running app in containers, that is also going up against being more user friendly. People creating several containers without know that 1 might do for their purpose, or other issues with navigating “sandboxed” applications leaving config and other remnants in your /home

2 Likes

The biggest issue is developers not making software work with portals.

Its mainly

  • pipewire
  • filesystem access
  • screenshare portal

I some cases like Inkscape, the file portal is lacking SVG preview or something so they dont use it.

Okular on the other hand works flawlessly without any filesystem permissions, but has them enabled for compatibility (I guess?)

But 90% of apps simply

  • require preset filesystem permissions
  • are not adapted to store their config files etc. in their container
  • need unrestricted access “because you may open a DVD”

I started a collection of software following good practices

3 Likes

I think if you separate the forest from the trees, and realize flatpak and the ecosystem are still nascent, we are incredibly lucky to have something as functional and polished as Fedora Atomic Deskops and flatpaks, especially Flathub.

It’s super easy – too easy – to lock stuff down. I read the docs and decided to build my system around public XDG dirs, it’s just an ini file:

/var/lib/flatpak/overrides/global

[Context]
filesystems=!home;!host;!host-etc;host-os:ro;xdg-desktop;xdg-documents;xdg-download;xdg-music;xdg-pictures;xdg-public-share;xdg-templates;xdg-videos;!xdg-documents/Secrets;

Normal apps can access my all my good ol’ classic Windows 95 / XDG dirs. I’m sure many have much better ideas of what “lock-down” means here, and my setup makes you want to puke in your own mouth, but this it what I want. I’m not paranoid to the point I need to lock down each and every app, but I don’t want apps running amuck outside home and host, I just want apps to use those well-know desktop folders.

I also don’t want any other flatpaks accessing ~/Documents/Secrets other than KeepassXC. I didn’t have to think about it, the docs spelled out how to do so:

/var/lib/flatpak/overrides/org.keepassxc.KeePassXC

[Context]
filesystems=xdg-documents/Secrets:create;

Not only is KeepassXC locked down, it’ll create my Secrets dir for me (if it doesn’t exist) the first time I launch it.

chef’s kiss

(You can also do all this as a user. All your overrides can live in ~/.local/share/flatpak/overrides. I just do this in case I want to go multi-user.)

I’ve tried to read the documentation for bwrap… Give me ini syntax any day. I spent maybe… 5 minutes reading the flatpak-metadata man page, and setting this up in an ini is just too easy. Too gud. =^)

As for the feeling of things being perpetually unfinished, that’s just part of life. Things change, modern programs become vintage, now Linux is on the Desktop, it gains mind-share. Now Linux Desktop has worms and ransome-ware. Suddenly you need an immutable OS, you need portals, and you need to get off X11 and re-think drag & drop.

As for what’s missing, built-in apps should be and are replaced by flatpak’d versions, but currently they just disappear into the void. Someone on Kinoite Matrix had their mom call them saying she couldn’t open pictures and PDF’s because gwenview and okular were just gone with no warning.

I don’t think multi-boot / multi-distro works at the moment either. Some people won’t mess with Atomic if they can’t safely install and remove it.

GUI tool-kits and themes can be an absolute nightmare. KDE does a good job of covering Qt and GTK with Breeze, but it’s still a mess, things can and do break randomly, either to flatpak updates or system updates… it’s not fun.

Can’t get paid on Flathub. Hopefully this happens in 2024.

3 Likes

What would happen, if we maintain, and keep an small immutable system core, aka Fedora Core, and we create layers by “bricks”. This could be like old times “kits”, sets of apps based on activities, and maybe Fedora contributor membership, if eg. I would like to have my own dev setup, with my own look and feel, and my own config files. Would be much easier to set modularity, atomic way, and we forget giant apps. We should rethink from cli apps, and then expand them with UI and its options if possible. The current issue is that if we would like to have an organised way, and connected parts that results a whole, we have to forget the current concepts. IF the basement (the core system + cli base) doesn’t give apps that can be tied with gui in our taste, that is bad. Instead currently the linux desktop looks like a mess from apps perspective. Flatpacks or similar solutions will give a path where you can define the elements, modules of the desktop - what is can be anything. From virtualisation, to online apps, till you only see a kde, gnome or just a Copilot admin app. IMHO.

[Context]
filesystems=!home;!host;!host-etc;host-os:ro;xdg-desktop;xdg-documents;xdg-download;xdg-music;xdg-pictures;xdg-public-share;xdg-templates;xdg-videos;!xdg-documents/Secrets;

Very cool! This means you can globally restrict and allow access for all apps? This is very cool!

1 Like

It is very cool :sunglasses:, behold:

2 Likes

In my experience, Silverblue already works pretty well as a drop-in replacement for Workstation for users who use their computers largely as Chromebooks – web browsing, basic document processing. These people use the GUI exclusively and expect whatever they need to be a few clicks away.

Power users – developers, scientists, users of professional apps – will be more difficult to convert. Those people have built up many years of habits and experiences with Fedora Workstation, particularly related to software management, and not all of them will work directly on Silverblue. For instance, if they want to stand up a web server, they might do dnf install nginx followed by systemctl enable nginx, which is almost possible on Silverblue but not really how Silverblue is intended to be used.

Fedora developers should enumerate common tasks and workflows in Fedora Workstation and make recommendations for how to map them to Silverblue, keeping in mind the intended audiences of Fedora Workstation. The reason is that there are sometimes multiple overlapping alternatives for a given workflow or none at all.

For example:

  • How should I install graphical apps? Of course Flatpak is probably the default recommendation, but what if the Flatpak version is crippled or doesn’t exist at all?
  • Linux has a plethora of useful CLI tools. How should I install them? For example, what should I do if I want to convert images using ImageMagick?
  • What about applications that have a combination of GUI, CLI, and system-level components?
  • What about various servers? SSH, VNC, VPN, databases, etc.
  • What about professional apps distributed as standalone RPMs or binary installers?
  • How do I build and run software distributed as source tarballs? If I were using Fedora Workstation I’d probably start with dnf install gcc, make, libXYZ etc.
  • How do I deal with drivers distributed through DKMS, such as Virtualbox or ZFS?

One should keep in mind only whether it’s possible to accomplish these tasks on Silverblue but how easy it is to do so. Cumbersome workarounds such as this one should probably be solved before Silverblue is marketed to the masses.

Some recommended best practices for using Silverblue will also be helpful. For example, various internet forums suggest using Toolbox todnf install software that don’t have suitable Flatpaks. But since Toolbox is essentially Fedora Workstation in a container without systemd or automatic updates, one is liable to accumulate a lot of out of date software if one lives primarily in a Toolbox container.

3 Likes

You can derive from any image you want, start from the upstream Fedora image if you want a fresh start.

1 Like

I work in this field so I thought I would pass along my experiences from discussions with lots of developer/ops people. I think there’s a clear line of use cases here that are being underrepresented in this thread. There are plenty of power users, developers, scientists, etc using cloud native tech and would benefit from this technology. There are more than 7 million cloud developers and Fedora has a huge technical lead here.

Desktop Linux is very underrepresented in this audience, including many who create and maintain some seriously technical projects. When it comes to KubeCon / Cloud Native Con, we’re surrounded by Macs (would love @jberkus 's experience here). This same audience has a very negative perception of Linux on the desktop which is unfortunately true – they hate it because it (often) doesn’t work. And entire classes of bugs and fundamental issues can be addressed immediately in one go, to an audience that have been docker pulling nginx this entire time. At a time when Asahi is becoming a realistic option, having podman just built into your desktop makes some of them wish that desktop Linux was more for them. Especially when you pair it with great hardware, and Fedora has great OEM relationships already. There’s no reason to slow down now, it’s almost done! :smiley:

You don’t have to switch to containers — normal packages will never go away. Distros make TONS of images: ISOs, .raw, .vmdk, images for EACH cloud (AMIs, etc), and then different variations of each, this will be just another thing they make. Like containers, this is additive technology. It’s literally the same code, just consumed different.

4 Likes

This is server field. But how will you accept all this as part of the mainstream desktop for average user?

My visually impaired brother in law has been using Fedora Silverblue since I installed it for him at around F29 time. He is still upgrading from that install to this day. Although he is a trained systems analyst, he told me he won’t ever go back to Workstation since Silverblue has been and continues to be so stable for him. I have used it in my “field of work” (programming PLC’s and HMI’s) for industrial control use, and also running VM’s of Win product for specific proprietary SW. It just works, in this type of use case and with the atomic nature of the OS, it is a relief for those times a change introduces a regression, something that Fedora can suffer from due to it’s near bleeding edge position. Workstation is very stable, don’t get me wrong, but the atomic offerings are more stable to use in my experiences so far. The simple fact that rolling back to your previous or known good system state is a boon, and so easily done. I think you should do what many who were skeptical have done, try it in your use case, and see how it fits for you. There is a user that I haven’t seen around for some time @znmeb , who was using/trying to use it for scientific pet container setups.

3 Likes

I look at it the same way Casey does:

ChromeOS is like the #2 most popular consumer Linux. Fedora with Silverblue not only offers that but a choice in browser + Flatpaked apps. The container stuff is for developers and advanced users.

2 Likes

By the way talking of ChromeOS: There are similar projects like kata containers, that will allow similarly performant isolation of “untrusted” apps like on ChromeOS. (Secureblue issue)

I agree that it is so important, because we need to convince people that dont use Linux, that its awesome.

  • schools
  • offices
  • kiosks
  • libraries
  • offices

All those just want automatically updating systems that never break, in an isolated environment, with preinstalled apps and limited users.

So adding to this is the very big importance to fix rpm-ostree for non-wheel users. I already created the matching polkit rule and I have no idea how to proceed. Basically, everyone needs to be able to repo-refresh and update, all the rest can be left out, needing a password.

Then the setup of user flatpaks should be made more clear. What it its advantage for security? It allows people not in the flatpak group to manage it, is that right? Now to make them unchangeable you should use system flatpak, create a polkit rule only allowing updating, right?

Also for systems like this, we need more immutable Desktops. You can totally break everything without any admim privileges. Linux is just made like this.


And for converting traditional Linux users, just pump out working base images and as mentioned above translate all those workflows to Toolbox, and you are just fine. I switched to Kinoite because everything constantly broke before.

2 Likes

It uses the unix wheel group to allow standard users to manage flatpaks. It’s a weird group name, but it has a long history of use for these kind of escalation-of-privilege needs.

1 Like