Hacker News Reader

Comment by bfrog | Hacker News Reader

Nix is pretty cool but has some significant usability issues.

Having never used Nix before, I would like to know what kind of usability issues it faces.

For me, the biggest one is that I can't use it at clients running a Windows shop. That's a blocker.

I think biggest ones are i) nix command is a bit complex, but it's getting redesigned [1] & ii) nixpkg definitions sometimes contain a lot of cruft.

I've found Guix and GuixSD, which are a GNU-blessed Guile Scheme-based reimplementation of Nix and NixOS, more aesthetically pleasing. Quite simple and elegant in fact.

The major differences are that Guix DSLs are implemented on top of Scheme, whereas Nix uses a custom DSL. Furthermore, Guix avoids systemd and uses GNU herd instead.

[1] https://github.com/NixOS/nix/issues/779

Guix uses it’s own init system implemented in Scheme: Sheperd (https://www.gnu.org/software/shepherd/)

Herd/Hurd is a kernel, not an init system, although since systemd is Linux only, using a different kernel implies using a non-systemd init system.

Shepherd is not a kernel, Hurd is, and shepherd page mentions a relation, that dmd/shepherd was developped closely to Hurd but it not the same thing.

Sure, I wrote herd not Hurd!

herd is the commandname of Shepherd client:

https://www.gnu.org/software/shepherd/manual/shepherd.html

Ah — confusing as Herd is the second recursive acronym of Hurd... sorry to pedantic :-)

Nitpick---but while we're here---Hurd technically refers to the set of (microkernel) servers. The microkernel itself is Mach. In spirit, Mach and the Hurd servers together provide what the Linux kernel provides monolithically.

Anyway... :)

For my practical reasons I can not use pure GNU distributions, I am not aware of easy community way to re use packages for other distro or something hacky like that. Not everyone have brainpower and time to build custom packages for rare distro, it is a shame, I really like Guix. NixOS got some recepies for using not 100% libre software.

There are repos around packaging tons of non-free (mainly scientific) software for Guix.

I was told guix has some support for importing normal Nix packages, but I don't know how well it works in practice.

https://www.gnu.org/software/guix/manual/html_node/Invoking-...

This is also what keeps me away from Guix. I get that there are third-party repos with non-free software, but using a fringe package of a fringe packager is too far for me.

There’s no good choice here: Nix package definitions and tools are inscrutable and user-hostile; and the alternative Guix is burden with GNU/free software zealotry and GPL.

A somewhat comparable third option is Habitat, from Chef. It also has a pure build system, a package source, and pure, discrete environments. But it’s also got a bunch of service orchestration parts...

Hopefully the Nix redesign will make the tools more palatable for mortals.

What kind of non-free tools are you missing from Guix?

The only notable omission is linux, as Guix is based on linux-libre instead. But changing this is a matter of 1 LOC.

> But changing this is a matter of 1 LOC.

And how difficult is it for a new user to find that line?

Including non-free software in Guix would defeat the goal of a 100% bit-for-bit reproducible distribution. Non-free software is incompatible with Guix both ethically and technically.

One of the major turn-offs for me in regards to Nix was that it uses a ton of bash scripts.

Guix's use of Scheme is a lot more elegant and powerful, and a lot less hacky than bash.

You could use nix the same way guix uses scheme. The lowest level operation in nix is not "run-this-bash-script" but "run- this-executable-with-these-arguments".

But even still you are mixing languages, so the problem remains. The issue is not that Nix uses Bash, but that Nix uses different languages for the host-side and build-side. AFAIK people aren't writing the build-side code in the Nix language, and I'm not sure if it even has the features necessary to do it. Guix unifies the different layers of code execution with a single language, and using a Lisp enabled that design.

For a complete explanation of this design, see the "Code Staging in GNU Guix" paper: https://arxiv.org/abs/1709.00833

> Nix uses different languages for the host-side and build-side.

I'm not sure what you mean by that. Nix packages are Nix expressions.

Those package expressions have Bash snippets embedded in them that run on the build daemon. The daemon doesn't evaluate Nix code.

How is that a problem?

The paper I linked to explains the drawbacks to such a design.

He is probably referring to the thing you see when you look into a .drv file, aka the immediate result of evaluating a derivation in nix. That language/datastructure is what nix-build evaluates to actually build things, otherwise the nix language itself is purely functional and cannot really do anything on it's own.

I guess in guile/scheme the equivalent data structure happens to be an s-expression. Edit: except the paper actually describes that it's a g-expression.

When will the redesign be merged?

It's over a year that I first read about Nix and they talked about the redesign.

The redesign is merged and available via `nix-shell -p nixUnstable`. It isn't so much an issue of merging, but calling the new version stable. We're working on it. No definite timetable though.

Ah, cool!

Are there docs for the usage after "nix-shell -p nixUnstable"?

Primarily from my perspective... the entire package repo acts as one enormous program. Which is both good and bad. Its not that easy imo to create ad hoc packages or packaging scripts

I strongly disagree. Creating a Nix package is significantly easier than creating, e.g.: an Arch package, from my experience. packageOverrides is really nice too.

Try packaging a postgres extension :-)

If you tell me which specific piece of software you tried to package, I can probably explain what is going on. I strongly suspect that it is either not Nix's fault, or an inherent tradeoff in packaging software (i.e.: not a design flaw, but simply a result of the correctness of package expressions being more tightly controlled in Nix than in other languages). The main exception to that statement that I've seen are cases where Nix works fine, but the Nix expression takes so long to build that iterating on it is very difficult. Luckily, there is a solution for that in the pipeline: "recursive Nix", which allows `nix-build` to be called _inside_ a Nix build sandbox, thus allowing safe memoization of things like `gcc`.

What's the status of recursive nix / people's thinking about recursive nix?

Discoverability is a problem everywhere in Nix, from configuration options to documentation. Which makes it necessary to learn its weird poorly implemented functional programming language and read code. Then there is performance, it's very slow and uses a lot of memory making it impossible to use on a 512 MB vm, for example.

If you just want a solution for your packaging management needs - Nix is definitely not it. Nix is more like a thing to get inspired by to make a package manager.

That's nice to hear you say, because I am making a package manager, and I find nix inspiring :p

I keep trying to convince myself that someone's already done it better, and there's no point, but then every solution I look at doesn't seem to be good enough.

Agreed, it’s an area where nothing is quite there. Take a look at Habitat - another not quite there option, but one with interesting ideas.

What's the downside of Habitat?

I don’t know anyone using it.

> Then there is performance, it's very slow and uses a lot of memory making it impossible to use on a 512 MB vm, for example.

No, this is just a side effect of the CLI user experience being garbage.

`nix-env -i <regex>` is almost never what you want, because its semantics are to evaluate everything in nixpkgs, find the set of packages whose `name` attribute is matched by the given regex, and install all of the packages in that set modulo the equivalence relation generated by package `name` equality ignoring version numbers.

Instead, you should use `nix-env -iA <channel>.<attribute-path>`, where `<channel>` is the name of a Nix channel (viewable via `nix-channel --list`, usually it is `nixos` or `nixpkgs`) and `<attribute-path>` is a valid attribute path in the nixpkgs package set (these can be discovered by running `nix-repl '<nixpkgs>'` and tab-completing).

It apparently works in WSL [1], so Windows needn't be an issue.

[1] https://www.reddit.com/r/NixOS/comments/64xyd7/nix_package_m...

Do you use Windows 10 Creators Update on production? It needs to work on Windows Server 2012 or no dice. Maybe Nix will be an option in 5 years when companies upgrade their servers, but that's not an option now.

You could say the same thing about Windows: Windows just isn’t an option yet.... maybe in 5 years when WSL is performant and MSFT has open-sourced enough to not be a threat to more cautious companies.

No, I don't think you can say that. The point is that I have clients that use linux, clients that use windows, and clients that use both windows and linux which need to talk to each other. I need a solution that can factor out the operating system into a module and build packages that will work for both the quants and the servers. I don't get to tell my clients what operating systems to use. I must provide solutions that work on whatever they're running.

Nix has facilities for creating Docker and Singularity containers from a nix expression, which lets you package up arbitrary environments. Does that satisfy your use-case?

https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools

* is pretty cool but has some issues.

Reply on news.ycombinator.com