5 ms·

Exactly this, but not just Python. The traditional way most Linux apps work is that they are splayed over your filesystem with hard coded references to absolute

Exactly this, but not just Python. The traditional way most Linux apps work is that they are splayed over your filesystem with hard coded references to absolute paths and they expect you to provide all of their dependencies for them. Basically the Linux world was actively designed to apps difficult to distribute.

dabockster 1y ago
> Basically the Linux world was actively designed to apps difficult to distribute. It has "too many experts", meaning that everyone has too much decision making power to force their own tiny variations into existing tools. So you end up needing 5+ different Python versions spread all over the file system just to run basic programs.
antod 1y ago
It wasn't about making apps difficult to distribute at all, that's a later side effect. Originally distros were built around making a coherent unified system of package management that made it easier to manage a system due to everything being built on the same base. Back then Linux users were sysadmins and/or C programmers managing (very few) code dependencies via tarballs. With some CPAN around too. For a sysadmin, distros like Debian were an innovative godsend for installing and patching stuff. Especially compared to the hell that was Windows server sysadmin back in the 90s. The developer oriented language ecosystem dependency explosion was a more recent thing. When the core distros started, apps were distributed as tarballs of source code. The distros were the next step in distribution - hence the name.
- IshKebab 1y ago
  Right but those things are not unrelated. Back in the day if you suggested to the average FOSS developer that maybe it should just be possible to download a zip of binaries, unzip it anywhere and run it with no extra effort (like on Windows), they would say that that is actively bad. You should be installing it from a distro package!! What about security updates of dependencies?? And so on. Docker basically overrules these impractical ideas.
  - graemep 1y ago
    I would say those are good point, not impractical ideas. You make software harder to distribute (so inconvenient for developers and distributors) but gain better security updates and lower resource usage.
    - IshKebab 1y ago
      The success of Docker shows that this is a minority view.
      - graemep 1y ago
        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?
        IshKebab 1y ago
        > 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.
        graemep 1y ago
rwmj 1y ago
It was more like, library writers forgot how to provide stable APIs for their software, and applications decided they just wanted to bundle all the dependencies they needed together and damn the consequences on the rest of the system. Hence we got static linked binaries and then containers.
- arccy 1y ago
  even if you have a stable interface... the user might not want to install it and then forget to remove it down the line

dabockster 1y ago

> Basically the Linux world was actively designed to apps difficult to distribute. It has "too many experts", meaning that everyone has too much decision making power to force their own tiny variations into existing tools. So you end up needing 5+ different Python versions spread all over the file system just to run basic programs.

antod 1y ago

It wasn't about making apps difficult to distribute at all, that's a later side effect. Originally distros were built around making a coherent unified system of package management that made it easier to manage a system due to everything being built on the same base. Back then Linux users were sysadmins and/or C programmers managing (very few) code dependencies via tarballs. With some CPAN around too. For a sysadmin, distros like Debian were an innovative godsend for installing and patching stuff. Especially compared to the hell that was Windows server sysadmin back in the 90s. The developer oriented language ecosystem dependency explosion was a more recent thing. When the core distros started, apps were distributed as tarballs of source code. The distros were the next step in distribution - hence the name.

IshKebab 1y ago
Right but those things are not unrelated. Back in the day if you suggested to the average FOSS developer that maybe it should just be possible to download a zip of binaries, unzip it anywhere and run it with no extra effort (like on Windows), they would say that that is actively bad. You should be installing it from a distro package!! What about security updates of dependencies?? And so on. Docker basically overrules these impractical ideas.
- graemep 1y ago
  I would say those are good point, not impractical ideas. You make software harder to distribute (so inconvenient for developers and distributors) but gain better security updates and lower resource usage.
  - IshKebab 1y ago
    The success of Docker shows that this is a minority view.
    - graemep 1y ago
      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?
      - IshKebab 1y ago
        > 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.
        graemep 1y ago

rwmj 1y ago

It was more like, library writers forgot how to provide stable APIs for their software, and applications decided they just wanted to bundle all the dependencies they needed together and damn the consequences on the rest of the system. Hence we got static linked binaries and then containers.

arccy 1y ago
even if you have a stable interface... the user might not want to install it and then forget to remove it down the line