Is it possible to ship a DE with containers?

My understanding on Silverblue:

  1. The user is not supposed to act as a system admin like on other distros, so he doesn’t need root password to update the system shipped with OSTree and to install/update apps shipped with Flatpak
  2. Flatpak is for apps only, it’s not possible to ship Desktop Environments
  3. The DE is part of the OSTree image and to install additional DEs OSTree layering and root permissions are needed, so the unpriviledged user must stay with DE(s) installed by default and can only install apps with Flatpak

So would it be possible to ship Desktop Environments using containers? The idea is that the user install a DE by downloading a (Docker/Podman) image and the login manager show an entry in the “session” menu to run a container with the DE. I understand that the login manager must be aware somehow of sessions available for each users and AFAIK adding sessions needs root permissions.

And in general is there any idea/vision on how to let users install DEs with the same experience they have now but without root permissions, similar to how Android users install custom launchers?

Thank you for any reply

In software, anything is possible :wink:

I am pretty sure people have done this with the original Container Linux and Docker. Running the desktop out of one or more containers would have some really neat advantages. But, also a lot of disadvantages.

The main thing is that running in a container like this is really quite different from running on the host, and keeping both ways working would impose a burden on everyone maintaining those parts of the stack.

They’d necessarily be highly privileged; having any kind of reasonable isolation from the host would be a whole other thing.

And particularly for things like GDM, there can really only be one active at a time…you can’t have them fighting over the display.

One more thing: an aspect I struggle with a lot is that we really want to still have a usable system even if you blow away your container stack. Of course, you could be dropped back to the CLI I guess if you remove your desktop container but…

And finally, we really want to ship something that’s tested together. There’s a lot of interactions between e.g. the kernel and mesa and the desktop core, and I think even if we eventually containerized parts of the core desktop OS, we’d still end up inventing a mechanism to “pin” the two things together by default across upgrades.

Thank you for your reply! I already run KDE Plasma with Docker since KDE Neon provides images and a cool script to manage them.

My question is more about how Silverblue will enable users to install additional DEs, if there is such vision.

I can manually setup a session entry in the login manager that launch the DE, for example Plasma, from a Docker image instead of the default one. But to let unpriviledged users to create new sessions in the login manager we need this feature supported by the login manager it self I think. I’m not aware of any login manager that display session entries per user i.e. User A has GNOME and User B has GNOME and Plasma.

Separate trees for each spin I’m presuming.

Yes, but now you can have multiple DE on normal distro. It’s suboptimal to have a different installations for each DE…

Also I think that the point of using PackageKit before and Flatpak and Podman now is to making the user able to install additional software without root password. If this is the case for GUI apps (Flatpak) and other tools (Podman) I don’t understand why we shouldn’t use the same model for DE too… I mentioned the login manager issue but that just mean adding support for user-defined sessions to a login manager and we should be OK

Having multiple large DE’s on a single install has never been a great idea. You end up with duplicated apps, services, login managers etc.

1 Like

AFAIK the login manager is always one. Having multiple DE installed is part of current design since almost all login manager have an option to select the session…

Also the combination of Plasma, Sway and LXQt doesn’t produce a moltitude of services.

It sort of depends. E.g. when I had GNOME and KDE both installed back on Arch, tracker would never work but baloo would run under GNOME and eat up insane amounts of CPU.

Adding on extra window managers isn’t as much of an issue. You’d probably be fine with Plasma and Sway, or LXQt and Sway, but Plasma and LXQt would have more potential for issues.

I think we are going a bit off topic here, but that is just a bad implementation that can be solved using containers. If Tracker and Baloo live in their own containers you won’t get one when running a session that depends on the other.

You can try this using KDE Neon Docker images. It just works by manually start the container with CLI. The only problem is that the login manager doesn’t look for custom sessions configured by an unpriviledged user. So I wanted to know if Silverblue has plans or a vision on how to ship DEs.

GNOME you can always replace the current session, but otherwise I think the use case for custom sessions is very rare.

So I wanted to know if Silverblue has plans or a vision on how to ship DEs.

I think the only viable solution is package overlaying or trees for the spins. The DE rarely gets updated that a restart every few months isn’t going to hurt.

Thank you for your replies but you are totally missing the point.

I’m interested in additional DEs/sessions installed by unpriviledged user like it’s now possibile for apps via Flatpak and for (development) tools via containers managed by Podman. I’m not interested in other solutions.

Actually, I think using rebase to switch to a different DE and get all its integrated apps without having to manually remove the old ones or just keeping everything at the same time will be quite nice.

edit: And I think you can rebase as an unprivileged user as long as you can get access to the image you want. I’m not sure what the plan for official spins is though or if you will be able to rebase to them without having an admin add the repos.

You have to be in the wheel group (an admin) to rebase or update, just polkit takes away the need to enter your password.

See /usr/share/polkit-1/rules.d/org.projectatomic.rpmostree1.rules

There are so many replies suggesting other things so maybe I should make it more clear:

Please think about Flatpak and Docker/Podman containers: you can install a flatpak or run a container from an image everywhere if flatpak/docker/podman is installed. On Fedora Silverblue you can use flatpaks from FlatHub for example. You can use Podman to run containers from images downloaded from Docker Hub for example.

Now I can run an entire KDE Neon container from any distro that has Docker or Podman and so have different Plasma versions (user, dev stable and dev unstable). Read more here: https://community.kde.org/Neon/Docker

So the point is: how can we make the experience of doing so the same of apps shipped with Flatpak?

Ideally the user download an image (using a command line tool like Podman or a GUI as we can do for flatpaks) like KDE Neon’s official Docker images and in the login manager an additional entry in the “session” menu is shown and what it does is running a container from that image that contains the DE that the user will use in that session.

I don’t ever think that’s ever going to be a supported thing, the use case is very small. There’s still the question of why?

If you’re developing DEs, most desktop managers will happily read from /usr/local/share/xsessions and /usr/local/share/wayland-sessions, so you can still develop DE’s on Silverblue that way or just use nested clients as you can today.

Why? Why do we have Flatpak? We can have apps that run everywhere, same for Docker containers. Flatpak is needed because distros can’t package all the apps out there. Why we shouldn’t have the same for DEs? Why we should rely on DEs packaged by the distro? Can’t we have an OSTree image with no DE but install all the DEs built elsewhere and run in a container?

I don’t wonder why we should do it, I wonder why we’re not already doing it.

Because DE’s are system software, not applications? They’re a lot more delicate and people rarely have more than one installed.

Before Flatpak there were not “system” and “user” software, the distinction was introduced by Flatpak.
Why DEs are “system software”? What’s the line between system and user software? There could be a clear definition: it’s “user software” all the software with which the user interacts directly. So are all the GUI apps, the DE’s shell and the window manager. The system software would be everything else that is used to run user software, from the kernel to daemons.

Finally with Flatpak we have the user in control of his apps (even third party ones) without being a system admin. The next step is of course doing the same with the DE (mainly the shell and the window manager).

Instead considering the DE as “system” is a relic of the past.

BTW this is my last message on “why”. I’m interested only in “how”.

Maybe under X, but not with Wayland. You could containerise parts of the DE though.

Except with Wayland, what were described as window managers, are now compositors. They have clients, they manage graphics hardware, they assist with sandboxing. They are very much part of the system, more so than ever.

DE’s include daemons, especially GNOME.

I don’t see the issue with if you want to try a different compositor without installing it using the current methods that already exist?

Another example of running DEs in containers: http://ghanima.net/doku.php?id=wiki:lxc:deinlxc

The fact window managers act as a compositor in Wayland doesn’t mean anything. They are still window managers because they manage windows, that are something the user should be in control, like choosing between a classic wm and a tiling one, he shouldn’t depend on whatever the system administrator install.

This is not about me trying other DEs. This is taking the next step in building a sane and modern Linux OS. Containers for the development tools was the first step, Flatpak apps the second and the same for DEs the third.

I understand that this may be not clear in classic Linux distro paradigm, but: the user is not the system administrator. The user must be able to control the aspects of the software he directly interact with without needing root permissions. Root permissions to install another DE or replace the window manager with a tiling one is insane.

But I would like to know why you think DEs can’t be properly run in containers. What changes to the DEs are needed to do so? Why do you think we can’t put the Wayland compositor in the container?