5 ms·

>Sure, containerizing an application is /easier/ than working out the dependency trees and solving dependency conflicts between them. It is by no means fundamen

by 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.

by jasode 4y ago

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.