Hacker News Reader

Comment by nine_k | Hacker News Reader

So, what is the problem we intend to solve here? Can anyone ELI5? (Or at least ELIPhD?)

The actual Ubuntu has already tried to move to the AppImage-like package management: it's when you put all dependencies of the program into the package. These "Click" packages were used for the UbuntuPhone applications. There were also "Snap" packages for more server-oriented use cases.

The whole deal is about the software developers who are having hard time managing the dependencies. Because they've got to update the code all the time. Especially bad for the proprietary ship-once-and-forget software.

Ubuntu has not changed the package format. To be used, it has to be tested. To be tested, it has to be used.

It's time for new package management.

One that isn't snapshot images (docker, bundled java/ruby/libraries)

One that takes testing and integration seriously

One that takes security seriously

One that uses c-groups like they were intended

One that allows multiple versions

There are a lot of things that could come together for a new style and generation of package manager, but to do it right you would have to manage a whole lot of things

Let's take a look at Nix and Guix. Which checkboxes of the above list they fail to check? Cannot reasonably check?

It seems to me like nix fits all of those criteria.

Honestly not sure why this is downvoted. Would really like to hear from the contrarians since none of this strikes me as controversial.

I am curious why "snapshot images" are bad though. What's the fundamental difference between this and shipping a static binary (they're just a different image format, right?).

hardly.... the whole point of dynamic linking (and shipping or not shipping dynamically-linked binaries) is to reduce the amount of redundant code on a system. (it also helps keep update sizes down.) If you're shipping application images then youre shipping copies of all your library code -- you might as well have made a static binary; it certainly would be easier to work with.

> you might as well have made a static binary; it certainly would be easier to work with

Not all programming languages can produce static binaries. That's the point of an image format to begin with.

Reducing redundant code is a nice idea, but there aren't any systems^1 that solve for dependency hell and disk efficiency, and I'd rather trade a few hundred MBs of disk than fight with dependency hell.

^1: This isn't entirely true; Nix (and friends) do solve for this, but it's a relatively niche system and it's got its own usability issues that are (in my opinion) well worth sacrificing some disk to avoid. If these systems cross that threshold, then I'm happy to jump on that bandwagon.

As a user of linux on the desktop since 2003 I haven't seen any "dependency hell" save for packages not designed for the current distro/version or software not properly packaged. Usually proprietary crap NOT in your distros repos.

APT (on linux) and MSI (on Windows) platforms both attempt to solve for those factors. Both are also bedrocks for the the operating systems they are designed for. Everyone else on this thread seems to be skipping right over both these names. Why?

Can't speak to MSI, but apt doesn't do a very good job. For me, this manifests in an error like "one of your packages is broken, run again with the -f flag to fix it" which has never ever ever worked for me ever. I've had some luck with aptitude in the past, but it often fails to resolve because you're only allowed one version of a package on your system at a time. Static linkage on the other hand is pretty close to foolproof.

dpkg, which is what underlies APT, is really picky. Definitely a downside for APT, but its a solved problem.

Wasn't aware of the one-version issue with APT, though MSI definitely allows multiple versions (and attempts to manage the resulting dll hell)

Ok, perhaps I should have said I’m not aware of any Linux package managers that support installing multiple versions of the same package except for Nix which manages it by munging the dynamic library lookup paths at runtime so the binary loads the right versions of its dependencies. Without this, I don’t think it’s possible to (correctly) support multiple versions, and even then the package maintained must take care that multiple versions of the same package don’t wind up in the closure (or the loader will load the first it encounters in the search path).

The problem with dynamic linking is that experience has taught us that it is more trouble than it is worth in a lot of cases. It's great where it makes sense, like in base system components (but only if said components are stable so they can be relied upon), but otherwise it's just a headache. There's a reason static linking, Docker, etc. have become so popular.

APT satisfies most of those already, if you use it right

Security at the package manager level is closing the barn door after the horse has gone. As far as I can see you can't have a useful system and be able to install malware safely. The best choice continues to be curation.

Testing is logically discrete from package management its entirely possible to test well or poorly with any system.

For several other points nix also featured on the front page right now seems interesting.

Does this new package management system mean that each package is deployed with it's own version of dependencies? Or are dependencies only installed once, in a central location, like they are with 'traditional' Linux package management systems?

Reply on news.ycombinator.com