10 ms·

It’s a bloody shame that Linux is incapable of reliable running software programs without layers and layers of disparate, competing abstractions. I’m increasin

It’s a bloody shame that Linux is incapable of reliable running software programs without layers and layers of disparate, competing abstractions. I’m increasingly convinced that the mere existence of a package manager (for programs, not source code) is a sign of a failed platform design. The fact that it exists at all is a miserable nightmare. Flatpak and Snap tried to make this better. But they do too much which just introduced new problems. Steam does not have this problem. Download game, play game. Software is not that complicated.

pxc 1y ago
> Steam does not have this problem. Download game, play game. Software is not that complicated. Steam on Linux essentially has its own "package manager" which uses containerized runtimes: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools https://gitlab.steamos.cloud/steamrt/steam-runtime-tools
- forrestthewoods 1y ago
  The Steam Linux Runtime is pretty bare bones. Their most recent runtime hasn’t been updated in 4 years. That’s quite different.
  - yjftsjthsd-h 1y ago
    > Their most recent runtime hasn’t been updated in 4 years. That’s quite different. Bad, even.
    - forrestthewoods 1y ago
      False. The exact opposite of bad. The “system” should provide the barest minimum of libraries. Programs should ship as many of their dependencies as is technically feasible. Oh what’s that? Are crying about security updates? Yeah well unfortunately you shipped everything in a Docker container so you need to rebuild and redeploy all of your hierarchical images anyways.
      - yjftsjthsd-h 1y ago
        > False. The exact opposite of bad. I don't mind stable base systems, I don't mind slow and well tested updates, I actively like holding stable ABIs, but if you haven't updated anything in 4 years, then you are missing bug and security fixes. Not everything needs to be Arch, but this opposite extreme is also bad. > The “system” should provide the barest minimum of libraries. Programs should ship as many of their dependencies as is technically feasible. And then application developers fail to update their vendored dependencies, and thereby leave their users exposed to vulnerabilities. (This isn't hypothetical, it's a thing that has happened.) No, thank you. >Oh what’s that? Are crying about security updates? Yeah well unfortunately you shipped everything in a Docker container so you need to rebuild and redeploy all of your hierarchical images anyways. So... are you arguing that we do need to ship everything vendored in so that it can't be updated, or that we need to actually break out packages to be managed independently (like every major Linux distribution does)? Because you appear to have advocated for vendoring everything, and then immediately turned around to criticize the situation where things get vendored in.
        forrestthewoods 1y ago
        > So... are you arguing that we do need to ship everything vendored in so that it can't be updated, I’m arguing that the prevalence of Docker is strong evidence that the “Linux model” has fundamentally failed. Many people disagree with that claim and think that TheLinuxModel is good actually. However I point that these people almost definitely make extensive use of Docker. And that Docker (or similar) are actually necessary to reliably run programs on Linux because TheLinuxModel is so bad and has failed so badly. If you believe in TheLinuxModel and also do not use Docker to deploy your software then you are, in the year 2025, a very rare outlier. Personally, I am very pro ShipYourFuckingDependencies. But I also dont think that deploying a program should be much more complicated than sharing an uncompressed zip file. Docker adds a lot of crusting. Packaging images/zips/deployments should be near instantaneous.
        imiric 1y ago
        > I’m arguing that the prevalence of Docker is strong evidence that the “Linux model” has fundamentally failed. That is a very silly argument considering that Docker is built on primitives that Linux exposes. All Docker does is make them accessible via a friendly UI, and adds some nice abstractions on top such as images. It's also silly because there is no single "Linux model". There are many different ways of running applications on Linux, depending on the environment, security requirements, user preference, and so on. The user is free to simply compile software on their own if they wish. This versatility is a strength, not a weakness. Your argument seems to be against package managers as a whole, so I'm not sure why you're attacking Linux. There are many ecosystems where dependencies are not vendored and a package manager is useful, viceversa, or even both. There are very few objectively bad design decisions in computing. They're mostly tradeoffs. Choosing a package manager vs vendoring is one such scenario. So we can argue endlessly about it, or we can save ourselves some time and agree that both approaches have their merits and detriments.
chpatrick 1y ago
Does Steam let you control the whole dependency tree of your software, including modifying any part of it and rebuilding from source as necessary, or pushing it to a whole other machine? Real life software is much more than just downloading a game and running it.
- forrestthewoods 1y ago
  Pushing to another machine? Yes. By strict definition. Steam exists to sell pre-compiled proprietary programs for dollars. Rebuilding? No. Linux package management is so-so at allowing you to compile programs. But they’re dogshit garbage at helping you reliably run that program. Docker exists because Linux can’t run software.
  - chpatrick 1y ago
    Docker (and also Nix) exists because it's not trivial to manage the whole environment needed to run an application. There's a reason everyone uses it for ops these days, and not some Windows thing.
    - forrestthewoods 1y ago
      Yes. The reason is that Linux made very bad design decisions. > it’s not trivial to manage the whole environment needed to run the application This is a distinctly Linux problem. Despite what Linux would lead you to believe it is not actually hard to run a computer program.
      - chpatrick 1y ago
        Ok then where is the amazing non Linux deployment solution that everyone uses instead?
- vilunov 1y ago
  > Real life software is much more than just downloading a game and running it. Real life software outside of Linux is pretty much just downloading and running it. Only in Linux we don't have a single stable OS ABI, forcing us to find the correct package for our specific distro, or to package the software ourselves.
anglesideangle 1y ago
> I’m increasingly convinced that the mere existence of a package manager (for programs, not source code) is a sign of a failed platform design. Nix is a build system for source code, similar to make. It is such a robust build system that it also can be used as a package manager with a binary cache
zbentley 1y ago
> I’m increasingly convinced that the mere existence of a package manager (for programs, not source code) is a sign of a failed platform design > Steam does not have this problem. Download game, play game. These statements seem contradictory. Steam is a package manager. So is the Apple App Store. Sure, they have different UX than, say, apt/dnf/brew/apk/chocolatey, but they're conceptually package managers. Given that, I'm unclear what the gripe is (though I'm totally down to rip on Snap/Flatpak; I won't rant here, but I did elsewhere: https://news.ycombinator.com/item?id=44069483 https://news.ycombinator.com/item?id=44069483). Is the issue with OS/vendor-maintained package managers? Or is the issue with package installers that invoke really complicated build systems at install time (e.g. package managers that install from source)?
- forrestthewoods 1y ago
  This is getting into semantics. Personally I would not consider downloading a zip file from a GitHub releases page in a web browser to be using a “package manager”. But someone could try and make that argument. None of this has formal definitions which makes it difficult to discuss. Your rant on Snap/Flatpak was great. The core gripe is that I want running computer programs on Linux to be easy and reliable. It is not. MacOS and Windows are far more reliable, and they don’t require (imho) package managers to do it.
  - zbentley 1y ago
    > The core gripe is that I want running computer programs on Linux to be easy and reliable. It is not. No argument here. What's interesting, though, is that package managers on Linux are the attempted solution to that problem. Without them, hand-managing dependencies and dependency discovery via the "download a zipfile from GitHub" approach just falls apart: said zipfile often wants to link against other libraries when it launches. Windows (and runtimes like Golang) take a batteries-included approach by vendoring many/most dependency artifacts with binary distributions. MacOS app bundles do a bit of that, and also have a really consistent story about what system-level dependencies are available (which is only a feasible approach for MacOS because there's a single maintainer and distributor of the system). But even on those platforms, things break down a lot! There are all sorts of problems for various Windows apps that need to be solved by "acquire so-and-so.dll and copy it into this app's install folder, or else its vendored version of that dll will break on your system". Homebrew on MacOS exists (and has highly variable complexity levels re: installation/dependency discovery) precisely because the amount of labor required to participate in the nice app bundle/MacOS native-app ecosystem is too great for many developers. That said, there's not really a punchline here. It's complicated, I guess? > Your rant on Snap/Flatpak was great. Thank you!

pxc 1y ago

> Steam does not have this problem. Download game, play game. Software is not that complicated. Steam on Linux essentially has its own "package manager" which uses containerized runtimes: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools https://gitlab.steamos.cloud/steamrt/steam-runtime-tools

forrestthewoods 1y ago
The Steam Linux Runtime is pretty bare bones. Their most recent runtime hasn’t been updated in 4 years. That’s quite different.
- yjftsjthsd-h 1y ago
  > Their most recent runtime hasn’t been updated in 4 years. That’s quite different. Bad, even.
  - forrestthewoods 1y ago
    False. The exact opposite of bad. The “system” should provide the barest minimum of libraries. Programs should ship as many of their dependencies as is technically feasible. Oh what’s that? Are crying about security updates? Yeah well unfortunately you shipped everything in a Docker container so you need to rebuild and redeploy all of your hierarchical images anyways.
    - yjftsjthsd-h 1y ago
      > False. The exact opposite of bad. I don't mind stable base systems, I don't mind slow and well tested updates, I actively like holding stable ABIs, but if you haven't updated anything in 4 years, then you are missing bug and security fixes. Not everything needs to be Arch, but this opposite extreme is also bad. > The “system” should provide the barest minimum of libraries. Programs should ship as many of their dependencies as is technically feasible. And then application developers fail to update their vendored dependencies, and thereby leave their users exposed to vulnerabilities. (This isn't hypothetical, it's a thing that has happened.) No, thank you. >Oh what’s that? Are crying about security updates? Yeah well unfortunately you shipped everything in a Docker container so you need to rebuild and redeploy all of your hierarchical images anyways. So... are you arguing that we do need to ship everything vendored in so that it can't be updated, or that we need to actually break out packages to be managed independently (like every major Linux distribution does)? Because you appear to have advocated for vendoring everything, and then immediately turned around to criticize the situation where things get vendored in.
      - forrestthewoods 1y ago
        > So... are you arguing that we do need to ship everything vendored in so that it can't be updated, I’m arguing that the prevalence of Docker is strong evidence that the “Linux model” has fundamentally failed. Many people disagree with that claim and think that TheLinuxModel is good actually. However I point that these people almost definitely make extensive use of Docker. And that Docker (or similar) are actually necessary to reliably run programs on Linux because TheLinuxModel is so bad and has failed so badly. If you believe in TheLinuxModel and also do not use Docker to deploy your software then you are, in the year 2025, a very rare outlier. Personally, I am very pro ShipYourFuckingDependencies. But I also dont think that deploying a program should be much more complicated than sharing an uncompressed zip file. Docker adds a lot of crusting. Packaging images/zips/deployments should be near instantaneous.
        imiric 1y ago
        > I’m arguing that the prevalence of Docker is strong evidence that the “Linux model” has fundamentally failed. That is a very silly argument considering that Docker is built on primitives that Linux exposes. All Docker does is make them accessible via a friendly UI, and adds some nice abstractions on top such as images. It's also silly because there is no single "Linux model". There are many different ways of running applications on Linux, depending on the environment, security requirements, user preference, and so on. The user is free to simply compile software on their own if they wish. This versatility is a strength, not a weakness. Your argument seems to be against package managers as a whole, so I'm not sure why you're attacking Linux. There are many ecosystems where dependencies are not vendored and a package manager is useful, viceversa, or even both. There are very few objectively bad design decisions in computing. They're mostly tradeoffs. Choosing a package manager vs vendoring is one such scenario. So we can argue endlessly about it, or we can save ourselves some time and agree that both approaches have their merits and detriments.

chpatrick 1y ago

Does Steam let you control the whole dependency tree of your software, including modifying any part of it and rebuilding from source as necessary, or pushing it to a whole other machine? Real life software is much more than just downloading a game and running it.

forrestthewoods 1y ago
Pushing to another machine? Yes. By strict definition. Steam exists to sell pre-compiled proprietary programs for dollars. Rebuilding? No. Linux package management is so-so at allowing you to compile programs. But they’re dogshit garbage at helping you reliably run that program. Docker exists because Linux can’t run software.
- chpatrick 1y ago
  Docker (and also Nix) exists because it's not trivial to manage the whole environment needed to run an application. There's a reason everyone uses it for ops these days, and not some Windows thing.
  - forrestthewoods 1y ago
    Yes. The reason is that Linux made very bad design decisions. > it’s not trivial to manage the whole environment needed to run the application This is a distinctly Linux problem. Despite what Linux would lead you to believe it is not actually hard to run a computer program.
    - chpatrick 1y ago
      Ok then where is the amazing non Linux deployment solution that everyone uses instead?
vilunov 1y ago
> Real life software is much more than just downloading a game and running it. Real life software outside of Linux is pretty much just downloading and running it. Only in Linux we don't have a single stable OS ABI, forcing us to find the correct package for our specific distro, or to package the software ourselves.

anglesideangle 1y ago

> I’m increasingly convinced that the mere existence of a package manager (for programs, not source code) is a sign of a failed platform design. Nix is a build system for source code, similar to make. It is such a robust build system that it also can be used as a package manager with a binary cache

zbentley 1y ago

> I’m increasingly convinced that the mere existence of a package manager (for programs, not source code) is a sign of a failed platform design > Steam does not have this problem. Download game, play game. These statements seem contradictory. Steam is a package manager. So is the Apple App Store. Sure, they have different UX than, say, apt/dnf/brew/apk/chocolatey, but they're conceptually package managers. Given that, I'm unclear what the gripe is (though I'm totally down to rip on Snap/Flatpak; I won't rant here, but I did elsewhere: https://news.ycombinator.com/item?id=44069483 https://news.ycombinator.com/item?id=44069483). Is the issue with OS/vendor-maintained package managers? Or is the issue with package installers that invoke really complicated build systems at install time (e.g. package managers that install from source)?

forrestthewoods 1y ago
This is getting into semantics. Personally I would not consider downloading a zip file from a GitHub releases page in a web browser to be using a “package manager”. But someone could try and make that argument. None of this has formal definitions which makes it difficult to discuss. Your rant on Snap/Flatpak was great. The core gripe is that I want running computer programs on Linux to be easy and reliable. It is not. MacOS and Windows are far more reliable, and they don’t require (imho) package managers to do it.
- zbentley 1y ago
  > The core gripe is that I want running computer programs on Linux to be easy and reliable. It is not. No argument here. What's interesting, though, is that package managers on Linux are the attempted solution to that problem. Without them, hand-managing dependencies and dependency discovery via the "download a zipfile from GitHub" approach just falls apart: said zipfile often wants to link against other libraries when it launches. Windows (and runtimes like Golang) take a batteries-included approach by vendoring many/most dependency artifacts with binary distributions. MacOS app bundles do a bit of that, and also have a really consistent story about what system-level dependencies are available (which is only a feasible approach for MacOS because there's a single maintainer and distributor of the system). But even on those platforms, things break down a lot! There are all sorts of problems for various Windows apps that need to be solved by "acquire so-and-so.dll and copy it into this app's install folder, or else its vendored version of that dll will break on your system". Homebrew on MacOS exists (and has highly variable complexity levels re: installation/dependency discovery) precisely because the amount of labor required to participate in the nice app bundle/MacOS native-app ecosystem is too great for many developers. That said, there's not really a punchline here. It's complicated, I guess? > Your rant on Snap/Flatpak was great. Thank you!