Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Nix and NixOS get so close to perfect

christine.website

Post reply on HN
Print view View original

51–60 of 183 posts

Re: How Nix and NixOS get so close to perfect

#51

Post by stavros »

xena wrote: post #50
stavros wrote: post #44

Earlier quoted context omitted.

I don't think JSON is a nice way to write config files at all. You can't even add comments. I'd much prefer something like Cue.

I think the hard part here is using enough of a type system to ensure data sanity but not so much of one that you drown in metadata. I'm not really sure of a proper compromise like that.

Yeah, fair point. I don't know Cue well enough to know how much drowning there is, from my limited understanding you can specify as many types as you want and leave the rest dynamic, but I'm not sure at all.

Re: How Nix and NixOS get so close to perfect

#52

Post by [deleted] »

atoav wrote: post #3

As 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…

[deleted]

Re: How Nix and NixOS get so close to perfect

#53

Post by xena »

tjoff wrote: post #48
colordrops wrote: post #13

Earlier quoted context omitted.

I don't see how you could maintain purity and reproduceability with something imperative. I used ansible for a while and it was a mess that broke half the time and was difficult to maintain.

How does that have anything to do with it being imperative and not the fundamental design of the system? How nix is architectured is exactly why it achieves purity and reproducibility, not the configuration language. It isn't even a goal of ansible in the same sense, per design. The building blocks of nix is simple, of course it can be implemented in something imperative.

Think about it like this: with Ansible you start from some unknown state of the system and then iteratively do actions to hopefully get what you want. With Nix you know what the base state of the system is, and the configuration language lets you describe your desired end state. Then the computer figures out what to do in the middle.

The fundamental design of Ansible is that you do imperative steps to reach an end state. The fundamental design of NixOS is that you describe the end state and the compiler derives the intermediate steps.

Yes, normally things work out with Ansible, but the devil is in the details and can involve a lot of fighting configurations that are non-cromulent.

Re: How Nix and NixOS get so close to perfect

#54

Post by ris »

KronisLV wrote: post #11
mananaysiempre wrote: post #6

Earlier quoted context omitted.

> 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 “…

> 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: How so? Where's the Java/Python-like languages in this consideration, why wouldn't those work? Or something more like Ansible? I'm pretty sure that you can express the same concepts for the most part in something imperative as well.

> Or something more like Ansible?

If you make it more like Ansible, you will end up with ... Ansible.

If you want to use Ansible you are perfectly welcome to, but as a Nix person the entire Ansible way looks like a completely wrongheaded approach to system management.

Re: How Nix and NixOS get so close to perfect

#55

Post by xena »

atoav wrote: post #3

As 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…

I've been working on things to help onboard people. If you wanted something to help onboard you with NixOS, what would you want to see?

Re: How Nix and NixOS get so close to perfect

#56

Post by dmitriid »

bspammer wrote: post #38
dmitriid wrote: post #2

Somehow 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".

Doesn’t it say something about how useful nix is when you have all these smart people complaining about its warts (and it definitely has quite a few) but still using it? It is the way I’ve always wanted a package manager to work, and it really does work. It feels insane to use anything else now, I can’t go back.

> Doesn’t it say something about how useful nix is when you have all these smart people complaining about its warts (and it definitely has quite a few) but still using it?

No, not really. Tech people especially are susceptible to sunk cost fallacies We also get the kick out of conquering complexity.

Re: How Nix and NixOS get so close to perfect

#57

Post by tjoff »

ris wrote: post #49
tjoff wrote: post #39

Earlier quoted context omitted.

I really struggle with selling argument of lazy evaluation in the nix context, it is not a big deal. Sure, nix has been built around it, but it could just as well have been built around something else. And most certainly can't see how that would influence the number of packages. And honestly, the package situation is the biggest downfall of nix(os), there are tons of packages, yes. But they are often buggy (simply be…

> And honestly, the package situation is the biggest downfall of nix(os), ... but it has a long way to go. I have a big problem with "it has a long way to go" arguments. "It has a long way to go" in comparison to what? Every project I know of could be described as having "a long way to go". If we're comparing it with ubuntu/debian, there are few packages that ubuntu/debian have that nixpkgs is missing. On the other h…

> I have a big problem with "it has a long way to go" arguments. "It has a long way to go" in comparison to what? Every project I know of could be described as having "a long way to go".

In comparison to any other mainstream OS nixos is going to have a lot of friction for most usecases. That is what I mean with it having long ways to go.

Part of that is configuration.

Other part of it is the package system being very immature. It is a direct consequence of the massive task nix has set out for itself, but that isn't always comforting for the end-user. And oh boy, the situation with looking for github-issues for packages is a freaking nightmare.

Just because nixos has a package for it doesn't mean that it does what it should or is up to date. That of course isn't the case for any package management system. But, all other mainstream OSes have matured. Nixos has a long way to go.

I love nixos, it is my main driver on my laptop and I run many VMs with it. If the future isn't incorporating the selling points of nixos I'm going to be dissapointed. But unless you want your OS to be your hobby I most certainly would not recommend nixos.

Nixops is another things that disappoint me / has long ways to go. It is the logical extension of what nixos is and it isn't really mature. There are lots of competing efforts for it and as someone willing to really invest time in it I just get exhausted.

Re: How Nix and NixOS get so close to perfect

#58

Post by xena »

encryptluks2 wrote: post #32

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 co…

Author of the post and survivor of several cults here. Nix is nothing like a cult. There is no behavior control, information control, thought control or emotion control at work. There are just people that are passionate about the tool and want to see it thrive. I would hardly call this a cult, more of just an interest group with weird nerds in it.

Honestly after a while the language starts to fade into the background and you just focus on what you are doing. Keep in mind that I am an expert at this point and have prior experience with Lisp, Haskell and a little bit of ML; so the overall flow of the configuration language and the like is easy for me to feel my way into. I have been trying to work on documentation to help get people up to that level; but trying to explain things you understand intuitively is hard :)

I'm trying though. With my Nix flakes series I'm probably going to rebase a lot of it around using NixOS with WSL to make it easier to approach for newcomers.

Re: How Nix and NixOS get so close to perfect

#59

Post by fuzzy2 »

0des wrote: post #42
colordrops wrote: post #14

Earlier quoted context omitted.

Maybe a better design. Bet? Not so sure. Guix is Betamax to Nix's VHS.

What a bad analogy. Betamax was superior to vhs.

Yes and yet it failed. That's what GP is saying: Guix may well be better, but it is even less popular than Nix and thus at (greater) risk of dying.

Re: How Nix and NixOS get so close to perfect

#60

Post by tjoff »

xena wrote: post #53
tjoff wrote: post #48

Earlier quoted context omitted.

How does that have anything to do with it being imperative and not the fundamental design of the system? How nix is architectured is exactly why it achieves purity and reproducibility, not the configuration language. It isn't even a goal of ansible in the same sense, per design. The building blocks of nix is simple, of course it can be implemented in something imperative.

Think about it like this: with Ansible you start from some unknown state of the system and then iteratively do actions to hopefully get what you want. With Nix you know what the base state of the system is, and the configuration language lets you describe your desired end state. Then the computer figures out what to do in the middle. The fundamental design of Ansible is that you do imperative steps to reach an end st…

Yes - that was exactly my point. It has nothing to do with the configuration language. The end result of nix(os) could just as well be done from a bash script (not advisable, no).

And the problems with ansible would not be any better off if they had used something like the nix-language instead.

Post reply on HN