Live data from Hacker News

Nix – Death by a Thousand Cuts

dgt.is

141–150 of 336 posts

Re: Nix – Death by a Thousand Cuts

#141

I use NixOS, one of the annoying things to me is the documentation and error reports. I swapped my installation to a Flake managed install a few months ago, and parts of my Nix files that were perfectly fine before started throwing out errors (specifically HomeManager), which no amount of Googling the error message that gone thrown got me any closer to a solution. I looked at documentation recently to try and enable…

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.

Re: Nix – Death by a Thousand Cuts

#142
post #71

I courted making the switch to NixOS a couple times, but I just don't really see the value add to me right now. Yes, if you have a lot of machines then it maybe make sense. At this point I just use Nix home manager for my dotfiles/userspace programs on a normal distro and I feel like I get 90% of the benefit without any of the headaches.

The reason I keep it around on my laptop is mostly because of the snapshotting. I generally do know my way around Linux command line nowadays, but with Ubuntu and Arch (especially early in my career when I didn't know what I was doing), I would get into states that break the video driver, or break GRUB, or make the machine unstable, and the only thing I could do was reinstall the whole OS. With NixOS, since it's all…

Just a side note for those who aren't on NixOS, but who would like 90% of snapshotting: use timeshift. Especially if your file system is BTRFS. It'll do daily snapshots of all your system files, going back 5 days by default. I've only had to use it once, but it was invaluable. Another nice thing is it's very much a set-and-forget program.

Re: Nix – Death by a Thousand Cuts

#143

Earlier quoted context omitted.

> an Ansible-like setup Using another common tool (salt/chef/puppet/...) or something home-rolled? (Just asking because I'm interested in new options in this space)

As I said, a small shell script I wrote. The only things it needs to do are sync files according to the `filelist` files and sync packages according to the `packages` files, so I don't need the full verbose DSL of Ansible etc. Also it means it has no dependencies on the target machine. You might say Ansible doesn't need anything on the target machine except ssh, but it does require the target machine to be reachable…

How do you deal with removing a package? For examplet the case where you have htop in your config, but no longer want it on your system or in your configs.

Re: Nix – Death by a Thousand Cuts

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

You're going to need to do more than just link to the flake if you want to show why that's better than the Dockerfile equivalent, because the code itself isn't selling it.

Re: Nix – Death by a Thousand Cuts

#145

I use NixOS as my daily driver. I concur. I wouldn't recommend it for most people (even for me, when I decided to give it a try). I'd probably just go Arch if I were to do it over again. The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too…

My experience has been in complete agreement with yours: I love the theory, but the practice is so, so painful.

And yes, I also had to settle for your NVIDIA fix. I suspect I would have had a marginally better time on Arch as there are more people beating their heads against it and documenting how they made it work. NixOS documentation is piss-poor in comparison.

Re: Nix – Death by a Thousand Cuts

#146

I use NixOS, one of the annoying things to me is the documentation and error reports. I swapped my installation to a Flake managed install a few months ago, and parts of my Nix files that were perfectly fine before started throwing out errors (specifically HomeManager), which no amount of Googling the error message that gone thrown got me any closer to a solution. I looked at documentation recently to try and enable…

This is why I haven't switched my NixOS to flakes yet. The community discussions always act as though flakes should be the default that everyone should use now, but I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason. So far so good—my system is far more stable than it was under Debian and I've yet to run into anything that didn't have an easy answer. I have a…

I'm glad I'm not the only one who's grinding their gears with flakes.

I decided to migrate to flakes because a lot of the documentation for things I wanted to do with NixOS required flakes. It took me at least a few hours to understand what the purpose of them was though.

I just wish the documentation would be improved really, as an example https://nixos.wiki/wiki/Build_flags#Building_the_whole_syste... no longer works (gcc complains).

Re: Nix – Death by a Thousand Cuts

#147

The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".

I tend to agree. I also think both sides need to learn to better appreciate the other. Without people getting shit done with the tools we’ve built, there would be no demand for better tools and no need to write them. Without better tools, the things we can get done are limited. Better tooling is an exponent to our productivity. The things we can accomplish today would have been nearly unimaginable nearly thirty years…

> Better tooling is an exponent to our productivity

Nix & NixOS have made me much more productive. Maintaining a desktop is effortless. If something breaks, I can simply reboot to a previous installation. I can also try software without installing, and develop parallel projects relying on dependencies that would be mutually incompatible in a regular imperative package manager.

But I recognize that if you need to do something slightly unusual, documentation is incomplete and scattered. For simple things, my contrarian view is that Nix is not hard at all. The subset of Nix I use can be learned in a couple of hours. I think the trick is to avoid getting sucked into packaging complex software with messy build systems. If the stack you use is well packaged in NixPkgs, it's a joy to use. If it's not, it's better to stay away.

Re: Nix – Death by a Thousand Cuts

#148
post #123

Earlier quoted context omitted.

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

You're going to need to do more than just link to the flake if you want to show why that's better than the Dockerfile equivalent, because the code itself isn't selling it.

1. Unbelievable layer reuse out of the box. Each Nix build output is placed in its own layer, including your binary (up to a max of 120 or so layers). Rebuilding the image will only result in the final layer changing, which minimizes work on image push.

2. Everything is pinned to nixpkgs, including dependencies. Anyone who builds this image will get the exact same versions (vs. apt-get update in a Dockerfile pulling a more recent version). It’s just sqlite in this case, but you can imagine how it would work with more dependencies.

3. It is trivial to build a “FROM scratch” image - in fact, that’s the default behavior in Nix, because Nix implicitly includes all runtime dependencies alongside your binary. This is less of a challenge with Go, but YMMV with other languages.

4. You can define your entrypoint script - or any other one-off script - in-line. Not a huge advantage, but still quite useful.

There is even an alternative pattern that allows you to reap these same benefits directly in your Dockerfile:

https://mitchellh.com/writing/nix-with-dockerfiles

Hope that helps.

Re: Nix – Death by a Thousand Cuts

#149

> It seems very cool that you can roll back in the case of a catastrophic upgrade failure, but has that every happened to you? Not me. Rollbacks saved me from completely destroying my entire system. I managed to fill up my boot partition in a way that deployed successfully but left the whole system unbootable after reboot, and the only way I managed to save it without having to completely wipe and reinstall from scra…

I use NixOS on my home router and rollbacks also saved me from a Firewall misconfiguration that broke all network connectivity.
Post reply on HN