I’ve been running a NixOS based homelab for awhile now with 5 physical hosts and about 30 NixOS containers/VMs in an Incus cluster and I can’t imagine moving away from my central Nix repo and ability to rebuild/upgrade the entire fleet in one command and feel confident that things will work.

While I’m concerned about the disbanding, it would take quite a lot to make me look elsewhere, and there’s enough critical mass that I feel confident others will step up.

Why doesn't your company fund development of nix and its associated ecosystem?

In my mind, Nix was unstoppable, and I particularly loved how empowered I imagined developers would feel. No mystery-meat CI scripts pushing packages to distant infrastructure that no one understands or even has the permissions to interact with, just the entire build system in one repo, trivially cloneable and hackable... add patches or build steps to anything and it's the same build as always, build it locally or send it to Hydra, it doesn't matter.

A devs "got" it and did leverage those things, used PRs to do safe evaluation of bumps to core dependencies, but I think on the whole it was regarded as cool but not tractable, and a few years after leaving, it sounds like plans are being laid to replace it all with something containers or whatever.

Very frustrating, particularly in a world where it should be trivial to identify the 5-10 typical tasks that people want to do with the nix code, and set up Claude skills to handle those. Given how easy and self-contained the build-test loop is, it feels like an almost perfect fit for agent-led development.

The PRs keep rolling and things keep improving!

If someone wants to be a part of the community, I can see why this might dissuade people though.

Also see roberth's resignation [2], and Gabriella439's retrospective [3], and then there's Jon Ringer's thing, the list goes on.

[1]: https://discourse.nixos.org/t/a-statement-from-members-of-th...

[2]: https://discourse.nixos.org/t/stepping-down-from-the-nix-tea...

[3]: https://haskellforall.com/2025/09/steering-committee-retrosp...

“Rebuild everything in one command and have it work” is not something that I’m chasing after and I am skeptical that it would work anyway. Maybe there is something I’m missing, but when I update the software, the updates come with changes and it’s possible that things break. My goals are to keep reasonably up to date and to be able to fix things quickly if they do break.

Regarding Nix complaints:

Package maintenance is kind of a crapshoot. Maybe your package is in nixpkgs, maybe there is a flake for it, maybe you find something that is actively updated, maybe not. Maybe there is a package but half the features are turned off because the maintainer didn’t bother. Maybe there is a package but half the features are turned off on macOS for unknown reasons. What I want is just to know what level of distro-level maintenance the package has, including its transitive dependencies.

Docs are just kinda bad. Fragmented across different sites. Docs teaching you Nix forwards or backwards, or teaching old Nix, or teaching Nix with flakes, or teaching you Nix for end-users or developers or package maintainers, or Nix on Mac or NixOS. A surprising number of broken links. What I want is one site, with a little drop-down menu to select the version I am using. What I have is hours spent on the NixOS Discord trying to figure out how to do basic stuff.

That being said, I think it is still a concept worth pursuing.

The core team was just 2 people and they disbanded?

There was also a steerco for just 2 people?

I’m now even more confused.

I have stopped visiting the discourse and other discussion venues years ago, they have permanent culture wars, drama, and people on power trips. It is sad seeing a project burn out so many people.

Nix and NixOS are two of the most revolutionary pieces of software in my experience. Hopefully Nix finds a governance structure worth of it.

https://lwn.net/Articles/970824/

The moderation team posted an open letter demanding he step down, among other reasons this accused him of jeopardizing the safety of people from "marginalized backgrounds" and allowing "fascists" in the community

I have tried very hard to find any examples of what this is a actually referring to and genuinely have no idea

https://github.com/save-nix-together/open-letter/blob/main/c...

but the other usage is to create an entity, and say "this entity is responsible for so and so problem", and humans then sign up to be part of the entity as a formal indication that they are working on this problem. and in this sense of the word it's perfectly fine for a core team to be two people, and for it to officially disband when those people no longer want to be working on the problem for whatever reason. note that they did try to recruit new people to the effort, and if they had succeeded then the "core team" entity would have provided some sort of continuity to the project despite the original people moving on.

I'm not using "rebuild" to describe recreating an instance from scratch, but in the "nixos-rebuild" sense, i.e. I can deploy a fleet-wide configuration shared by all hosts, or apply package updates across the fleet, etc.

As for the skepticism, all I can offer is my experience which is that it does indeed work, and I've been running this way for awhile.

> Maybe there is something I’m missing, but when I update the software, the updates come with changes and it’s possible that things break.

The only time I've had breaking changes that required manual intervention was on a major release update. The issue amounted to "You're using abc configuration option but should be using xyz instead". This message was clearly logged, and fixing it was a matter of a few minutes of reading why a particular property name had changed.

Those updates happen twice/year, and in the last ~3 years I think two packages have forced me to make a change. Unless you're running unstable, you won't encounter this for ongoing package updates within a release.

On the topic of rebuilding from scratch, that's not a single command, but it's only a few. VMs/containers mount incus volumes (zfs-backed) for data storage, and a fresh rebuild is a matter of spawning a new instance from my homelab base image (I use OpenTofu to orchestrate this), running a nixos-rebuild targeting the new instance from my workstation, and things are back up and running. But I'm less focused on full rebuilds since I'm already doing Incus backups and can restore on any of the nodes in my Incus cluster.

> My goals are to keep reasonably up to date and to be able to fix things quickly if they do break.

My goals are similar. I can completely understand sticking with Debian for two hosts. I had experimented with NixOS for years but never really went all-in until I started expanding my homelab environment. At that point, NixOS just clicked and I'm far more productive with 30+ hosts than I used to be with 1-2.

> Package maintenance is kind of a crapshoot. Maybe your package is in nixpkgs, maybe there is a flake for it, maybe...

Which channel were you running on? And do you have any examples of specific packages? What you're describing just sounds foreign to me. I currently default to the latest stable release but if there's something that isn't in stable I'll override that specific package to use unstable. Much of the community just runs everything on unstable, but I prefer a slightly slower pace of updates.

Nixpkgs is the largest package repository across distros by volume, and as much as I love Debian, it's far more common to find things missing there.

> Maybe there is a package but half the features are turned off on macOS for unknown reasons

This sounds like you're branching into territory that can no longer be reasonably framed as NixOS vs. Debian (or other distro of choice).

> Docs are just kinda bad.

This is by far the project's greatest weakness. LLMs have been the saving grace. The frontier models are excellent at NixOS and I've switched to mostly having a conversation in my NixOS Claude project when I need info. This is in no way a defense of the docs, but for anyone motivated to use NixOS, there is at least a good option beyond the docs themselves.

Just note that the community is unstable and prone to civil wars.

Nix/NixOS is fundamentally about a declarative system configuration.

And as far as I understand, StageX doesn’t have that.

Plus, in our highly individualized and hierarchical society, people don't have a lot of practice making decisions democratically, or coming to a consensus with people they disagree with. "Group projects" in grade school is pretty much the only time this happens during our socialization, which is incredibly sparse and inadequate. Anthropologically speaking, we should be doing this nearly every day.

Please name the next iteration something less spicy.

> These issues have persisted despite our repeated attempts to discuss them. This is, of course, a systemic problem rather than one any single SC member could solve; we don’t envy the demands of the role, have been impressed by the efforts of several members, and recognize that every individual naturally has limited time and energy and can only do so much in the context of a representative majoritarian committee.

For that work project though, the final closure was thousands of store paths, with hundreds of source repos being brought together across a multiple of languages and build systems. A lot of that was/is essential complexity, just the reality that robotics is hard, the tools aren't as mature as in other domains, and so you have to be able to develop features and bugfixes all over a huge software stack simultaneously. Doing that with conventional tooling basically gets you a rigid world where you have to tag/release intermediate packages all the time just to get changes into testing, or you have to build the world on every push (lol docker).

With input addressing and hermetic building of the intermediate stages, Nix and Bazel are systems that don't make you make that choice.

A stagex containerfile can define a system build recipe in such a way that several competing build systems that obey the same standard can all get the same hashes, which we sign every release.

https://github.com/nixpkgs-architecture

https://www.youtube.com/watch?v=gp0FI8Gw1iA

anyways, i hope there’s a path to some kind of redemption and reconciliation in the future for the community. it sounds like it’s been Bad for years at this point.

Any organization is eventually controlled by people more interested in the organization than its mission. Or something to that effect.

(Accidentally attached this to the wrong post, meant for the post above this)

If you like writing bash scripts then go for it. (Personally I'd rather be doing literally anything else, like, I don't know, shoveling manure.)

It seemed to me that it was all the friction of immutability without any of the benefits of reproducibility.

There could be similar issues with NSS but I think more people are ready to bypass NSS altogether.

Like I’ve created a rough media player with curl, jq, mpv powered by my subsonic server. The same issues happens with my emacs config which depends on various utilities. Yes I could create a main toolbox for all of that, but the whole thing was a bit cumbersome.

When I do want proper isolation, I create a VM.

I like the friction aspect to some extent because I think keeping the base system pure confers many benefits. But you’re right. Bazzite imposes a certain workflow. For installing new software …

1) try ujust first (since there is some porcelain provided for some things that can be challenging to install properly on immutable distros, such as Steam or DaVinci Resolve)

2) if that doesn’t work, try flatpaks from Bazaar/Flathub

3) if that doesn’t work, use Homebrew which installs into your home dir by default

4) use rpm-ostree as a last resort.

Functionally I find this has driven me towards a very devcontainer-centric setup. Of course in theory Nix can do better, but in practice I’ve found the combo Bazzite offers, not to mention the excellent hardware support, hits the sweet spot for me.

The Nix drama from the start has been profoundly untethered from actual development or improvement of the project rather than minutia of committee organization and moderation of the Discourse forum

Whatever you think about the $5000 Anduril sponsorship for example, the "discussion" around that took up a ridiculous amount of mindshare relative to the actual dev work compared to almost any other open source project like Linux kernel for example