7 ms·

> auto-update more than a thousand packages, praying my Python and other projects survive, just because I want a browser update You may want to check out Nix.

> auto-update more than a thousand packages, praying my Python and other projects survive, just because I want a browser update You may want to check out Nix. It's a package manager which isolates each program's dependencies; so you can have multiple versions of the same package. > or a security fix having a centralized repository like this helps in case a it's a library that needs a security fix, because you only need a single update to apply the fix to all applications. Applications that bundle their own deps (including Docker images) will need to publish their own update with the updated version of the lib.

l0b0 7y ago
> You may want to check out Nix. Nix is a fantastic concept, and I hope it takes over the world. But the NixOS packages are a mess. I tried it for a few months last year before giving up after several packages and even whole collections of packages became unusable even in the stable repository. The repository needs some serious reworking before Nix can really shine.
- zrm 7y ago
  It's really trading one problem for a different one. The reason traditional distributions only package one version of a given library and make everything use that same version is so they only have to maintain one version of the library. If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the library separately. Doing that isn't much if any of a reduction in workload compared with getting every application to use the version the distribution ships, and is much more likely to end up with a situation where dozens of versions of the same library exist and half of them are broken in some way. The better solution is for libraries to only break compatibility between major versions. Then the packager can ship some suitably recent minor version for each major version of the library, at most two or three major versions are supported at any given time which keeps the maintenance overhead feasible, and every application can successfully link against one of those major versions or another.
  - avar 7y ago
    It doesn't entail any of that. Traditional distributions like Debian allow you to install any number of library combinations, they just do so badly by requiring you to do so on different installations updated at different times. Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild. It just means when users upgrade they can do so gradually for some sets of packages at a time. You can emulate this on traditional distributions by having a single VM image you use for your browser, then cloning the image, updating packages, and using that one for your E-Mail etc. Having a mechanism like this should mean less support is needed from the distribution, because system-wide breakages are less likely to occur. You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages. For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like. In Debian testing this sort of thing happens occasionally and will get fixed sooner than later, but that it happens at all is just an emergent property of how the versions are managed. If I were to run the latest firefox with those new versions and not touch the other packages until they're recompiled both myself and the package maintainers would be exposed to fewer bugs, not less. I'd get a bugfixed firefox today, and they wouldn't need to deal with bug reports about a broken upgrade, or firefox bugs in an older version users like me can't upgrade past simply because firefox happens to share the use of a popular OS library.
    - zrm 7y ago
      > Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild. It's not about combinations. It's about, there's a serious bug in the library and now there are 79 different actively used versions of it that need to be patched instead of 2, which means half of them never get fixed. > You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages. You'll get the same bugs and then the 5% of packages a security update breaks are broken until they're fixed, which should happen promptly because broken packages should be very high priority. Is it really better in that short time for the other 5% of applications to "work" but be insecure and get your system compromised because the new vulnerability is being actively exploited? The real solution is for sufficient testing to be done during the embargo period so that by the time the new version goes wide it doesn't actually break anything. > For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like. Right, that's a problem. It's valid to need version >= 5.6 of some library, but something has gone wrong if some other package specifically needs version 5.5 -- version 5.6 should be able to satisfy that dependency. Or if it can't then "5.6" should be 6.0 and it should be possible to have 5.x and 6.x installed together, but that should happen only rarely so that at most two or three mutually incompatible versions are in active use at once. In general the latest version should be able to satisfy applications expecting older versions and then you need only a suitably recent version and nothing else, and the lack of that is the real issue.
- millettjon 7y ago
  I've been using it for 2 years with very few problems.
danieldk 7y ago
You may want to check out Nix. It's a package manager which isolates each program's dependencies; so you can have multiple versions of the same package. In principle true, yes. But it comes with a cost. Even the nixpkgs Firefox maintainers are considering to only ship Firefox ESR starting with NixOS 20.03: https://discourse.nixos.org/t/firefox-on-19-09-could-be-marked-as-insecure-or-downgraded-to-esr-68/4577 https://discourse.nixos.org/t/firefox-on-19-09-could-be-mark... https://github.com/NixOS/nixpkgs/pull/72126 https://github.com/NixOS/nixpkgs/pull/72126
- progval 7y ago
  I won't blame them. Firefox is a huge piece of software, and is updating every month. It's a bit shitty of Mozilla to expect every single distribution (most of which are run by volunteers) to package all their new dependencies and check everything works every single month.
  - rusk 7y ago
    This sounds like ”move fast and break things” writ large, and a salutary lesson in the flaws of this approach.
  - jcelerier 7y ago
    but you can just use Mozilla's official binary packages, which are tested to work with a specific set of libraries, and I think are built with higher optimization levels (O3/pgo) than what distros conservatively do (O2) because of cargo-culting early-2000 gentoo forums (that was the case a few years ago, not 100% sure it is still the case today as I could not find easily the current release flags).
    - progval 7y ago
      Mozilla doesn't provide binary packages for all architectures and OSs supported by Nix/NixOS Maintainers also sometimes need to patch software to conform to their distribution's norm. For example, Debian patches it to accept extensions installed with APT. And I'm glad distribution maintainers always recompile software themselves, it helps making sure: 1. binaries are really made from the open source code (I know, it's not bullet-proof) 2. it's actually humanly possible to actually compile it from source (my pet peeve in this area is Kafka: it's used everywhere, but no one seems to know how to actually fully compile it from sources anymore)
jrockway 7y ago
Is this kind of like Ubuntu's "snap" thing? (I know snap involves cgroups, which aren't strictly necessary to give Firefox a different version of rust than everything else... but it seems widely deployed and easy to use, at least if you're on Ubuntu.)
xvilka 7y ago
Guix[1] also. It's written in Scheme but also solves the bootstrapping problem with minimal seed[2]. [1] http://guix.gnu.org/ http://guix.gnu.org/ [2] https://guix.gnu.org/manual/en/html_node/Reduced-Binary-Seed-Bootstrap.html https://guix.gnu.org/manual/en/html_node/Reduced-Binary-Seed...

l0b0 7y ago

> You may want to check out Nix. Nix is a fantastic concept, and I hope it takes over the world. But the NixOS packages are a mess. I tried it for a few months last year before giving up after several packages and even whole collections of packages became unusable even in the stable repository. The repository needs some serious reworking before Nix can really shine.

zrm 7y ago
It's really trading one problem for a different one. The reason traditional distributions only package one version of a given library and make everything use that same version is so they only have to maintain one version of the library. If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the library separately. Doing that isn't much if any of a reduction in workload compared with getting every application to use the version the distribution ships, and is much more likely to end up with a situation where dozens of versions of the same library exist and half of them are broken in some way. The better solution is for libraries to only break compatibility between major versions. Then the packager can ship some suitably recent minor version for each major version of the library, at most two or three major versions are supported at any given time which keeps the maintenance overhead feasible, and every application can successfully link against one of those major versions or another.
- avar 7y ago
  It doesn't entail any of that. Traditional distributions like Debian allow you to install any number of library combinations, they just do so badly by requiring you to do so on different installations updated at different times. Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild. It just means when users upgrade they can do so gradually for some sets of packages at a time. You can emulate this on traditional distributions by having a single VM image you use for your browser, then cloning the image, updating packages, and using that one for your E-Mail etc. Having a mechanism like this should mean less support is needed from the distribution, because system-wide breakages are less likely to occur. You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages. For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like. In Debian testing this sort of thing happens occasionally and will get fixed sooner than later, but that it happens at all is just an emergent property of how the versions are managed. If I were to run the latest firefox with those new versions and not touch the other packages until they're recompiled both myself and the package maintainers would be exposed to fewer bugs, not less. I'd get a bugfixed firefox today, and they wouldn't need to deal with bug reports about a broken upgrade, or firefox bugs in an older version users like me can't upgrade past simply because firefox happens to share the use of a popular OS library.
  - zrm 7y ago
    > Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild. It's not about combinations. It's about, there's a serious bug in the library and now there are 79 different actively used versions of it that need to be patched instead of 2, which means half of them never get fixed. > You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages. You'll get the same bugs and then the 5% of packages a security update breaks are broken until they're fixed, which should happen promptly because broken packages should be very high priority. Is it really better in that short time for the other 5% of applications to "work" but be insecure and get your system compromised because the new vulnerability is being actively exploited? The real solution is for sufficient testing to be done during the embargo period so that by the time the new version goes wide it doesn't actually break anything. > For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like. Right, that's a problem. It's valid to need version >= 5.6 of some library, but something has gone wrong if some other package specifically needs version 5.5 -- version 5.6 should be able to satisfy that dependency. Or if it can't then "5.6" should be 6.0 and it should be possible to have 5.x and 6.x installed together, but that should happen only rarely so that at most two or three mutually incompatible versions are in active use at once. In general the latest version should be able to satisfy applications expecting older versions and then you need only a suitably recent version and nothing else, and the lack of that is the real issue.
millettjon 7y ago
I've been using it for 2 years with very few problems.

danieldk 7y ago

You may want to check out Nix. It's a package manager which isolates each program's dependencies; so you can have multiple versions of the same package. In principle true, yes. But it comes with a cost. Even the nixpkgs Firefox maintainers are considering to only ship Firefox ESR starting with NixOS 20.03: https://discourse.nixos.org/t/firefox-on-19-09-could-be-marked-as-insecure-or-downgraded-to-esr-68/4577 https://discourse.nixos.org/t/firefox-on-19-09-could-be-mark... https://github.com/NixOS/nixpkgs/pull/72126 https://github.com/NixOS/nixpkgs/pull/72126

progval 7y ago
I won't blame them. Firefox is a huge piece of software, and is updating every month. It's a bit shitty of Mozilla to expect every single distribution (most of which are run by volunteers) to package all their new dependencies and check everything works every single month.
- rusk 7y ago
  This sounds like ”move fast and break things” writ large, and a salutary lesson in the flaws of this approach.
- jcelerier 7y ago
  but you can just use Mozilla's official binary packages, which are tested to work with a specific set of libraries, and I think are built with higher optimization levels (O3/pgo) than what distros conservatively do (O2) because of cargo-culting early-2000 gentoo forums (that was the case a few years ago, not 100% sure it is still the case today as I could not find easily the current release flags).
  - progval 7y ago
    Mozilla doesn't provide binary packages for all architectures and OSs supported by Nix/NixOS Maintainers also sometimes need to patch software to conform to their distribution's norm. For example, Debian patches it to accept extensions installed with APT. And I'm glad distribution maintainers always recompile software themselves, it helps making sure: 1. binaries are really made from the open source code (I know, it's not bullet-proof) 2. it's actually humanly possible to actually compile it from source (my pet peeve in this area is Kafka: it's used everywhere, but no one seems to know how to actually fully compile it from sources anymore)

jrockway 7y ago

Is this kind of like Ubuntu's "snap" thing? (I know snap involves cgroups, which aren't strictly necessary to give Firefox a different version of rust than everything else... but it seems widely deployed and easy to use, at least if you're on Ubuntu.)

xvilka 7y ago

Guix[1] also. It's written in Scheme but also solves the bootstrapping problem with minimal seed[2]. [1] http://guix.gnu.org/ http://guix.gnu.org/ [2] https://guix.gnu.org/manual/en/html_node/Reduced-Binary-Seed-Bootstrap.html https://guix.gnu.org/manual/en/html_node/Reduced-Binary-Seed...