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

41–50 of 361 posts

Re: The Curse of NixOS

#41

Post by tazjin »

amarshall wrote: post #34
avakand wrote: post #21

I tried using NixOS on a laptop for a month and switched back to Arch a couple of months ago. It was an interesting experience - I never used functional programming language before, but nix was pretty ok as a configuration language. It looks like funny version of JSON with functions. Debugging it was a real pain though - I was trying to write (or copy from someone else config) a function to recursively import all mod…

> I haven't found a clear list of packages that were going to be updated. The ideal here, IMO, is to use flakes and the nix-diff to compare the build before switching. E.g. nixos-rebuild --flake '.#myhost' build nix-diff /nix/var/nix/profiles/system result sudo nixos-rebuild --flake '.#myhost' switch Could do the same without flakes after the fact by running nix-diff on different generations in /nix/var/nix/profiles…

There's nothing there that needs flakes (an experimental feature which people should not enable without understanding the implications). You could build a system derivation and run a diff against /run/current-system on it.

For what it's worth, nix-diff has very verbose output (it literally diffs everything that is different in the inputs & outputs). A slightly nicer way to diff systems is nvd[0] (example output[1]) which only shows version changes and added/removed packages.

[0]: https://gitlab.com/khumba/nvd

[1]: https://deploys.tvl.fyi/diff/4xmyvkr9nw0cwkn5q38p0cfc58x3jdy...

Re: The Curse of NixOS

#42

Post by jcranberry »

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…

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.

Re: The Curse of NixOS

#43

Post by alpaca128 »

globular-toast wrote: post #7
gypsyharlot wrote: post #2

I always found Guix more appealing, because it uses a programming language that is useful for other things as well (GNU Guile). I really can't stand having to learn a new language for each thing I want to manage.

Is the author aware of Guix?

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

Re: The Curse of NixOS

#44

Post by avakand »

amarshall wrote: post #34
avakand wrote: post #21

I tried using NixOS on a laptop for a month and switched back to Arch a couple of months ago. It was an interesting experience - I never used functional programming language before, but nix was pretty ok as a configuration language. It looks like funny version of JSON with functions. Debugging it was a real pain though - I was trying to write (or copy from someone else config) a function to recursively import all mod…

> I haven't found a clear list of packages that were going to be updated. The ideal here, IMO, is to use flakes and the nix-diff to compare the build before switching. E.g. nixos-rebuild --flake '.#myhost' build nix-diff /nix/var/nix/profiles/system result sudo nixos-rebuild --flake '.#myhost' switch Could do the same without flakes after the fact by running nix-diff on different generations in /nix/var/nix/profiles…

I was using flakes, yes. I remember seeing nix-diff, but most of the time nixos-rebuild dry-build was enough. Sometimes dry build was failing with error, but switching or activating it ran without errors. Never figured out what was wrong :(

Re: The Curse of NixOS

#45

Post by tazjin »

gushogg-blake wrote: post #40

> but the connection between those two things is essentially undocumented I often think documentation would be vastly improved if the author was simply answering the question _what problem did you solve, and how?_, but that seems like it would reveal too much of the dirty details of the design process somehow, so they try to describe the all the neatly encapsulated abstractions and metaphors they've come up with to d…

This implies that the author of the documentation is the person that wrote the thing though, which is surprisingly rare in larger projects.

I wrote one of the more popular Nix language tutorials[0] and my approach there has been to try and explain everything as straightforwardly as possible and make it work both as a reference and a manual (i.e. you can quickly jump to a section that interests you, or read it from top-to-bottom).

One thing that nixpkgs (the Nix package set, which is ~most of the public Nix code) suffers from is reinvention of abstractions (simply due to its age). For example, most programming languages have their own slightly different implementation of a `withPackages` function that gives you a prepared environment with some dependencies. Some of these use open sets, some of them use closed sets, in the latter cases overlaying things into them can get really confusing even for experienced Nix users and so on.

In my opinion, the community should slow its focus on making lots of new features and spend time consolidating existing logic and agreeing on some basic abstractions. Maintenance work like that is not always fun though, and especially in unpaid open-source projects it's difficult to keep up the motivation for it.

[0]: https://github.com/tazjin/nix-1p

Re: The Curse of NixOS

#46

Post by JamesSwift »

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…

I was definitely in the "I just dont get it" camp for a couple years before coming across a comment on HackerNews pointing to Burke Libbeys fantastic playlist on Nix [1]. It was a revelation and was what I needed to finally have the DSL click for me. Cant recommend it enough.

[1] - https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...

Re: The Curse of NixOS

#47

Post by dangerbird2 »

gnu wrote: post #37

NixOS and Guix are nice! Guix folks are doing some wonderful work off late. I have used NixOS for a while. But for casual desktop GNU/Linux users, it seem like solving a problem that doesn't exist. Have been using Debian on all my computers since 1998. Unless you are using Debian unstable and updating it daily, I hardly hit any breakage. Servers and deployments is another story.

How does Guix compare to Nix? It seems like by using a scheme-based DSL instead of an ad-hoc configuration language, it solves one of the main complaints the author has about Nix.

Re: The Curse of NixOS

#48

Post by 2pEXgD0fZ5cF »

avakand wrote: post #21

I tried using NixOS on a laptop for a month and switched back to Arch a couple of months ago. It was an interesting experience - I never used functional programming language before, but nix was pretty ok as a configuration language. It looks like funny version of JSON with functions. Debugging it was a real pain though - I was trying to write (or copy from someone else config) a function to recursively import all mod…

Same here, tried NixOS for ~3 months, I tried to go all-in too, I spend time to really read the docs and work out an intricate configuration that leverages features like flakes and covers my system setup and dotfiles (got inspired by Lissners NixOS configuration) and was ready to handle multiple systems in preparation to roll it out to my 2nd and 3rd machine.

Ultimately there were warts that I was able to solve, but still annoyed me greatly and felt ugly and forced me to step outside the convience of my nixos config system (like wifi with iwd, btrfs + swap files) and at one point I was no longer able to `nixos-rebuild switch --upgrade`, the command kept failing even on versions of my config that I was able to confirm working, I spent some time trying to find the problem but eventually came to the conclusion that it might not be worth it in the long run.

In the end I went back to my previous distribution of choice. I still find the whole concept interesting and I will give Guix a try next.

Fixing NixOS problems that the community hasn't encountered or solved yet really fills me with a special kind of dread compared to regular distributions where finding a solution to a rare problem is usually just a mix of taking a look at upstream and writing a patch or adapting general solutions from other distributions.

Re: The Curse of NixOS

#49

Post by JamesSwift »

ashtonkem wrote: post #23

The real break for me using NixOS as a regular driver was that I just could not figure out how to get Ruby on Rails to play nice with it. NixOS breaks a lot of assumptions that programs make about $PATH, and even if it's done for good reasons it plays holy hell with the development stack of some languages. I eventually gave up and moved my dev setup back to OSX (and then that PC died anyways). Maybe they've fixed it…

I moved to Docker for ruby/rails dev long ago and never looked back. Trying to do it locally, especially if there are others involved, is a path to pain and frustration as "works on my machine" creeps into a `bundle install` every few months.

Re: The Curse of NixOS

#50

Post by ghostwriter »

rgoulter wrote: post #35
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...

Nix is wonderful, but absolutely is under-documented. (In part due to a small community, etc.). A couple of examples I've run into: https://github.com/NixOS/nix/issues/2259 showed people trying to make use of the "hello world" package which was given in the NixPkgs manual, but couldn't quite figure out how to get it to build. e.g. if you want a package that's a simple script, "writeScriptBin" seems like what you'd wa…

> you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri...

Is it too much to ask from developers in 2022? At source, the function is well documented and is provided with an example [1]. The only missing part is a rendered HTML with the same information.

[1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

Post reply on HN