Live data from Hacker News

Nix – Death by a Thousand Cuts

dgt.is

211–220 of 336 posts

Re: Nix – Death by a Thousand Cuts

#211
I'm a NixOS user and contributor.

This post is fair.

Nix is very flexible, and it hasn't yet stabilised on a firm set of recommendations for a happy path.

Going on a whim:

* Use nixos-unstable. It's defacto stable, and gets much more attention than nixos-stable.

* Use flakes.

* Don't use multiple versions of nixpkgs. In the rare case a package is failing to build, then raise an issue, or wait, or rollback.

* On NixOS, don't use user profiles. They won't interop in the way OP hopes.

* Only use nixpkgs. If you absolutely must use another flake, only use popular ones from https://github.com/nix-community.

But until the community give opinionated suggestions, users will stray towards bad practices.

(Also, no need to mix pipewire and jack. Pipewire can emulate jack.)

Re: Nix – Death by a Thousand Cuts

#212
post #68

I love NixOS, it's my daily driver on my personal laptop, but it definitely has given me more than its fair share of headaches. If everything you're going to do is in Nixpkgs, great! Nix will mostly "Just Work" and you'll get all the nice declarative goodness that you want. Since Nixpkgs is constantly getting updated, this isn't that weird of a thing. The thing that's been most annoying to me is when I try and run ge…

Just use Nix/Home Manager on Ubuntu or something instead of NixOS. You get, by far, most of the reproducibility and none of the NixOS issues. NixOS feels more like a great server environment, but not that good of a DE.

Re: Nix – Death by a Thousand Cuts

#213
post #86

I only wish Guix had a more robust nonfree packages I think it could really give Nix a run for its money.

If you're looking for robust, nonfree packages for Guix, you can find them here: https://github.com/nonguix/nonguix

I know about nonguix. It's the only way the wifi drivers work on my laptop. But it doesn't have half the stuff Nix does. I need a nix service running in my system configuration to install Teams and Discord. That channel is practically unmaintained compared with Nix, I'd guess because it's not an official part of Guix.

Re: Nix – Death by a Thousand Cuts

#214
post #126

I really like Nix but recently I ended up in a very tricky situation: If you you are cut from the internet or end up with a very slow connection you can end up totally blocked. As a minor configuration change can require you to download a lot of data. I also found out there is not much you can do to protect you from this.

If you’re using flakes, this is minimized, as long as you don’t cleanup (GC) your Nix store and don’t update your lock file.

Yes but the problem is the underlying complexity of modern systems. Actually kudos to NixOS for hiding it very well from you. My system is fully configured with flakes and in practice the smallest change in configuration can trigger the need for connectivity, usually to download a new dependency.

I mean if you have VMs in the cloud, who cares. If you have a laptop or a small network that require to be fully operational even if connectivity is lost, think about it twice.

Re: Nix – Death by a Thousand Cuts

#215

Earlier quoted context omitted.

Worth noting that ChatGPT et al. Are equally useless for debugging Nix. Frustrating that it’s so far behind. Error messages are often cryptic and misleading.

Yep, I thought ChatGPT was trained on Github but it's generated precisely 0 correct .nix files for me to date.

I suspect Sturgeons law is at work here. "90% of everything is crap"

I can believe that especially with nix - there isn't a defined way to do things. Most flakes out there will be done by newcomers learning and flakes is relative new e.g. 2020. The documentation of nix is bad.

SO ChatGPT3 had very little good stuff to learn from and later won't have much better.

Re: Nix – Death by a Thousand Cuts

#216

Earlier quoted context omitted.

Yep, I thought ChatGPT was trained on Github but it's generated precisely 0 correct .nix files for me to date.

I suspect Sturgeons law is at work here. "90% of everything is crap" I can believe that especially with nix - there isn't a defined way to do things. Most flakes out there will be done by newcomers learning and flakes is relative new e.g. 2020. The documentation of nix is bad. SO ChatGPT3 had very little good stuff to learn from and later won't have much better.

A lot of the documentation includes code snippets but with no detail or context on where those snippets should be, so ChatGPT often puts things in the wrong place.

Re: Nix – Death by a Thousand Cuts

#217
Yeah, same.

I originally had a very positive nix experience. I had to fix some docker build issue at work. This particular dockefile needed the buildx command. Except for whatever reason I just couldn't install the needed component for buildx to work. Somewhere during a messy Ubuntu 18.04 to 22.04 upgrade something broke and now I was getting a conflict (with nothing btw, it's just empty).

I used nix to install docker and the required component with no hassle and was able to get on with my work.

Inspired by this experience I wanted to evaluate nix for a more long-term usage. I setup my personal PC to dualboot windows and nixos. The trouble started basically immediately.

I couldn't get KDE plasma 6 to work with Wayland. It turns out that you need to also enable Wayland support in sddm. Why the official installer did not do this or why this was only documented on some random unrelated page in one of the two wikis I couldn't tell.

Ok, video working I immediately spotted another problem. I set up my disk encryption, login and kde wallet passwords to match in the hopes that on boot I will only have to enter it once (this is an option you can enable). Login screen worked, but kwallet just wouldn't log in automatically. I spent literal hours on this over the past year each time walking away frustrated. Is this a nix issue, Linux issue or kwallet issue? Who knows. Eventually I just set an empty password for kwallet. This still didn't solve my git ssh keys not loading automatically. I just gave up.

Most importantly, dev environments just do not want to work with VSCode. The recommended extension stopped working years ago, the other extension still works but there's no way to force a specific load order so randomly other extensions will just not see your nix env. I had to resort to installing rust globally just so I could get rust analyzer working. So much for dev environments. I don't even want to go over how much working with package managers when using nix for building sucks (particularly npm/pnpm/yarn).

If I had installed nix on a work laptop they would have fired me for wasting time. Next time I'm trying one of the immutable config driven distros. Hopefully that is going to work better.

Re: Nix – Death by a Thousand Cuts

#218
post #174

Earlier quoted context omitted.

> I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the similar lazy nature of the language. My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by…

My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by only the inputs), but whose implementation is very much not (it builds packages from a specification). Evaluation is completely pure (at least with flakes, which disallows querying environm…

> Evaluation is completely pure (at least with flakes, which disallows querying environment variables, etc.). Evaluation of derivations will result in .drv files in the store, but that does not add impurity to the language itself. Building the .drv is a separate step (instantiation).

If import-from-derivation is enabled (it normally is, it's a very useful feature, and the foundation of flakes), then some derivations need to be built to complete the evaluation.

https://nix.dev/manual/nix/2.25/language/import-from-derivat...

Even then functions like "readFile" are considered to be pure in nix, but not in haskell.

> If I am not mistaken, this is how Guix started - they evaluated derivations defined in scheme to .drv files and then let the Nix daemon build them

IIRC it still works that way; there's no real reason to change. Scheme isn't purely functional though (and the guix programming model is clearly imperative), so it doesn't have this mismatch.

Re: Nix – Death by a Thousand Cuts

#219
post #123
post #72

Earlier quoted context omitted.

It's basically, I refuse to learn how to containerize. Just learn, use, promote best practices and stop forking the ecosystem _even_ further... There, I got that off my chest.

Nix handles containerization better than Docker does. Here is a flake that builds a Go app and a Docker image for it (based on headless Chrome): https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0... And here is how the image is built in CI: https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0...

here is a derivation that fetches https://www.usememos.com/ from source, changes the color palette, builds a docker image out of it and spins up a container that traefik exposes automatically: https://gist.github.com/knoopx/afde5e01389e3b8446f469c056e59...

Re: Nix – Death by a Thousand Cuts

#220
post #190
post #130

Earlier quoted context omitted.

Nix currently has the most packages of any distribution, see https://repology.org/ The model of having packages on Github with pull requests scales very well. Therefore, you could argue that people are getting things done with Nix.

> Nix currently has the most packages of any distribution, see https://repology.org/ This is a meaningless point. Different distros split packages differently.

No it’s very much meaningful. for every new ecosystem it’s immediately graded based on whether it has the critical mass of adoption. The build and release system is great, what I actually wish for is nixpkgs to offer debs and rpms to ensure that maintainers flock here
Post reply on HN