I was replying to a comment comparing the distribution of self-contained binaries to Linux package management. This is a much more straightforward question
Containers are a related (as the GP comment says) thing, but offer a different and varied set of tradeoffs.
Those tradeoffs also depend on what you are using containers for. Scaling by deploying large numbers of containers on a cloud providers? Applications with bundled dependencies on the same physical server? As a way of providing a uniform development environment?
> Those tradeoffs also depend on what you are using containers for. Scaling by deploying large numbers of containers on a cloud providers? Applications with bundled dependencies on the same physical server? As a way of providing a uniform development environment?
Those are all pretty much the same thing. I want to distribute programs and have them work reliably. Think about how they would work if Linux apps were portable as standard:
> Scaling by deploying large numbers of containers on a cloud providers?
You would just rsync your deployment and run it.
> Applications with bundled dependencies on the same physical server?
Just unzip each app in its own folder.
> As a way of providing a uniform development environment?
Just provide a zip with all the required development tools.
> Those are all pretty much the same thing. I want to distribute programs and have them work reliably.
Yes, they are very similar in someways, but the tradeoffs (compared to using containers) would be very different.
> You would just rsync your deployment and run it.
If you are scaling horizontally and not using containers you are already probably automating provisioning and maintenance of VMs, so you can just use the same tools to automate deployment. You would also be running one application per VM so you do not need to worry about portability.
> Just unzip each app in its own folder.
What is stopping people from doing this? You can use an existing system like Appimage, or write a windows like installer (Komodo used to have one). The main barrier as far as I can see is that users do not like it.
> Just provide a zip with all the required development tools.
vs a container you still have to configure it and isolation can be nice to have in a development environment.
vs installing what you need with a package manager, it would be less hassle in some cases but this is a problem that is largely solved by things like language package managers.
Most Linux apps do not bundle their dependencies, don't provide binary downloads, and aren't portable (they use absolute paths). Some dependencies are especially awkward like glibc and Python.
It is improving with programs written in Rust and Go which tend to a) be statically linked, and b) are more modern so they are less likely to make the mistake of using absolute paths.
Incidentally this is also the reason Nix has to install everything globally in a single root-owned directory.
> The main barrier as far as I can see is that users do not like it.
I don't think so. They've never been given the option.
> Most Linux apps do not bundle their dependencies, don't provide binary downloads, and aren't portable (they use absolute paths).
That is because the developers choose not to, and no one else chooses to do it for them. On the other hand lots of people package applications (and libraries) for all the Linux distros out there.
> I don't think so. They've never been given the option.
The options exist. AppImage does exactly what you want. Snap and Flatpak are cross distro, have lots of apps, and are preinstalled by many major distros.
You make software harder to distribute (so inconvenient for developers and distributors) but gain better security updates and lower resource usage.