The Curse of NixOS • Hacker News Board

Re: The Curse of NixOS

#21

Post by avakand » Mon, Jan 24, 2022, 2:21 PM UTC

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 modules from a folder and the error messages were hard to understand with stacktraces ending somewhere deep in standard library.

The other problem was with nixpkgs, i.e. I haven't found a clear list of packages that were going to be updated. Jetbrains IDEA was updating very slowly and when I wanted to pin a version of it simply overriding version variable in the overlay was not enough - there were also some other linked variables. Emacs package from custom overlay constantly tried to compile itself, requiring me to check build status on hydra build system.

In the end I decided that it's not really worth it. I don't have many systems and services to manage and for a raspberry pi and a vps multiple docker-compose.yaml files in git repo is enough. I think Henrik Lissner (author of Doom Emacs) wrote a really good piece about why someone should choose to use NixOS - https://github.com/hlissner/dotfiles#frequently-asked-questi...

Re: The Curse of NixOS

#22

Post by Throwaway194902 » Mon, Jan 24, 2022, 2:23 PM UTC

AshamedCaptain wrote: post #14

> But at the same time, I can patch the Python interpreter and then have some software running on my system actually use the patched version, since all of this stuff is configured through the same configuration system. If I want to do that, then I have to rebuild the entire system so as to use my patched version. This is because the NixOS "dependencies" are basically expressed as hashes of binaries. That is for me th…

NixOS and Guix do _not_ require static linking. They go even one step further and allow many versions of a dynamic object to exist at the same time and each software on your system chooses, which version of the object to link against.

Re: The Curse of NixOS

#23

Post by ashtonkem » Mon, Jan 24, 2022, 2:26 PM UTC

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 since then, I haven't tried.

I do continue to use it for my homelab infrastructure though. It is extremely good at handling new versions of configuration of Prometheus, and I would never consider anything else at this point. Just not what I'd use as a dev environment.

Re: The Curse of NixOS

#24

Post by ashtonkem » Mon, Jan 24, 2022, 2:27 PM UTC

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 this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". Maybe that is difficult for people who haven't had an experience with pure/functional programming?

I've programmed professionally in Lisp (SBCL) and Clojure, and done a lot of hobby work in Haskell and Rust. I found Nix the language utterly incomprehensible largely because of documentation and tooling reasons.

Re: The Curse of NixOS

#25

Post by colinramsay » Mon, Jan 24, 2022, 2:28 PM UTC

nine_k wrote: post #17

colinramsay wrote: post #11

> I'm going to keep using it, since I can't stand anything else after having a taste of NixOS This is how I feel about NixOS. I like what it gives me but I don't really like much else about it. Unless something _just works_, you're looking at hours of debugging which will most likely lead to failure. Off the top of my head there are a couple of things I've hit a dead end on recently: - Packaging a Flutter desktop app…

I'd say that packaging an app for NixOS should include rewriting all such impure steps, and making the fonts packaged along with the app is one such step. If the fonts can't be packaged for licensing reasons, even as a separate package, then well, you indeed can guarantee that you'd be able to install the app next time. If it's not what you seriously need, then likely the value proposition of Nix is not for you.

I agree. That doesn't negate the fact that it took me a while to understand what the issue was, see if I could get around it, work out how to disable the font downloading in Flutter, etc, etc. I may have been trying to force a round peg into a square hole but NixOS didn't do much to help me see the shape of the pegs and holes in the first place.

Re: The Curse of NixOS

#26

Post by AshamedCaptain » Mon, Jan 24, 2022, 2:30 PM UTC

Throwaway194902 wrote: post #22

AshamedCaptain wrote: post #14

> But at the same time, I can patch the Python interpreter and then have some software running on my system actually use the patched version, since all of this stuff is configured through the same configuration system. If I want to do that, then I have to rebuild the entire system so as to use my patched version. This is because the NixOS "dependencies" are basically expressed as hashes of binaries. That is for me th…

NixOS and Guix do _not_ require static linking. They go even one step further and allow many versions of a dynamic object to exist at the same time and each software on your system chooses, which version of the object to link against.

You cannot change the version used by a given binary unless you rebuilt that binary, effectively making it similar to static linking (you still get sharing of DSO files & pages, though). i.e. even if I have two versions of some low-level library installed, depending installed packages still hardcode which one of the two low-level libraries to use, and if I want to switch the system from one to the other, I have to rebuilt it (or at least all depending packages).

Suppose I make an overlay of libc to add some functionality that I am debugging which changes the libc binary, albeit not the ABI. Can I still reuse the same packages? Can I still reuse someone else's binary cache ? Basically, can I do without having to rebuild the entire system (save for libc) ?

Re: The Curse of NixOS

#27

Post by ashtonkem » Mon, Jan 24, 2022, 2:30 PM UTC

vasergen wrote: post #19

colinramsay wrote: post #11

> I'm going to keep using it, since I can't stand anything else after having a taste of NixOS This is how I feel about NixOS. I like what it gives me but I don't really like much else about it. Unless something _just works_, you're looking at hours of debugging which will most likely lead to failure. Off the top of my head there are a couple of things I've hit a dead end on recently: - Packaging a Flutter desktop app…

> Unless something _just works_, you're looking at hours of debugging which will most likely lead to failure. Exactly my experience, in this case I simply switch to my OS package system (I use Nix only as a package manager on my Ubuntu). I think, I have round 95% of software coming from Nix, for the other 5% that doesn't work out of box, I just do 'apt-get install' Also, for installing different programing languages…

I think they were using NixOS, not just Nix, which means that you can't fall back to the "OS package system" because Nix is the OS package system.

The difference between Nix and NixOS was a branding mistake by the Nix team. It's unnecessarily confusing.

Re: The Curse of NixOS

#28

Post by ghostwriter » Mon, Jan 24, 2022, 2:31 PM UTC

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.

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

Re: The Curse of NixOS

#29

Post by valyagolev » Mon, Jan 24, 2022, 2:31 PM UTC

mplanchard wrote: post #20

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…

There is also a nix store query to find this information. I’m on my phone so I can’t get it right now, but I’ll try to remember to grab it later. You can query all the dependencies of any derivation… this is how I verify the full suite of software that nix-direnv installs for local projects, by querying the store for its cached derivation’s deps.

i think “statically” means without executing the nix language stuff

Re: The Curse of NixOS

#30

Post by mindslight » Mon, Jan 24, 2022, 2:32 PM UTC

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…

The semantics are simple and necessary, yes. The syntax is kind of crap in some ways (in others it's awesome and I wish other languages were as lightweight). Syntax in general is a bikeshed, but that doesn't mean we can't objectively critique things like having function definition being a mere ":". That one on its own is probably responsible for much of the indecipherability.

Also some of the higher level constructs really aren't clear (like overrideDerivation/overrideAttrs/override, I still don't fully get). And mkDefault/mkForce/etc could be a bit more front and center rather than in "lib".

Also every time I run nixos-rebuild and it takes several+ seconds to evaluate my Nix expression I've got to wonder how much the implementation being this cute functional fixpoint is holding performance back.