4 ms·

>GNU/Linux distributions in general lack the aforementioned perks of Guix. Some of the most critical points include: >Lack of support for multiple package vers

>GNU/Linux distributions in general lack the aforementioned perks of Guix. Some of the most critical points include: >Lack of support for multiple package version, or “dependency hell”. Say, when the latest mpv requires a new ffmpeg, but upgrading ffmpeg breaks most other programs relying on it, we are stuck we dilemma: either we break some packages or we stick to older versions of other packages. Worse, a program could end up not being packaged or support by the OS at all. This issue is inherent to most distributions which can simply not provide the guarantee to fulfill their primary objective: package any program. I disagree. Having multiple versions of a package means having old versions of a package, and that's something most users should not be messing with because they are not in a position to track and backport security fixes. It's always undesirable to have to a dependency on an old, probably unsupported version of a library. The distributions that do it have a correspondingly huge maintenance burden. One of the advantages (from my point of view) of a lighter rolling distribution like Arch is that because all the software on the system is expected to be compatible with a library version that is upstream-supported, there is significantly less maintenance work to be done. Note that this is compatible with, say, packaging both GTK2 and GTK3 programs, since both of those are supported upstream. The OS is perfectly compatible with shipping multiple versions of a library, but Arch sensibly (IMO) chooses not to do so by default. One way to quickly experience the pain points of the OP's way of doing things is to try to use or distribute software written in a language with a "modern" build tool like npm or cargo. These systems implicitly encourage hardcoding a single version (or a small set of versions) as dependencies, and the convenience of this means that many developers rarely update the list even if the new library versions are fully compatible with their code. So as the user building the software, or someone who wants to distribute it, you can either run with libraries that have known vulnerabilities, or you can update the libraries yourself and run an unsupported configuration, hoping you don't break anything in the process. A more reasonable position is that it is a bug if your program crashes with the latest version of a library.

zapzupnz 8y ago
> A more reasonable position is that it is a bug if your program crashes with the latest version of a library This makes sense for actively maintained code. There are a lot of pieces of software that aren't actively maintained but that don't exhibit any breaking bugs and people continue to rely on them. If the libraries that these pieces of software ever make breaking changes, either (a) someone has to step up and start maintaining the software again, (b) an older version of the library must be installed, or (c) the software dropped, annoying a lot of people who still depend on the tool. What macOS has is .frameworks, which let you version shared dynamic libraries. When building a project against a framework, one can either choose to build against a specific version or (more commonly) leave the version unspecified and use the latest. No fuss, no muss.
- white-flame 8y ago
  > When building a project against a framework... That still implies active maintenance, ie doing new builds. If it's assumed to work with the "latest version", but then breaks in the future, it is a decision outside of the build itself as to which version of the library it should link up with. The only thing that should be baked into the software is which specific version of the dynamic lib it was compatible with, then externally the system can determine which most-recent version of the library is still compatible.
  - zapzupnz 8y ago
    > then externally the system can determine which most-recent version of the library is still compatible This is great until a more recent version of a library still has the same interface but a completely different behaviour or seriously breaking bug in the implementation.
    - white-flame 8y ago
      That's exactly what I'm talking about. That compatibility information is what needs to be captured, and is outside any future preference that the program was originally built to. Instead, most automatic systems just blindly say "this version number is newer, so use that" and break everything. Programs were built to a specific version which worked, and only those versions compatible to that specific version should be used.
Ericson2314 8y ago
Distributions (package sets) can and do enforce that a as few versions of something as possible be supported. But it's just stupid to make this a hard requirement of the package manager itself---both old-school upgrades and new-school docker-style workflows become so much harder.
TeMPOraL 8y ago
Counterargument: constant updating contributes to "software bit rot" - i.e. perfectly good hardware and software suddenly stopping to work simply because they were not updated to keep up with the changes of the environment around it. Put another way: updates are risky, and can randomly and unexpectedly break your setup. The software you're depending on may no longer be developed, or the new version (or alternatives) are worse than the old one - which is something increasingly frequent in this industry. Not every update is important. Hell, I'd say most aren't, since developers are freely mixing security patches with feature updates. Until the culture changes to cleanly separate the two, all updates will carry the risk of degrading or breaking things. > These systems [npm or cargo] implicitly encourage hardcoding a single version (or a small set of versions) as dependencies, and the convenience of this means that many developers rarely update the list even if the new library versions are fully compatible with their code. Counterpoint: version pinning prevents your project from suddenly breaking apart at unexpected times, because some dependency had a breaking change. It also prevents you from automatically pulling in vulnerabilities introduced - sometimes intentionally - in the newer version. NodeJS in particular has a "malicious package" drama roughly every 6 months. In all honesty, you should be auditing your dependencies anyway, and it's harder to keep up if they change faster than you can review them.
- nwmcsween 8y ago
  The package manager should have regression tests that test for linking breakage, etc before installing, pinning is just a lazy solution.
AnIdiotOnTheNet 8y ago
Works > Secure. Don't believe me? You're using a computer right now. Doubtless you are running both hardware and software that have had vulnerabilities exposed in the past and almost certainly have vulnerabilities right now that haven't been exposed yet. You use them anyway because at the end of the day shit needs to get done. That's why being able to run out of date things is important to people in the real world.
- millettjon 8y ago
  Exactly. If additional security is needed it can be applied in layers e.g., container sandboxing. If updates are forced old/infrequently used content will simply be broken/not accessible.

zapzupnz 8y ago

> A more reasonable position is that it is a bug if your program crashes with the latest version of a library This makes sense for actively maintained code. There are a lot of pieces of software that aren't actively maintained but that don't exhibit any breaking bugs and people continue to rely on them. If the libraries that these pieces of software ever make breaking changes, either (a) someone has to step up and start maintaining the software again, (b) an older version of the library must be installed, or (c) the software dropped, annoying a lot of people who still depend on the tool. What macOS has is .frameworks, which let you version shared dynamic libraries. When building a project against a framework, one can either choose to build against a specific version or (more commonly) leave the version unspecified and use the latest. No fuss, no muss.

white-flame 8y ago
> When building a project against a framework... That still implies active maintenance, ie doing new builds. If it's assumed to work with the "latest version", but then breaks in the future, it is a decision outside of the build itself as to which version of the library it should link up with. The only thing that should be baked into the software is which specific version of the dynamic lib it was compatible with, then externally the system can determine which most-recent version of the library is still compatible.
- zapzupnz 8y ago
  > then externally the system can determine which most-recent version of the library is still compatible This is great until a more recent version of a library still has the same interface but a completely different behaviour or seriously breaking bug in the implementation.
  - white-flame 8y ago
    That's exactly what I'm talking about. That compatibility information is what needs to be captured, and is outside any future preference that the program was originally built to. Instead, most automatic systems just blindly say "this version number is newer, so use that" and break everything. Programs were built to a specific version which worked, and only those versions compatible to that specific version should be used.

Ericson2314 8y ago

Distributions (package sets) can and do enforce that a as few versions of something as possible be supported. But it's just stupid to make this a hard requirement of the package manager itself---both old-school upgrades and new-school docker-style workflows become so much harder.

TeMPOraL 8y ago

Counterargument: constant updating contributes to "software bit rot" - i.e. perfectly good hardware and software suddenly stopping to work simply because they were not updated to keep up with the changes of the environment around it. Put another way: updates are risky, and can randomly and unexpectedly break your setup. The software you're depending on may no longer be developed, or the new version (or alternatives) are worse than the old one - which is something increasingly frequent in this industry. Not every update is important. Hell, I'd say most aren't, since developers are freely mixing security patches with feature updates. Until the culture changes to cleanly separate the two, all updates will carry the risk of degrading or breaking things. > These systems [npm or cargo] implicitly encourage hardcoding a single version (or a small set of versions) as dependencies, and the convenience of this means that many developers rarely update the list even if the new library versions are fully compatible with their code. Counterpoint: version pinning prevents your project from suddenly breaking apart at unexpected times, because some dependency had a breaking change. It also prevents you from automatically pulling in vulnerabilities introduced - sometimes intentionally - in the newer version. NodeJS in particular has a "malicious package" drama roughly every 6 months. In all honesty, you should be auditing your dependencies anyway, and it's harder to keep up if they change faster than you can review them.

nwmcsween 8y ago
The package manager should have regression tests that test for linking breakage, etc before installing, pinning is just a lazy solution.

AnIdiotOnTheNet 8y ago

Works > Secure. Don't believe me? You're using a computer right now. Doubtless you are running both hardware and software that have had vulnerabilities exposed in the past and almost certainly have vulnerabilities right now that haven't been exposed yet. You use them anyway because at the end of the day shit needs to get done. That's why being able to run out of date things is important to people in the real world.

millettjon 8y ago
Exactly. If additional security is needed it can be applied in layers e.g., container sandboxing. If updates are forced old/infrequently used content will simply be broken/not accessible.