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

The Curse of NixOS

blog.wesleyac.com

Post reply on HN
Print view View original

151–160 of 361 posts

Re: The Curse of NixOS

#151

Post by aaronchall »

kstenerud wrote: post #87
ghostwriter wrote: post #28

Earlier quoted context omitted.

> My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough. How hard have you tried? It's literally two clicks and one scroll away from the official home page: https://nixos.org/ -> click "Learn" -> Scroll down -> click "Full Nix Manual": https://nixos.org/manual/nix/stable/expressions/builtins.htm...

The other problem is the condescending replies from the higher tier nix folks while everyone else struggles. I almost think they garner a sadistic pleasure in watching everyone fail. After months of "It's obviously this" and "you're not even trying" and "have you even looked?" and "there are plenty of examples out there already" and "you should start out by reading the introduction docs" and "you obviously don't know…

Maybe you should look within.

I'm still a long ways from understanding everything Nix/NixOS completely, but I've never gotten these kinds of comments apart from the extremely reasonable "you should start out by reading the introduction docs" - that the directions lead with.

And if you have a problem with that, I can see how you might have provoked that kind of response that seems so out of character to me.

I ask questions when I have them, and sometimes I get answers from them, and sometimes I answer them myself.

But I started off reading as much of the docs as I could tolerate before and while getting started, and always trying to self-help before asking for help.

Re: The Curse of NixOS

#152

Post by eigengrau »

light_hue_1 wrote: post #83

Nix has two kinds of problems: the language and the interface. They can solve interface problems, but the Nix language is a tumor that won't be easily removed. The problem is that Nix the language is the worst of all worlds: - You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are saf…

> You can't print anything because the language is lazy. Forcing any values to print them can and will result in random operations happening on your store. You can never know which values are safe to inspect. This kills debugging.

I don’t quite follow the conclusion. Forcing values will not result in random operations on the store. Forcing values can only ever create store derivations, which is an internal representation of all derivations that were encountered while evaluating some expression. I won’t ever mutate existing data or remove anything from the store, nor will it actually build anything or fetch cached packages, so forcing values should be unproblematic. Store derivations can later be garbage collected.

Re: The Curse of NixOS

#153

Post by zaphar »

AshamedCaptain wrote: post #52
amarshall wrote: post #38

Earlier quoted context omitted.

This can be avoided my not overriding the package attribute, but instead creating a new one and then only using that as-needed. What you describe as a deal-killer is just purity and safety. Updating a build input gives no guarantee that the build output will be the same or even work. Sure, as smart humans we can say “I know this change does not impact X, so it’s fine”, but NixOS is based partly on the claim that we d…

> What you describe as a deal-killer is just purity and safety. It's not really "pure" since you are packaging software with side-effects to begin with. Even if you use the same text bit by bit it's also no guarantee that the output will be the same or that even it will work. You are still relying on some human claiming that it will do. So the advantage is not really that big in practice, and the disadvantage means r…

I think you might be vastly understating the advantage here. I've been the guy who shipped software that "worked on my machine" but didn't work in production because on my machine there was a system installed dependency that got used but didn't exist in production and the only way to discover that was to ship to production. Nix makes that a far less likely scenario. It get's a lot of things wrong in how it achieves that but it fixes a real and very substantive problem.

Re: The Curse of NixOS

#154

Post by tomberek »

assbuttbuttass wrote: post #8

As a NixOS user, I like this article a lot. But one thing stood out to me: > It also means that it's impossible to statically know what other packages a given package might depend on. Currently, the way this is implemented is essentially grepping a package for /nix/store/ to try to figure out what the dependencies are, which is obviously... not great. I'm not sure what the author is talking about here. He says it's i…

Just like any other package manager, this information can be queried without grep.

  nix-store --query --references /run/current-system
  # or with new CLI:
  nix path-info --recursive /run/current-system
This information is managed and tracked for you. And while I understand the desire to have "normal" FHS paths, the hashing and the injection of the hashes (think "tags") is exactly the mechanism that makes dependency tracking possible to do automatically. This is similar to the trick by log aggregation tools that assign each source event a UUID to make it possible to search and find it in all sorts of unexpected places. Otherwise how would you know what "/usr/bin/bash" really means if you came across it in an error log? What version was it at THAT EXACT MOMENT? That hash in the path is the tag that enables all of it to work.

Re: The Curse of NixOS

#155

Post by qudat »

JamesSwift wrote: post #132
qudat wrote: post #125

Earlier quoted context omitted.

After having spent weeks learning nix, I'm convinced that docker is simply a better tool for most use-cases of nix.

Coming from docker before nix, I think nix is a better version of docker for some use-cases. If the ecosystem is supported then I much prefer nix for speed (both runtime and development speed)

I agree that when nix works, it's great.

However, I find debugging docker infinitely easier than debugging nix. I played around with the idea of adding nix for work projects and getting buy-in from other colleagues. But after working with it for weeks and still running into issues, there's no way I could in good conscience recommend the tool.

Re: The Curse of NixOS

#156

Post by darkarmani »

112 wrote: post #93

Ranting about Nix being hard is like going to Russia and complaining that the local language doesn't sound English. Like many other things worth your time, it's something you learn through deliberate practice and focus.

> it's something you learn through deliberate practice and focus.

That sounds like a massive barrier to entry and more effort than solving the problems I currently have.

Re: The Curse of NixOS

#157

Post by mikepurvis »

tikhonj wrote: post #146

I've been using Nix and NixOS for a while and I've seen four core advantages: 1. Nix store: what the article covers: multiple versions of the same package, "virtualenv for everything"... etc 2. Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. 3. Flexibility: Nix works for system packages on NixOS as well as user pac…

"... with no system state to worry about"

I don't disagree with you, but one of my skepticisms about this is that Docker and Dockerfiles made the same promise like eight years ago, and at least as a small time operator (eg, homelab), it never really felt like the system was as stateless as it was telling me it was. There were always logs, indexes, caches, database content, and all the rest of it, and all of this had to be carefully volumed-out with those data containers being protected and versioned and carried forward independent of the throwaway Dockerfile-defined "application" containers.

So far my experience of NixOS is that it doesn't particularly offer a new solution here, but at least it doesn't pretend anything. The configuration.nix "defines" the whole system, but obviously doesn't touch anything in /home or /var, so that's on you to back up, migrate, whatever.

Re: The Curse of NixOS

#158

Post by kerblang »

Why do we need a programming language to run software installers?

Like, all I really need is the ability to say, "Hey, for this thing, install it in a versioned directory, please, and leave /usr/bin the heck alone." or even "Okay you're stubborn and you won't give up on /usr/bin but at least do the first part for me."

For most things (ls, find, etc) this is unnecessary but yeah for the pythons & javas and so forth, it's helpful. Seems like a lot of package managers already do the latter but sysadmins insist on There Shall Be Only One even when /usr/bin is already symbolic links into versioned installs (or links to links to links to versioned installs..).

Maybe I'm missing the point entirely.

Re: The Curse of NixOS

#159

Post by zaphar »

I actually think as a language Nix's runtime semantics are worse than borgcfg. Both have an obtuse and confusing syntax it's true. But Nix's extreme approach to laziness in the language means it essentially has "come from" semantics which is the source of the spooky action at a distance that the author speaks about. This combined with a lack of compile time type checking means that that debugging your nix code comes pretty close to feeling impossible. It is deterministic but tracking down what exactly broke your nix package code can be difficult when the source could literally be almost anywhere.

Re: The Curse of NixOS

#160

Post by tikhonj »

mikepurvis wrote: post #157
tikhonj wrote: post #146

I've been using Nix and NixOS for a while and I've seen four core advantages: 1. Nix store: what the article covers: multiple versions of the same package, "virtualenv for everything"... etc 2. Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. 3. Flexibility: Nix works for system packages on NixOS as well as user pac…

"... with no system state to worry about" I don't disagree with you, but one of my skepticisms about this is that Docker and Dockerfiles made the same promise like eight years ago, and at least as a small time operator (eg, homelab), it never really felt like the system was as stateless as it was telling me it was. There were always logs, indexes, caches, database content, and all the rest of it, and all of this had…

That's true. I guess I see it as the difference between the system and what I'm doing with the system—it's like having a database system where I'd want the config for the database to be totally reproducible and immutable, but I'd expect to manage the data itself separately.

And, as a practical benefit, I found setting up borg backups for /home on NixOS a lot easier than I expected :)

Post reply on HN