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

61–70 of 361 posts

Re: The Curse of NixOS

#61

Post by epage »

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…

Another problem I ran into is trying to figure out how each package wants me to define plugins. There are common examples for Python environments (Python packages are like plugins into Python) but when it came to other software, I was at a loss when digging into things, even after reading all of the general documentation.

Re: The Curse of NixOS

#62

Post by mikepurvis »

jcranberry wrote: post #42
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.

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 package since you have to use overridePythonAttrs instead, but the corresponding function for other builders (eg overrideBazelAttrs) doesn't exist.

Re: The Curse of NixOS

#63

Post by ninjin »

mplanchard wrote: post #39
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.

I completely agree, but the main benefit nix has over guix is some amount of MacOS compatibility. I don’t currently use a Mac, but I know that next time I have to use one for work, my home-manager-mediated config, which contains almost all of my user-specific configuration, will port right over just fine. The guix team doesn’t seem particularly interested in supporting MacOS, and I can’t blame them. The other benefit…

I have had NixOS as my daily driver for nearly three years now and maintain a small number of packages in Nixpkgs. From my perspective, macOS support is a headache as it all of the sudden may require you to debug on a proprietary OS that you lack access to and that runs on two different hardware architectures in order to get a patch accepted. I am probably not going to make any friends for saying so, but I would much prefer if Nixpkgs for macOS was maintained separately.

My personal reasons for not going with Guix is that it is a GNU project and thus you have to buy into the entire FSF philosophy. Sadly I do need to run on “problematic” hardware from time to time and would prefer if doing so did not require me to add unofficial extensions and be wary of uttering such heresy in the company of my fellow users. That being said, I like what Guix is doing and their documentation does frankly look better compared to the grass where I am standing.

Lastly, yes, NixOS is a damn curse. Once you get the taste of having a declarative operating system it is really hard to go back. Trying out tiny tweaks to your audio, kernel, etc. all with the confidence that you know how to get back to what you had before is so very addictive. We need more diversity in this space.

Re: The Curse of NixOS

#64

Post by valyagolev »

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.

as much respect as I have for Guile, I'd love the nix configuration language to have at least partially enforced types...

Re: The Curse of NixOS

#65

Post by yewenjie »

altgans wrote: post #56

I am a NixOS user, but am interested in Guix. Based on a cursory look I have some questions: - How big is Guix on GNU? Does it throw wrenches in your way if you do anything "unfree"? How easy is it to install the nvidia-drivers? - How is the package ecosystem? 20.000 official packages seems a little low? Are there community packages? How easy it is to create your own packages? Why is the Neovim package only at versio…

Yes, the low number of readily available packages is the primary reason I switched from Guix to Nix.

Re: The Curse of NixOS

#66

Post by assbuttbuttass »

altgans wrote: post #56

I am a NixOS user, but am interested in Guix. Based on a cursory look I have some questions: - How big is Guix on GNU? Does it throw wrenches in your way if you do anything "unfree"? How easy is it to install the nvidia-drivers? - How is the package ecosystem? 20.000 official packages seems a little low? Are there community packages? How easy it is to create your own packages? Why is the Neovim package only at versio…

As someone who's used Guix:

They only package linux-libre, so if your device needs proprietary wifi, you're out of luck. Also they package icecat instead of firefox which is kind of cool.

I tried to package slash'em a few years ago, and found it very difficult. The documentation is gigantic and it's hard to find what you're looking for. I found folks on IRC very helpful.

Re: The Curse of NixOS

#67

Post by mplanchard »

ninjin wrote: post #63
mplanchard wrote: post #39

Earlier quoted context omitted.

I completely agree, but the main benefit nix has over guix is some amount of MacOS compatibility. I don’t currently use a Mac, but I know that next time I have to use one for work, my home-manager-mediated config, which contains almost all of my user-specific configuration, will port right over just fine. The guix team doesn’t seem particularly interested in supporting MacOS, and I can’t blame them. The other benefit…

I have had NixOS as my daily driver for nearly three years now and maintain a small number of packages in Nixpkgs. From my perspective, macOS support is a headache as it all of the sudden may require you to debug on a proprietary OS that you lack access to and that runs on two different hardware architectures in order to get a patch accepted. I am probably not going to make any friends for saying so, but I would much…

Oh yeah no doubt MacOS is a huge pain. We use nix for installing system deps at work, and it seems like once every six months or so something will inexplicably stop working on Mac. Luckily I have an old Mac at home, but the new architecture means that one is becoming pretty much useless now for debugging some of the stuff that comes up.

Still, being able to guarantee everyone working on the project has the same versions of everything is pretty nice. No need to worry about ancient Mac versions of bash or awk or sed or whatever, so we can script confidently.

Re: The Curse of NixOS

#69

Post by mikepurvis »

otabdeveloper4 wrote: post #15
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". It's too simple and straightforward. Writing Nix expressions is a bit like writing Javascript without frameworks or libraries. Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)

The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages.

I don't agree with this direction, though. Basic packages can already be described pretty simply using native nixlang, and the complexity scales well— you can add patches, fixups, flags on dependencies, extra fetcher args, whatever and it's a pretty smooth ramp all the way up. Whereas it would be considerably more jarring if you could use the "simple" thing up until the point where you abruptly hit a wall and then suddenly had to start over in real Nix when you hit that one thing that happens to require it.

Quite apart from that side of things, if a significant portion of nixpkgs were converted to the new simplified package definition style, it would majorly shrink the potential pool of example package definitions for novices to examine.

Re: The Curse of NixOS

#70

Post by ryukafalz »

assbuttbuttass wrote: post #66
altgans wrote: post #56

I am a NixOS user, but am interested in Guix. Based on a cursory look I have some questions: - How big is Guix on GNU? Does it throw wrenches in your way if you do anything "unfree"? How easy is it to install the nvidia-drivers? - How is the package ecosystem? 20.000 official packages seems a little low? Are there community packages? How easy it is to create your own packages? Why is the Neovim package only at versio…

As someone who's used Guix: They only package linux-libre, so if your device needs proprietary wifi, you're out of luck. Also they package icecat instead of firefox which is kind of cool. I tried to package slash'em a few years ago, and found it very difficult. The documentation is gigantic and it's hard to find what you're looking for. I found folks on IRC very helpful.

>They only package linux-libre, so if your device needs proprietary wifi, you're out of luck.

I wouldn't say you're out of luck in that case. If you need upstream Linux, nonguix has it: https://gitlab.com/nonguix/nonguix

Post reply on HN