[Suggestion] Running UI (X11/wm or Wayland) in a box, not on the host

[mutech]

Is your feature request related to a problem? Please describe.

I would like to run the X server and WM (or Wayland) in a container to avoid having to install all the dependencies on the host. Then I want to split off several apps and/or work environments in separate boxes, that use the X/wm box for display.

This would solve two problems I keep having: the bloat on the host and the lack of isolation of apps that rarely need change. I keep trying to keep my main computer clean, but it inevitably rots leading to me having to reinstall over and over again.

Describe the solution you'd like

Ideally, distrobox would take on the coordination required between host, UI/WM box and various app-boxes. Problems are permissions to X11 sockets, authorization and all that. Another problem is the use of things like D-Bus and systemd integration/passthrough.

The second best solution would be a documentation that outlines how this can be achieved. I found some articles for doing that with docker or lxd, but they are incomplete, outdated and rather complex. That's to be expected, because this use case is a bit fringy in a container context that is more focused on solving problems on the server side.

That's why I think that distrobox is the ideal context to do something like that, because it's much closer to user interfaces/desktops/workstations. I think that the separation of host (for hardware, networking and virtualization), UI/WM (to create a degree of standardization that mac and windows has because they only have a single UI paradigm) and apps (again to cope with diversity on linux) is necessary. I appreciate Linux' diversity, but it's just completely overwhelming.

Describe alternatives you've considered

The natural alternative would be to configure the host as minimal server and run a virtual machine with a UI. There, distrobox solves the separation of desktop chaos on one and cleanly configured/customized software modules/packages in boxes.

The disadvantage of that approach is that a VM cannot just open a display on a console, it either runs on a remote display (host) or it takes over the gpu. If remote display, you yet again have to setup a UI on the host, and for gpu passthrough the host has to either run headless (unpractical without a console in case of network problems) or you at least loose flexibility.

This X-in-a-box approach would be perfect. Maximal performance, minimal bloat, maximal flexibility.

[89luca89]

Duplicate of #579

[mutech]

Duplicate of #579

not planned is fine, but I don't think this is really a duplicate of #579, since what I want is to run X (or Wayland) from the container but on the hosts devices, not on a separate GPU or Xephyr.

One difference would be, that I could start the host without UI, landing on the text console. From there I could start one or more Desktop containers, each of which would run on its own virtual console (just like startx/xinit and the like would).

Another difference is that if the container has access to just the devices it needs, from there it would have no more performance or compatibility issues and wouldn't need fuddling with GPU settings. It's also the most transparent implementation of the bunch. While this is more effort, the effort is mostly related to permissions, namespaces and that kind of stuff, not to the world of pain that GPUs are.

I managed to get this to work on a plain docker container a while ago, but it was a major headache and had a couple of flaws. I gave up on this approach at the time, because I couldn't find fixes for these issues (don't even remember what they were).

Distrobox already went a long way solving similar issues and making container UI functionality super-accessible. That's why I would have loved to see this feature.

Again, don't want to push, just clarify.

[89luca89]

Actually you're right, I misinterpreted 👍 sorry!

I'm not actually planning anything at the moment, but let's keep this around for discussions 👍

[89luca89]

I managed to get this to work on a plain docker container a while ago,

This indicates that a rootful box is needed, as docker runs as root (or sudo podman alternatively)

Just stating it for reference

[mutech]

I managed to get this to work on a plain docker container a while ago,

This indicates that a rootful box is needed, as docker runs as root (or sudo podman alternatively)

It was rootless, but I did the same with lxd, because docker had additional headaches.

I think the problem boils down to two areas. One is to expose and allow access to the relevant device files on the host (console for tty switching, video, audio and input) and then on the way back, expose the containers DISPLAY and whatever the Desktop environment exposes to clients (Dbus, systemd sessions and god knows what else).

My problem with that is that I don't find a place where any of that is documented (with any degree of reliability). What I find only covers parts, a lot of stuff is obsolete, there are always at least three different standards/tool-chains/services doing the same thing, often at the same time. It's just really overwhelming.

So yes, I perfectly understand if you don't want to touch this. I don't want either, that's why I'm writing issues :D