After using Silverblue for a while now, I have come to the realization that containerized applications could use a service to start further applications. It’s tedious to operate on other containers when the shell is already containerized. For example, it would be nice if clicking on an HTTP link opened a browser in another container.
I have created a proof of concept, named silverkube, that demonstrates how this could work: demo.
Before pursuing this experiment further I’d love to hear what do you think about this idea.
This seems interesting, however I think Flatpak has already largely covered a similar use case via the desktop portals and D-Bus activatable applications.
This is a really intriguing idea. I have been contemplating something similar but my usecase was that I wanted to run a desktop where most of the applications were running in a kubernetes cluster.
Mainly because single system image clusters isn’t a thing any more
Nice demo. I think this can be useful. The only problem I see is relying on X because that beast has long teeth and isn’t the way forward. Sadly doing the same on wayland is less than trivial it seems.
But to get back on topic. Good job, I enjoyed the demo very much.
Thank you for the prompt feedbacks. Here are some more details I forgot to mention:
Silverkube currently demonstrates how k8s can start xorg and xmonad and then how an emacs pod can be started from the xmonad context. It should be possible to use Wayland (iiuc it’s mostly about replacing /tmp/.X11-unix by /run/user/1000/wayland). As a follow up, I meant to add dbus and nm-applet to the desktop.yaml file. It may also be possible to start Flatpak inside Silverkube. I take this as a k8s learning opportunity and to see how much can be moved from the ostree image into pods.
Lastly, I previously wrote a cli named podenv where some applications are already described declaratively. Podenv currently converts the description as a podman command, and perhaps it could also generate kube objects to be applied to silverkube. Then podenv may also generate kube objects to be applied to a remote cluster, for example, by substituting x11 by Xspice and by forwarding local pulseaudio socket.
There is a lot to design and I’m looking for interested users. For example, the kube api and cri-o are currently started as system services which is an issue as it is tedious to prevent root access. Perhaps the required services can be provided by rootless podman. Also I wasn’t able to start cri-o as an unprivileged user because it tries to change the storage owner to root…