GNU Guix sports functional package management

I wouldn't think that user-installed packages are available to other users. For example, I install software into ~/misc/root/$name instead of /usr/local or whatever because it makes uninstalling a snap (rm -rf) and doesn't require sudo permissions.

Also, currently installed applications wouldn't use the new package; the old package that was linked into the suid binary would still be there.

Think about the types of installs users already tend to do in their own accounts -- desktop themes, panel apps, browser plugins and extensions, conky configs -- and every program has its own method of managing installed material. After a while it gets to be a mess. I've long wished I could manage these types of additions using apt-get, yum, emerge, or whatever. Then I could keep all my stuff up to date with a simple "apt-get upgrade". Or I could just see everything I have installed with "dpkg --list". You get the idea.

This is the type of package management that would be most useful for individual users. Allowing a user to install their own private version of Firefox, however, would be secondary, at least in my opinion.

System .so files *cannot* be updated, because of the design of Nix/Guix. (Well, unless you're root and manually break things, obviously.) /etc/ld.so.cache is not used because it's an impurity. I believe NixOS/Guix uses rpath (runpath) in binaries rather than having a global library search path. (e.g. see http://nixos.org/patchelf.html )

"[Unprivileged?] users cannot install setuid binaries." - http://nixos.org/nixos/ . (Also, Openwall GNU/*/Linux has made a working system with no suid/sgid/fscaps binaries at all. I hope everyone goes this way eventually.)

Yes, it's a can of worms; these people opened the can and killed all the worms. After all, these worms threatened purity even without unprivileged package installation. Consider: If you (sysadmin) left an old, vulnerable 'sudo' installed? System security depends on whether you garbage-collect it![*] But if the filesystem cannot grant capabilities, and if users are already allowed to run their own binaries in their home directories, then adding data to new places in /nix/store is not a risk (besides defense-in-depth).

[*] I'm not up-to-date regarding whether Nix and/or Guix have this old-setuid-executables risk. I think the Openwall approach to setuid would be the best, but maybe that's just me.