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. whizzter · 1790758103 · focus · HN ↗

            1: Sounds like something that could be improved rather than being something inherent, could be part culture though since slightly incompatible C/C++ libraries isn't an uncommon thing so unless there's proper testing channels the user-diskspace/time is a tradeoff (not perfect, but reasonable)

            2: Doesn't really sound like a problem for most desktop stuff unless there's some components you use that depend on non-upgradable data. Users have their browser, word files, excel files, pdf files and so on.

            3: Sounds annoying, but also like a fixable feature. How much common user software have native plugins ?

            4: Binaries for Linux is a bit of a mess in general, I think someone in jest wrote that now that Wine has improved, win32 binaries is the preferable binary distribution format for Linux.

            1. mike_hearn · 1790760592 · focus · HN ↗

               The problem with (1) is it's inherent to the design concept. Nix defines package identity to include the dependency closure. Fixing that would require introducing the concept of an interface export that blocks the recursion, and then having other packages depend on that. This is nothing radical and plenty of build tools do it e.g. Gradle has a concept of this, as does a private build system I built myself. But Nix doesn't have it, it's something that would have needed to be there from day one, and AFAIK there are no plans to add it. Also by the time you're done with this it doesn't look much different to a conventional package manager.

               Incompatibilities can of course happen, but so can improvements. Nix throws the baby out with the bathwater. You can rerun CI of upstream (open source) projects against a new set of component versions if you want, it doesn't imply anything about how the distribution mechanism should work.

               For (2) the issue is non-downgradeable data, not non-upgradeable. Apps basically never support downgrades. Consider your web browser changing the format of its HTTP cache or credentials store, consider your word processor adding a new feature that the user incorporates into their documents and then it's suddenly downgraded. There isn't even any way to downgrade Chrome via its normal user interfaces!

               For (3) crashes aren't just annoying, they're indicative of a fatal design flaw. Native plugins were a common feature on other operating systems in the past and have historically been a feature of KDE and GNOME too. I don't know if there are new Linux-native apps of high complexity being written these days though. The dominance of Electron means plugins have moved server-side where the user's OS can't screw them up. Nonetheless, you can't have a serious productivity-focused desktop OS if apps can't be composed at all. You can at best maybe do a ChromeOS competitor.

               For (4) sure it can be just defined as out of scope, same thing Nix[OS] does with lots of other important problems. It's embarrassing to present Linux as a solution if it depends on Microsoft to solve the hard stuff for you, though.

               1. whizzter · 1790782439 · focus · HN ↗

                  1: I think that's still a decision of the OS developers, you can have a purity-of-install to have functioning software (avoiding incompatible libraries), in the end though for all binaries it's just instructions with little knowledge moving around an instruction pointer, so is there anything fundamental that precludes an overlayed patch-stream where you have installed versions (nix world) but a runtime linker that silently replaces core libraries (that would cause extensive reloads, say OpenSSL) during link-time to have a functioning userland until the next release occurs?

                  2: I hear you, I still think it's a minor inconvenience in the grand scheme of things, worst case administrators should manage for full user backups in case of breakage (people bad backups habits are more likely to cause havoc for other reasons like hardware failure than the occasional downgrade of system data).

                  3: only thing that immediately comes to mind is Blender, but there it's Python scripts and intentionally not supporting C++ plugins (last I checked you're supposed to rebuild the entire thing if you want C++ additions).

                  4: OSS unixy systems has always had tilt to the former in the conflict between the security/sysadmin view (no local binary searching due to security, binaries upgrade everywhere) vs users (who wants to run programs and don't care too much about what glibc version it was compiled with, even taking that big binary with all libraries bundled).

                  I see Nix as more like Windows SxS instead of just shipping everything like with flatpak,docker,etc. But it always boils down to the same dependency on absolute filepaths for everything that's hard to escape (because you can "just recompile").

                  flatpak exists though, doesn't it work well enough?

Unofficial Hacker News client; not affiliated with Y Combinator.