Live data from Hacker News

The Curse of NixOS

blog.wesleyac.com

291–300 of 361 posts

Re: The Curse of NixOS

#291
post #117

Earlier quoted context omitted.

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…

This right here is enough for me to not even bother tying this OS. I'm always interested in operating systems (and the adjacent config systems that live on top of the Linux kernel, Arch Linux is one of those, Gentoo is another). But I'm not so interested in adding vitriol to my life, no matter the technical excellence. I'd rather live with a mundane kludge than deal with knowledge elitism.

Lol cause one guy was cranky on the internet?

Re: The Curse of NixOS

#292

Earlier quoted context omitted.

> 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 just switched away from asdf (primarily developing Go on Mac) because of the problems it caused.

What problems, if I may ask?

Re: The Curse of NixOS

#293
post #191

Earlier quoted context omitted.

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…

I honestly think that Nix is one of those things where "going all in" is one of the worst things you can do. Running a desktop system on NixOS is quite a tricky prospect for someone with no experience of Nix and you'll likely get frustrated with having to learn some potentially alien concepts to achieve simple things. I tend to recommend people start in the shallow end, using Nix on a regular Linux distribution (or e…

I found that building my configuration on a virtual machine was the best way to go. This way I was not desperate to get things working and simply moved when I felt like all my essential programs were in place.

Re: The Curse of NixOS

#294
I don't understand what's wrong with the Nix language. Sure, the space-delimited lists can get a little annoying, but other than that it's minimalistic enough to use a configuration language but complex enough to do more complicated things like overriding derivations. Maybe it's because I learnt Haskell before Nix so the syntax is very familiar to me, whereas I see how it could be a learning curve for other users.

What I find the most annoying is the lack of documentation of some of the nixpkgs functions. Some of the functions provided by import {}.lib appear to be the same as the ones builtin to the Nix language and there doesn't seem to be any clear guidance on when to use which version. I've also had to look at the source code to find out the difference between writeTextFile, writeText, writeTextDir, writeScript, and writeScriptBin. [The docs][1] explain writeTextFile, but the only documentation for the rest is ‘Many more commands wrap writeTextFile including writeText, writeTextDir, writeScript, and writeScriptBin. These are convenience functions over writeTextFile.’.

Additionally, it's a bit frustrating for me how all the documentation for nixpkgs — the lib functions, how to make a derivation, specific details for building packages in certain languages, how to contribute to nixpkgs, overriding packages/overlays etc — are in [one gigantic web page][2] that's quite slow to load and even slower to search for things in.

[1]: https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri...

[2]: https://nixos.org/manual/nixpkgs/stable/

(copied from my Lobsters comment https://lobste.rs/s/psfsfo/curse_nixos#c_y83hvy)

Re: The Curse of NixOS

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

Is there anything that explains the why and how a bit deeper?

As an example, in the video "Packaging a Gem as a Nix derivation", he basically just and copies and pastes another default.nix, changes some strings and mentions he doesn't understand what 'passthrough.updateScript' does, but just changes a string there too.

This doesn't really help me understand Nix.

Re: The Curse of NixOS

#296

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…

I've tried to use Nix on and off for years. I always run into issues where I need to write some package and (1) I get mired in packaging low level transitive dependencies and things which seem like they should be easy end up being nearly impossible (2) Basic things like figuring out the argument types for a particular nixpkgs function take an insanely long time. It always involves grepping around the whole repo (nixp…

Exactly what I've found. The concept is brilliant. The execution is user-hostile. I wish someone brilliant would take a good look at it for a long time, then head off into the tropics for a month while meditating on how to simplify it and/or make it more user-friendly, and return with something that is equal to Nix in concept but superior in execution and UX.

Re: The Curse of NixOS

#297

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…

> Reproducibility: because package definitions are self-contained, I can pin and reliably reproduce everything for my packages. And I do mean everything. Does that mean we get downloadable precompiled binary packages too? If not, why not?

Yep. The cool thing is that installing a binary version of a source package is totally transparent from Nix's point of view—it's not a different entity, it's solely a matter of caching. If you're building a package that somebody else built and uploaded to a cache that you can access, you'll download the binary instead. There's a public cache, so when you use a standard package set as your base, you'll be getting most things as binaries. But if you make some changes or something else breaks and binaries aren't available, it falls back to building from source transparently—sometimes this can take a loooong time, but it usually doesn't, and I'd rather have the option to do that than not :).

The other bonus is that it takes very little effort to share your own binary cache—either privately (so that you or your company only need to build something once) or publicly (so that people installing your open source tool don't have to build from source). There's even a really well-designed commercial service called [Cachix][1] that provides a totally turn-key binary cache, including a free tier for open source projects.

[1]: https://www.cachix.org/

Re: The Curse of NixOS

#298
I used Nix and NixOS for more than a year as my daily driver. I've contributed to Nixpkgs. I agree with the author on most if not all of their points. Here's some advice: If you're interested in Nix, take steps not leaps. Use the Nix package manager. It's a great addition to distros like Debian. Then maybe use Home Manager (even though I think Home Manager is way over-hyped, see below). Then write a bunch of derivations. Then go learn the ins and outs of systemd. THEN go play with NixOS. If you skip any steps before the NixOS part, you will get lost in the weeds. The happy path of NixOS is very happy. The other paths are very challenging. You should really know a lot about both Nix and more traditional Linux packaging methods before you go all in on NixOS. And honestly, learning more traditional Linux utilities is a far better use of your time than learning the complex, ever-changing Nix landscape. It's a super cool project, I'm so glad it exists. But it should really be viewed as a _research_ project. Many good things will come out of it. Hopefully one of those things (like the author mentions) is a Nix clone written in a common language with a much better UX. Until then, try to avoid the urge to play with shiny things and stick to just using the Nix package manager and more traditional tooling.

And about Home Manager, the reason why I think it's over-hyped is because it provides a declarative approach to something that was... already declarative. Your $XDG_CONFIG directory does not need a leaky Nix abstraction on top of it. It actually just makes everything 10x harder. The Home Manager Nix abstractions are terrible but people seem to love it? Why would I write my i3 config in Nix?? An i3 config literally cannot get any simpler. Why make it more complicated for no benefit? I also don't need a declarative list of all installed packages. I'd rather just use `nix-env` personally.

Re: The Curse of NixOS

#299
post #117

Earlier quoted context omitted.

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…

This right here is enough for me to not even bother tying this OS. I'm always interested in operating systems (and the adjacent config systems that live on top of the Linux kernel, Arch Linux is one of those, Gentoo is another). But I'm not so interested in adding vitriol to my life, no matter the technical excellence. I'd rather live with a mundane kludge than deal with knowledge elitism.

>I'd rather live with a mundane kludge than deal with knowledge elitism.

But I would put up with a lot, if the payoff is more knowledge.

Re: The Curse of NixOS

#300

I understand the first complaint but not the second > The second flaw is that NixOS does not actually provide real isolation. I thought this would going to be about security, but then it was about having to repackage the world. But Nixpkgs is current the biggest and most up to date package repository in the world (we finally beat AUR). Packaging enough stuff is emphatically not the problem. What I want to see is deve…

I think you missed the key point. Software needs to be altered to run on Nix, and it needs to do so _systematically_. Grab a script from the internet? Edit the shebang! Download some prebuilt software? Good luck finding /lib/ld-linux.so.2! Need to use some proprietary software you cannot edit? HALP! Of course there must be some tooling to get around this, since stuff like steam is available (at least I hope), or else…

Side note: It would be nice to have a way to look up library -> package name.
Post reply on HN