DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
39% Positive
Analyzed from 2386 words in the discussion.
Trending Topics
#nix#team#nixos#core#more#something#community#maybe#nixpkgs#things

Discussion (73 Comments)Read Original on HackerNews
Personally, I'm sorry and grateful. Sorry that it ended in core folks being burnt out. Grateful since they did some of the most amazing work, more than anyone can imagine two people doing.
That being said, I think it is still a concept worth pursuing.
Please name the next iteration something less spicy.
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.
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.
Meanwhile, my company is using Nix for everything heavily internally. Everyone gets their dependencies via Nix unless you are like using PAM or something.
Reminds me of Bazel, in the way that it gets adopted by companies with developer support teams (because it solves real problems) but feels frustrating for us ordinary folk. Nixpkgs is kind of a critical part of “ordinary folk” and with the core team disbanding, I feel like my personal moves away from Nix (for projects) are proving correct.
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.
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.
“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.
Why doesn't your company fund development of nix and its associated ecosystem?
This is an almost poetic description of micromanagement. I really like Nix and have been running it as my main OS for several years in the past ~ 10 years.
I don’t think the issues they have are unsolvable, it just appears that the governance model they’re trying to have is not working out, and it’s very difficult to roll back.
Nix governance: still hasn't resolved dependency hell for humans apparently.
I’m in the process of about to deploy Nixos to server workloads, but am now hesitant because I don’t understand these ramifications.
Nix and NixOS are two of the most revolutionary pieces of software in my experience. Hopefully Nix finds a governance structure worth of it.
It seemed to me that it was all the friction of immutability without any of the benefits of reproducibility.
Nix/NixOS is fundamentally about a declarative system configuration.
And as far as I understand, StageX doesn’t have that.
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.
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.
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)
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.
> 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.