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

NixOS: A Personal Post-Mortem

nathan-kim.org

Post reply on HN
Print view View original

11–20 of 41 posts

Re: NixOS: A Personal Post-Mortem

#11

Post by nvarsj »

I spent 2 years using NixOS as my sole development OS and I learned a ton. But every little thing is a battle. Prior to that I used Arch Linux for like 8 years and it was so much more pleasant to use for day to day dev (due to the great package manager and high quality packages and, well, mutability).

At some point last year I came to the conclusion that the immutability/repeatability of NixOS just isn't worth the drawbacks for a development machine. I swapped to openSUSE Tumbleweed and haven't looked back. It never gets in the way - I install what I want, manage my dotfiles in chezmoi, and rarely need to fight the OS to do what I need it to do.

I think NixOS has some interesting applications at scale. If I had to manage a fleet of 100+ machines and ensure they are all identical, and I can easily roll back changes, NixOS would be a prime candidate.

Similarly, I still think Nix the package manager is pretty great for individual project dependency management. There isn't really anything like it as far as I know.

Re: NixOS: A Personal Post-Mortem

#12

Post by ris »

I keep having to say this to people - if you're unsure about nix/nixos, "diving in the deep end" and using nixos as your desktop operating system is probably just going to annoy you. I really suggest using nix on a regular distribution for a good while beforehand.

Of course, IMHO, servers is where nixos really shines.

Re: NixOS: A Personal Post-Mortem

#13

Post by Kim_Bruning »

I really hate Hate HATE nixos. If any good alternative to nixos shows up, I'd use it in a split nanosecond.

Meanwhile, the advantage of reproducible builds and rapid rollback are so huge for me that I use it anyway.

May the source gods have mercy on me. :-/

Re: NixOS: A Personal Post-Mortem

#14

Post by aeonik »

Kim_Bruning wrote: post #13

I really hate Hate HATE nixos. If any good alternative to nixos shows up, I'd use it in a split nanosecond. Meanwhile, the advantage of reproducible builds and rapid rollback are so huge for me that I use it anyway. May the source gods have mercy on me. :-/

GNU Guix seems to be an alternative that I've been interested in.

The configuration is done with Scheme. I haven't tried it.

https://guix.gnu.org/

Re: NixOS: A Personal Post-Mortem

#15

Post by ris »

williamvds wrote: post #7

Thanks for the great write-up. As someone who somewhat recently got into Nix I've struggled with many of the same problems. With the whole "your system is read-only" bit, I'll add that Nix can make trial and error editing of config files quite tedious. Editing and reapplying the configuration is fast, but not as fast as editing a file and `systemctl restart`ing the service in question. On development environments I'v…

> Then comes Python, which introduces the same nightmares which the author experienced. Python packages that use system shared libraries are troublesome.

The nightmares come from pypi packages and their assumptions that e.g. the particular version of `libfoo.so` that happens to be in your `/usr/lib` at the time of installation is the one you need it to link against, which is a very crass assumption in 2023. Nix doesn't hide you from this. But it's quite straightforward to write your own nix packages based on upstream python packages which should work fine alongside other nix packages.

By and large, nix does not play particularly well with other package managers, because the nix view is that it's absurd having 7 different package managers fighting for control of the same system.

Re: NixOS: A Personal Post-Mortem

#16

Post by ris »

frozenport wrote: post #8

We were running nix in production and it was an absolute mess While the language is declarative your configuration is scattered, debuggers are absent, and you're ultimately interacting with a a layer on top of what the original package was designed to do. This makes it hard to figure the system out, how to debug, and occasionally support is missing.

> you're ultimately interacting with a a layer on top of what the original package was designed to do

This is fundamentally necessary, because the "original package" (for some value of "package") doesn't care about anything else on the system apart from getting itself running using whatever arbitrary configuration scheme / fs layout / daemon management happens to please the upstream author.

Re: NixOS: A Personal Post-Mortem

#17

Post by eisbaw »

My garbage can is a few meters away from my desk. That's too far -- guess I'll just litter on the floor -- it's more convenient. ... but soon the trash builds up.

Upgrade the whole system? Dangerous. Upgraded and it kinda works, but you'd like to roll-back? Though luck.

NixOS is definitely not for everybody - perhaps Developer workstation is the most tricky to get right. But for production server use, the repeatability is great.

Nix ofc is agnostic of NixOS, is is generally my preferred way of getting packages.

I also happen to love when software makes too-wide assumptions and break. That is generally software poorly written and to avoid.

These side-effects and mutations cross-product with each other so much that computers have become failure dumpsters.

Re: NixOS: A Personal Post-Mortem

#18

Post by williamvds »

ris wrote: post #15
williamvds wrote: post #7

Thanks for the great write-up. As someone who somewhat recently got into Nix I've struggled with many of the same problems. With the whole "your system is read-only" bit, I'll add that Nix can make trial and error editing of config files quite tedious. Editing and reapplying the configuration is fast, but not as fast as editing a file and `systemctl restart`ing the service in question. On development environments I'v…

> Then comes Python, which introduces the same nightmares which the author experienced. Python packages that use system shared libraries are troublesome. The nightmares come from pypi packages and their assumptions that e.g. the particular version of `libfoo.so` that happens to be in your `/usr/lib` at the time of installation is the one you need it to link against, which is a very crass assumption in 2023. Nix doesn…

> which is a very crass assumption in 2023

No, I think it's a very sensible assumption. As far as I can see, virtually every GNU/Linux OS has shared libraries in /use/lib, and it even has crude support for versioning.

When these assumptions break with Nix, I'll grumble about it, but I won't blame it on the original package. Nix's approach is a break from the norm, so really it has the responsibility of maintaining compatibility.

> But it's quite straightforward to write your own nix packages based on upstream python packages

Things break down when you have to stick to specific versions of packages, at which point creating/overriding nixpkgs quickly becomes untenable. My idea is to use Nix to complement the existing standard standard Python tools everyone uses.

Re: NixOS: A Personal Post-Mortem

#19

Post by throwaway17995 » 

    What you might not be as familiar with is that these authentication sites often block you from visiting any domain at all, and then to access the authentication site on their own domain you must explicitly link their domain to an IP address through the /etc/hosts file.³
    
    3. I'm assuming on Mac and Windows this is taken care of for you somehow and it is a non-problem.
I... have never had to do this in any distro or OS (NixOS, Arch, macOS at least). The way I've found captive portals to work in practice is that when I connect to the WiFi, my computer gets the captive portal's DNS server through DHCP, and their DNS server points any and every website to the IP address of the captive portal. To make it even easier, Firefox checks "detectportal.firefox.com" every so often to see whether or not there's a captive portal, and gives me a prompt to log in to it if need be.

Re: NixOS: A Personal Post-Mortem

#20

Post by throwaway17995 » 

    To edit it, you must edit your system Nix configuration in /etc/nixos/configuration.nix and then rebuild your system, which —get this — requires a network connection to complete! So somehow, to connect to the Internet, you must be able to connect to the Internet.
I'll be pedantic and say that this isn't true, it's not required for you to be connected to the internet to rebuild your system when you're only changing /etc/hosts. However, the fact that it's not immediately obvious _how_ to do this is a rather bad problem with NixOS's tooling.

For what it's worth, the following worked for me, though there appear to be other ways as well:

    cd /etc/nixos # Or wherever you store your configuration.
    nixos-rebuild build
    sudo nix-env -p /nix/var/nix/profiles/system/ --set ./result
    sudo ./result/bin/switch-to-configuration switch
And finally, for a neat report from a few years ago on using NixOS without an internet connection: https://discourse.nixos.org/t/using-nixos-in-an-isolated-env...
Post reply on HN