Hacker News Reader

My problem with NixOS is the second you try to go "outside the guardrails", the difficulty increases 100x

Kind of the same for docker? Plopping a docker compose file and setting up few environment vars vs writing dockerfiles from scratch.

Not really. No. You can easily checkout repo containing the Dockerfile, add a Dockerfile override, change most of the stuff while maintaining the original Dockerfile instact and the ability to use git to update it. Then you change one line in docker-compose.yaml (or override it if it's also hosted by the repo) and build the container locally. Can't imagine easier way to modify existing docker images, I do this a lot with my self-hosted services.

I'll be honest, that does not sound "easy".

It is straightforward, but so is the NixOS module system, and I could describe writing a custom module the same way you described custom Docker images.

If that’s not easy I don’t know what is.

This is a familiarity problem. I've never used NixOS and all your posts telling me how simple it is sounds like super daunting challenges to me versus just updating a Dockerfile or a one liner in compose that I am already familiar with, I suspect its the inverse for you.

It isn't the absolutely easiest process.

But it works on Ubuntu, it works on Debian, it works on Mac, it works on Windows, it works on a lot of things other than a Nix install.

And I have to know Docker for work anyhow. I don't have to know Nix for anything else.

You can't win on "it's net easier in Nix" than anywhere else, and a lot of us are pretty used to "it's just one line" and know exactly what that means when that one line isn't quite what we need or want. Maybe it easier after a rather large up-front investment into Nix, but I've got dozens of technologies asking me for large up-front investments.

It only works on Mac and windows as a VM.

Nix is for reproducibility. Nix and docker are orthogonal. You can create reproducible docker image via nix. You can run nix inside docker on systems that doesn’t allow you to create the nix store.

If it wasn't easy, I wouldn't be using it. I'm the laziest of programmers or users.

I find the granular nature of dependency sharing in NixOS to be really nice. In particular, I like systemd as my hypervisor. With systemd I can still isolate and lock down processes, but they can still, for example, share memory pages of `glibc`. It is certainly less "secure", and with Docker at least you're sharing the same kernel. It's also hard to share resources between Docker containers. Getting 4 Docker containers to use the same instance of Avahi, for example, requires explicit configuration.

Docker containers also don't have a "standard" for where to put binaries (outside of CMD/ENTRYPOINT), how to configure users/uids (many still run as root?), whether to put multiple services in one container or separate containers, where to put user data, etc. NixOS coordinates this centrally like any distro, assigning paths and UIDs and ports.

I have found Nix and NixOS to be able to absorb any amount of complexity I throw at it with grace.

If a Docker image truly is the best way to use a bit of functionality (like Home Assistant), then I will just configure NixOS to run it in podman as a systemd service with host networking.

I have not come across something that I could not package. The trick is that Nix composes functionality in a way that Dockerfiles or docker-compose configs cannot, because it's one language, one system, one abstraction.

Is it? Why? If a NixOS module doesn’t support what you need, you can just write your own module, and the module system lets you disable existing modules if you need to. Doing anything custom this way still feels easier than doing it in an imperative world.

> you can just write your own module, and the module system lets you disable existing modules if you need to

That sounds about 100x more difficult to me

I can see your point that it can be daunting to have all the pain upfront. When I was using Ubuntu on my servers it was super simple to get things running

The problem was when I had to change some obscure .ini file in /etc for a dependency to something new I was setting up. Three days later I'd realise something unrelated had stopped working and then had to figure out which change in the last many days caused this

For me this is at least 100x more difficult than writing a Nix module, because I'm simply not good at documenting my changes in parallel with making them

For others this might not be a problem, so then an imperative solution might be the best choice

Having used Nix and NixOS for the past 6-7 years, I honestly can't imagine myself using anything than declarative configuration again - but again, it's just a good fit for me and how my mind works

In the NixOS scenario you described, what keeps you from finding an unrelated thing stopped working three days later and having to find what changed?

I’m asking because you spoke to me when you said “because I'm simply not good at documenting my changes in parallel with making them”, and I want to understand if NixOS is something I should look into. There are all kinds of things like immich that I don’t use because I don’t want the personal tech debt of maintaining them.

Not OP, and not a very experienced with NixOS (I just use Nix for building containers), but roughly speaking:

* With NixOS, you define the configuration for the entire system in one or a couple .nix files that import each other.

* You can very easily put these .nix files under version control and follow a convention of never leaving the system in a state where you have uncommitted changes.

* See the NixOS/infra repo for an example of managing multiple machines' configurations in a single repo: https://github.com/NixOS/infra/blob/6fecd0f4442ca78ac2e4102c...

Both of those things are true of running containers, no?

I think the sibling answer by oasisaimlessly is really good. I'd supplement it by saying that because you can have the entire configuration in a git repo, you can see what you've changed at what point in time

I'm the beginning I was doing one change, writing that change down in some log, then doing another change (this I'll mess up in about five minutes)

Now I'm creating a new commit, writing a description for it to help myself remember what I'm doing and then changing the Nix code. I can then review everything I've changed on the system by doing a simple diff. If something breaks I can look at my commit history and see every change I've ever made

It does still have some overhead in terms of keeping a clean commut history. I occasionally get distracted by other issues while working and I'll have to split the changes into two different commits, but I can do that after I've checked everything works, so it becomes a step at the end where I can focus fully on it instead of yet another thing I need to keep track of mentally

I just realised I didn't answer the first question about what keeps me from discovering the issues earlier

The quick answer is complexity and the amount of energy I have, since I'm mostly working on my homelab after a full work day

Some things also don't run that often or I don't check up on them for some time. Like hardware acceleration for my jellyfin instance stopped working at some point because I was messing around with OpenCL and I messed up something with the Mesa drivers. Didn't discover it until I noticed the fans going ham due to the added workload

> because you can have the entire configuration in a git repo, you can see what you've changed at what point in time

That’s true of docker too.

I'm not really sure what your point is, but I'll try to take it in good faith and read it as "why doesn't docker solve the problem for it, since you can also keep those configurations in a git repo?"

If any kind of apt upgrade or similar command is run in a dockerfile, it is no longer reproducible. Because of this it's necessary to keep track of which dockerfiles do that and keep track of when a build was performed; that's more out-of-band logging. With NixOS I will get the exact same system configuration if I build the same commit (barring some very exotic edge cases)

Besides that, docker still needs to run on a system, which must also be maintained, so Docker only partly addresses a subset of the issue

If Docker works for you and you're not facing any issues with such a setup, then that's great. NixOS is the best solution for me

That’s all my point was, yeah. Genuinely no extra snark intended.

> it is no longer reproducible

The problem I have with this is that most of the software I use isn’t reproducible, and reproducible isn’t something that is the be all and end all to me. If you want reproducible then yes nix is the only game in town, but if you want strong versioning with source controlled configuration, containers are 1000x easier and give you 95% of the benefit

> docker still needs to run on a system

This is a fair point but very little of that system impacts the app you’re running in a container, and if you’re regularly breaking running containers due to poking around in the host, you’re likely going to do it by running some similar command whether the OS wants you to do it or not.

> if you want strong versioning with source controlled configuration, containers are 1000x easier and give you 95% of the benefit

For some I'm sure that's the case; it wasn't in my case.

I ran docker for several years before. First docker-compose, then docker swarm, finally Nomad.

Getting things running is pretty fast, but handling volumes, backups, upgrades of anything in the stack (OS, scheduler, containers, etc) broke something almost every time - doing an update to a new release of Ubuntu would pretty much always require backing up all the volumes and local state to external media, wiping the disk, installing the new version, and restoring from the backup

That's not to talk about getting things running after an issue. Because a lot of configuration can't be done through docker envs, it has to be done through the service. As a consequence that config is now state

I had an nvme fail on me six months ago. Recovering was as simple as swapping the drive, booting the install media, install the OS, and transfering the most recent backup before rebooting

Took about 1.5 hours and everything was back up and running without any issues

I've written a dozen flakes because I want some niche behavior that the home-manager impl didn't give me, and I just used an LLM and never opened Nix docs once.

It's just declarative configuration, so you also get a much better deliverable at the end than running terminal commands in Arch Linux, and it ends up being less work.

"Just" write your own module?

Have you seen how bad the Nix documentation is and how challenging Nix (the language) is? Not to mention that you have to learn Yet Another Language just for this corner case, which you will not use for anything else. At least Guix uses a lisp variant so that some of the skills you gain are transferable (e.g. to Emacs, or even to a GP language like Common Lisp or Racket).

Don't get me wrong, I love the concept of Nix and the way it handles dependency management and declarative configuration. But I don't think we can pretend that it's easy.

I’ve never seen nix, but I’d rather learn “yet another language” than fight yet another yaml syntax.

That time would be better spent just learning YAML, since you’ll encounter it in a hell of a lot more places than Nix

The documentation is not great (especially since it tends to document nix-the-language and not the conventions actually used in Nixpkgs), but there are very few languages on earth with more examples of modules than Nix.

Examples don't help if you can't understand them.

I've hosted Immich since it came out and all my photos have been migrated to it at this point. I would never host Immich on NixOS (and I do use it for certain things). The reason? It's not simpler than a container option and creates a single point of issue. The container option is tested and supported by Immich, they recommend it. So everything I need is part of that. I moved servers midway through the year and the storage for my Immich implementation is NAS hosted and the mount is simply exposed to the Immich container. It took me less than 15 minutes to move Immich. And while that would have likely been the same with NixOS it's actually more of a chore to roll back with Nix. My Compose file is locked to major/minor and I choose when to do upgrades. But rollbacks are actually simpler IMO. I just stop the container, tar the operational directory, flip the bits in the Compose file and restart. I've not actually had an issue with Immich ever while doing it this way and I manage about 10TB of photos and videos currently in Immich.

I actually thought about doing this with NixOS last year, but it seemed counterproductive compared to how I self-host, I don't want to manage configurations in multiple places. If I switched everything it would likely be just as much work and then I'm reliant on Nix. Over the years I've gone from the OS being a mix of Arch and Ubuntu to mostly just Debian for my self hosting LXC or VMs. I already have the deployments templated so there's nothing for me to do other than map an IP, give it a hostname and start it.

To each their own, but I don't want to be beholden to NixOS for everything. I like the container abstraction on LXC and VMs and it's been very good to minimize the work of self-hosting over 40+ services both in my home lab and in the bare metal server I lease from Hetzner.

A few thoughts.

> It's not simpler than a container option and creates a single point of issue. The container option is tested and supported by Immich, they recommend it. I don't want to be beholden to NixOS for everything.

I think there's a misunderstanding here. You aren't beholden to NixOS here. You don't have to use nixpkgs nor home-manager modules. You can make your own flakes and you can use containers, but the benefit is still that you set it up declaratively in config.

It's not incompatible with anything you've said, it's just cool that it has default configurations for things if you aren't opinionated.

> I don't want to manage configurations in multiple places.

I've accumulated one big Nix config that configures across all my machines. It's kind of insane that this is possible.

Of course, it would seem complicated looking at the end result, but I iterated there over time.

Example: https://github.com/johnae/world -- fully maintained by a clanker (https://github.com/johnae/world/pulls?q=is%3Apr+is%3Aclosed)

> I think there's a misunderstanding here. You aren't beholden to NixOS here. You don't have to use nixpkgs nor home-manager modules. You can make your own flakes and you can use containers, but the benefit is still that you set it up declaratively in config.

There's actually no misunderstanding and this is exactly my point. With any Nix config you are beholden to that specific platform. What I'm saying is any other Linux distro can be dropped in with almost no changes in my existing implementation. I've already experienced breaking changes pre-Flakes with Nix and so I don't actually view it as stable as other options. Beyond that there's some politics surrounding Nix that I don't care to follow. So when you say "all you have to do is write your own Flake"... Why? I already have something that's able to be reliably reinstalled in minutes if need be. I don't need a specific declarative set of tooling to get there.

I like the idea of a declarative setup, but I don't think Nix is mature enough nor does it bring enough differentiation to the plate to be worthwhile as of yet.

I'm running NixOS on some of my hosts, but I still don't fully commit to configuring everything with nix, just the base system, and I prefer docker-compose for the actual services. I do it similarly with Debian hosts using cloud-init (nix is a lot better, though).

The reason is that I want to keep the services in a portable/distro-agnostic format and decoupled from the base system, so I'm not tied too much to a single distro and can manage them separately.

How do you update the software in the containers when new versions come out or vulnerabilities are actively being exploited?

My understanding is that when using containers updating is an ordeal and you avoid the need my never exposing the services to the internet.

> How do you update the software in the containers when new versions come out or vulnerabilities are actively being exploited?

You build new image with updated/patched versions of packages and then replace your vulnerable container with a new one, created from new image

Am I the only one surprised that this is a serious discussion in 2025?

Perhaps. There are many people, even in the IT industry, that don't deal with containers at all; think about the Windows apps, games, embedded stuff, etc. Containers are a niche in the grand scheme of things, not the vast majority like some people assume.

Really? I'm a biologist, just do some self hosting as a hobby, and need a lot of FOSS software for work. I have experienced containers as nothing other than pervasive. I guess my surprise is just stemming from the fact that I, a non CS person even knows containers and see them as almost unavoidable. But what you say sounds logical.

Self-hosting and bioinformatics are both great use cases for containers, because you want "just let me run this software somebody else wrote," without caring what language it's in, or looking for rpms, etc etc.

If you're e.g: a Java shop, your company already has a deployment strategy for everything you write, so there's not as much pressure to deploy arbitrary things into production.

The world is too complex, and life paths too varied, to reliably assume "everyone" in a community or group knows about some fact.

You're usually deep within a social bubble of some sort if you find yourself assuming otherwise.

I'm a career IT guy who supports biz in my metro area. I've never used docker nor run into it with any of my customers vendors. My current clients are Windows shops across med, pharma, web retail and brick/mortar retail. Virtualization here is hyper-v.

And it this isn't a non-FOSS world. BSD powers firewalls and NAS. About a third of the VMs under my care are *nix.

And as curious as some might be at the lack of dockerism in my world, I'm equally confounded at the lack of compartmentalization in their browsing - using just one browser and that one w/o containers. Why on Earth do folks at this technical level let their internet instances constantly sniff at each other?

But we live where we live.

I refer you to:

https://xkcd.com/1053/

If you're the one building the image, rebuild with newer versions of constituent software and re-create. If you're pulling the image from a public repository (or use a dynamic tag), bump the version number you're pulling and re-create. Several automations exist for both, if you're into automatic updates.

To me, that workflow is no more arduous than what one would do with apt/rpm - rebuild package & install, or just install.

How does one do it on nix? Bump version in a config and install? Seems similar

Now do that for 30 services and system config such as firewall, routing if you do that, DNS, and so on and so forth. Nix is a one stop shop to have everything done right, declaratively, and with an easy lock file, unlike Docker.

Doing all that with containers is a spaghetti soup of custom scripts.

Your understanding of containers is incorrect!

Containers decouple programs from their state. The state/data live outside the container so the container itself is disposable and can be discarded and rebuild cheaply. Of course there need to be some provisions for when the state (ie schema) needs to be updated by the containerized software. But that is the same as for non-containerized services.

I'm a bit surprised this has to be explained in 2025, what field do you work in?

Your understanding of not-containers is incorrect.

In non-containerized applications, the data & state live outside the application, store in files, database, cache, s3, etc.

In fact, this is the only way containers can decouple programs from state — if it’s already done so by the application. But with containers you have the extra steps of setting up volumes, virtual networks, and port translation.

But I’m not surprised this has to be explained to some people in 2025, considering you probably think that a CPU is something transmitted by a series of tubes from AWS to Vercel that is made obsolete by NVidia NFTs.

It's not that easy.

First I need to monitor all the dependencies inside my containers, which is half a Linux distribution in many cases.

Then I have to rebuild and mess with all potential issues if software builds ...

Yes, in the happy path it is just a "docker build" which updates stuff from a Linux distro repo and then builds only what is needed, but as soon as the happy path fails this can become really tedious really quickly as all people write their Dockerfiles differently, handle build step differently, use different base Linux distributions, ...

I'm a bit surprised this has to be explained in 2025, what field do you work in?

It does feel like one of the side effects of containers is that now, instead of having to worry about dependencies on one host, you have to worry about dependencies for the host (because you can't just ignore security issues on the host) as well as in every container on said host.

So you go from having to worry about one image + N services to up-to-N images + N services.

I think you are not too wrong about this.

Just that state _can_ be outside the container, and in most cases should. It doesn't have to be outside the container. A process running in a container can also write files inside the container, in a location not covered by any mount or volume. The downside or upside of this is, that once you down your container, stuff is basically gone, which is why usually the state does live outside, like you are saying.

pull new container, stop old and start new. can also make immutable containers.

Ditto on having services expressed in more portable/cross distro containers. With NixOS in particular, I've found the best of both worlds by using podman quadlets via this flake in particular https://github.com/SEIAROTg/quadlet-nix

> There is something to be said about NixOS, it really is a matter of setting `services.immich.enable = true;` in a configuration file.

Assuming someone has added it to NixOS, yeah. There are plenty of platforms even easier than that where you can click "install" on "apps" that have already been configured.

> There are plenty of platforms even easier than that where you can click "install" on "apps" that have already been configured.

Yeah, like TrueNAS, where they've decided it was good entire to run Kubernetes on NAS hardware, with all the fun and speed that comes with. You just hit "Install", wait five minutes, and you get something half-working but integrated with the rest of their "product".

I'll stick with configuration I can put in git, patch when needed and is easy to come back to after 6 months when you've forgotten all about the previous context you had.

Nit: TrueNAS migrated away from Kubernetes in 2024.

This is my favorite use of CLI AI coding tools: updating my nix config. I can just ask my computer to configure services for me!

I remember when people claimed to use NixOs in order to have a deterministic, repeatable setup.

AI generated Nix is equally deterministic and repeatable. The deterministic behavior makes Nix well suited for AI yolo code, either it evaluates and builds or it doesn't, and if the result isn't functional you revert back to the previous generation.

That is the use case for NixOS yes, can you clarify how it is no longer deterministic? I have been using it for a few months and was not aware of this change

my setup is SO deterministic and repeatable that it hurts sometimes

Indeed! This morning I needed a service to port forward ssh from my server to a firewalled machine, to access stuff while I work from a mountain cabin over the next few days. ChatGPT gave me a nice nix config snippet, and it just worked! Auto reconnecting and everything.

I would of course have thrown up a port forward manually today, and maybe even spent the time to add a service later, but now it was fixed once and “forever” in two minutes!

Immich was my gateway into NixOS. It did a really good job of showing how well it can work. I'm only a couple of months in, so we'll see if it sticks, but I'm also running it on my laptop now.

I hope someone will create a Debian package for Immich. I’m running a bunch of services and they are all nicely organized with user foo, /var/lib/foo, journalctl -u foo, systemctl start foo, except for Immich which is the odd one out needing docker compose. The nix package shows it can be done but it would probably be a fair amount of work to translate to a Debian package.

I'll try to install in a short-ish while, and look into its installation in a detailed manner.

I may try to package it, and if it proves to be easy to maintain, I might file an ITP.

You could try setting it up as a Podman Quadlets, those hook into systemd so you can treat them like a normal service.

But what's the performance of NixOS compared to other distros? Also, I imagine CUDA installation is not as simple as changing a few lines of config file?

https://nixos.wiki/wiki/CUDA

It’s not too bad. As others have said, AI makes it easy to get right.

It's confusing, but bear in mind that nixos.wiki is an unofficial wiki, the official one is at: https://wiki.nixos.org/wiki/CUDA

> But anyone who can install a distro can install NixOS. Instead of running your apt/dnf/pacman commands, you edit a file with your package names and services you want to enable, and run `nixos-rebuild switch`.

You can do the same with any configuration manager such as puppet, salt or chief.

Nix can be easy,but it's not simple.

Obligatory link: https://youtube.com/watch?v=SxdOUGdseq4

> There is something to be said about NixOS

OK, I'll stick with Ubuntu + KDE (so Kubuntu really) on all my machines.

Regarding NixOS, I'm mostly afraid of them going on a user purge after their developer purge. You just never know who this group of people will come after next, especially after they started defining "Fascism" as "anyone asking for how they define Fascism".

And the jump of getting rid of people you hate who contribute to your project and you can do little harm to, to getting rid of people you hate who are of no use to you and you can do genuine damage to (e.g. by installing a tor exit node) is a step down if you think you could get away with it.

NixOS is open-source, if needed it can be forked anytime and continued to work on with new maintainers.

And flakes make that viable

> Regarding NixOS, I'm mostly afraid of them going on a user purge after their developer purge

... Why? I don't know what developer purge you're talking about, but getting rid of people running a project almost never means suddenly they'll start to get rid of users, I'm not sure why that assumption is there. Not to mention that they couldn't even "purge users" if they wanted to, unless they make the download URLs private and start including some licensing schema which, come on, hardly is realistic to be worried about...

Honestly one of the funniest things I've read on HN in a while. Would you call yourself anti-anti-fascist?

They're likely just doing the ol' "what opinions, mfer" goose meme.

To provide some opinionated context for this unhinged rant:

The community developing nix had a falling out with a couple highly unsavory groups that basically consisted of the Palmer Lucky Slaughter Bot Co. and a couple guys who keep trying to monetize the project in extremely sleazy ways. This wasn't some sort of Stalinistic purge, it was people rejecting having their name attached to actual murder and sleazy profiteering.