4 ms·

The fundamental problem is not that distribution maintainers do not leverage containers, but rather we do not understand dependency models/trees of our programs

The fundamental problem is not that distribution maintainers do not leverage containers, but rather we do not understand dependency models/trees of our programs. Containers are golden images. You find combination of stuff that works, carefully package them together and ship this whole package. Gold images run on bare metal, containers run on container runtime enabled kernel. Sure, containerizing an application is /easier/ than working out the dependency trees and solving dependency conflicts between them. It is by no means fundamentally better approach. If anything, this argument dismisses most work done by distros - building and solving those dependency trees. Maintainers of free OSes sometimes do not bother to solve all possible conflicts, however instead of breaking the system/packages, they do inform you of possible conflicts that are not solved. Inability to cherry-pick dependencies is deceptively wrong. Traditional distributions resort to use of so called meta-packages and alternatives to keep the system up to date. Deb/rpm packages are simple archives with additional metadata slapped on. The packaging system is transparent to contents: nothing forbids you to package versions 1.0 and 2.0 and have them happily coexist as long as they do not share common paths. In fact, a lot of packages are distributed in exactly the same way. It seems that the author has a solution - containers - and tries to find a problem for said solution.

jasode 4y ago
>Sure, containerizing an application is /easier/ than working out the dependency trees and solving dependency conflicts between them. It is by no means fundamentally better approach. [...] The [distro] packaging system is transparent to contents: nothing forbids you to package versions 1.0 and 2.0 and have them happily coexist as long as they do not share common paths. I think your comment is analyzing the problem from a different abstraction level than the author's examples. In other words, your alternative approach of "solving dependency conflicts" is abstract advice unless you try to make it concrete by focusing who solves those dependency conflicts. Using the author's example of a VSCode conflict (collision of "/usr/bin/code") with Actor in italics: - Microsoft owns commercial the build of /packages/visual-studio-code-bin - Filipe Laíns & Massimiliano Torromeo owns the open-source-license build of /packages/community/x86_64/code/ - Levente Polyak, et al owns the Arch Linux distribution - end user owns the computer that needs to run conflicting software Generalize the above matrix to every software package and consider which of those 4 actors can practically solve the conflicts in a scalable way? Filipe Laíns & Massimiliano Torromeo can't control what Microsoft does and vice-versa. (Ironically, the freedom to not be controlled by the other actor is one reason there's a package conflict!) And Levente Polyak could "solve" it by blessing Filipe Laíns's package and rejecting Microsoft's but this creates a new "problem" for users who specifically want Microsoft's commercial build. The fundamental issue is that you have independent actors that can't control what others do. Result is that sometimes software packages clash (namespace collisions, dependent libraries not in sync, incompatible licenses, etc). The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other.
- redkoala 4y ago
  There are design choices that can be made to guarantee namespace isolation - having different software packages installed within the same /usr/bin/ directory is a guarantee for namespace collisions.
- friendzis 4y ago
  > The fundamental issue is that you have independent actors that can't control what others do. Result is that sometimes software packages clash (namespace collisions, dependent libraries not in sync, incompatible licenses, etc). Yes, I agree. Where we are in disagreement is what the role of a distro is here. Distros are there to solve that stalemate in one way or another. In Code's case distro maintainers chose to mark these packages as conflicting. They could have changed namespace of one (or both) package[s]. As I have mentioned in reply to a sibling comment this is exactly the work distros are doing - solving the stalemate between upstreams. > The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other. Sure, containers do try to get past the stalemate, but they try to solve a different problem - how to make conflicting dependency trees coexist. Containers can also fail to solve the stalemate. Sure, containers can isolate `/usr/bin/code` between containers, but contention on `/etc/code`, `$HOME/.code` or other static user data still has to be solved one way or another.
- humanrebar 4y ago
  This is why we need packaging standards, especially around metadata, instead of further decamping into language-specific ecosystems. Because even with containerized apps, you still want a few launch scripts and a compiled program (for instance) that might contain multiple dependencies from different languages (C, Go, and Fortran, maybe).
- kasabali 4y ago
  > The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other What does that is bundling your dependencies, not containers. You could always bundle everything an app needs into a single tarball or a package. Containers didn't make it possible, they made it easy and popular.
pid-1 4y ago
> If anything, this argument dismisses most work done by distros > It seems that the author has a solution - containers - and tries to find a problem for said solution. I don't really follow this. Distro maintainers are working in a problem and some people are happy with the results. But the fact Nix, Guix flatpack and others exist shows other folks are not and are coming up with their solutions. It seems you're painting the author as some container weirdo just for not liking your favorite distribution method.
- friendzis 4y ago
  Distro maintainers are working on a problem (conflict resolution in dependency trees) and solving it. Use of containers is sidestepping of the problem. Containers solve entirely different problem - how do you make conflicting dependency trees coexist in isolation. Layered containers solve this particular problem quite well. But it's a different problem than distros try to solve.
  - dooglius 4y ago
    There is no "conflict" other than that which is created by most distros; there is no inherent problem to having different applications use different versions of libraries. Containers/nix/whatever do not really sidestep this, so much as not having this problem in the first place.

jasode 4y ago

>Sure, containerizing an application is /easier/ than working out the dependency trees and solving dependency conflicts between them. It is by no means fundamentally better approach. [...] The [distro] packaging system is transparent to contents: nothing forbids you to package versions 1.0 and 2.0 and have them happily coexist as long as they do not share common paths. I think your comment is analyzing the problem from a different abstraction level than the author's examples. In other words, your alternative approach of "solving dependency conflicts" is abstract advice unless you try to make it concrete by focusing who solves those dependency conflicts. Using the author's example of a VSCode conflict (collision of "/usr/bin/code") with Actor in italics: - Microsoft owns commercial the build of /packages/visual-studio-code-bin - Filipe Laíns & Massimiliano Torromeo owns the open-source-license build of /packages/community/x86_64/code/ - Levente Polyak, et al owns the Arch Linux distribution - end user owns the computer that needs to run conflicting software Generalize the above matrix to every software package and consider which of those 4 actors can practically solve the conflicts in a scalable way? Filipe Laíns & Massimiliano Torromeo can't control what Microsoft does and vice-versa. (Ironically, the freedom to not be controlled by the other actor is one reason there's a package conflict!) And Levente Polyak could "solve" it by blessing Filipe Laíns's package and rejecting Microsoft's but this creates a new "problem" for users who specifically want Microsoft's commercial build. The fundamental issue is that you have independent actors that can't control what others do. Result is that sometimes software packages clash (namespace collisions, dependent libraries not in sync, incompatible licenses, etc). The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other.

redkoala 4y ago
There are design choices that can be made to guarantee namespace isolation - having different software packages installed within the same /usr/bin/ directory is a guarantee for namespace collisions.
friendzis 4y ago
> The fundamental issue is that you have independent actors that can't control what others do. Result is that sometimes software packages clash (namespace collisions, dependent libraries not in sync, incompatible licenses, etc). Yes, I agree. Where we are in disagreement is what the role of a distro is here. Distros are there to solve that stalemate in one way or another. In Code's case distro maintainers chose to mark these packages as conflicting. They could have changed namespace of one (or both) package[s]. As I have mentioned in reply to a sibling comment this is exactly the work distros are doing - solving the stalemate between upstreams. > The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other. Sure, containers do try to get past the stalemate, but they try to solve a different problem - how to make conflicting dependency trees coexist. Containers can also fail to solve the stalemate. Sure, containers can isolate `/usr/bin/code` between containers, but contention on `/etc/code`, `$HOME/.code` or other static user data still has to be solved one way or another.
humanrebar 4y ago
This is why we need packaging standards, especially around metadata, instead of further decamping into language-specific ecosystems. Because even with containerized apps, you still want a few launch scripts and a compiled program (for instance) that might contain multiple dependencies from different languages (C, Go, and Fortran, maybe).
kasabali 4y ago
> The approach of using containers -- however flawed it is -- gets past the stalemate of independent actors in the software landscape being incompatible with each other What does that is bundling your dependencies, not containers. You could always bundle everything an app needs into a single tarball or a package. Containers didn't make it possible, they made it easy and popular.

pid-1 4y ago

> If anything, this argument dismisses most work done by distros > It seems that the author has a solution - containers - and tries to find a problem for said solution. I don't really follow this. Distro maintainers are working in a problem and some people are happy with the results. But the fact Nix, Guix flatpack and others exist shows other folks are not and are coming up with their solutions. It seems you're painting the author as some container weirdo just for not liking your favorite distribution method.

friendzis 4y ago
Distro maintainers are working on a problem (conflict resolution in dependency trees) and solving it. Use of containers is sidestepping of the problem. Containers solve entirely different problem - how do you make conflicting dependency trees coexist in isolation. Layered containers solve this particular problem quite well. But it's a different problem than distros try to solve.
- dooglius 4y ago
  There is no "conflict" other than that which is created by most distros; there is no inherent problem to having different applications use different versions of libraries. Containers/nix/whatever do not really sidestep this, so much as not having this problem in the first place.