Re: Adoption of Nix?
Daniel Burrows <dburrows <at> debian.org> writes:
>
Note: I'm not subscribed to the list, and pulling this old thread through
Gmane; please CC directly to me.
The purpose of this is to cross-examine Daniel's thoughts and bring new
thoughts to the surface. Daniel's thoughts are valid; however my thoughts
tend to be ... parasitic. My thought process tends to follow:
- Can we use this?
- Yes! Integrate it!
- No, that's stupid, but this part looks interesting so let's rip
that off
The prior discussion of 2008 seems to have established that Nix isn't
something Debian wants. So let's look at the tail end.
I'll put the main proposal up front:
I feel that being able to install multiple system profiles with dependency
resolution is a good feature--i.e. the feature of Nix that lets one program
see /usr/lib (or what is effectively its /usr/lib) as something entirely
different from what another program sees.
It shouldn't be a core, absolute feature.
Instead, I think it's best to find the least-effort way to modify dpkg so that
it:
1) Can handle running on a system managed like this; and
2) Provides an API to extend dpkg/apt to function this way
In other words, add the capability for a plug-in that changes the way packaged
files are stored and managed, and let somebody else hook up to the glue code
and make it happen. Don't break Debian for the rest of us.
That would appropriately increase aji and leave open many possibilities for
the future.
(For what it's worth, I don't like the direction Nix went in. Stick to
managing packages and system layout; Nix goes all the way out to managing your
configuration file CONTENTS, which among other things makes it completely
useless in serious production cases--Nix wants to live in its own, rigid little
world and not play well with others at all).
> Hi there. As I'm sure everyone knows, I'm not exactly unbiased here
> since I've done a lot of work on the apt system (although nix looks more
> like a replacement for dpkg).
[...]
>
> ====
> Nix stores packages in the Nix store, usually the directory /nix/store,
> where each package has its own unique subdirectory such as
>
> /nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/
> ====
>
> Never mind that this breaks the FHS -- I'll pretend for now that
> we've amended policy to allow this, or that we've stuck it in /var
> with some horrible bind-mounting to make it appear in the right places.
>
I've poked around in Nix. I find this not terrible, but the design decision
of whether to put things in /var/system or whatnot is a design decision I don't
care about. Fiddly bits.
> That's a terrible user interface decision! This is Unix, and
> filenames are part of the user interface. That file name, aside from
> breaking all user expectations (as per my note about the FHS), is
> completely unmemorable, means that packages with the same name aren't
> necessarily sorted together in directory listings, breaks tab-completion,
> and includes a long string of (to the user) meaningless gobbledygook.
> At the very *least*, you should put the package name first, to fix the
> tab-completion and sorting problems:
>
> /nix/store/firefox-2.0.0.1-r8vvq9kq18pz08v249h8my6r9vs7s0n3
>
> but then what if I have two firefox-2.0.0.1s installed? How do I
> know which one is which?
>
Mostly: Unimportant. Good question, but not that important.
> I hope nix at least has stow-like abilities to create a unified /bin
> directory, but that doesn't help when you want to track down the files
> of a program for whatever reason.
And this is why.
In Nix, it appears you have /usr/bin/env and /bin/sh that are symlinks. Beyond
that there is some sort of path to the current system that has a bin and lib
directory filled with symlinks, all pointing to a whole lot of
/nix/store/*/bin/* stuff.
So, a horrible mess.
The fact is, though, a "system image" is sort of constructed from a whole bunch
of symlinks. You can find the real target via readlink -f, I think.
In effect, if you look at 'which ls', it tells you where your system directory
is.
As I said right at the beginning: this nightmare is useful, but should be
wholly elective and not a core part of dpkg/apt.
>
> ====
> Multiple versions
>
> You can have multiple versions or variants of a package installed at the
> same time. This is especially important when different applications have
> dependencies on different versions of the same package — it prevents the
> “DLL hell”. Because of the hashing scheme, different versions of a package
> end up in different paths in the Nix store, so they don’t interfere with
> each other.
> ====
>
> That's fine as long as your hard drives (never mind the flash devices
> embedded systems use, where dpkg is already painfully heavy) are infinitely
> large, or you don't install very many versions of very many packages.
This got me too.
I think the best way to handle this would be to do a dependency resolution of
all installed packages and remove old versions. That is to say: if you
upgrade mysql, you have 3 applications that depend on various conflicting
packages, and none of any of THAT leads to dependencies on the older version
of mysql ... then remove that old version of mysql.
Ubuntu--and I suspect Debian proper--have 'apt-get autoremove' to remove
unneeded dependencies. A similar cleaning function would make sense in an
environment like Nix proposes.
>
> ====
> An important consequence is that operations like upgrading or uninstalling
> an application cannot break other applications, since these operations
> never “destructively” update or delete files that are used by other
> packages.
> ====
>
> That sounds like they haven't thought hard about the problems around
> upgrades and removals, which are not trivial. (there's a research team
> at the University of Paris they could talk to about this, if they
> haven't already) Because of that, I suspect that we *can't* disable
> the "install multiple versions" feature -- it sounds like the package
> manager fundamentally relies on this to do anything.
>
This is a guarantee that should be removed. At some point we have to stop
pretending that we can make changes to systems with zero risk. If you look at
the Nix home page and relevant research papers, these folks have deluded
themselves into the belief that they have discovered 100% security while
allowing users to make administrative changes to the system. The belief that
you can upgrade things with no risk is also delusional.
> In addition to my earlier comments: what if I have multiple Web
> servers or database servers installed (or multiple versions of one of
> them)? Which one runs at startup, and what if I have packages that
> specifically depend on another one?
I think ideally you would have to accept that the start-up system is going to
run whatever is the 'active' version of an application, by some mechanism. If
you have postgresql 8.2 and 9.3 installed, your init script should reference
one of these. In actuality, your system should reflect one of these--when you
run psql, a particular binary is in your path. That binary resides with the
postgresql server as well, and both are from the same version (unless, I
guess, they come from different packages).
While there would be a mechanism to run multiple postgresql server versions,
the normal behavior would be current stuff. "Current" is flexible, but it
means essentially that you have to not be schizophrenic and actually have one
version of postgresql active.
Due to the way Nix behaves, and the way a similar system would behave, it's
not a far fetched idea to say that you could specify an application profile
that lets you run postgresql 8.2, and have an init script that calls that, such
that you have /etc/init.d/pgsql and /etc/init.d/pgsql-8.2; this is a later
consideration.
Specific forms possible include:
- Multiple init scripts
- A configuration file that specifies configuration for multiple versions
- A configuration file that specifies init to call for multiple versions (with
separate /etc configurations and separate init scripts)
- A mechanism to switch to an application's profile, then activate its init
script, and thus init would be aware that BOTH init scripts would be run
I suspect that current init systems would balk at the last 2.
>
> ====
> Complete dependencies
> ====
>
No arguments here. The magic dependency gathering solutions are not my cup
of tea.
I would suggest the package manager would be aware of dependencies and take
appropriate action, rather than relying on fuzzy logic.
>
> ====
> Garbage collection
> ====
>
> That's great, as long as they include the ability for me to say "I
> really want to remove firefox, please show me all the packages that are
> keeping it on my system." Of course, we already have that in Debian.
Agree. We have dependency resolution and we can re-install stuff from
packages. No need for stuff hanging around "just in case".
>
> ====
> Multi-user support
>
> Starting at version 0.11, Nix has multi-user support. This means that
> non-privileged users can securely install software. Each user can have a
> different profile, a set of packages in the Nix store that appear in the
> user’s PATH. If a user installs a package that another user has already
> installed previously, the package won’t be built or downloaded a second
> time. At the same time, it is not possible for one user to inject a Trojan
> horse into a package that might be used by another user.
> ====
>
> I like this, and I've thought from time to time about how we could
> theoretically integrate it into dpkg. I'm a little worried about the
> interaction with garbage collection: it sounds to me like a normal user
> can DoS the system by depending on someone else's package so that it
> never gets garbage collected.
Agree, although it depends somewhat on Nix-like behavior or on front-loading
the user's PATH with PATH=/usr/local/users/$ME/usr/bin not to mention /etc,
/lib, and so on.
It's also a feature many of us simply do not want. Just like all Nix-like
behavior.
> With all that said, I think that Nix is a useful program, both because
> it explores some new ideas in package management, and also because I can
> see it being very useful in some niche areas where current package
> managers are lacking.
And therein is my point: It's a cute exploratory program, but it doesn't fit
in with the needs of most people and is immature. Taking lessons from these
sorts of explorations is a good thing.
Reply to: