Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix – Death by a Thousand Cuts

dgt.is

Post reply on HN
Print view View original

21–30 of 336 posts

Re: Nix – Death by a Thousand Cuts

#21

Post by theossuary »

nunez wrote: post #17

I'd like more clarity on this: > The advantage over docker here is that (when using Flakes) Nix builds are completely reproducible. Docker containers may be isolated, but surprisingly they are not deterministic out of the box. With some work you can make docker deterministic, but thats what you need, its much easier to use Nix. as the whole purpose of the Dockerfile is to create a reproducible environment.

I guess you could consider a docker image a "reproducible environment," but it's certainly not a reproducible build; running docker build twice on the same directory isn't guaranteed to give you the same image. You could put in the work to make it a reproducible build, but it doesn't do anything to help you achieve that. Nix defaults to reproducible builds, and requires flags for "impure" non-reproducible builds. It does this by requiring all dependencies be managed by nix, and all sources be copied into the nix store.

Re: Nix – Death by a Thousand Cuts

#22

Post by JamesSwift »

nunez wrote: post #17

I'd like more clarity on this: > The advantage over docker here is that (when using Flakes) Nix builds are completely reproducible. Docker containers may be isolated, but surprisingly they are not deterministic out of the box. With some work you can make docker deterministic, but thats what you need, its much easier to use Nix. as the whole purpose of the Dockerfile is to create a reproducible environment.

Its reproducible at a superficial level. Tags are mutable, so someone can push a different “3.1” between build 1 and 2, which results in a different build. You can also be fuzzy with tags, so if you say “from nginx:3” as your base (or nginx:latest) then build 1 and 2 can change because of a new tagged build upstream.

Then theres the million app-level changes that can creep in, eg copying local source is non-deterministic, apt-update, git clone, etc. Nix requires you to be fully explicit about the hash of the content you expect in each of those cases and so if you build it twice it is actually the same build.

Re: Nix – Death by a Thousand Cuts

#23

Post by cbrozefsky »

tuananh wrote: post #20
ris wrote: post #18

Earlier quoted context omitted.

Why? It just isn't what draws me to Nix. I've never even really tried NixOS on the desktop TBH.

nothing. it's just from someone with no experience with nix like me, it feel weird that someone is already deep into Nix but isn't tempted to use it daily.

You can use it daily, intimately, without using nixos. Using it for dev environments on macos for example, and servers. Did that for years before I installed nixos on my desktop.

Re: Nix – Death by a Thousand Cuts

#24

Post by anirrudh »

I've been daily driving nixOS on my desktop, and manage my work and personal macOS machines with flakes. I love this ecosystem, and have even managed to make folks at work use nix devShells -- frankly, the learning curve is pretty steep; the payoff is that I've learned so much. I've been very happy with it -- I run a windows VM with libvirt/KVM/QEMU when I want to game, and use the same to run "local" LLMs. While docker is a great technology, I actually prefer using nixOS containers (which are, under the hood, systemd-nspawn containers).

When I worked on my startup briefly, I built nixOS images with everything needed for raspberry pis; all I needed to do was use dd to burn the image to an SD Card.

For me, nix is a wonderful and perfect solution for building stable software.

Re: Nix – Death by a Thousand Cuts

#25

Post by jonotime »

nunez wrote: post #17

I'd like more clarity on this: > The advantage over docker here is that (when using Flakes) Nix builds are completely reproducible. Docker containers may be isolated, but surprisingly they are not deterministic out of the box. With some work you can make docker deterministic, but thats what you need, its much easier to use Nix. as the whole purpose of the Dockerfile is to create a reproducible environment.

Author here.

The idea with nix flakes is it has a lock file which should guarantee the same build. This is like package-lock.json or pdm.lock which contains dependency checksums for every package.

Docker works more like your standard package manager. If you ask for mysql 5, today you may get mysql 5.1, but next week you may get mysql 5.2. So it does not come with a guarantee.

Re: Nix – Death by a Thousand Cuts

#26

Post by woile »

tuananh wrote: post #20
ris wrote: post #18

Earlier quoted context omitted.

Why? It just isn't what draws me to Nix. I've never even really tried NixOS on the desktop TBH.

nothing. it's just from someone with no experience with nix like me, it feel weird that someone is already deep into Nix but isn't tempted to use it daily.

I've been using nix in a Mac for a year now. Recently I got a new Lenovo machine and first thing I did was install nixos, it's actually much better than I was expecting. You do notice that nix is designed around nixos

Re: Nix – Death by a Thousand Cuts

#27

Post by ChocolateGod »

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 PGO/LTO and Zen 3 optimizations (don't mind compiling everything) and I think I saw at least 10 ways and none worked (gcc errors, etc).

Re: Nix – Death by a Thousand Cuts

#28

Post by wpm »

tuananh wrote: post #20
ris wrote: post #18

Earlier quoted context omitted.

Why? It just isn't what draws me to Nix. I've never even really tried NixOS on the desktop TBH.

nothing. it's just from someone with no experience with nix like me, it feel weird that someone is already deep into Nix but isn't tempted to use it daily.

Maybe it’s everyone else using it on their daily driver that got it wrong?

It’s like doubting Kubernetes because one of the maintainers doesn’t run their desktop in KubeVirt.

Re: Nix – Death by a Thousand Cuts

#29

Post by jmartens »

tuananh wrote: post #20
ris wrote: post #18

Earlier quoted context omitted.

Why? It just isn't what draws me to Nix. I've never even really tried NixOS on the desktop TBH.

nothing. it's just from someone with no experience with nix like me, it feel weird that someone is already deep into Nix but isn't tempted to use it daily.

What is so interesting about Nix is that it's not one thing. Its not (just) a distro. Its not (just) a package manager. Its not (just) a system manager. Its not (just) a language. Its not (just) a build tool.

It is all those things, but specifically, what you want it to be. Yes, that makes it super confusing, but also powerful.

Re: Nix – Death by a Thousand Cuts

#30

Post by FrostKiwi »

Have my server infrastructure on NixOS. Huge boost in productivity and stability, would never go back to standard linux. But man if something breaks it's a nuke going off. Sry for the long post, but thought I share my experience:

Mass storage on a big encrypted RaidZ array of spinning rust, no issues. Bootloader, /boot, Encrypted Root and Databases on Mirrored NVME Drives. And man is that a nailbiter on each update. Setup my drives during 22.11 following NixOS Root on ZFS instructions [1], which were amended following reports of systems becoming unbootable [2] and mostly removed later [3].

Besides initially being a broken setup [4] with an increasing amount of mounts each update stalling any system writes and causing updates to fail, it became a well running machine after that was fixed. Then during the 24.05 update and with no config change, the system became unbootable [5]. After a tough recovery [6] I never figured out how to do mirrored bootloaders again, switched to a single bootloader setup. To this day I have interactions I don't understand and am trying to fix [7], which sometimes causes updates to knock services offline due to the `nixos-rebuild switch` process stopping services, going to update the bootloader, failing due to missing mounts and exiting with services being offline, prompting manual intervention.

[1] https://github.com/openzfs/openzfs-docs/blob/1211e98faf1f37a...

[2] https://github.com/openzfs/openzfs-docs/commit/1211e98faf1f3...

[3] https://github.com/openzfs/openzfs-docs/commit/4fb5fb694f44c...

[4] https://github.com/NixOS/nixpkgs/issues/214871

[5] https://github.com/openzfs/openzfs-docs/issues/531

[6] https://github.com/openzfs/openzfs-docs/issues/531#issuecomm...

[7] https://discord.com/channels/568306982717751326/132854109967...

Post reply on HN