True, but if I do nothing on the main system but start containers, then a breakage in the pet container where I do work will likely impact me as much as having my main system broken in a regular system. Granted, i would be in a better position to fix it, as I would have a browser, plenty of tools to look at it, and likely a way to salvage files. But if my pet container is broken because I have been careless, I can’t work like I wasn’t able if my system was broken. So I kinda feel we are just pushing the problem one layer further.
Yup, but that goal is also going against the idea of a pet container, since people will likely customize in a way that make reinstallation painful to them. That’s what I am trying to do, and if that’s annoying for me to throw away after 2 or 3 hours of tinkering, I can see how people will be annoyed after 2 or 3 months.
In the end, that’s already what we could do with our desktop already, and I think the problem was never “initial installation is annoying”, more the post installation part where we have to recustomize everything. At least, that’s my perception.
I think I was unclear on this, my bad. Let me explain a bit more with details.
So, first example. I was doing some CTF (Capture the flag, a security challenge where you have to try to exploit vulnerabilities for fun) around Bluetooth ( hackgnar: Learning Bluetooth Hackery with BLE CTF ). I decided to do quick and dirty pet container for that, mostly various “make && make install” to play with things and I hit the first wall. It turn out that bluetooth use a specific socket type blocked by docker/podman, and so I have to use the right options for that. And that’s what I mean by sandbox limitation, aka me being limited by the podman/docker sandboxing.
Another example, I am coding in python for $work. Good, so I want to deploy my flask prototype and this requires to deploy postgresql. While I could use sqlite for some projects (and do because this is easier), sqlite do not support postgresql features I use (stored procedure for a start), so I can’t use it. So I go in my container, do pip install, etc. And then figure how do I start postgresql. In my container, I can’t use systemd (because it doesn’t play nice), and there isn’t much built-in support for starting 2 process in a clean way. Ideally, I should do 2 containers. But then, I start to be blocked because the 2 containers are living in separate world wrt to filesystem (so no socket sharing), or network wise. So I have again to poke holes in the sandbox created by the namespaces used by podman/docker while I don’t in a regular distribution.
And that’s not just when I am dealing with my own code. I was also trying to do some wordpress customization (again for a personal project), and wordpress requires mysql. So same issue, and I did a oc cluster up + deployment script to get it running (that’s the story behind Openshift Origin on Silverblue, story of one thousand cuts)
A third example, my post on Uplink: My adventure of doing a flatpak package of Uplink
There is the part about bwrap needing --privileged (which is “bypass the sandboxing” super flag), and the part about fuse and --disable-rofiles-fuse. Both of them are issues created by the sandboxing and namespace and stuff.
And that’s just me on top of my head, and my experience doing containers on Silverblue. 1 for playing with some low level stuff very much in the hobbyist tinkerer market (I could tell about how flashing a arduino firmware also requires --privileged), 1 for doing packaging work (so kinda contributors workflow), and 1 for a regular python/php development.
And then, there is also where the sandbox (this time for flatpak) do cause issue with some specific feature of software. For example with Inkscape Inkscape on Silverblue, a few caveat to keep in mind but also people report issue with IDE: Developing applications using Flatpak-packaged editors/IDEs
Again, this is kinda due to the sandboxing, and we have to constantly find way around it. I know this is a hard problem and kinda like SELinux and firewalls faced in the past.