NixOS is making me less afraid

+1. I personally have always wanted to write down my thoughts on NixOS in a long-ish form post.

But it’s just really hard to articulate. NixOS is such a step above any other distro that it becomes hard to convey exactly why this is the case. It is also because so many pieces work together in tandem - both above and below the covers so to speak - to make this the case.

Here is a random dump of features that I have found both valuable and very difficult to achieve on other distros:

* Config rollback in bootloader to undo mistakes without needing to boot from recovery media

* Flake lockfiles to pin all config and packages

* Config layering: base config that applies to all machines, per-machine overrides, etc

* NixOS module system, very useful to conditionally enable functionality (e.g. subset of machines run Syncthing)

* Rebuild a host over SSH by copying over packages via nixos-rebuild

* Image builders i.e. Packer-lite (now in nixpkgs)

* Build a live CD/USB custom installer to quickly boot from with your own packages, user, dotfiles, etc

* NixOS integration testing framework (extremely powerful), makes package and config stability better under the hood in nixpkgs

* Build and run your config as a QEMU VM

* nixos-anywhere to convert a running Linux machine into NixOS, very useful for VPS/cloud machines

* Stylix for centralized theming config across apps

* Natively build a Docker image from your package

Coming back to Nix (and Linux in general) this year has been an absolute pleasure.

Not because it's suddenly got better, but because the learning curve has collapsed to a flat line. My problem with linux has always been how un-user friendly it is. Constant tinkering around with config files and googling how to fix problems. Now I just install claude code and tell it what I want my OS to be and how I want it to look.

I don't want to bore my HackerNews fellows, so I'm sorry in advance, but wasn't there a lot of drama in the Nix community? I've read some time ago that a private company was buying parts of its infrastructure (or something like that) and forcing some changes upstream and people were not happy about it.

I'm interested in NixOS, but I'm at an age where I just want things to stay stable and change only when they really have to. I already have a lot of big mandatory changes from life itself, I don't need more :)

I'm writing this in good faith. I'm genuinely curious and interested in trying it again.

A lot of folks have been praising the harmony of Claude code + nixOS. For those of you doing this, I would recommend you to ask your agent to switch your config to nix flakes. It's a much better paradigm for working with the versioning than the default channels interface. Additionally, you should ask your agent to look into home manager, if it hasn't done so already.

Similar here, but I'm running rootless podman containers in Guix like this:

  (oci-container-configuration
        (environment
         '("CRON_MIN=2,32"
           "LISTEN=0.0.0.0:80"
           "OIDC_ENABLED=0"))
        (image "freshrss/freshrss:edge")
        (log-file (container-log "freshrss"))
        (extra-arguments
         '("--pod=freshrss"))
        (provision "freshrss")
        (respawn? #t)
        (volumes
         '("...")))

Your title is verbatim how Nix made me feel when I first started years ago. It does so many small things in a pure format that it was hard to immediately come up with the "key ROI" the larger industry expected. Did it just speed up dev envs? Did it just make my builds faster? Back then, a lot of folks barely cared or understood the impact of the deterministic and reproducible foundation using Nix sets. I used to hear a lot of "but that's a day 100 issue", "docker/(insert other tool) solved all of this already". "less afraid" was the easiest way to put it :) Disclosure, fully Nix pilled Ron here from flox.dev and the NixOS foundation.

Same here. Reproducible configuration is amazing. Even a moderately complex app like Forgejo is easy to set a Nix module up for, with all the needed nginx/database/backup/etc. config nailed down and easily transferable to another machine if need be.

Personally I prefer ansible plus I can easily manage multiple machines but this is a little but different use case. I have 5 micro PC like orange pi, Raspberry pi, radxa... so I prefer to bootstrap them from I laptop with a single command in am event of failure

Also everything is running in kubernetes isolation so my OS is immutable and consume much less disk space than NixOS (I don't have too much of it and future is looking bleak in this department)

If you’re curious about FreshRSS please also evaluate miniflux. A fraction of the resource consumption and a better overall experience IMO.

Miniflux homepage really undersells it.

> I dislike maintaining side projects. That includes my own code, but also self-hosted services developed by someone else. I’m okay with a few minutes of maintenance here and there, but having to schedule hours of uninterrupted work to upgrade something, or spending any amount of time at all on emergency maintenance, really kills my desire to work with computers.

I've struggled with the same problem, and Coolify helped me with it. It supports auto-deployment from GitHub via a bot integration, so you don't have to manage Github Actions. It can also deploy from a Docker Compose file, which is good for self-hosting other people's projects.

Of course you still have to have a list of instructions on how to set up your server with Coolify. But at least it's a finite set of instructions, meaning you don't have to update it every time you host a new project.

I'm getting a lot of mileage converting all my little VMs and containers over to NixOS. Entirely using AI, Claude Code is remarkably good at creating Nix flakes. The declarative OS is a good match for LLM generation of system specs. No side effects of commands to track, everything testable and reproducible by the agent. And NixOS itself works quite well. Most of the packages I need are there and if something's missing Claude doesn't seem to have any problem making it itself.

9 or 20 lines of nixos vs 7 steps on another OS vs some copy/paste with docker. It's not very convincing

> two builds from the same Dockerfile separated by time can result in rather different container images

This is true, and the same is true of shell scripts, but isn't it true of nix as well? If you update nixpkgs and then install something, you have the same chance of getting a new version of it as you do with the `sudo apt-get install` in the Dockerfile, no? I had once looked into using nix to intentionally install older versions of software and it was not as easy as I had hoped.

How do you configure the backups with NixOS? Didn't see that explained in the article at all

RSS feeds are getting rare now days. Thankfully, Google News still has a very robust and useful RSS feed.

I have a container running on GGoogle Cloud Run within the free tier. It runs runs twice weekly as well as once a month (for monthly news summary) to parse through specifically setup Google News RSS feeds and then trigger an email with key news items I'm specifically interested.

Gemini is used for determining which articles to include and exclude from the email summary based on my predefined criteria. It works really well in being able to keep on top of specific industry/tech news I'm interested in.

I need a new linux flavour. How is nix is for you desktop?

Same for me. I have an agent generate the Nix and a tightened systemd unit for it, and off it goes. If I later want to remove it, I just throw it out of the config.

im sure nixos is fantastic but honestly i just love arch so much i cant imagine ever using anything else.

Giving your LLM a copy of nixpkgs and a nix executable is really great for getting something workable

I've spent the last few years deep diving Nix / NixOS and I can definitely say that you do not want to run the unstable channel nor using flakes. Just stick with stable and if you must; add very limited unstable packages via flake configuration. Keep 99.99% on stable and do not use the latest Linux kernel either.

Using unstable will result in breaking changes giving you a headache. Trying to run a bleeding edge modern laptop with some of the absolute latest software versions is only going to blow up on you and you'll be stuck trying to work around upstream breaking changes that are not even the fault of NixOS.

Lately, I use NixOS on servers mostly without flakes and use flakes and Home Manager on Win11 WSL & macOS Darwin. However, NixOS on my laptop and workstation blew up on me with a blank black screen on every boot. There were no code changes just updating stable / unstable nixpkgs and it refused to boot. A.I. couldn't figure out what the problem was. It wasn't the video drivers; it was some kind of kernel bug with the latest kernel that bit me. I ended up with a bricked system even after burning a new ISO and wiping it out, the new installation failed in the exact same way. Trying an older kernel didn't fix it either. It would boot from flash ISO install everything, but first boot resulted in the black screen. It was eventually fixed 2-3 days later but I had a need to fix that laptop urgently.

I decided to give Omarchy a spin and was impressed; I replaced NixOS on my laptop and primary desktop workstation with Omarchy. Servers are still NixOS. While I built most things myself in NixOS, having that out of box experience with Omarchy and the fact that I can just tell the A.I. to fix and configure stuff was a game changer.

In the last year or so, A.I. has gotten much better with configuring NixOS. Omarchy provides skills.md files to train Omarchy on how to configure and fix things. This improves the overall A.I. experience on Omarchy. Without any A.I. skills the frontier A.I. agents have gotten much better at working with NixOS.

If the NixOS Community writes some skills for A.I. agents, it should vastly improve the quality of using A.I. agents to configure NixOS.

Where NixOS really shines is in solving software development problems. Writing a flake.nix file and dropping it into your repo then any users with Nix installed will execute that flake.nix via direnv when changing directories into the cloned project directory. Thus, installing all the of the project's dependencies including the language. Therefore, Node.js / Python / Ruby can be installed per project instead of per user or globally on the system. Imagine you have an old Python project that won't run with the latest Python. This is no longer a problem because when you change directories into project1 and it installs the versions you need then when you exit the project folder all the dependencies are de-referenced from the /nix/store and the environment destroyed. Change to project2 and it spins up an entirely different set of dependencies. This instantly solves many problems from a newbie developer joining the team and being immediately able to clone and build a project to ensure all the devs have the same flake.nix so they all immediately reproduce the project perfectly ensuring all the proper dependencies are working. You can also put the flake.nix in your CI / CD pipeline to ensure nightly builds are working same as the developers. Spread this across Production, QA / Test, & Development environments. You can create a custom ISO installer including your configuration in the ISO and you can PXE network boot it too. You can have a variety of computer configurations in the same Nix set of configuration files.

Nix the package manager can be installed on any Linux distribution. I am likely going to install Nix on Omarchy so I can use it for development purposes. I find Nix more robust over MISE which Omarchy depends upon for most of their development tooling.

> NixOS ad or Claude Code ad

Can never tell with these submissions.

While i admire the nix community i don't know how people can be spending their time on it to solve the types of problems they are, when AI is shitting out bad python code quicker than anyone can keep up with that's degrading all our systems. By one token you can argue that's a way of fighting back, but maybe also a possible way to bury your head in the sand while the rest of the world burns around you.

[flagged]

> container image [...] no guarantee the same thing works six months down the line when reinstalling, unless we wrote down which exact container image we downloaded

Then you should write down the exact image you downloaded. Images are tagged and hashed, you're guaranteed to download the same thing again if you ask for it.

I always explicitly request a version tag for every container image I configure in my system. If I want to upgrade, it's obvious what I'm going from and to, so I can check the changelog for breaking changes.

Are people seriously running :latest everywhere? No wonder the author thinks it's not stable.