Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I get what you're saying, but I don't think it violates the Unix philosophy in that way, at least not any more than any other package manager like apt or dnf does.

Nix as a package manager is made up of multiple tools that interact, such as nix-env, nix-store, nix-shell, etc.

NixOS additionally has nixos-rebuild and other commands that are layered on top of those core Nix commands.



sort by: page size:

> Nix is a tool that takes a unique approach to package management and system configuration.

Nix is the basis of an OS distro: NixOS.

This article is just re-articulating the idea that {the/an} OS distro should be managing this stuff, and not some fledgling language-specific programs (that go behind its back, and do a half-baked job by not controlling the packages external to their language ghetto).


Nix isn't designed as an application. It's designed as a system package manager.

> Nix itself is in first approximation "just a package manager"

I'd go even further: Nix is just a build tool, like Make.

In fact, it assumes far less about the system than Make; e.g. Make does all sorts of shell-related things, whilst Nix simply executes a binary (with a list of arguments and a set of env vars).

(Nixpkgs definitions almost always use a bash binary as their executable, so it feels more like Make; but Nix doesn't care)


> uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels.

I'm confused; Nix mostly works by passing the '--prefix' argument to standard, off-the-shelf configure scripts. Some build/packaging tools don't seem to work with a user-chosen prefix, and hence need some sort of workarounds; but that's surely a fault with those tools.

> Horrible-horrible way to compute runtime-dependencies of packages. This may be okay as a heuristic to initialize a project, but in the end it must be tweakable manually.

I completely agree with this one. I've never experienced a problem with it; but that surprises me ;)

> This would be solved by a more modular architecture, where we can manage package with a one tool and build packages with a different tool. Until then, I would be forced to code in Nix, and that's problematic no matter how good the package management is.

The Nix store provides quite a nice separation between the "definition" side (where the Nix language lives), and the "building" side. In principle you can avoid the Nix language, e.g. the way Guix uses Guile Scheme. The only reason I use the Nix language is due to all of the definitions provided by Nixpkgs ;)


You're stating a lot of interesting opinions, but I do not see any arguments to help describe why you feel that way. How exactly is Nix monolithic or proprietary? And what is complicated about it? It seems pretty simple to me, if not at odds with how other package managers do things. It's one of the few package managers that can successfully work across multiple Linux distributions, some BSD systems, MacOS, and even Windows for some software. In my opinion it's the least proprietary or monolithic package managers around, the other being Guix which follows the same principles.

But I think the biggest issue is in your last paragraph where you don't describe why or how the solution needs to happen in the software itself rather than at a higher level.


Also people forget that the Nix philosophy doesn't end in the package manager Nix, there's also NixOS which takes a functional approach to configuration management of the whole OS. And many other things.

Package management is great, and Nix is neat, but Nix isn't the entropy-eliminating panacea the author makes it out to be.

Just like every other package manager, from rpm to dpkg, Nix is responsible only for the aspects of the filesystem that it's specified to be responsible for. It's not going to remove garbage left behind by users or poorly-written post-install scripts, and it's not going to automatically undo other non-filesystem-related state changes on package removals. And the practical reality is that not everything on a system can be a native package anyway.


The thing about Nix is that it's the first project, as far as I know, that tries to solve the problem of package management with a fundamentally different approach. Most of the solutions to date were just okay: they worked with a tolerable degree of failure.

A solution that works good enough is often a serious obstacle for developing a solution that works really well. E.g. Unix works just good enough to preclude the adoption of a new paradigm in OS'es such as Plan 9.

Treating packages like immutable values sounds like a genuinely new idea. So what I think is that people don't go "this seems better than my current development toolchain", instead they think that the idea that underlies Nix might result in disproportionately more reliable tools in package management. That's worth fussing about.

Disclaimer: I am not associated with Nix in any way.


I think in conversation we don't separate the fundamental concepts that Nix implements from the particular implementation.

The fundamental idea is this: Every package is built in a "hermetic" environment that guarantees that the only inputs are the ones you have explicitly specified. Those inputs include tools, source files, compilers, build instructions etc., all specified by a hash. Those inputs themselves can then be packages build in this way, such that everything in your system forms a big Merkle tree.

This approach enables a number of excellent things - you get excellent build reproducibility, you can cache any step you want etc. A lot of the concerns you get with a more conventional system just go away.

People have objections to Nix(OS) - the language, the sporadic documentation, some of the design decisions made, the learning curve etc. But I think those (very reasonable) objections obscure the more interesting debate about the underlying approach and value.


This might get down voted, but here goes. I agree that the Nix documentation can be confusing and even contradictory at times. I agree that there is a steep learning curve to getting started with Nix and NixOS. However, I do not think that Nix has ever claimed or intended to be a tool that can be used easily by everyone.

If the ideas seem pointless and confusing to you, that's fine, don't use it. There are bunch of great package managers and linux distros that will probably suit you better. But, if you see the need for declarative package management, then Nix is for you.

I'm a phd student in computational science. I use a bunch of different packages on my computer and I need to know exactly what I've installed and I do not have time to debug problems from dependency hell. Nix and NixOS have been two of the most interesting and useful tools I have every used. Not only have a gained huge productivity boost from having reproducible environments and declarative package management, but I've thoroughly enjoyed the process of learning these unique tools that, for me, are leagues better than any package management system I've used in the past.

If it didn't work for you, I hope you find a tool that suits you better. But that doesn't mean its bad. It might just mean it wasn't intended for you.


Nix is a tool for deployment, that happens to have some build capabilities. This is how I view it anyway.

Given their background I think they meant nix as Linux/Unix and not Nix the programming language/package manager.

Despite its clear fit with the current hotness of immutable systems and functional programming, I don't think I've seen anyone in for-profit industry on a Nix/NixOps stack.


I'm starting to see more of a cult attitude with Nix. It is like the Arch Linux crowd (I use Arch) but much worse. I think is is great that Nix has provided something valuable to a lot of people, but so does a lot of software and tools.

Nix fills a void in package management. It is like Ansible or Terraform for a semi-idempotent distro. It is probably quicker in most ways than building something similar with other configuration management tools, but I still prefer other tools because the language for Nix is just bleh. Had they went with a simple YAML format or HCL, then I'd give it a chance, but because they didn't I'm certain eventually someone will create something better learning from the mistakes of Nix.


I do love Nix, and I think much more people should use it, but I don't really consider that a good alternative in the context of my original comment.

I'd argue writing a Nix derivation isn't that different from writing a package definition for any one Linux distribution. It solves the distribution problem for people who use that particular distribution/tool, not everyone. Now, Nix can be installed on any distribution, but if I was going for widespread adoption, I might point to Nix being a solution, but I probably wouldn't advertise it as the main one.


> Because Nix is a functional package manager...

I'd explain "functional package manager" as "package manager where packages are declared as a function of their inputs".

e.g. a package's inputs would be the compiler used to build it, and the source code.

One motivation for doing this is ensuring that a package's behaviour is reproducible.

There are all sorts of neat benefits this ends up allowing.


> it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone.

On the other hand, one of Nix's greatest strengths is that in many respects, its innovations are conservative. It brings software building and distribution forward in terms of reproducibility and isolation (like containers do) but (unlike containers) also retains the traditional package management virtues of granularity, efficiency, and sharing common resources (dependencies) when possible.


As a huge Nix fan, I think it's perfectly acceptable to say non-linux package management is an abomination, linux package management is a mess, and nix is not (yet :)) ideal.

Engineers shouldn't assume something is done well because nobody is doing any better. Some things suck and there's nothing to blame but other priorities or sheer laziness.


> Nix is like a kind of Docker from an alternative universe.

Nix is often compared to Docker, but Docker is essentially just a way to run programs (in a sandbox). Saying "I'll build it with Docker" says how you're going to run it, but not what you're going to run. Unfortunately, the "what" usually turns out to be a shell script, which runs one package manager to fetch another package manager, downloads a bunch of files from some random URLs, etc.

Nix is all about keeping careful track of the dependencies between things, such that all the fetching has been done by the time our scripts start (access to the network, and any paths outside the build sandbox, is disabled by default).

Also, the way Docker tends to be used involves downloading an entire Linux distro, just to run those scripts. Nix does the opposite: scripts only have access to precisely what they've asked for.


> Determinism

Except not. I don't think "determinism" was ever an explicit goal of Nix. The sales pitch on their site is "learn how to make reproducible, declarative and reliable systems".

Nix takes very much a worse-is-better Unix approach. It aims to unify the mess of package management of Unix distributions and language runtimes in a reliable and easy-to-use way, but it doesn't aim to solve the computing world's problems in some quixotic quest for "purity".

next

Legal | privacy