3 ms·

The most important takeaway from this is, to me, the need to separate sandboxing from dependency management. However, as can be seen with AppImage, which seems

The most important takeaway from this is, to me, the need to separate sandboxing from dependency management. However, as can be seen with AppImage, which seems to be strictly focused on dependency management, that results in bloat. It would be great if we could have a sandboxing solution that ignores the dependency management altogether. The problem is not with Flatpak or Snaps (or Docker). The problem is that the fragmentation in the actual, live-deployed Linux system runtime is huge. At one point, I know Canonical suggested a common, shared baseline for all LTS editions of all distributions at some point, but there was no interest from Red Hat in particular (the other "largest" player). It's not too surprising, since Red Hat is the biggest contributor to the base GNU/Linux system, so it can decide how it deals with it and push it onto others. Backwards compatibility is hard in software in general, but I think simple extensions of tools like apt and apt archives (like Launchpad PPAs) would have allowed binary distribution of software in an already familiar way where dependency management is not a solved problem per se, but has all the familiar gotchas. As for app stores, that's surely an effort to extract some profits, but it's also what big customers are asking for for their IoT solutions.

AnIdiotOnTheNet 5y ago
> Backwards compatibility is hard in software in general I disagree. Pretty much every desktop OS in the world manages to get quite a lot of backwards compatibility without a whole lot of trouble, except for Linux Desktop. That suggests the problem isn't hard, it's just that the culture of Linux Desktop is incompatible with the concept.
- southerntofu 5y ago
  > Pretty much every desktop OS in the world manages to get quite a lot of backwards compatibility without a whole lot of trouble, except for Linux Desktop. That's not at all my experience with Windows or MacOS. Sure some older apps work fine, but certainly not all of them.
  - AnIdiotOnTheNet 5y ago
    The vast majority of them do, in my experience. Especially if you take into consideration how badly it doesn't work in Linux Desktop. You cannot usually even run a binary compiled for the previous version of your distro on the latest one!
- necovek 5y ago
  You must have missed all the articles on the huge effort Microsoft went to to maintain backwards compatibility (like that famous SimCity story). I can't find the original article anymore, but you can find references to it on Joel Spolsky's blog: - https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii-chicken-and-egg-problems/ https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii... - https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... Referenced posts probably live somewhere on https://devblogs.microsoft.com/oldnewthing/ https://devblogs.microsoft.com/oldnewthing/ today, but the quoted snippets should tell you that it's not that easy at all, and that Microsoft is investing heavily in maintaining it.
  - AnIdiotOnTheNet 5y ago
    Yes, in order to increase their backwards compatibility Microsoft has, historically at least, done things like that. However, mostly they achieve backwards compatibility by just not breaking ABIs all the goddamned time. Windows backcompat isn't perfect, true, but largely the stories of where it fails are exceptions to the rule. Where as you can't even have backward compatibility in a Linux Desktop with applications compiled for the previous version of the same distribution in many cases.
    - necovek 5y ago
      You started off by disagreeing that backwards compatibility is hard, because other platforms (like Windows or MacOS) can do it. When given evidence that it's at huge cost and investment that they manage to do that (basically an admission from them that it is hard — you may have a different definition of "hard" than I do), you seem to suggest that either they are not doing a lot of work towards compatibility or that they are wasting all that money because they could have simply maintained backwards ABI compatibility while developing new features "easy-peasy". Why did they choose not to take the easy way out and made it hard for themselves? From my software development experience, maintaining API backwards compatibility is "hard" (requires significant extra effort to achieve compared to just not doing it), not to mention ABI complexities on top.
pabs3 5y ago
The tool that flatpak uses for sandboxing is bubblewrap, that can be used to sandbox distro packages fairly easily. None of the desktops do that though.
- necovek 5y ago
  Thanks: bubblewrap seems to have been extracted from flatpak. The documentation seems to focus on filesystem access sandboxing. Is there something with practical suggestions on how to sandbox things like webcam access, clipboard, screen (for screen sharing/recording apps), networking... with bubblewrap? (I know some of that is visible in the filesystem, but not all of it is)
  - pabs3 5y ago
    Look into Flatpak portals. I'm not sure how they work wrt bubblewrap, but they pass limited interfaces to various things into the container. Things on the host side then prompt the user for which webcam/etc the app should get access to. I think they are similar to Android intents in that the app can't ask for access to a specific thing, just for access to certain kind of things and then it is up to the user to choose which one.
    - necovek 5y ago
      Yes, I am familiar with portals and what they do: I was exactly wondering if bubblewrap contains something similar — it's been ages since I was involved with Linux system architecture (let's say I am stuck in the SysV init world, and I still go for "service apache2 restart" :)), so it'd be great if there was a quick introduction for someone wanting to use flatpak/snap style sandboxing without the dependency management and distribution channels.
      - pabs3 5y ago
        bubblewrap can bind-mount paths from outside the container inside the container. I haven't verified this but I'm assuming portals are just sockets bind-mounted into the container. I suggest you maybe install Fedora in a VM and run a flatpak app there that uses portals and try to inspect what files are passed into the container.

AnIdiotOnTheNet 5y ago

> Backwards compatibility is hard in software in general I disagree. Pretty much every desktop OS in the world manages to get quite a lot of backwards compatibility without a whole lot of trouble, except for Linux Desktop. That suggests the problem isn't hard, it's just that the culture of Linux Desktop is incompatible with the concept.

southerntofu 5y ago
> Pretty much every desktop OS in the world manages to get quite a lot of backwards compatibility without a whole lot of trouble, except for Linux Desktop. That's not at all my experience with Windows or MacOS. Sure some older apps work fine, but certainly not all of them.
- AnIdiotOnTheNet 5y ago
  The vast majority of them do, in my experience. Especially if you take into consideration how badly it doesn't work in Linux Desktop. You cannot usually even run a binary compiled for the previous version of your distro on the latest one!
necovek 5y ago
You must have missed all the articles on the huge effort Microsoft went to to maintain backwards compatibility (like that famous SimCity story). I can't find the original article anymore, but you can find references to it on Joel Spolsky's blog: - https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii-chicken-and-egg-problems/ https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii... - https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... Referenced posts probably live somewhere on https://devblogs.microsoft.com/oldnewthing/ https://devblogs.microsoft.com/oldnewthing/ today, but the quoted snippets should tell you that it's not that easy at all, and that Microsoft is investing heavily in maintaining it.
- AnIdiotOnTheNet 5y ago
  Yes, in order to increase their backwards compatibility Microsoft has, historically at least, done things like that. However, mostly they achieve backwards compatibility by just not breaking ABIs all the goddamned time. Windows backcompat isn't perfect, true, but largely the stories of where it fails are exceptions to the rule. Where as you can't even have backward compatibility in a Linux Desktop with applications compiled for the previous version of the same distribution in many cases.
  - necovek 5y ago
    You started off by disagreeing that backwards compatibility is hard, because other platforms (like Windows or MacOS) can do it. When given evidence that it's at huge cost and investment that they manage to do that (basically an admission from them that it is hard — you may have a different definition of "hard" than I do), you seem to suggest that either they are not doing a lot of work towards compatibility or that they are wasting all that money because they could have simply maintained backwards ABI compatibility while developing new features "easy-peasy". Why did they choose not to take the easy way out and made it hard for themselves? From my software development experience, maintaining API backwards compatibility is "hard" (requires significant extra effort to achieve compared to just not doing it), not to mention ABI complexities on top.

pabs3 5y ago

The tool that flatpak uses for sandboxing is bubblewrap, that can be used to sandbox distro packages fairly easily. None of the desktops do that though.

necovek 5y ago
Thanks: bubblewrap seems to have been extracted from flatpak. The documentation seems to focus on filesystem access sandboxing. Is there something with practical suggestions on how to sandbox things like webcam access, clipboard, screen (for screen sharing/recording apps), networking... with bubblewrap? (I know some of that is visible in the filesystem, but not all of it is)
- pabs3 5y ago
  Look into Flatpak portals. I'm not sure how they work wrt bubblewrap, but they pass limited interfaces to various things into the container. Things on the host side then prompt the user for which webcam/etc the app should get access to. I think they are similar to Android intents in that the app can't ask for access to a specific thing, just for access to certain kind of things and then it is up to the user to choose which one.
  - necovek 5y ago
    Yes, I am familiar with portals and what they do: I was exactly wondering if bubblewrap contains something similar — it's been ages since I was involved with Linux system architecture (let's say I am stuck in the SysV init world, and I still go for "service apache2 restart" :)), so it'd be great if there was a quick introduction for someone wanting to use flatpak/snap style sandboxing without the dependency management and distribution channels.
    - pabs3 5y ago
      bubblewrap can bind-mount paths from outside the container inside the container. I haven't verified this but I'm assuming portals are just sockets bind-mounted into the container. I suggest you maybe install Fedora in a VM and run a flatpak app there that uses portals and try to inspect what files are passed into the container.