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

171–180 of 361 posts

Re: The Curse of NixOS

#171

Post by Filligree »

darkarmani wrote: post #156
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.

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

It's a lot of effort, and in the end you're left with a different, more interesting set of problems.

I don't regret spending that effort, but it needs to be easier if we want more users. I don't think there's any answer besides lots more effort from the nixos dev side, however.

Re: The Curse of NixOS

#172

Post by alpaca128 »

Filligree wrote: post #167
alpaca128 wrote: post #43

Earlier quoted context omitted.

Apparently not, or forgot about it when writing the article: > it's so clearly the only operating system that actually gets how package management should be done

He might be one of the many, many people whose hardware isn't supported by Guix.

Oh right, I forgot it's a purely Free Software distro.

Re: The Curse of NixOS

#173

Post by taeric »

I feel the conflict between the good and bad here is interesting.

First, it has to be acknowledged that the reason everything can be installed to separate directories is a modern luxury. Hard drive space used to be much more constrained.

Second, everything being installed to a unique location is why everything has to be rebuilt. And gets into the fun that you can't update just part.

The problem, then, is we never converged to foundational level software. That is, if we agreed that bash was a foundation of the system, there would just be the one. And you wouldn't get an odd web of versions of it linked everywhere. All code would just use bash.

I'm assuming there has to be some level of this in the package management. That some software is foundational to the system, while some is convenience shared code for applications?

Re: The Curse of NixOS

#174

Post by jonringer117 »

zeec123 wrote: post #124
jcranberry wrote: post #42

Earlier quoted context omitted.

It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these special functions which as far as I can tell were undocumented and I couldn't figure out what they could do. So there was sort of this gap in terms of documentation between theoretical understanding and tooling/functional understanding which I struggled to cross.

What really helped me were the videos of Jon Ringer: https://www.youtube.com/user/elitespartan117j27

Glad someone found them useful :)

Re: The Curse of NixOS

#175

Post by jonringer117 »

TheYumasi wrote: post #12
rgoulter wrote: post #6

"""The first is relatively simple: they developed their own programming language to do configuration, which is not very good and is extremely difficult to learn. The vast majority of people using NixOS do not understand the language, and simply copy/paste example configurations, which mostly works until you need to do something complicated, at which point you're completely high and dry.""" Maybe this is nitpicking, b…

> Maybe that is difficult for people who haven't had an experience with pure/functional programming? I found my understanding of the Nix language became a lot better once I started learning some Haskell. Specifically once I understood what currying was about. 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.

All builtins functions can how render doc with `:doc` in the `nix repl`. I think there's work to make this possible with any arbitrary function.

Re: The Curse of NixOS

#176

Post by Filligree »

dangus wrote: post #169

Something that perhaps detracts from the positives of NixOS is that a lot of the tools that have the biggest issues with the need/difficulty of dealing with multiple versions and environments have long ago come up with their own solutions to the problem. Python has pyenv, NodeJS has nvm, Terraform has tfenv, and the list goes on. Then if you're running on a server/VM/cloud, it seems to me that you should be treating…

> Then if you're running on a server/VM/cloud, it seems to me that you should be treating your systems as cattle instead of pets. I never update packages on servers, I build a new image/instance, test it, and replace the server.

I have six or so servers, all of them configured differently. Not completely differently; they share some configuration. But not very similarly either.

They're pets. They have a lot of state. Backups are running, but I certainly don't want to reinstall them.

Despite being pets, I still want to do as little work to manage them as I possibly can. NixOS is great in this scenario.

Re: The Curse of NixOS

#177

Post by throwamon »

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…

> The configuration.nix "defines" the whole system, but obviously doesn't touch anything in /home

https://github.com/nix-community/home-manager

> or /var, so that's on you to back up, migrate, whatever.

https://grahamc.com/blog/erase-your-darlings

https://github.com/nix-community/impermanence

Re: The Curse of NixOS

#178

Post by FRidh »

mikepurvis wrote: post #62
jcranberry wrote: post #42

Earlier quoted context omitted.

It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these special functions which as far as I can tell were undocumented and I couldn't figure out what they could do. So there was sort of this gap in terms of documentation between theoretical understanding and tooling/functional understanding which I struggled to cross.

As someone 8 months into a major Nix packaging effort (1200 package definitions, mostly auto-generated), this is 1000% the most significant issue. Reading the pills can get you the first little bit, like the difference between derivation and mkDerivation, but so much later stuff is just completely undiscoverable and inconsistent, like the fact that overrideAttrs may subtly not do what you want if it's a Python packag…

This is indeed not very good. Note there is a reason that overridePythonAttrs exists: it overrides the call to buildPythonPackage instead of mkDerivation. There is/was an RFC on standardizing overriding in Nixpkgs but it got stuck. I think for these things to improve what is really necessary is funding to improve Nixpkgs. These kind of issues are fairly hard to solve as they span multiple ecosystems and require coordination.

Re: The Curse of NixOS

#179

Post by kristjansson »

zeec123 wrote: post #123
snowytrees wrote: post #55

Earlier quoted context omitted.

100% this. The language is designed for its use case which is packaging and configuration (nothing more or less). It has a learning curve due to being lazy and functional but works great once you get the hang of it. But the documentation of all its functions is so annoying. You have builtins and the nixpkgs functions[1]. There is learning the language, and then learning how to use it. Then there is the entire ecosyst…

However, until this works, nixpkgs should provide a wrapper around FHSUserEnv which allows developers to develop without the curse.

Convenient (version-addressed!) FHSUserEnv is exactly what I want out of Nix. Land me in an environment that has a list of deps (at specific versions, not hashes!), let me go mess with it.

Re: The Curse of NixOS

#180

Post by aidenn0 »

I've been using NixOS for years and this article made me reflect on the nix language a bit. The nix language is weird looking, particularly if you don't have haskell/ml experience. It also has some unusual semantics that make for punctuation being necessary in places it otherwise might not.

However, I think what trips people up is how foreign the semantics for the nixpkgs standard are. If you are spending all of your time confused and there's this thing that looks weird and confusing, which one are you going to blame?

I will say that a dynamically typed lazy language is its own special hell for debugging though. The only sane way to find an error is to:

1. Start with something that is error-free

2. Make a single small change and see if it is still error free

3. repeat until you get an error; that last change is where the error was. Unless of course you just caused something else to be evaluated that wasn't before. Then that something else is where the error is.

Post reply on HN