Is it possible to ship a DE with containers?

Project Discussion
21

You technically can do all of this, but it would take an insane amount of glue. For instance:

  • In Wayland, your window manager is the compositor. In particular, the compositor would have to be able to create a socket that exists outside the container.
  • Now your container also needs to be able to access all the standard directories for reading desktop files and icons, let’s expose that too.
  • We need to be able to run applications under the user’s session, which…exists inside the container. Let’s create a daemon of some sort for setting up the session outside and communicating with it.
  • We need to talk to logind, let’s expose the dbus session socket into the container.
  • What the systemd user services that are part of the DE? Let’s just mount some (but not all of them of course) in the outside world or something, you could probably stretch portablectl into doing this via horrible tricks.
  • What about distro-specific tweaks to the desktop environment? Even little things like different installation paths and stuff to make it play nicely with its peer packages. Let’s just have distros all distribution their own containers, right?

Basically once you try to achieve a polished experience, your container ends up becoming and incredibly leaky, crappy distribution mechanism. You can check out Flatpak, which is already a rather large codebase despite handling a fraction of what would be required here. IMO at least given our current technology, it’s not worth it, and it won’t be worth it for a rather long time.

With Xorg we could get away with this because the X server could run outside the container and take care of some of this. However, that came with its own, incredibly large set of problems, which is why we’re now moving to Wayland.

2 Likes
22

Whilst I think allowing non-root users to be able to install their own DE’s is a bad idea (think enterprise), I think a way forward for tiling is DE’s offering accessibility APIs to allow tiling window managers, very much like macOS.

I think KDE might even have something like this already.

Edit: Don’t think I’m being negative or anything, just what you’re asking is an awful amount of hackery and work for very little gain, very similar to what @refi64 said. The Android Launcher comparison isn’t really true either because the Android launcher doesn’t provide the system UI and frameworks, where a DE does.

23

If it hackery it’s just because Linux desktop is badly designed. What I’m saying is just how things are expected to be. As I said: root permissions to use another window manager? It’s insane.

24

I don’t think any other operating system, except the BSDs, lets you swap out desktop environments in the same way most Linux distros do, there’s no bad design here.

I think Google’s Fuchsia that might allow something you’re suggesting, but it’s a completely different operating system design based on capabilities.

Edit: You might also want to see if Mir does what you’re asking, given that it’s a now a Wayland display server with plugins, which can be window managers.

25

The fact there isn’t something like that is not an argument to say “no bad design here”. Before Flatpak there even wasn’t the concept of running third party software in a secure way. There was not even the concept of “app” in Linux desktop world so no app platform. According to your reasoning, the Linux desktop not supporting any platform for third party “apps” was not a bad design choice so there was no reason for Flatpak. But here we are in a forum category dedicated to an OS with a totally different paradigm than the other Linux distro and that makes sense just because we have Flatpak now.

26

Flatpak is still a young technology and Silverblue is basically in its infancy. Not cool to call them bad designs, they are amazing designs that no one else is doing quite the same especially Silverblue. MacOS and Windows isn’t even sniffing the same level of innovation.

I don’t think what you are asking for is a good idea. First, the concept of Silverblue is to make an immutable OS that basically cannot be borked, or rolled back if it is. Bringing the DE back into user hands would go against this philosophy. I also question your assertion that there was not user and system software before Flatpak, I’ve thought of it in those terms since Windows 95.

Second, the textbook definition of a container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A DE is going to have a lot more dependencies than a typical application, even robust ones like VLC or Steam. I’m not sure that even with shared runtimes you aren’t going to introduce a lot of bloat to your system.

Furthermore, making it a truly sandboxed container would make it difficult to install Flatpaks on top of it, as containers usually don’t have the permissions to create other containers (see Docker; you have to “run --privileged” to create a Docker container inside a Docker container, essentially just running the software on the host).

I think the closest thing you are looking for are snaps, which bundles everything inside squash filesystems and mounts it on the OS. Of course if you feel there needs to be DEs shipped as Flatpaks, you are welcome to build it yourself. I have not seen any other such demand for that.

1 Like
27

Flatpak is still a young technology and Silverblue is basically in its infancy. Not cool to call them bad designs, they are amazing designs that no one else is doing quite the same especially Silverblue.

I was not talking about Flatpak and Silverblue, they are right steps in the right direction and I’m apply the same reasoning to the DE too. “Bad designed” was for this aspect of Linux on desktop and Flatpak capability to install software as user too and not only as “system” is exactly the fix to this bad design. Again, I’m just applying the same reasoning to the DE.

I don’t think what you are asking for is a good idea. First, the concept of Silverblue is to make an immutable OS that basically cannot be borked, or rolled back if it is. Bringing the DE back into user hands would go against this philosophy.

No, it’s exactly the opposite, Silverblue is meant to use Flatpak for apps, I’m just saying that the same could be applied to the DE. How is it against Silverblue’s philosophy?

I also question your assertion that there was not user and system software before Flatpak, I’ve thought of it in those terms since Windows 95.

I was talking about Linux on desktop: before Flatpak there was not user vs system concept. As a user you were not supposed to “install” software, only the system administrator was supposed to. On a server the user is the system administrator so OK, but on desktop the user vs system concept is needed, exactly like on Android, where the user can install apps without root permissions. On Linux desktop before Flatpak and Wayland you were supposed to install only the software from the distro repositories. There was not any attempt to provide a platform to install third-party “apps” without compromising the security. Flatpak instead is meant to be the missing app platform for Linux on desktop.

Second, the textbook definition of a container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A DE is going to have a lot more dependencies than a typical application, even robust ones like VLC or Steam. I’m not sure that even with shared runtimes you aren’t going to introduce a lot of bloat to your system.

To be honest I’ve no idea of what you are talking about… may you elaborate? How does this “bloat” compares to what Flatpak does with Freedesktop, KDE and GNOME runtimes? Isn’t having a couple of them installed like having a little distro inside user’s home?

Furthermore, making it a truly sandboxed container would make it difficult to install Flatpaks on top of it, as containers usually don’t have the permissions to create other containers (see Docker; you have to “run --privileged” to create a Docker container inside a Docker container, essentially just running the software on the host).

I don’t want to run (Docker) containers inside (Docker) containers, I don’t know where I said that…

I think the closest thing you are looking for are snaps, which bundles everything inside squash filesystems and mounts it on the OS. Of course if you feel there needs to be DEs shipped as Flatpaks, you are welcome to build it yourself. I have not seen any other such demand for that.

You don’t see demand, and so? Can’t I discuss with other people interested in experimenting with this? I’m already doing so and I’m happy with the results so far.

This thread is so bloated. If you all were not interested in what I’m saying you could just not reply. I was happy to clarify my ideas but this went too far, my impression is that you all have no idea of what I’m talking about, with respect.

3 Likes