Thread

1. paulvnickerson · 1790685464 · focus · HN ↗

   They didn't have to go with NixOS...

   1. whizzter · 1790692949 · focus · HN ↗

      The NixOS foundation is Dutch, probably felt like a safe starting point (esp considering that the French has already gone that way).

      Besides, technically, if you're chosing an OS in 2026, it sounds like a good plan to start with a system that has many reproducibility, correctness properties and separated packages designed in from the start.

      Now, I'm not a NixOS user (altering mostly between win,fbsd,osX and some debians), maybe there's some horrible dragons lurking in using it in practice (do share in that case), but from reading about it sounds like a plan for a system used in a future where people don't need to curse too much about legacy decisions?

      1. mike_hearn · 1790693628 · focus · HN ↗

         No, unfortunately NixOS will prove unworkable. It's a classic case of bureaucrats making decisions about things they don't understand based on random political factors like where the creators are based.

         Nix has numerous properties that make it unsuitable for a normal desktop OS:

         (1) It has no concept of libraries being backwards compatible, so if a 200kb core library changes in a backwards compatible way e.g. security hotfix, it will rebuild/redownload pretty much everything you have installed. This kills your ability to roll out security fixes quickly and ensures that updates are far more painful for end users than even on Windows.

         (2) Nix advertises its main benefit as being that you can easily roll back bad updates, which is just false. It makes this false claim because Nix treats user state as being out of scope. Try upgrading Postgres across major versions with Nix and then rolling it back and see what happens, or really any program that stores stuff in $HOME and doesn't support rollback. It'll just die, make a mess, and Nix will wash its hands of the affair by saying it did the bit it wanted to do (change the binaries on your path) and the rest is just out of scope.

         (3) It has no working concept of native plugins, related to point (1). If two plugins depend on slightly different versions of their host program, they'll just load incompatible libraries into the address space and things will crash.

         (4) It cannot run binaries shipped for generic Linux without lots of fragile hacks like binary rewrites. But in the real world lots of important domain-specific programs are shipped as binaries, if they support Linux at all.

         1. erikw · 1790696787 · focus · HN ↗

            I think it depends on what they want it for. I can imagine NixOS being perfect for user workstations for example, as an alternative to Windows workstations managed with Active Directory.

            I imagine you have a lot more experience than I do packaging for NixOS and other distros given your product, but in the few cases that I've needed to run a binary, I just wrap it with a flake and it's done. I also stay on NixOS stable, so I avoid the sharp parts of "bleeding edge". In my experience as a desktop user, I've never had a failed rollback since using NixOS as my primary OS since around 2016. However, whenever I try to use it as a server OS, I often do hit the pain point you mentioned around statefulness. More specifically, the happy path is extremely happy, but once you need something off the happy path, you find yourself creating some really ugly glue to get it to interface with the happy path. The pattern I've settled on is using Podman quadlets for most services, but that isn't without pain either. Then you find that you've become a Unix sysadmin, managing different UIDs for rootless podman, different network domains, dealing with permissions issues, etc. I'm currently experimenting with microvm.nix to see if that will be cleaner, but no conclusions yet.

Unofficial Hacker News client; not affiliated with Y Combinator.