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

71–80 of 336 posts

Re: Nix – Death by a Thousand Cuts

#71

Post by tombert »

yoyohello13 wrote: post #45

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 declarative, if I end up really breaking something, I can always reboot and choose a previous generation. It makes things a lot less scary for me, I can experiment with and play with different boot parameters and drivers and I know that I won't be stuck spending two hours reinstalling everything. It changes the entire way that I work.

For example, on my current laptop (Lenovo Thinkpad, AMD), I was having an issue with my USB ports idling out, so sometimes the first ~4 seconds of my typing wasn't registering since the USB port had to wake up. The solution involved adding a kernel parameter `usbcore.autosuspend=-1`.

Had this been something like Ubuntu, I have been burned enough trying to add kernel params that I might honestly have just lived with the annoyance because I didn't want to risk everything breaking, but because I knew that there was no actual risk with NixOS, I was able to fix it permanently, and I have the solution committed to Git if I ever have to do this on another computer.

Re: Nix – Death by a Thousand Cuts

#72

Post by rob_c »

azeirah wrote: post #69
Baeocystin wrote: post #65

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

The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better. The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.

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.

Re: Nix – Death by a Thousand Cuts

#73

Post by antonvs »

soraminazuki wrote: post #49
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.

Docker images are just as reproducible as binary blobs, which is essentially what they are.

Binary blobs can be easily reproducible, depending on how they’re built. By comparison, the “easily” part doesn’t apply to any non-trivial Docker image.

The issue is that you have to lock down all your dependencies, including local data, repos, and registries. Most people, and even most companies, don’t have the resources to achieve that, so they simply don’t do it.

Further, Docker doesn’t provide any significant mechanisms to help ensure reproducibility in the face of these issues, so you can’t say that Docker supports reproducibility.

Re: Nix – Death by a Thousand Cuts

#74

Post by jvandreae »

rob_c wrote: post #72
azeirah wrote: post #69

Earlier quoted context omitted.

The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better. The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.

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.

The problem with docker is less the containerization and more the half-baked build system.

Re: Nix – Death by a Thousand Cuts

#75

Post by jjmarr »

rob_c wrote: post #72
azeirah wrote: post #69

Earlier quoted context omitted.

The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better. The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.

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.

Well, yeah.

Nix is attempting to be better than containerization.

Saying "improvements aren't necessary because we already have 'good-enough' technology" is a meaningful argument when the improvements aren't significant.

In my view, they are significant because Nix can be used to create a fully featured OS instead of just a VM.

Re: Nix – Death by a Thousand Cuts

#76

Post by lilyball »

> 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 scratch (which means losing all my data) was to load the SD card onto my laptop, fix the boot partition by hand to ensure the kernel from the previous generation was valid, and edit the bootloader config to delete the offending configuration (because accidentally trying to boot it would re-corrupt the boot partition).

I've also used rollbacks in other less catastrophic situations, such as when I broke wireless (since I build remotely on a much more powerful machine and deploy over SSH).

Re: Nix – Death by a Thousand Cuts

#77

Post by edude03 »

rob_c wrote: post #72
azeirah wrote: post #69

Earlier quoted context omitted.

The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better. The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.

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.

As a heavy container user myself - I've been using containers since I needed to build my own 3.x kernel to test them - docker doesn't solve the reproducibility problem nix solves - IE, I can make a Dockerfile that does `RUN curl foo.com/install.sh` and who knows if that'll work ever again. Nix on the other hand doesn't allow you to do IO during builds[^0] only describe the effect of doing the IO.

[0]: Though apparently darwin (mac) doesn't support sandboxing by default, so you can bypass that but anyway

Re: Nix – Death by a Thousand Cuts

#79

Post by edude03 »

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.

Containers are only reproducible at run time not at build time. Once you build a container and pull it down by its sha256, you'll get the same environment each time. However if your Dockerfile does any IO (curl, apt get, pip install etc) you're quite likely to get different images on different machines.

Re: Nix – Death by a Thousand Cuts

#80

Post by thln666 »

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.

The whole purpose of the Dockerfile is not to create a reproducible environment. The purpose of a Dockerfile is to run a bunch of commands inside of a container and save the output. Those commands may or may not produce the same output every time they're run.

For example, if you have a debian base container that you run `apt install nginx` in, what version you actually get depends on a lot of different things including what the current version of nginx is inside of the remote repositories you're installing from _when the docker build command is executed_, not when the Dockerfile is written.

So, if you do "docker build ." today, and then the same thing 6 months from now, you will probably not get the same thing. Thus, Dockerfiles are not reproducible without a lot of extra work.

Nix flakes are not like that - they tag _exact_ versions of every input in the flake.lock, so a build 6 months from now will give you the _exact same system_ as you have today, given the same input. This is the same as like an npm lock file or a fully-specified python requirements.txt (where you have each package with an ==).

So, you definitely can make Dockerfiles reproducible, but again, the Dockerfile itself is not made to do that.

Hope that helps your understanding here!

Post reply on HN