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 · 1790698375 · focus · HN ↗

            I think people are unfairly downvoting this comment, but I do want to drill into your point (1) a bit. You're right that you can't really do a delta patch in NixOS. But I feel like that is so so so important these days with active supply chain attacks. I don't want a 200kb change to a core library that is "claimed" to be backward compatible to be able to make its way into my codebase. In an ideal world sure, there would be some way to prove that the update doesn't break anything and isn't malicious, and that is certainly possible for some limited subset (provers like Rocq, OS functionality like BSD Pledge, etc), but for now this is mostly based on trust.

            1. mike_hearn · 1790710057 · focus · HN ↗

               What does my codebase mean, though? A normal desktop OS doesn't require app devs to issue updates for any change to any library and it would be extremely insecure to do so. The OS is better maintained than the apps.

               Redownloading everything doesn't protect against supply chain attacks. Those can still happen, no problem.

               1. erikw · 1790712733 · focus · HN ↗

                  Reflecting on it, I guess my OS config has turned into a codebase. I have a single Nix closure that includes all my OS config, all the services running on it, and all the small utilities that need to be compiled from source (either because they are something I wrote, or something that isn't packaged in Nixpgs). I'm not sure whether this is considered best practice or not. To your point though, I would be unaware if an upstream maintainer released a security patch for something that I'm compiling from source, because I am pinned to a specific Git commit. On the other hand, I can just point an LLM at my Nix source, and ask it to scan it for security issues periodically. I do this from time to time with one of the smart models, but it might be an interesting experiment to set up a daily scan with an inexpensive or even a local model.

Unofficial Hacker News client; not affiliated with Y Combinator.