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

251–260 of 361 posts

Re: The Curse of NixOS

#251

Post by roblabla »

qudat wrote: post #150
roblabla wrote: post #126

Earlier quoted context omitted.

I am all-in on nixos. I've also experienced those problems, but I for one am glad that those don't work. Let me explain. My use-case for Nix is to make my build system so reproducible that, if I get back to the project in five years, it should still compile, and if I give it to someone else, they should be able to make it work without any issue. Like the install steps for them should be as simple as "Install nix, the…

> It's a bug with that package, which should check whether the prebuilt blob will work on your distro. I used nix on arch. I tried using nix via flakes and it didn't work. Then I removed flake from the project, loaded `nvm` and ran it again: it works. For both `nix` and `nvm` the underlying OS was the same. I buy your argument but at the end of the day, I have to get work done. I also feel like I need to mention that…

Yes, for what it's worth I don't mean to diminish your experience. Nix definitely requires pouring a lot of time to get to a working state, is very under-documented, has terrible error messages, will cause errors that don't exist elsewhere, and has no clear "best practice" guide on how to use it. Those are all super annoying pain-points and I do hope they'll get better over time.

At the end of the day, it's a bit of a balancing act. For me, the up-front work of getting a nix build up was definitely worth it, as it allowed my collaborators to get up to speed on complex projects with complex build systems quickly, and gave me a very simple way to reproduce old binaries when I need to bissect bugs. But it definitely took a huge up-front investment.

If all you're after is a way to pin your toolchains, I echo the recommendation of asdf made in a sibling comment. I use it on simpler projects where I just need to pin a language version (and let the language tooling pin the rest of the dependency tree - package.lock-style). It will often be enough, and is much easier to get started with! The only thing that won't pin will be system dependencies (like openssl and such), but that is often an acceptable tradeoff.

Re: The Curse of NixOS

#252

Post by Karupan »

I gave nix (the package manager) a shot about a month back and gave up quickly. The lack of documentation is real for anyone getting started. And it got even more confusing as you’d typically need more tooling and hacks for particular dev environments (Node.js is what I tried).

As much as I dislike docker for dev environments, it is easy and consistent to setup and works for all the languages I’ve had to deal with.

Re: The Curse of NixOS

#253

Post by 42jd »

AceJohnny2 wrote: post #215
dqv wrote: post #212

Earlier quoted context omitted.

>Installing emacs? You'll want to use the binary cache. No biggie. Except when it doesn't work, and your system update ends up building it from scratch--a two-hour process on my stalwart old desktop. Just don’t use emacs ;) In all seriousness, were you pulling from unstable? Disallowing installation because the hydra build is failing has gotten me, albeit for an obscure package I never use. >And flakes are explained…

> I finally figured out the weird incantation to get flakes to work. It was not trivial. Care to share with the class? ;)

I wrote a blog post on NixOS/home manager configurations with nix flakes. I make sure to link out to other resources for those who don’t have the whole background. See: https://jdisaacs.com/blog/nixos-config/

Re: The Curse of NixOS

#254

Post by bpye »

smasher164 wrote: post #120

For me, Nix is one of those systems where I just had to spend a long time with it to understand it. It wasn't something I could master within a few weeks. After about a year of continued use and struggle, I've finally gotten to the point that I'm comfortable going off the beaten path and even contributing to nixpkgs.

Yeah I agree here, I used to find Nix somewhat unintuitive but I have now managed a few non-trivial projects. One being to package Xilinx ISE as a flake [0], and another to build an immutable Linux image using busybox and runit [1]. For the latter I still haven't quite gotten where I want but that's because I realised I needed dbus for avahi and dbus is just so ridiculously complex.

[0] - https://github.com/benpye/nix-fpga-tools/

[1] - https://github.com/benpye/nix-embedded

Re: The Curse of NixOS

#255

Post by lallysingh »

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…

The problems are twofold:

1. The language is a significant problem. If you get everything right, it will do what you want. That's the only nice thing I can say about it. Almost every error it will give you will be misleading. I haven't had such a hard time figuring out errors since early C++ template metaprogramming. And frankly, that was easier.

It needs real diagnostics, and that frankly, that means it needs real types. But that won't happen. Too much of the informal type system of nix is "whatever keys that library function uses, go look in the source."

2. Half-implemented packages. Try walking out of the golden path on a package, without having to modify its nixpkgs entry.

Between the two, it's more nerd-bait than usable platform.

Re: The Curse of NixOS

#256

Post by kaba0 »

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…

Seeing that the nix language was influenced heavily by haskell, perhaps Dhall would be an interesting “port”/change for the project - it is a deliberately non-Turing complete configuration language with types (but heavy type inference) and functions.

Because let’s be honest, types are user documentation as well, and the project would benefit greatly from the latter.

Re: The Curse of NixOS

#257

Post by kaba0 »

ghostwriter wrote: post #33
ashtonkem wrote: post #24

Earlier quoted context omitted.

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

I've programmed professionally in Haskell, I find Nix the Language to be one of the nicest DSLs for defining build pipelines. It's lazy, pure, and it's sandboxed. Whenever you need types on top of it you just pick Dhall and dhall-nix and continue with a productivity gain.

Wow, I just commented that dhall would probably be a fruitful language to consider for nix! And it seems to exist, though according to the readme, general recursion, not strongly typed code and row polymorphism is not supported by dhall but is used heavily by nix :/

Do you by chance know whether a non-Turing complete language like Dhall would be enough to “replace” nix?

Re: The Curse of NixOS

#258

Post by mindslight »

xorcist wrote: post #242
mindslight wrote: post #209

Earlier quoted context omitted.

I think your reasons are focused on Nix for package management. For NixOS specifically, I would add: 5. It's essentially a source distribution with caching. If you want to add say a kernel patch, or any other type of patch, it's straightforward. Whereas running Debian and finding the solution to some problem is building a modified package, my usual conclusion was just to bear the problem until it was fixed upstream,…

Building packages from scratch for Debian can be a hairy endeavour, lots of tooling and it can be hard to know which one to use. But building packages for Debian is dead simple, it is literally one command. Adding a patch to an existing package, and then rebuilding it, is a common operation.

I've run Debian for two decades, so I've definitely ended up going down the path more than a few times. Yes, the actual building process wasn't so hard. It was the maintenance burden afterwards. Maybe I just didn't commit hard enough with my own apt repo, pinning, staying ahead of what was coming through backports, etc. But point is that it effectively never stuck long term, the end result was always going back to vanilla upstream. Whereas in Nixos such patches are some lines in the larger config file, which feels a lot more persistently manageable.

Re: The Curse of NixOS

#259

Post by nh2 »

MayeulC wrote: post #114
AshamedCaptain wrote: post #26

Earlier quoted context omitted.

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 re…

Guix has graft for something similar to this: https://guix.gnu.org/manual/devel/en/html_node/Security-Upda... It's one of the points where it differs from Nix.

Is this different from Nix's `system.replaceRuntimeDependencies` posted in the sibling comment?

Re: The Curse of NixOS

#260

Post by sandgiant »

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…

This mirrors my (very limited) experiences with Nix. I've so far only dipped my toes in home manager, but being able to share shell config and cli tools declaratively between WSL, linux and MacOS with very little branching has been great!
Post reply on HN