Hacker News Reader

Comment by drdaeman | Hacker News Reader

Everyone talks about advantages. Would love to hear about disadvantages. Not obvious ones (like having to learn configuration language semantics or package missing stuff myself), but things that don't lie down in a plain sight right away and only discovered after a few days, weeks or months of usage.

Anyone to share their experiences?

(Migrating from Arch to NixOS at the moment, but thought maybe I'd detour a bit and try Guix.)

View on HN

From my understanding, the biggest disadvantage to purely functional package management is that you can't just swap out a package in isolation when many others depend on it. If I upgrade a package, I have to upgrade its whole DAG of dependent packages if I want them to use the new version (I could however delay that; they would simply continue to use the old version which hasn't been garbage-collected yet because they still use it).

So lots and lots of compilation (on build farms at least), and lots of bandwidth usage. Though something like ccache can help with the compilation, and binary diffs could help with the bandwidth.

Immutable data structures in FP are probably a good analogy.

Edit: argh, this was supposed to be a reply to the question about the disadvantages of the purely functional package managers specifically, not the OS in general.

To save compilation time and bandwidth the authors might be able to make their package dependencies sort of inside out, using a smaller program simply to perform the needed library loading and dependency injection on the core of the software.

Then if you're going between versions, you can avoid having to update the lion's share of code just because the dependencies change.

    jabberwork-1.2
      jabberwock.core-1.6
      jabberwock.apache.interface-0.3
    
    jabberwock-1.3
      jabberwock.core-1.6
      jabberwock.apache-interface-0.4

Instead of having to update all the hefty ".core" modules, you could get away with only updating the hopefully lighter launchers / library loaders and the specific interface code being updated.

I also started thinking things along the lines of that when I first looked into how Guix does things, but after annoying the developers a little (many thanks to Ludovic's patience) I've come to understand that things like that beat the whole purpose of having pure packages not only in binary content but also in run-time behavior.

Basically, reproducible builds are a red herring here. A package's identity is not only the hash of its byte-by-byte contents, it also includes ("closes over") the identities of all packages it "references" (depends on), meaning it will always have the exact same run-time behavior everywhere because even all its dependencies count as part of its identity.

The learning curve is pretty steep. It's not just a new config language, it's also letting go of many preconceptions one may have (where stuff lives on the filesystem e.g.).

That's also true for software I'm packaging. Certain ecosystems just really love to load configuration files and write log files relative to the binary path which breaks in nixos because all packages live on a read-only mount (looking at you ruby, cargo from rust will also be fun).

Lastly there's just not the same number of contributors yet so you're going to have more of the small issues that get fixed and reported by the armies of users that e.g. Ubuntu has.

I'm saying all this as an incredibly happy user. I can think of few technologies that have given me as much leverage as nixos in recent years.

> The learning curve is pretty steep. It's not just a new config language, it's also letting go of many preconceptions one may have (where stuff lives on the filesystem e.g.).

As a fairly new developer I don't find the learning curve to be steep. The configuration language is a Scheme DSL and is a lot simpler to my brain than spec files or Debian-style directories.

Where stuff lives in the filesystem becomes largely irrelevant because you can treat the store as a blackbox cache. What matters is only the stuff in ~/.guix-profile/, which is very tidy and only contains the software you installed to your profile.

A disadvantage is that some services (like dbus) look for service files in a well-known location. When packages are installed they don't place any of their files in a directory outside of their target directory. So, JACK2, for example, won't be able to place its dbus service file in a location that the dbus service natively knows about.

In many cases situations like this can be fixed by setting environment variables, but in some cases more patching is required to make this work properly.

EDIT: I don't consider this a serious disadvantage, though. It is not unusual for packagers to patch software in other distributions. (I dare you to check out spec files for popular RPMs.) It's just something a package maintainer has to think about under some circumstances.

I should also note that I'm surprised at how little patching is required for most software (besides the common shebang patching).

1. There are few packages, compared to dpkg.

2. It creates guix-specific users for building purposes.

There really isn't much bad to say about guix. You can even switch to it without giving up on your old package manager. That way, even point 1. isn't an issue. Of course, 2. isn't really an issue in itself; `cat /etc/passwd` already contains a lot of users whose purpose I know little about.

Reply on news.ycombinator.com