5 ms·

> the main benefit is that it keeps your tools/libs updated with the latest. For tools you want to be on the latest version of, why not use a package manager l

> the main benefit is that it keeps your tools/libs updated with the latest. For tools you want to be on the latest version of, why not use a package manager like homebrew that isn't tied to your distro? I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority.

bravetraveler 3y ago
A distribution is a collection of software - if reduced to a certain point, the identity is lost! It makes sense to me for a distribution to find commonly wanted software, package it up, and make it available. There's tailoring to consider! Some go further and introduce patches. Not every distribution is as good at both contributing and being accepted upstream. Now, if you want something newer, then you're obviously welcome to acquire that as you see fit. The distribution will help with that, too -- providing build utils, headers, etc. Enabling third party repositories, ie: PPA/COPR There are also runtimes to avoid building; Flatpak/Snap, Docker/Podman, etc. Though, these also lose some of the 'distribution spirit'
- ripley12 3y ago
  This is a really good answer, thank you.
happymellon 3y ago
For tooling I use something like nvm, Pyenv, or SDKMan. I don't want Python to update from 3.10 to 3.11 silently, but I also don't want to be held back if they decide that they don't want to support Python 4 yet. I also want to be able to pin to particular versions if I want, or at least update in a structured way. I dislike the way that distros purge older packages, so building containers requires me to build my own package repo cache to allow me to have repeatable builds. It might make sense for the distro, but this is where the difference between the base operating systems requirements and mine differ.
mixmastamyk 3y ago
Brew has some sketchy practices (re system folders, telemetry). Thankfully there are plenty of alternatives… containers, flatpak, ppa, nix, tgz, etc.
- sjmulder 3y ago
  I settled on pkgsrc, very portable, configurable, sits cleanly alongside the OS or other packages managers and has a friendly community. Con: building from source, needs some massaging sometimes.
blablabla123 3y ago
> I've never understood the Linux culture of tightly coupling OS and package management The ABIs are quite tightly coupled though. There's e.g. a dependency to glibc, so either you make a compromise and use the oldest common glibc or ship packages for various glibc versions. So unless everything is built from source, this approach has its limits. edit: of course it's possible to use static linking but even then there's a residue of calls that are dynamically linked at runtime. (That's why there's flatpak, snap, ... which bundle dependencies redundantly)
jwells89 3y ago
Where to draw the line is fuzzy and probably subjective, but to me it seems natural for "system" packages to be updated and managed entirely separately from user-installed packages of all kinds (not just things that get wrapped in flatpaks or shipped with their jungles in Docker), even if that means dependency redundancy. I think for most people trading off some storage for assurance that user packages can never ever influence or worse, break the environment would be worth it.
- ripley12 3y ago
  That makes a lot of sense to me. I find it useful to keep the two separate; I think most of my confusion stems from people trying hard to use 1 tool to do both.
  - ElevenLathe 3y ago
    IMO two tools is reasonable -- something like homebrew or guix plus the system package manager. The frustration sets in when you realize you actually use a dozen: pip, npm, go get, Docker (which has the same problem again, fractally), homebrew, tfenv, gem, rvm, the list goes on. If you are in an environment where there is even cursory review of your dependencies, it can become a nightmare. This is the origin of (also nightmarish) inflexible corporate policies like "we are a CentOS shop: don't use anything that isn't in those repos without a months-long review and sign off from the VP of infosec."
jcastro 3y ago
| but I seem to be in the minority. Every time one of these threads comes around it's like the same thing on repeat: "I could either learn how to use a container or dist-upgrade my entire operating system to solve this."
michaelmrose 3y ago
If you peel off the layers that have accrued in some distros centralized package management is incredibly simple to implement and effective and met the performance,security, stability, and storage needs at the time of implementation. Think of it like manual transmissions. Consider the package management system of Arch or Void for instance. As in all cases where one technology supplants another its not enough to be superior in one dimension it's a hard sell unless its not only better but substantially better for all concerns without substantial cost or downside or foisted on users from on high by someone that can't fire by switching brands. For instance app images have been a thing for a while but nobody formalized it with a store with standards, security, testing for actual not theoretical compatibility etc so its a tool you can pick up rather than an actual ecosystem a user can rely on. Nix/guix are cool as heck but they are also complicated and difficult to understand. They can also have issues not present in the source software VMs are of course unwieldy App vms are restricted to Qubes Snap relies on a proprietary backend and starts slow among many and varied flaws. Flatpak still starts slower than native, doesn't have most software, isn't suitable for libraries or software that will be consumed by non flatpaks, doesn't have most software. Homebrew is mostly used by expats from Apple land because its virtues are moreso leveraging existing know how and work flows. Docker/Podman are more like developer tooling than user tools. Bedrock Linux is for crazy people who wish arch and ubuntu were one distro Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo
- doubled112 3y ago
  > Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo It already has the exported .desktop files, right? I wonder why they didn't just (ab)use that mechanism and add it to the default path on install
  - michaelmrose 3y ago
    It has desktop files. You could trivially add scripts named foo but you can't stick them somewhere global because the flatpaks actually exists in the users home dir but having a ~/bin is not standard either. It doesn't exist because it doesn't aesthetically fit. You can create it for yourself of course.
rlpb 3y ago
> I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority. It allows one side of your artificial divide to specify dependencies on the other. I can conceive of a packaging system that is designed with your split in mind and can cross that gap, but today no such system exists.

bravetraveler 3y ago

A distribution is a collection of software - if reduced to a certain point, the identity is lost! It makes sense to me for a distribution to find commonly wanted software, package it up, and make it available. There's tailoring to consider! Some go further and introduce patches. Not every distribution is as good at both contributing and being accepted upstream. Now, if you want something newer, then you're obviously welcome to acquire that as you see fit. The distribution will help with that, too -- providing build utils, headers, etc. Enabling third party repositories, ie: PPA/COPR There are also runtimes to avoid building; Flatpak/Snap, Docker/Podman, etc. Though, these also lose some of the 'distribution spirit'

ripley12 3y ago
This is a really good answer, thank you.

happymellon 3y ago

For tooling I use something like nvm, Pyenv, or SDKMan. I don't want Python to update from 3.10 to 3.11 silently, but I also don't want to be held back if they decide that they don't want to support Python 4 yet. I also want to be able to pin to particular versions if I want, or at least update in a structured way. I dislike the way that distros purge older packages, so building containers requires me to build my own package repo cache to allow me to have repeatable builds. It might make sense for the distro, but this is where the difference between the base operating systems requirements and mine differ.

mixmastamyk 3y ago

Brew has some sketchy practices (re system folders, telemetry). Thankfully there are plenty of alternatives… containers, flatpak, ppa, nix, tgz, etc.

sjmulder 3y ago
I settled on pkgsrc, very portable, configurable, sits cleanly alongside the OS or other packages managers and has a friendly community. Con: building from source, needs some massaging sometimes.

blablabla123 3y ago

> I've never understood the Linux culture of tightly coupling OS and package management The ABIs are quite tightly coupled though. There's e.g. a dependency to glibc, so either you make a compromise and use the oldest common glibc or ship packages for various glibc versions. So unless everything is built from source, this approach has its limits. edit: of course it's possible to use static linking but even then there's a residue of calls that are dynamically linked at runtime. (That's why there's flatpak, snap, ... which bundle dependencies redundantly)

jwells89 3y ago

Where to draw the line is fuzzy and probably subjective, but to me it seems natural for "system" packages to be updated and managed entirely separately from user-installed packages of all kinds (not just things that get wrapped in flatpaks or shipped with their jungles in Docker), even if that means dependency redundancy. I think for most people trading off some storage for assurance that user packages can never ever influence or worse, break the environment would be worth it.

ripley12 3y ago
That makes a lot of sense to me. I find it useful to keep the two separate; I think most of my confusion stems from people trying hard to use 1 tool to do both.
- ElevenLathe 3y ago
  IMO two tools is reasonable -- something like homebrew or guix plus the system package manager. The frustration sets in when you realize you actually use a dozen: pip, npm, go get, Docker (which has the same problem again, fractally), homebrew, tfenv, gem, rvm, the list goes on. If you are in an environment where there is even cursory review of your dependencies, it can become a nightmare. This is the origin of (also nightmarish) inflexible corporate policies like "we are a CentOS shop: don't use anything that isn't in those repos without a months-long review and sign off from the VP of infosec."

jcastro 3y ago

| but I seem to be in the minority. Every time one of these threads comes around it's like the same thing on repeat: "I could either learn how to use a container or dist-upgrade my entire operating system to solve this."

michaelmrose 3y ago

If you peel off the layers that have accrued in some distros centralized package management is incredibly simple to implement and effective and met the performance,security, stability, and storage needs at the time of implementation. Think of it like manual transmissions. Consider the package management system of Arch or Void for instance. As in all cases where one technology supplants another its not enough to be superior in one dimension it's a hard sell unless its not only better but substantially better for all concerns without substantial cost or downside or foisted on users from on high by someone that can't fire by switching brands. For instance app images have been a thing for a while but nobody formalized it with a store with standards, security, testing for actual not theoretical compatibility etc so its a tool you can pick up rather than an actual ecosystem a user can rely on. Nix/guix are cool as heck but they are also complicated and difficult to understand. They can also have issues not present in the source software VMs are of course unwieldy App vms are restricted to Qubes Snap relies on a proprietary backend and starts slow among many and varied flaws. Flatpak still starts slower than native, doesn't have most software, isn't suitable for libraries or software that will be consumed by non flatpaks, doesn't have most software. Homebrew is mostly used by expats from Apple land because its virtues are moreso leveraging existing know how and work flows. Docker/Podman are more like developer tooling than user tools. Bedrock Linux is for crazy people who wish arch and ubuntu were one distro Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo

doubled112 3y ago
> Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo It already has the exported .desktop files, right? I wonder why they didn't just (ab)use that mechanism and add it to the default path on install
- michaelmrose 3y ago
  It has desktop files. You could trivially add scripts named foo but you can't stick them somewhere global because the flatpaks actually exists in the users home dir but having a ~/bin is not standard either. It doesn't exist because it doesn't aesthetically fit. You can create it for yourself of course.

rlpb 3y ago

> I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority. It allows one side of your artificial divide to specify dependencies on the other. I can conceive of a packaging system that is designed with your split in mind and can cross that gap, but today no such system exists.