4 ms·

Ok maybe i am missing something, but it seems to me you may want some mutability in a package manager. For example, updates that are simply bug fixes and securi

by hristov 14y ago

Ok maybe i am missing something, but it seems to me you may want some mutability in a package manager. For example, updates that are simply bug fixes and security fixes but are backward compatible should be substituted for older versions. Suppose you have a networking library, which is used by several applications. All of a sudden you find a security hole in the networking library. And then you fix it. But the fix does not affect any of the published APIs or functionality and is thus completely backwards compatible for all legal uses. When you fix the library you release a new version of it. Shouldn't that new version be automatically used for all applications that use the library? If you have an immutable packaging system, all applications will still use the old version of the library and they would have to have their packages explicitly modified to use the new version. Now this may work for super high value and super secure systems, where someone has the time to individually test the new version of the library with each application that uses it and then individually update each application. But for the usual desktop system this sounds like a recipe for having a bunch of out-dated hole ridden software, where multiple badly maintained applications still carry known security holes from many years ago; or, in other words, this sounds very much like Windows.

moonboots 14y ago
This is a potential problem, but I think in practice backwards compatible updates and patches for Nix could work very similarly compared to a distro like Debian. For example, when openssl releases a security fix, Debian uses its large, mostly automated test suite [1] to verify that this new update does not break compile and (to a lesser extent) runtime compatibility and correctness. Instead of an implicit promise of compatibility, a Nix continuous build and testing system[2] could explicitly mark openssl-dependent packages as compatible by bumping their versions. The end user would need to update a lot more packages, but these cost could be reduced by binary diffing old and new packages, which should be almost identical with the exception of dependency metadata. [1] http://www.youtube.com/watch?v=3aoDjW1bjxo http://www.youtube.com/watch?v=3aoDjW1bjxo [2] http://nixos.org/hydra/ http://nixos.org/hydra/
9mit3t2m9h9a 14y ago
In practice it gives you more options for a price of keeping more junk on HDD. After a security update, all application hashes are calculated using the new default version of a library. So, once you launch an update you get a fresh package set linked against the latest version of the library. For large applications used by many people you are likely to get a small binary patch from the previous version, but this is just an optimization. So the default is just spending a bit more resources on the same behaviour. What does change, though, is that you can opt to pass another version of the library to a specific application manually. If update from libA v1 to libA v2 breaks AppX, you can easily build AppX-with-libA-v1. It doesn't make any sense for security updates, but for major interface changes it sometimes provides a smoother migration path.

by hristov 14y ago

moonboots 14y ago

This is a potential problem, but I think in practice backwards compatible updates and patches for Nix could work very similarly compared to a distro like Debian. For example, when openssl releases a security fix, Debian uses its large, mostly automated test suite [1] to verify that this new update does not break compile and (to a lesser extent) runtime compatibility and correctness. Instead of an implicit promise of compatibility, a Nix continuous build and testing system[2] could explicitly mark openssl-dependent packages as compatible by bumping their versions. The end user would need to update a lot more packages, but these cost could be reduced by binary diffing old and new packages, which should be almost identical with the exception of dependency metadata. [1] http://www.youtube.com/watch?v=3aoDjW1bjxo http://www.youtube.com/watch?v=3aoDjW1bjxo [2] http://nixos.org/hydra/ http://nixos.org/hydra/

9mit3t2m9h9a 14y ago

In practice it gives you more options for a price of keeping more junk on HDD. After a security update, all application hashes are calculated using the new default version of a library. So, once you launch an update you get a fresh package set linked against the latest version of the library. For large applications used by many people you are likely to get a small binary patch from the previous version, but this is just an optimization. So the default is just spending a bit more resources on the same behaviour. What does change, though, is that you can opt to pass another version of the library to a specific application manually. If update from libA v1 to libA v2 breaks AppX, you can easily build AppX-with-libA-v1. It doesn't make any sense for security updates, but for major interface changes it sometimes provides a smoother migration path.