How Nix and NixOS get so close to perfect
christine.website
How Nix and NixOS get so close to perfect
1–10 of 183 posts
Re: How Nix and NixOS get so close to perfect
#2Somehow 60% or more of the presentation is spent on what is charitably called "papercuts": bad tooling, bad documentation.
It's not "getting so close to perfect". A jet-powered cart (from the comic in the presentation) is not "close to perfect" by any imaginable criteria. Well, unless your idea of perfect is "a jet-powered cart".
Re: How Nix and NixOS get so close to perfect
#3As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users.
And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that in other spots decisions have been made in a logical and/or straightforward way.
I am trying to have a less terrible experience with dependency and configuration management — but what I am not trying is making dependency and configuration managment my nerdy hobby. I have enough nerdy hobbies already.
So in short: My worry is that the seemingly big investment in terms of time is not worth the advantage this might give me over e.g. a traditional debian system.
The thing is: I really, really want an system that does the things nix does, but nix doesn't seem to be it. I am grateful about the honest presentation, but if nix is really the future, these paper cuts have to be dealt with.
Re: How Nix and NixOS get so close to perfect
#4Somehow 60% or more of the presentation is spent on what is charitably called "papercuts": bad tooling, bad documentation. It's not "getting so close to perfect". A jet-powered cart (from the comic in the presentation) is not "close to perfect" by any imaginable criteria. Well, unless your idea of perfect is "a jet-powered cart".
I feel differently: when proponents of a thing are open about its flaws, and those flaws are not in the fundamental ideas or principles of that thing, then it makes me more convinced that perhaps the thing does have merit. (Although I can buy the argument that it's not close to "perfect", mostly because I have no idea what perfect package management would look like.)
Re: How Nix and NixOS get so close to perfect
#5As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…
> And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...)
I agree that the name is bad and has always been bad. I wonder what they were thinking. But the syntax of the Nix language is not based on Haskell. It would be better if it were, but the Nix syntax is actually based on trying to twist a functional language into looking like a Unix-style configuration file. It's horrible, and conceptually big details like "this is a function" are hidden by subtle syntax (a single colon). The liberal use of semicolons and the use of space-separated lists is another concession to looking like a config file. I feel Nix would have been better if it didn't try to cater to older conventions in this way. Sometimes the old ways are just bad. Incidentally, one of the big advantages of Guix (a Nix fork/derivative) is that it uses Scheme as its declaration/configuration language.
I switched to Nix some years ago on my desktop system. While I was initially quite frustrated at lots of the paper cuts - particularly the byzantine design of Nixpkgs itself which is built around manual programming with fixed-point combinators - I was carried through by two things:
1) I was intellectually convinced that the basic premise was sound.
2) Getting a basic desktop system running doesn't require you to understand all the complexity. NixOS works really well out of the box with its standard settings, and making basic configuration changes and adding/removing packages doesn't require you to know anything about the Nix language or the design of Nixpkgs.
Not much later I was able to do pretty radical things like changing the version of LLVM used by Mesa on my system, to work around a defect in AMDs GPU drivers[0]. I have no idea how I would do something like that on Debian. Even better, when this workaround later became unnecessary, I just removed the pertinent parts from my configuration file, and it was like it was never there. My system is fully declarative and not soiled by the remnants of previous hacks.
[0]: https://github.com/athas/dotfiles/blob/d495aeb85fe38569eb212...
Re: How Nix and NixOS get so close to perfect
#6As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…
> Using Haskell as a base for the syntax
I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities:
- Kind of like Lisp (parens everywhere, painful with pervasive currying);
- Kind of like ML (var and fun everywhere);
- Kind of like Haskell.
Nix is chooses the last of those, and it does not have most of Haskell’s funkiness: no “alignment”-based blocks, no custom operators, no separate type sublanguage. The merged string interpolation / field lookup thing looks kind of funny, but has nothing to do with Haskell. The scoping rules for 'with' are weird, but, first, are not syntax, and second, have nothing to do with Haskell either.
Really, if one were to design the language that fits Nix’s description—a dynamically-typed (not Dhall), lazy (not Guix) higher-order (not CUE) language with a JSON data model—I don’t see how it would look much different. It could be less consistent, it could have more infix operators for things, or it could use a list concatenation operator that is not like anything instead of like Haskell. That’s it? If anything, any alternatives I can think of would be less conventional and/or more Haskell-like.
Re: How Nix and NixOS get so close to perfect
#7Somehow 60% or more of the presentation is spent on what is charitably called "papercuts": bad tooling, bad documentation. It's not "getting so close to perfect". A jet-powered cart (from the comic in the presentation) is not "close to perfect" by any imaginable criteria. Well, unless your idea of perfect is "a jet-powered cart".
I feel differently: when proponents of a thing are open about its flaws, and those flaws are not in the fundamental ideas or principles of that thing, then it makes me more convinced that perhaps the thing does have merit. (Although I can buy the argument that it's not close to "perfect", mostly because I have no idea what perfect package management would look like.)
You can only work with what something is. Not with what it might be, one fine day.
Re: How Nix and NixOS get so close to perfect
#8I'm curious what was used to make the avatar in that presentation.
Re: How Nix and NixOS get so close to perfect
#9As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…
Guix seems to be a better bet.
Re: How Nix and NixOS get so close to perfect
#10Earlier quoted context omitted.
I feel differently: when proponents of a thing are open about its flaws, and those flaws are not in the fundamental ideas or principles of that thing, then it makes me more convinced that perhaps the thing does have merit. (Although I can buy the argument that it's not close to "perfect", mostly because I have no idea what perfect package management would look like.)
You can only work with what something is. Not with what it might be, one fine day.
Sure, but e.g. the documentation problems with Nix don't prevent you from working with it. While the problems make it less smooth and productive than it otherwise might have been, it might already be better than legacy systems for you.
In particular, Nix can be used in a non-invasive add-on manner on ordinary distributions. We have it installed on RHEL servers at work, where it is used exclusively as a build system and for "userspace programs" (not in the kernel sense, but in the sense of programs that are not core to the functioning of the system).