Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • We use NixOS for all of our robots and servers at https://www.monumental.co, hard to imagine how we would do constant updates of our robot fleet without it.

    If you're working on cloud systems it's easy enough to just throw away VMs all the time but you can't really do that with physical hardware that's on a construction site for months on end, where you only have a shared 5G connection. NixOS makes this all manageable!

    by bouk
  • Cool company! Do you guys hire only local to the Netherlands? I see some roles I might be a good fit for (experience w/ Rust, cpp, nix), but dont wanna waste your time
  • > Removed 17532 outdated packages, in an effort to keep the package set maintainable and secure.

    Thanks for this! I appreciate the acknowledgement that more software in nixpkgs is not necessarily better.

  • I decided to move to NixOS a few months ago. In terms of OS, it was one of the best decisions I've made so far. It's awesome to have the rollback experience, upgrade whenever you want and also being able to experiment without being afraid of breaking already working stuff.

    Another great benefit, is that AI can read my whole OS (good and bad at the same time, I know). This makes the AI way more accurate on giving you a good solution instead of having to scan all of your OS and dig into /etc.

    Personally, I really like NixOS. It's hard but definetely worth the try. Probably not for everyone, but worth it if you're a computer scientist or need to maintain hundreds of computers.

  • I post this on every post about Nix I encounter, but I sincerely hope that it gets static electricity typing one day. I have yet to try typenix (a fork of the typescript compiler applying the typescript type system to nix)

    https://github.com/ryanrasti/typenix

  • > static electricity typing

    I assume that was an autocomplete typo?

  • I'm fairly close to releasing something called nix-compile, which is a type inferring Hindley-Milner compiler that unifies across nixlang and bash. It finds a lot of bugs. Because it has a very complete view of your project, it can do cute stuff like precise go to definition across modules, annotate code with types in the comments, it's cool.
  • Adding TS types to Nix would make it so much easier to write Nix code. Which string do I need here? Oh the type system knows, the language server shows it inline - I don't have to look at the source. I've used NixOS since 2018 and written nixpkgs derivations and it would've saved me so much time.

    I'm glad that TypeNix exists but it really should just be officially supported or even the default.

  • One of the best things about Nix, aside from LLMs being able to manage your config, is having a monorepo that contains the config across all machines (shared and machine-unique), like hosts/{nas,macbook}/{configuration.nix,home.nix,modules/}.

    Now I have the same setup across my macbook, desktop, and NixOS servers.

  • After using NixOS for a bit and eventually learning to rely on it, life without it seems inconceivably complex
  • I love the slightly weird learning curve on NixOS where initially it seems incredibly complex writing this weird functional programming language for every change you want to apply to your system, then over time it clicks and you end up in a place where any operating system that doesn't define everything in a weird functional programming language seems incredibly complex. I read blog posts about doing things on other distros now and I'm left thinking that an 800 word set of instructions would be 25 lines of Nix expressions.
  • NixOS has been my daily driver since 2022/2023 and I have greatly improved the management of my 2 computers and few VMs since. Because of LLMs, I now understand the language much better, but even if I didn't want to write Nix directly, describing the config to AI usually produces good results.

    The two main sticking points IMO are still:

    - Development environments are still a pain. devenv.sh is great for web and backend, but not perfect for dependency (package) management and more complicated environments like mobile or embedded

    - nixpkgs monorepo doesn't update fast enough IMO. As a consequence, I see a number of flake repositories popping up to more easily package and distribute software not yet on nixpkgs or that don't update often enough (https://github.com/numtide/llm-agents.nix is a good example). This is perhaps by design, but it takes some digging to find the reliable and trustworthy flake repos. I'm increasingly concerned with AUR-like trust issues

  • Is devens something else than nix shell?
  • > Development environments are still a pain. devenv.sh is great for web and backend

    Weird, development environments are one of my favorite things about nix. I don't use anything like devenv.sh, just add a `flake.nix` to the repo defining a devShell, and then add `use flake` to `.envrc` and let direnv activate it. Every major and most minor editors have support for direnv, and if they don't, you can just launch them from a shell in that directory. This makes the only system dependencies for a great dev environment nix and direnv.

    > I'm increasingly concerned with AUR-like trust issues

    Once you've done it a few times, most things are pretty easy to package yourself, and you can just check those derivations into your git repo for your machines and use them. Especially if you're using LLMs, it shouldn't be all that hard to package what you need in most cases. For stuff that's more complicated or difficult, it's more likely there will be some kind of de facto standard flake for it.

  • I really love NixOS for my two devices, one surface laptop (lol), and my nvidia pc. It reduced my headaches with drivers so much.

    Before updating my nvidia driver or something related to my surface I was scared to break something. With NixOS I can just go back to the old working config.

    Another underappreciated feature about NixOS is, that you can create a VM out of a NixOS config to locally test a server update/deployment.

  • I self host my own stuff in a data center with a bunch of computers. I have a virtualized setup all in nix defining nixos setups for all hosts. Switches are virtualized using open v switch and everything is made so that the nix expression generates a launch script to test the whole set up.

    Before I deploy I know that all hosts will be able to boot properly from tftp and then communicate and launch kubernetes.

    I never ssh into any of my nodes at this point. Amazing. It just works. Once in a while I'll restart them just for funsies.

  • > Another underappreciated feature about NixOS is, that you can create a VM out of a NixOS config to locally test a server update/deployment.

    And similarly, you can generate a bootable ISO of your NixOS config. It's really nice for both testing things out and also as a recovery mechanism. Rather than booting some generic ISO, connecting to the internet, installing whatever recovery tools and filesystem drivers I need, and then doing the recovery, I can boot an ISO that is identical to my main system, with all my favorite recovery tools pre-installed.

  • I've ditched M$, switched to NixOS last month and I feel like I don't hate computers again. Shouldn't have procrastinated this for so long. All other operating systems feel so silly to use now (at least when they aren't anxiety- and rage-inducing).
  • Yep, exactly the same experience as me. The fact that everything is declarative and revertible means that I'm much "braver" than I would be with virtually any other Linux.

    An example I have given before, but there was a weird quirk with my ThinkPad with Linux, where with USB keyboards, if I hadn't been typing for more than a minute, it would have to "wake up" for about four seconds, so I'd lose the first couple words that I was typing.

    Fixing this involved playing with a few boot parameters, which can be scary to play with on something like Ubuntu. The issue is annoying, but nothing I can't live with, so if I were on Ubuntu or something I probably would have just tried to live with it, but because it's NixOS, I realized that the worst case scenario is that I reboot and choose an older generation, so I did a few experiments with boot parameters and fixed it.

  • BTW, there is a NixOS.wsl for Win11 and Nix-Darwin for macOS and the Nix package manager runs on any Linux. You could run Fedora and configure somethings with Nix.

    Nix excels at solving real world problems for developers. No more "Well, it worked on my machine". You setup a flake.nix in your code repo along with direnv and even that new junior dev can merely clone the repo and all the dependencies are installed by the flake.nix configuration file. Including the language and IDE configuration for the team. i.e. tabs vs spaces and whatnot. The same flake.nix can be applied to your CI / CD to help with reliable builds. You can also use it to create Kubernetes and other containers or a bare metal NixOS server. Keep all the configs in git and run them straight from the repo.

    It's great for ensuring your devs don't break the freaking build by updating something with npm, etc. You should audit anything you install due to the severe threat of supply chain attacks. Recently impacting Node.js and Arch Linux AUR, etc.

    Yes, LLMs can write quite a lot of Nix but they don't necessarily get down to the nitty gritty best practices. So you need to be careful with it. You should also audit your configuration for security issues.

  • I love seeing all these posts from NixOS newcomers! It seems anecdotally like LLMs have really given it a boost recently, I guess by reducing the intimidation factor of the language and the unfamiliarity? Of all the positive and negative outcomes I have imagined from LLMs, NixOS becoming popular was not one of them, but I'll take it.
  • Absolutely.

    The language is just nothing for a casual Linux user.

    Arch? Easy. Gentoo love it. Ubuntu for all my servers.

    But nix and nix os, nah.

  • > It seems anecdotally like LLMs have really given it a boost recently

    I have been using Nixos for the past 5 years. And I really use the power of nix/nixos since Codex is doing good code with it.

    Setup easily systemd-user unit with podman rootless, backup, writing script during build...

  • I had quite a rollercoaster going from Windows 10 to Arch to Windows and then settling on NixOS. Main reason being able to do clean package/program setup and centralize, version-control my configuration.

    My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal. This might be because I had some things built and installed through AUR (e.g. latest mpv releases that sometimes broke). Eventually I went back to latest Windows 11 build wanting easy no-bs setup.

    Of course, then MS decides to shove down half baked AI integration that somehow used half my RAM and randomly slowed my CPU. I am guessing it was busy indexing, searching or security-scanning something.

    Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.

  • > installed through AUR (e.g. latest mpv releases that sometimes broke)

    On my home system I'd do this to switch to a new mpv release:

    "gitty mpv"

    (This is my alias to check out the latest mpv sources, from github, via git clone URL_HERE.)

    Scripts repackage mpv into .tar.xz after this git clone step.

    Then I do:

    "clangy mpv"

    clangy is my alias to compile via clang from llvm; and the specific instructions would be found in my COOKBOOKS_DIRECTORY aka recipes (similar to homebrew, but in .yml files), where all information is gathered from mpv.yml then.

    One setting there is:

       prefix: f
    
    This means "non-traditional prefix", aka "AppDir" prefix. AppDir prefix is how GoboLinux installs software, e. g. in /Programs/Mpv/22.06.2026/ (I keep the dd.mm.yyyy notation, but this can be toggled; on my home system I use /home/Programs/ though rather than /Programs/ for historic reasons, and also as I want to backup my /home/ directory, including all programs).

    So the above would, via clang, compile mpv from source (if the git clone worked), into the AppDir prefix. Then it would simply create symlinks and so some more processing, so /usr/bin/mpv would point at /home/Programs/Mpv/Current/bin/mpv, and Current is a Symlink to the current version in use. I can keep old entries of mpv under /home/Programs/Mpv/ so switching is trivial. And cleaning up is also trivial, I remove e. g. an old mpv version there, then call one post-removal script (or I simply pass the name of it, but I find it easier to work via the commandline in two steps here). The benefit of the above is that, for instance compared to your "latest mpv release sometimes broke", this would not affect me, the old mpv versions would work still, and there can not be any outside installation other than the versioned AppDir.

    Right now my /home/Programs/ has 499 entries. I'll eventually have all programs there, and work, then I'll switch to a completely custom LFS/BLFS. Right now my base system is manjaro, which works very well as a base system, even though it uses systemd. /lib/ is a symlink on manjaro by default towards /usr/lib/ and so forth. I find this works so much better than e. g. debian.

    > Got increasingly annoyed by Microslop and tried NixOS. Bumpy ride initially but after committing for few weeks I am finally settling on it be the last OS I need.

    Not disagreeing at all, but imo the issue you had with AUR is one that by design could be completely avoided. I am not saying this is your fault, mind you; just pointing out that this may be an assumption by both AUR as well as you, since your expectation is to trust the package manager. Here, my input would be the question whether a package manager would be necessary in the first place or not (I still have scripts to handle that, mind you, but the assumptions made via AUR may be wrong in many areas, including not offering versioned AppDirs by default. I don't understand why all package managers do not offer versioned AppDirs; it would solve so many issues).

    I should add that some programs are harder to install from source, but mpv works very well; ffmpeg too, surprisingly enough. LLVM/clang is a bit harder to setup, and by far the worst offender is firefox. Mozilla should be ashamed of mozconfig for life.

  • I'm borderline motivated putting Ubuntu onto my parents computers.

    Win11 was frustrating ...

  • https://github.com/CyberShadow/aconfmgr

    Aconfmgr is a good solution (practical trade-off for me). When it feel like "my OS must be dirty at this point", then I spend a couple minutes with this and I'm back to the clean state.

    I don't do this more then twice a year, so if you insist on an always clean system, YMMV

  • > My main issue with Arch was that after installing and trying stuff it left OS dirty even after package removal

    Yeah, that's literally a problem with every single OS that is not NixOS (or, shoutout, Guix, or the other Nix-based variants).

    That's also why I am sticking with NixOS. Been at least 5 years now- it's wonderful having a reliable LINUX system as my daily driver (or one of them).

    And you can reboot into any old configuration! Even more insurance against fuckups!

    > I am finally settling on it be the last OS I need

    Same here. As soon as I got everything set up just how I like it in a declarative, reproducible fashion, I had this feeling of... "OK, this is great. I can't see a reason to ever leave this."

  • I also really like that Nix (both on NixOS or as a package manager for Linux/macOS) can temporarily fetch packages with `nix shell` removing entirely the need to install something I am just trying out or something I know I am not going to need on a regular basis.

    Similarly the integration of flakes/devshells and direnv is great to create reproducible development environments. Everything I need and at the correct versions are automatically setup as soon as I `cd` into a project directory.

    by wrxd
  • I switched my workstation over to NixOS ~6 weeks ago and it's been really good, I'm a total convert. The thing that really got me over the hump was entirely configuring it using Claude Code.

    One unexpected benefit is that both my workstation and my backup laptop have the same setup, so I can run updates on the scratch box before doing my workstation. I decided to run the "latest" rather than 25.11 release, so it's nice to test before I apply (I hit a GDM issue a few weeks ago that left me at a black screen; but not a huge deal, just select the "previous" option in the grub screen).

    I've got everything to parity with what I had on my previous Ubuntu workstation. I had anticipated issues with some software that isn't packaged (but NixOS packages a LOT), but that wasn't an issue. Claude was able to do all those things no problem.

    The biggest tricky bit was with my vim setup; I've been using AstroVIM and trying to get away from managing my own vim setup. You can't, AFAICT, just apply astrovim in NixOS. So I described the vim setup I wanted to Claude Code, and I now have a ~700 line config that implements everything I wanted: LSP, TreeSitter, a small variety of other things. Unlike Astro/Lunar, where tweaks you want to make are buried in some set of files in this whole giant distro, it is all encoded in this one "neovim.nix" file.

    I also set up home-manager and SOPS and so far that has been working just great! I now have home directory settings that are replicated across 2 machines.

    I'm still really only using it on one machine, so we'll see how it gets more complicated if I start running it on some servers.