The Nixpkgs core team has disbanded
discourse.nixos.org
discourse.nixos.org
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.
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.
That being said, I think it is still a concept worth pursuing.
Please name the next iteration something less spicy.
NixOS is dying, everyone sees this right now.
> but we've also functioned without one for ~20 years.
Then this is also a PR problem because why need a team when the 20 years before were allegedly so perfect?
Huh? Based on what? The packages I use keep getting updated, so clearly nixpkgs is alive. The OS I use keep getting updated, so clearly NixOS is alive to. Who exactly is dying, and what makes you believe that?
Nix tends to have updates almost as quickly as Arch does, I run a lot of bleeding edge software and have no issues, and the breadth of packages is immense. Nix just has a different style. With the AUR, you can adopt an abandoned package more easily. That has pros and cons (the AUR has recently suffered multiple supply-chain attacks due to packages being adopted and infected).
I'm fairly certain that the graph you're thinking of is complete bullshit. It only had approximately a third of the package count listed for a particular Ubuntu version than said version had in actuality.
Source?
I won't believe that until Netcraft confirms it.
On the other hand, I just checked, and the domain ratemyflake.com is available. I think we should set it up, so that we can rate each other's nixings!
This is a massive part of the problem to be advocating for & adopting flakes. My config is much simpler: nixos-rebuild switch --file host/$HOSTNAME. This doesn’t require a properly evaluating, not-quite-Nix manifest file to just to build a system. If more folks understood the standard package format & overlays, they too would come to the conclusion that pointing to a file is simpler/uncoupled. packages are just derivations, as are apps, as are checks so there’s little value in separating them. Overlays, modules, configurations, these are all better as their own files too—instead of what I see more often which is coupling them to the flake so they can’t be consumed by stable nix. I have seen big corpos get totally boned by transitive dependency resolution exploding the lockfile too as input.follows does not offer the same power as overlays. The straw breaking camels’ backs to me is how restricted the input pinning options are to things being shipped by the C++ binary & the maintenance burden upstream now takes on trying to shove too many things into the binary instead of sticking to a few primitives.
You don’t need perfectionism—my config is a mess of some of my most beginner code—but the foundation folks are building on is not good & it ends up leaving very sour tastes in folks’ mouths and/or trying to build abstractions on abstractions to hide the underlying design (things built on ‘dendredic’ patterns, which itself is a questionable patterns, built on flake-parts which is questionable, all to hide limitations of flakes which is the core misstep which is hard to work with causing folks to want to overabstract).
I'm sorry to say that this is a highly ignorant reaction to the situation. Nixpkgs was nowhere the size it is now in terms of contributors and packages, the growth in the past six years was enormous.
But also out of those 6y the core team did not exist for ~5y, apparently. How is it a highly ignorant reaction?
Your argument only holds if I were to say "it grew to its current amount of monthly contributions in 2020 and then stayed constant, without growing any further."
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...
The second blog post is from someone on the steering committee who complains about Gabriella439 (the author of the 3rd blog post) "turning on" them after they tried to work with the moderation team, whatever that means.
The third blog post complains that the moderation team was too large, had a lot of absenteeism problems, and tried to do everything by consensus which didn't work with the large size combined with the absenteeism problems.
The last post is most revealing. It's also the least dramatic. It looks to me like they tried to form a way too large group of people who treated this as a low priority, then tried to do everything by heavy procedures and consensus with half the team not showing up. That's a common mistake in community organization that leads to collapse.
EDIT: I looked up the conversation about the NixOS moderation team resigning. Apparently the moderation team was causing a lot of their own problems within the community. I'm not going to read it all, but this looks like familiar overzealous moderator drama
My favorite example so far was that someone got banned and one of the conditions for getting unbanned was removing steak from their profile picture: https://github.com/NixOS/moderation/commit/e9d67b7efa03e6e9b...
One of the most notable actions of the team was managing a protest against defense companies assisting the project.
Its disbanding was just another instance of the well documented, and statistically supported, end of the cancellation committee trend that rapidly took off in 2021, peaked in 2023, and has nearly fully receded into oblivion since then.
The backlash against that trend, while not communicated publicly by most (far-right folks excluded...), has been massive, but handled tactfully, behind the scenes. Always important to remember that the equity-left is only about 20% of Americans, and the US is the global stronghold for such ideals. (That 20% makes quite a bit of noise, which gives many the impression that there are many more than there actually are. The reality is just that most people are polite, and don't want to get involved in discourse where their opinions could lead to them facing dramatic negative consequences.)
The global community has not been supportive of the continuing of the trend. So it's not just pushback from the (largely polite) majority of those in the English-speaking world that gave the whole situation a fair shake.
Anyway, to reiterate: the moderation team's disbanding had just about nothing to do with technical aspects of the project, and it could be argued that its disbanding was potentially a positive sign for stability.
What ? The U.S main ideological exports of the last 50 years are neoliberalism, alt-right and techno-feudalism. Its 2 party would register as far right and center right in basically any other country.
> The U.S main ideological exports of the last 50 years are neoliberalism, alt-right and techno-feudalism
U.S.A is responsible for the pervasiveness of social liberalism in the centre-left of Western countries, and more specifically the topics of its American version (the so called "wokeness"). It's distinct from neoliberalism, although academic left, and its pundits, like to use that misnomer for anything liberal they want to put down. And I want to point out that all of the terms you used are generally poorly defined.
> Its 2 party would register as far right and center right in basically any other country.
That's also wrong, just look at the current European landscape. American Democrats are not like CDU in Germany, Conservative Party in UK, PiS in Poland, etc. , but rather closer to the centre-left counterparts in the respective countries.
First time dealing with a committee? It is routine for every community to be shrouded in an ongoing cloud of drama and that doesn't indicate anything at all. There certainly could be problems and if there are it'll generate chatter, but the problems have to be dealt with individually. People resigning and complaining about a steering committee is normal.
This was the elected steering committee doing its job, and a sign of growing health.
> So while I shouldn’t let myself be bullied away, I am stepping down from the Nix maintainer team.
> I am not as of now stepping down from the SC, because that would be irresponsible.
Nice attempt to try to rescue here, but everyone sees that NixOS is dying.
When a group of, say, ten people give up in a moment, that does not bode well for the future of NixOS.
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.
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.
At the time of that talk we threw up a lightly sanitized version of the tooling on github. The basic idea was that there were these two repos:
https://github.com/clearpathrobotics/nix-ros-base
https://github.com/clearpathrobotics/nix-ros
The first was the "toolkit" repo that had all the manual maintained dependencies and functions, while the second was a managed repo which would have tags pushed to it by the pipeline.
So basically all the repos had a push hook attached to them that would run this centralized dispatch workflow (on Jenkins, but it could be anything). The dispatch job would sanitize the branch name like joey-b/fancy-feature and attach it to the most recent "released version" + devel timestamp, so you'd end up with like 2.25+20260808-12345+joey-b-fancy-feature, and that would be pushed as a floating tag to the nix-ros repo with all the sources from the hundreds of participating repos either locked to the versions set in the top level 2.25 devel branches or to the specified feature branch, so that a given build could pull together multiple same-named branches from across repos. That would be sent off to Hydra, and nix2container outputs were also built that went to simulator based validation.
But the end UI was pretty nice, basically a nix configuration mapped the names to the those repos so after the build was done you could just pull it and "enter the workspace" environment like:
nix build ros/2.25+2026080-12345+joey-b-fancy-feature#setup
source output/setup.sh
Anyway, as I say, I'm obviously proud of what was achieved, particularly in a pre-LLM world, and the experience of building this has given me many of pg's blub experiences over the years, where I look at the ways that other build and packaging systems solve these problems and think yes, yes I can see how that works, but also, I have experienced a world where in exchange for some relatively minor strictness tradeoffs, the set of problems that that is solving never had to exist in the first place.
With multiple types of machines involved, you want some sort of binary cache setup, ideally automated with CI. There's niks3 [0], celler [1] (a more active fork of attic [2]), hydra [3].
0: https://github.com/Mic92/niks3
1: https://github.com/celler-cache/celler
post-build-hook = .../upload-to-cache.sh
#!/usr/bin/env bash
set -euo pipefail
set -f
export IFS=' '
exec "${NIX_CACHE_NIX_BIN:-nix}" copy --extra-experimental-features nix-command \
--to "s3://my-cache-bucket?region=us-east-1" $OUT_PATHS
There could be similar issues with NSS but I think more people are ready to bypass NSS altogether.
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.
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.
I don’t want to configure a global environment. I just want a build system that works reliably in any environment and can cross-compile from any platform to any platform.
Nix does too damn much. All I want is a build system that doesn’t suck. And I want to run it on windows + Mac + Linux as a first class citizen. And I want to arbitrarily target any platform.
What this really comes down to is that Linux C/C++ toolchains are badly designed. Nix is a huge massive convoluted architecture to try and twist itself around that unfortunate reality.
At least that’s my spicy unpopular opinion that is probably wrong but is at least has elements of truth.
The pervasive link detection structure of effectively everything on GNU/Linux assumes is (more-or-less) objectively incorrect behavior in any sane security minded context. Binaries should be able to declare the interface/contract they expect (args/types/abi/exceptions/cryptographic signatures/digests). Then the runtime linker "match" against the local system. The current system is basically 2 levels of string equality checking.
Nix goes into the right direction by getting your runtime linker/elf-runtime & package manager "integrated". But this sort of just feels like putting 'lipstick on a pig' and dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer. Nix just manages the environment/symlinks such that `foo.exe` doesn't realize this fact.
Yes!!
> dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer
I’m curious if you have an opinion on how you think this should be handled?
At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world.
I also blame C/C++ toolchains for being very very bad on Linux.
To "totally overcomplicate things" but do it correctly
- Binary states a list of constraints (namespace:name [<|>|>=|<=|!=] semver). - ldconf/ld.so either integrate into your package manager and/or are easier to update (I'm not writing conf files by hand and/or flakes). I should simply be able to recursively scan. - Give the runtime linker an SMT constraint solver (when <1000 this is nearly instant) - Cache known states to avoid solving NP hard problems every time you launch `cat`.
> At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world.
Honestly same.
Having the package manager <-> elf runtime <-> shared libraries more-or-less be a blackbox is probably for the best (which is sort of what windows does with the install-shield/install-wizard stuff). But nobody in Linux Land really wants to "improve" userland, other then change to flavor-of-the-month display managers.
> I also blame C/C++ toolchains for being very very bad on Linux.
They honestly aren't, it is more your pacakge manager *is* your library manager. Because of the absolute bullshit of shared libraries.
If you pretend it is the 1970/80s everyone at your company has the architecture, unix version, etc. It is pretty nice. No cross compiling, multiple OSs, everything just sort of works pretty well. But like I said, "pretend".
Hrm. It’s trivial for Linux to cross-compile for Windows because Windows is sane. It requires moving mountains for Windows to cross-compile to Linux. Hell, the only way Linux can reasonably compile to target an older version of glibc is to create a full container image containing and using the old glibc. It’s absurd. I suppose this isn’t the root evil. But it feels related to me. Maybe not.
Sigh.
Overall I think it is succeeding, though it definitely doesn't 'just work' out of the box. We've invested a fair bit of effort into things like:
- containerised services[1]
- UI for branch deployment/service management
- delta patching (at the byte level, to save bandwidth)
The main problem was always that nixlang/nixpkgs are arcane and have a steep learning curve. The majority of your colleagues (in any workplace) don't care about build systems and just want things to work. I think that has been more or less solved by LLMs, and it's now more viable than ever to adopt Nix.
How were you doing that? Running your own channels, or something more complex?
Also, did you use a push or a pull model w.r.t. the robots?
As a result of that, in "production" we still actually delivered full rootfs images just to be absolutely certain, and the delta upgrades were for smaller test fleets that could updated hourly just via simple push tooling.
If I was building it from scratch though, I'd probably just do NixOS + colmena, and do a push model forever. It's not worth the saved SSH connection to not have those logs and status messages coming back to the central coordinator immediately.
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.
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.
I believe you. Do you believe me?
> At that point, NixOS just clicked and I'm far more productive with 30+ hosts than I used to be with 1-2.
There’s not much room for improvement in my own productivity here. The amount of time I spend maintaining these hosts is not large to begin with.
> This sounds like you're branching into territory that can no longer be reasonably framed as NixOS vs. Debian (or other distro of choice).
I was never talking about NixOS in the first place!
I use kubenix to manage the cluster, of course. ;-)
But as the host OS I use Talos Linux, which itself is declarative and minimal. For small Kubernetes version upgrades, I upgrade the kubelet with an API command. When that isn't possible, I upload a new Talos image and swap them.
Since the nodes are cloud VMs, I will use a spare VM to add as a new node, and remove an old node. So I never run with fewer nodes. For my on-prem cluster, I will do the same with a spare hypervisor VM. It really helps ensure my nodes are ephemeral.
So NixOS, for now, has become a desktop/laptop operating system for me, and whenever I need an execution environment, e.g. a CI runner or a remote shell, I choose "something Nix-like" which is `nix` in a container without systemd.
I'm still a huge NixOS fan.
Why doesn't your company fund development of nix and its associated ecosystem?
On the other hand, building an entire company atop experimental software that might explode or cease to exist tomorrow seems so monumentally stupid that the inevitable business failure is the outcome they don't need, but so badly deserve.
All things come to an end. Why not ride the wave of a FOSS project, eg by offering support as a business. As long as you are prepared to pivot or close the business when it's no longer needed, why not?
It doesn't strike me as stupid.
Nix governance: still hasn't resolved dependency hell for humans apparently.
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.)
Only if they isolate each atomic package individually. Which is exactly what Nix is and what Docker isn't.
Perhaps it is no surprise the earlier adopters were people with rigid views.
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.
Just note that the community is unstable and prone to civil wars.
It seemed to me that it was all the friction of immutability without any of the benefits of reproducibility.
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.
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.
It's Nix on the inside but the language is Guile Scheme instead of Nix.
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.
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.
I tell you what. Ever since I migrated my dev workflow to nix package manager (and home manager for system depa), my life became simpler like 10 times
I can configure any macos machine in like 20 mins (I use Determinate)
As a layman who has only used AI to package a couple things on NixOS for personal use, I would think that LLM agents are perfect for taking over most of the nixpkgs workflow.
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.
NixOS: “Given this configuration, build me the same system again.”
StageX: “Prove that every binary in this system came from the source code I think it did.”
If I remove a package from the list itt best uninstalled, if I add it gets installed, etc
Like setting up nginx as a package with SSL support for example.com domain, PHP working with nginx via PHP-FPM, etc.
StageX I don’t believe can do that. I believe it can only confirm that the nginx package hasn’t been tampered with.
That containerfile defines an entire deterministic custom OS image, every package, and every configuration etc.
Many patterns are possible, though this will be made way easier with our upcoming "box" primitives
Is this what the box primitives is about?
Not inventing our own language has drawbacks, but we are convinced the security and portability wins of sticking to standards with many existing implementations, however awkward at times, are worth it.
No major OCI runtime supports separate lock files yet, so for now they have to be maintained at the top of the file for portability. Most teams use scripts to maintain the hash blocks, though soon our official tool, sxctl will have a "lock" function to make this painless. Also only in most cases people will be able to get away with only one hash soon for most common use cases.
This leads to reducing repitition, "boxes" will allow us to have portable patterns such as "rootfs -> cpio" or "rootfs -> bootable iso" to make things dramatically more succinct. Here is an example of the upcoming pattern in action to produce multiple variants of a qemu/cloud bootable < 30mb busybox image: https://codeberg.org/stagex/stagex/src/branch/lance/distros/...
No need for hash locking inputs when in-tree as everything in tree must end up with deterministic digests signed by multiple team members before merging, which are generated in the digests folder.
Similarly we may introduce something a bit like Gentoo Overlays to allow for out-of-tree extension repos to still build with all the benefits of being in tree.
But when my current "distros" branch lands ideally this month, we will have in-tree support for building images for many common desktop, server, enclave, and embedded use cases.
Ubuntu: a problem needs solving -> spend an hour learning how to solve it -> implement solution -> a year goes by -> new machine -> same problem -> spend an hour because you forgot the solution -> implement it again
NixOS: problem -> spend 2 hours -> implement -> never repeat again
> 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.
Anyways the writing was on the wall for this and Nix is dying.
(They disagree)
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)
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
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.
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...
This resignation post reinforces the view that there is little good faith assumptions amongst the broader Nix ecosystem.
https://discourse.nixos.org/t/objection-to-minority-represen...
It's absurd to view this as a reason Eelco himself should be forced out of a project he himself created.
>For context, Anduril is a military contractor who produce drones using machine learning on Nvidia GPUs on NixOS as well as ML based systems for detecting migrants on the US-Mexico border, cheapening state violence against migrants.
Given that ICE are currently breaking into peoples apartments and rounding people up into concentration camps, would it not be logical to conclude that the company providing software for the agency are fascists and by extension Eelco relitigating the sponsorship policy can be taken as allowing fascists in the community?
For too many, building and celebrating things just because they are cool isn't enough.
The nature of nix prevents the nix community from being a group of like minded people because it tries to be a unifying layer over technology which is not made by like minded people. To do what nix does, you need to overcome whatever forces caused those cliques to form in the first place. You need representatives from each group. It's a bit like congress, which has similar problems.
And its not just disparate language communities. It's people who want to build influential businesses, and its people who want to insulate themselves against the influence of tech business. Its people who think it's OK to build killer robots, and it's people who don't want to be killed by those robots.
Getting people work together is hard. Nixpkgs tries to do that to such a degree that you can put a version number the result. Maybe it's admirable, maybe it's folly. I think it's both.
I'm not going to blame the people who are ambitious enough to try because as far as I'm aware, whatever other successful communities exist, they're succeeding at a less audacious goal.
Also, we see censorship running supreme again:
"This post was flagged by the community and is temporarily hidden"
People need to stop censoring everything, seriously.
NixOS going downwards also coincides with the rise of AI. AI slop really puts stress onto so many projects now.
Also nix is one of a better languages when it comes to ai, since invalid programs just don't really run. As long as I dislike the slop aspect of ai, I can trust it to do things to my nixos system without my system breaking, which I'd never even imagine on any other os. I believe that it may be one of a few languages that will benefit from clankers, since the barrier of entry is so high, you can use it as a very reliable crutch.
1. the "I used nix once/some time ago but I realized it's stupid/hard/whatever"
2. anime pfps/furries/trans/woke are bad
3. complaining about CoC/governance/etc
Irrespective of whatever the posted article is about relating to this technology. This is one of those threads.
Nix seems to have one of the worst discussion quality around here. Rust threads are similar (though they got better recently), specially on the negative unrelated comments side, but seem to have much more engaged people. Maybe Anubis has a similar ratio. I wonder why?
I didn't see it mentioned yet and maybe there are valid reasons for that happening that I'm not aware of.
Also, discussing the thread in itself seems more relevant than how hard/confusing/woke you find a language.
I'm not here making a call to action or trying to police the thread, if anyone want to go off topic be guest.
"If everywhere you go smells like dog poo, look at your own shoes."