Rendered at 20:49:13 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ronef 18 hours ago [-]
For anyone reading this and jumping to a broader conclusion: the Nixpkgs core team disbanding does not mean Nixpkgs or Nix is dying.
It does mean that this particular structure was not sustainable, very important contributors burnt out and we need to do better, faster. We need to continue learning from this and continue building a stronger ecosystem that prioritizes the contributors who are the only reason any of this is possible.
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.
tomberek 18 hours ago [-]
The Nixpkgs Core team was established in Sept 2025 (https://discourse.nixos.org/t/establishing-the-nixpkgs-core-...), so it is a fairly new concept and idea. They've accomplished some good things as highlighted in the post, but are now stepping down. Yes, we'd prefer for the team to exist, but we've also functioned without one for ~20 years. It may take multiple iterations to bootstrap the concept and to figure out the right structure - or we may find it isn't needed. So no, this is not a critical emergency. It's a return to the status quo of late last year.
That being said, I think it is still a concept worth pursuing.
xyzzy_plugh 16 hours ago [-]
I agree with the concept but the name is terrible. "Core team" gives one the impression that this is the most important team to the project. It's not! It could be called the "governance facilitator" team or admins or something.
Please name the next iteration something less spicy.
nextaccountic 11 hours ago [-]
exactly what rust devs realized. they went from "core team" to "leadership council" in the next iteratiion
jonringer117 16 hours ago [-]
There was an architecture team which existed, I would assume the usage of "core" was to disambiguate.
Packages were handled way before 2025 already, so it is strange that you insinuate they'd all only burn out within a year, and before that it was all cake and tea.
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?
black_knight 4 hours ago [-]
I know nothing about the organisation of NixOS, but I know that NixOS is in a unique position now that LLMs have arrived. It offers the unique experience where you can fearlessly let the LLM loose on your system config to setup any convenience you want. I am not alone to have made this observation, so I am hopeful that Nix and NixOS will gain even more momentum in the future!
embedding-shape 11 hours ago [-]
> NixOS is dying, everyone sees this right now.
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?
Pay08 4 hours ago [-]
Isn't nixpkgs still a pretty bad state? I know there used to be a lot of "abandoned" packages that went years without updating to the new versions provided by upstream, that a lot of packages were copying binaries around instead of building open source software from the source, etc.
toshinoriyagi 1 hours ago [-]
Nixpkgs is one of, if not the largest, package managers by # of packages. I think naturally that will result in more abandoned packages than others. What is the % of abandoned packages relative to total I can't say.
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).
nickdichev 38 minutes ago [-]
A common pattern is to manage your own "overlay" repo on top of nixpkgs to keep the packages you care about up to date.
bityard 10 hours ago [-]
> NixOS is dying
I won't believe that until Netcraft confirms it.
bombcar 10 hours ago [-]
Ah, good to see a fellow hot grits enjoyer.
13 hours ago [-]
dindresto 13 hours ago [-]
"we've also functioned without one for ~20 years"
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.
gcarvalho 11 hours ago [-]
I don't mean to be dismissive of the work done by the team which just resigned, and hope they get back on their feet.
But also out of those 6y the core team did not exist for ~5y, apparently. How is it a highly ignorant reaction?
dindresto 11 hours ago [-]
The amount of monthly contributions has doubled in the last four years alone, from ~7k to ~14k commits per month. Why did I take six years as a reference? Because 2020 is the year nixpkgs really started to pick up traction, and the growth has been almost linear ever since.
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."
aliasxneo 15 hours ago [-]
Correct, but it's another domino in a broader trend that appears to have a common root. It was only a year ago that the moderation team mass resigned pointing the finger at the steering committee [1]. It's not been the same people for the last two years, but clearly there must be systemic issues in the people getting elected to this board for there to be so many persistent problems.
Also see roberth's resignation [2], and Gabriella439's retrospective [3], and then there's Jon Ringer's thing, the list goes on.
I don't know if the moderation team's collapse is indicative of anything. The first blog post complains about the Steering Committee for doing, well, steering. The moderators complaining that the Steering Committee is "interfering" points to a bigger issue where the moderation team didn't understand their role.
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
I think the elephant in the room is that many tech nerds are just famously terrible at working with others and social skills in general, even if they have a long history of excellent work. Especially so if that experience was not gained from traditional careers where it wasn't possible to get by without people skills.
4 hours ago [-]
farfatched 12 hours ago [-]
The moderation team quit because they could no longer act with impunity.
This was the elected steering committee doing its job, and a sign of growing health.
roenxi 14 hours ago [-]
> but clearly there must be systemic issues in the people getting elected to this board for there to be so many persistent problems.
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.
Pay08 3 hours ago [-]
Drama certainly doesn't seem to be a problem for GNU.
farfatched 7 hours ago [-]
roberth resigned from the Nix maintainer team, not the Steering Committee.
> 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.
spoaceman7777 14 hours ago [-]
The moderation team stuff was largely unrelated to tech stuff, and was specifically involved with politics and ideological HR-style cancellation discourse.
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.
fcantournet 11 hours ago [-]
> Always important to remember that the equity-left is only about 20% of Americans, and the US is the global stronghold for such ideals
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.
Kratacoa 8 hours ago [-]
Both sentences are false.
> 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.
iamnothere 3 hours ago [-]
I agree with you. If you look at its biggest sponsors, it’s apparent that social liberalism is an attempt to shore up the position of neoliberal capitalism by redirecting ire away from capital and corporations. By elevating the individual above all else, and promoting identity groups secondly, it also implicitly directs people away from class-based politics (which is furthermore framed as a form of supremacy/oppression). Finally, the lowest classes in the West are divided evenly between whites and oppressed minorities, so keeping them at odds prevents intra-class cooperation.
throwaway260806 18 hours ago [-]
> more than anyone can imagine two people doing
The core team was just 2 people and they disbanded?
there are two distinct usesn of team/committee/council/etc in the software world, though they often get conflated. one is a formal structure to help with things like coordination and governance when many people are working on something, and it does seem a little silly to have one consist of just two people.
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.
kesor 15 hours ago [-]
It was 4 people originally a year ago. One left because too much drama. Another joined another committee and was ineligible to continue. The remaining two wanted to recruit new people, but no one wanted anywhere near that dumpster fire. So they got burnt out and disbanded the whole thing.
nylonstrung 16 hours ago [-]
[dead]
nullsanity 14 hours ago [-]
[dead]
shevy-java 13 hours ago [-]
> the Nixpkgs core team disbanding does not mean Nixpkgs or Nix is dying.
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.
farfatched 12 hours ago [-]
A team of two people decided to disband the team, but continue to make contributions.
stingraycharles 19 hours ago [-]
“Our experience is that the Steering Committee as an institution lacks a native instinct for the delegation envisioned by the constitution, while also not being sufficiently engaged and cohesive to handle individual decisions at those levels itself.”
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.
kesor 15 hours ago [-]
The governance of the project went into political extremes instead of focusing on technology. That made it impossible for anyone other than political extremists to continue in governance positions. Obviously these people had too much on their plate and couldn't find anyone who would join to help them, as they chased everyone away. Burn out was inevitable.
astrobe_ 15 hours ago [-]
The whole paragraph describes quite well what I feel at the company I currently work for. I think it is more accurate to say that it is interference (rather than micromanagement) and goalpost shifting because whoever is/are in charge don't have a clear idea of where they are going.
klodolph 19 hours ago [-]
There was a sweet spot in like 2024 when it seemed like everything was possible with Nix, but now it seems like everything “experimental” is permanently so (like flakes), packages I care about are not as fresh as I want, I have no mental recall for Nix commands…
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.
mikepurvis 18 hours ago [-]
I was lead on a Nix adoption effort for a few years that was kind of like that: it solved real problems, unlocked far faster, smaller, and cheaper builds than would have been possible any other way, and let us ship delta updates over crappy wifi connections to Linux computers on robots. Flakes were a perfect fit for our model, and we were just in time for stuff like up to date versions of cuda and tensorflow to be delivered via nixpkgs.
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.
rossng 13 hours ago [-]
We're using it in the same way - running NixOS on robots.
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.
Meanwhile I’m over here with my 100 line flake.nix that installs system dependencies with direnv across hundreds of dev users and dozens of repositories wondering why everyone is all up in arms about boring and stable technology that solves a specific problem
mikepurvis 16 hours ago [-]
In my personal life, I also like Nix for small projects, especially where you're crossing multiple ecosystems so that any one system's tooling/lockfiles aren't really enough to "enclose" the whole thing.
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.
shakow 7 hours ago [-]
> let us ship delta updates over crappy wifi connections to Linux computers on robots
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?
mikepurvis 5 hours ago [-]
At the time I was there we hadn't made it all the way to NixOS on the targets, so it was an Ubuntu "base" + Nix managing the app workspace as a kind of pseudo container, though able to bring more of its own system configuration with it (https://github.com/numtide/system-manager) than the more typical nuisance setup of container + separate outer config managed by ansible or a deb or whatever.
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.
18 hours ago [-]
forrestthewoods 14 hours ago [-]
My gut feeling is that Nix is just not quite the right abstraction level. I can’t quite articulate this. And hell maybe I’m wrong.
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.
hugmynutus 12 hours ago [-]
Shared Dynamic Libraries. Not to say they aren't useful. Keeping applications small, keeping security updates simple, sub linear ram scaling, yada-yada-yada, big wins cross the board, not debating that.
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.
forrestthewoods 1 hours ago [-]
> lipstick on a pig
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.
imadierich 11 hours ago [-]
[dead]
threethirtytwo 7 hours ago [-]
The truth is like the sun. The light from the sun touches everything, it's bright and it's obvious... yet no one can stare directly at it.
It's like saying obese people are not attractive. It's just obviously true, but no one likes to talk about it and many people (who are obese or aren't) don't want to hear it.
When you say this: "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."
The godawful truth is, Nix fails at the task above. It sucks at it and does a bad job at it because it's so freaking complex. Plenty of people in denial about this but they just can't stare at the sun. They build their complex convoluted solutions and convince themselves Nix was the way while blindly looking away from the pitfalls.
One commenter literally was talking about how his company adopted nix and how they suddenly backpedalled on nix and he COULD not understand why. If you are one of those people who cannot for the life of you understand I am here to tell you that why a company back pedals on nix is as obvious as the sun. You just can't stare at the sun or you don't understand humans.
nocman 4 hours ago [-]
> The truth is like the sun. The light from the sun touches everything, it's bright and it's obvious... yet no one can stare directly at it.
bad analogy. It can be very painful to accept the truth, but doing so is always a good thing. Staring directly into the sun can cause permanent damage to your eyes -- not a good thing.
threethirtytwo 4 hours ago [-]
No this is not true. There is an evolutionary reason why people lie to themselves. Look at the world.
Almost everyone believes in religions. The world lies to themselves on an unprecedented scale. If accepting the truth had an evolutionary benefit then most of the world would not be so delusional. Delusion dominates the population because lying to oneself conveys a survival benefit such that natural selection selects for this trait.
This short infographic illustrates and proves it. But you know what else proves it? Me getting voted down as I throw the truth down in front of everyone’s faces. I’m a target for selection.
Maybe nix will one day be a tool that’s actually good. It has elements of it but complexity and usability hinder adoption. So overall nix is just shit imo. It’s shit wrapped in a dream, a dream of an ideal way to do things. How do we make that dream a reality?
By lying to ourselves. By claiming nix is already there and that other people can’t see the light such that over the years after enough improvements nix becomes an actual good tool because enough delusional people pushed the dream far enough that it actually happened. But in order to do that… people like me must be culled from the herd.
haswell 18 hours ago [-]
Can you share more about what made you move away?
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.
klodolph 17 hours ago [-]
YMMV, I don’t run a home lab, I just have a NAS and run a personal website. I definitely don’t have a “fleet”. I have two servers running Debian and I can bring them back up from zero in <30 minutes.
“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.
dlahoda 6 hours ago [-]
Yeah. I fixed AI/GPU stack consisting of 6 existing packages to run CLI on Mac. Fixed all comments during several weeks. And then silence. No approve no nothing for few months. Closed PR and will never come back.
haswell 16 hours ago [-]
> “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.
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.
klodolph 6 hours ago [-]
> 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.
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!
sshine 14 hours ago [-]
I moved my homelab to Kubernetes. I just don’t see the use of single VPS’es. But I use the cluster as a training platform, so if I didn’t need Kubernetes in other parts of my life, I probably would have stuck with my NixOS VPS’es that all share config.
I use kubenix to manage the cluster, of course. ;-)
craftkiller 8 hours ago [-]
The two aren't mutually exclusive! I just finished porting my personal kubernetes cluster from running on Debian to running on NixOS. Now whenever I want to update the host OS on my kubernetes nodes, I just build a new bootable ISO from my Nix configs and upload it to my servers, swapping out the whole OS atomically. If anything goes wrong, I can swap back to my previous build. No more anxiety running `sudo apt-get upgrade` and hoping for the best.
lwfitzgerald 11 hours ago [-]
A
matheusmoreira 17 hours ago [-]
> Meanwhile, my company is using Nix for everything heavily internally. Everyone gets their dependencies via Nix unless you are like using PAM or something.
Why doesn't your company fund development of nix and its associated ecosystem?
pests 15 hours ago [-]
Why ask this? Maybe they are? Maybe they aren't, and that's ok too.
matheusmoreira 15 hours ago [-]
Why not ask this? People are burning out here. Meanwhile corporations be making billions. I don't like that.
isdononthephone 14 hours ago [-]
That's the social contract with open-source software. You are not owed a cent for your work. But they're not owed support either.
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.
pbhjpbhj 6 hours ago [-]
>building an entire company atop experimental software that might explode or cease to exist tomorrow seems so monumentally stupid
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.
supriyo-biswas 18 hours ago [-]
Is it really that complicated? I personally use direnv with nix to have per-project dependency versions installed automatically, and I’ve never had too much trouble. I know that the flake.nix files can become somewhat complicated, but mine have been pretty simple thus far.
klodolph 18 hours ago [-]
I didn’t use the word “complicated”, maybe I’m missing something, but I listed some specific complaints and “Nix is complicated” wasn’t on the list.
haswell 18 hours ago [-]
Not OP, I’m not really sure what your specific complaints are based on the original comment. They seemed more like general/nonspecific concerns, which left the comment pretty open to interpretation.
klodolph 17 hours ago [-]
I’m here in the thread and I can answer questions or elaborate on things, so if you want to know what I meant you can just ask me and there’s a good chance I’ll respond.
talentedcoin 19 hours ago [-]
This resonates with me as well. I was really into using Nix for awhile but it turned out to be more trouble than it was worth for a solo dev.
hibikir 18 hours ago [-]
It gets worse when you are not a solo dev, and there's sufficient variety on people's setups. Oops, someone updated a version, and then built things for just their processor, and now I am stuck in a 20 minute compilation loop because some bad pin. Debugging Nix problems like those makes me think that old Gentoo Linux back in 2005 was easy and user friendly.
GreenDolphinSys 12 hours ago [-]
Updating causing a rebuild isn't really a Nix or even a build tool problem though, is it? cache.nixos.org can't provide everything for every architecture all the time.
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].
Or my personal favorite, just an s3 bucket. In your CI's nix.conf:
post-build-hook = .../upload-to-cache.sh
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
Set up environment variables as necessary for auth.
mikepurvis 18 hours ago [-]
The way I set it up at my shop was that everything would build on your PR, and so by the time it merged, everything was already cached and no one should see a rebuild... at most a download.
JamesSwift 9 hours ago [-]
Im thinking through this for my team, any previous writeups on it? Or do you mind brain dumping the high level of how you had it setup from a design perspective : D
mikepurvis 5 hours ago [-]
This was a talk geared specifically at a ROS audience so it's lighter from a general infra point of view but there may still be something useful:
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:
And if you were hacking on the "base" repo itself, it was very easy to pass flags like --override-input base=ros-base#some-ref or path/to/local for quick iteration.
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.
JamesSwift 4 hours ago [-]
Awesome, thanks for taking the time to put this together, that really is impressive pre-LLM. We wont be at this level for a while but its great to have resources to look at for examples of others have solved things.
talentedcoin 18 hours ago [-]
Ha that is very funny. I also started thinking about Gentoo a lot as well which was a sanity check moment … “even Gentoo was easier than this” etc.
CuriouslyC 18 hours ago [-]
Agents are getting pretty good at Nix. I think it has sufficient critical mass that it'll be fine.
noosphr 18 hours ago [-]
Is your company paying anyone to develop nix?
klodolph 17 hours ago [-]
Yes
noosphr 10 hours ago [-]
Awesome!
nextaccountic 11 hours ago [-]
Flakes must drop the "experimental" moniker and be officially supported by Nix. It may not be perfect, but it has been widely adopted.
TheFuzzball 7 hours ago [-]
That's already the case in determinate-nix. Flakes do have big problems though - try cloning a big data project with GBs of data and see how much you love flakes when it copies it to the store every time you run `nix run .#analysis`.
What does this have to do with installing packages?
klodolph 18 hours ago [-]
I don’t have all of the details, sorry, but PAM is a bunch of .so that are dlopen'd and if you mess them up you lose access to your system pretty damn quick. I would tell people to just use the system libc but I don’t know the specific failure modes for using libc via Nix. Using system libc = building your project outside of Nix.
There could be similar issues with NSS but I think more people are ready to bypass NSS altogether.
binarin 15 hours ago [-]
It has to do with installing packages that use PAM to e.g. validate user passwords (e.g. display managers, screen lockers). So there is a system PAM with its configuration, but making a program packaged with nix respect that system PAM config is not as easy as just linking with libpam from nixpkgs.
ButlerianJihad 19 hours ago [-]
Welcome to zombocom
ishanz 19 hours ago [-]
Nix package manager: correctly resolves dependency hell for your entire OS.
Nix governance: still hasn't resolved dependency hell for humans apparently.
stevefan1999 19 hours ago [-]
but the dependency hell for human is inherently political
19 hours ago [-]
XorNot 16 hours ago [-]
For a certain definition of "correctly" (namely: it doesn't, it just does what containers do and ships unique versions for every package).
drawnwren 15 hours ago [-]
This is not what nix does unless a user configures it poorly. Nix will ship a single, dynamically linked package/version combo for all package that depends on it. Containers ship one for each package that depends on it.
otabdeveloper4 16 hours ago [-]
Containers don't solve dependency hell. They just give you a standard way to ship your bespoke bash scripts.
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.)
stevefan1999 3 hours ago [-]
Containers do solve dependency hell by isolation. It's like venv/uv in Python that you switch between different environment with different sets of dependency. Or speaking essentially, you lifted yourself away from having dependencies shenanigans since you have virtualizations of it
Brian_K_White 13 hours ago [-]
that's what they said
vehemenz 18 hours ago [-]
I’m not saying it’s decisively correlated, or anything on its own, but there sure are a lot of anime avatars in this community.
Cyph0n 18 hours ago [-]
Nix and NixOS probably wouldn’t exist if it weren’t for the anime pfps :)
coldbrewed 18 hours ago [-]
I do not like anime but holy crap do people with anime pfps make excellent software engineers and terrifying red teamers.
16 hours ago [-]
yoyohello13 18 hours ago [-]
It’s really the furries that keep the modern world running.
sunaookami 9 hours ago [-]
Furries != Weeaboos/Otakus
yoyohello13 4 hours ago [-]
Let’s me honest, the communities have a lot of overlap.
KingMob 15 hours ago [-]
When I did nix, I joked that everyone I met in the community was either a queer furry kayaker or a military-industrial Terminator dev, with no in-between.
twalla 12 hours ago [-]
that spectrum is really more of a horseshoe than most would think
farfatched 12 hours ago [-]
Nix is flexible enough to bend to your will.
Perhaps it is no surprise the earlier adopters were people with rigid views.
undeveloper 6 hours ago [-]
silly. without the anime avatars and the furries nix is dead in the water.
frantathefranta 18 hours ago [-]
[flagged]
coldbrewed 18 hours ago [-]
The Internet was fully functional and full of competent people when it was a much weirder place. Converting all spaces into the equivalent of dress shirts and blazers doesn't reduce anyone's competence but does make the experience so much more drab. Let people like things.
frantathefranta 17 hours ago [-]
I don’t mind the internet being a weird place and enjoy the weirdness that exists in places like the NixOS community. I’m fully aware that the software I use has been built by extremely smart people who seem to like anime. It’s just that my line in the sand is that if you are trying to share a serious topic on the Discourse, the anime pfp seems to undercut the message.
sph 14 hours ago [-]
There is more to variety than the FAANG bro and the non-binary furry with anime profile picture, yet it’s all you see in tech these days. None of these were the stereotypes, say, 25 years ago.
shakna 17 hours ago [-]
Why do you consider it so strongly to be inappropriate? It literally does not tell me anything about the user.
DOS was built in a basement. Pretty sure suit and tie wasn't the dejour whilst they were doing it.
Linux was a hobby project. Pretty sure that slacks featured more than a blazer.
frantathefranta 16 hours ago [-]
I will tell on myself here but having an anime pfp evokes something childish for me and I do judge the user based on it. I expect to be judged similarly because I use the album art for a favorite album of mine as a pfp on the same platform and would consider it equally inappropriate if I were to share a heartfelt and serious message like this one.
shakna 16 hours ago [-]
That sounds like you associate anime with childhood cartoons? But considering how much of that industry output is 16+ or 18+ (usually violence and themes), I'd say that is more of a cultural confabulation.
I would absolutely not expect a business profile image, regardless of the message. Nor do I get why you think it is so essential.
Half the red team industry are furries. Would you criticise them for not using a mugshot? Because a lot of them don't, whilst posting CVEs that affect half the world.
frantathefranta 6 hours ago [-]
Yes, I do believe not having a pfp at all would be better (for disclosing CVEs or sharing a statement about disbanding the nixpkgs team). By all means use any pfp for normal forum purposes.
shakna 5 hours ago [-]
I'm afraid at this point, that sounds more like a you problem. You're judging people for something inconsequential. Your reasons are your own but... Probably worth some introspection here.
frantathefranta 53 minutes ago [-]
I'm very well aware it's a me problem, anime just isn't for me and it's super popular. I'm honestly surprised that a single person seemed to agree with me.
> Pretty sure suit and tie wasn't the dejour whilst they were doing it.
It's totally wild that you think the only alternative to anime furries are suits and ties.
Just what kind of fucked up environment did your workplace have with such a policy?
:-)
krautsauer 17 hours ago [-]
Sorry for the snark, but would it kill you to change your definition of appropriate?
aliasxneo 19 hours ago [-]
I really don't think these issues are necessarily "systemic" in the sense that they've been ongoing for the last decade. I _was_ a long-time contributor until about two years ago when certain actors came into the community and started making a bunch of unnecessary drama. Since then I've seen some long-time friends in the community either slowly drop out or simply get ran out by a mob with pitch forks.
stingraycharles 15 hours ago [-]
It is a systemic issue, though, when the system enables these certain actors to remain in position and cause the community to break apart like it’s doing.
aliasxneo 15 hours ago [-]
That I agree with.
indy 14 hours ago [-]
Many such cases across all aspects of society.
RossBencina 9 hours ago [-]
Is it patchable? Are there any known-working fixes that can be broadly applied?
alberth 18 hours ago [-]
Can someone explain the ramifications of this to those of us not informed.
I’m in the process of about to deploy Nixos to server workloads, but am now hesitant because I don’t understand these ramifications.
toshinoriyagi 17 hours ago [-]
This was a governance structure that began ~1 year ago. Nix is 23 years old, so it won't be dying or going away due to this. But it is sad to see two extremely valuable contributors leave the project due to burn out.
Nix and NixOS are two of the most revolutionary pieces of software in my experience. Hopefully Nix finds a governance structure worth of it.
whateveracct 18 hours ago [-]
the thing being disbanded is less than a year old
Alien1Being 15 hours ago [-]
If you want to trust your servers to a product of this community, that is your call.
Just note that the community is unstable and prone to civil wars.
rrvsh 11 hours ago [-]
please enumerate the civil wars over the decades Nix has been around. It is insane to discourage someone from using a good piece of battle-tested software because you personally have opinions about their community.
zamalek 8 hours ago [-]
Flakes for a start.
soupbowl 18 hours ago [-]
After being a heavy user of NixOS, I quit using it due to the communities instability, I don't trust it.
farfatched 16 hours ago [-]
I've been a user for many years, and have 100+ PRs, but I'm not really a part of the community, so these posts are the only drama I see.
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.
microtonal 15 hours ago [-]
Same, I have contributed hundreds of PRs. You can contribute to nixpkgs while avoiding most politics (it can take time to get a PR merged 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.
frantathefranta 18 hours ago [-]
In my mind Nix is too strong of an idea and once this community finally self-immolates, someone else is going to pick it up (maybe Determinate) and it'll continue on.
aroman 18 hours ago [-]
What alternative have you moved on to?
Y_Y 7 hours ago [-]
Guix (and nonguix for nonfree things)
It's Nix on the inside but the language is Guile Scheme instead of Nix.
talentedcoin 18 hours ago [-]
I suggest giving Bazzite a try
aktau 34 minutes ago [-]
Much more resource heavy. I tried NixOS and Bazzite (and other spins purporting to be lighteweight) and the difference on a 2010-era mid-range laptop was noticeable in terms of sluggishness. Not that this laptop was going to be my daily driver, but I like experimenting. It was a good showing for NixOS and that decided which one I would take. All of the other nice things about NixOS (fast rebuilding, easy install images, remote deploy, easy build tweaks, ...) were cherries on top.
aroman 18 hours ago [-]
I tried Fedora Silverblue and I found its notion/implementation of immutability fairly frustrating. It’s actually the reason I went to nixOS.
It seemed to me that it was all the friction of immutability without any of the benefits of reproducibility.
doubled112 18 hours ago [-]
I'm convinced that some day bootc (or something similar) will be exactly what I'm looking for, but not yet.
talentedcoin 17 hours ago [-]
Very true.
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.
My issue with Silverblue is that the unix exosystem was meant to be deeply collaborative ecosystem for programs. Meaning each program doing one thing and communicating with each other through various IPC mechanisms. Atomic systems with containers broke that.
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.
otabdeveloper4 16 hours ago [-]
[dead]
garn810 16 hours ago [-]
Ah, yearly I hate/love nix post..
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)
Brian_K_White 13 hours ago [-]
You imply the discussion is uninteresting, then join it, in the most uninteresting way, merely to declare your team love/hate affiliation.
setheron 15 hours ago [-]
I dunno about all this hullabaloo. I'm at https://nix.vegas/ having fun and using Nix.
Sorry guys, it's my fault. Every time I try to get into nix, there's a new community meltdown. I just installed NixOS yesterday ...
Eueudhsbsj32 16 hours ago [-]
Hopefully a new governance structure will emerge and allow for a better path forward.
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.
lrvick 17 hours ago [-]
You can define an immutable, deterministic, and bootable system image for anything from an enclave to a laptop with just the primitives provided by the OCI Containerfile standard.
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.
yjftsjthsd-h 14 hours ago [-]
What is the stagex story for managing a "normal" laptop? Is there a tool that converts an OCI image to a ... rootfs partition? Or such?
lrvick 3 hours ago [-]
there are several distros built using stagex to get a disk image like airgapos. Just a containerfile a user writes at the last mile.
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.
alberth 14 hours ago [-]
Just to confirm my understanding, is the following corrects?
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.”
Because aren’t these two very different things.
yjftsjthsd-h 14 hours ago [-]
Different angles, same problem. Nix should deterministically take the same pinned inputs and produce the same output, which is also a solution to "Prove that every binary in this system came from the source code I think it did." (since that source code is one of the inputs that's pinned)
lrvick 13 hours ago [-]
Both statements are valid for StageX
nextaccountic 11 hours ago [-]
How to define the list of installed packages in a config file in StageX, and tell the system that it should be the new list of packages? Like done in nixos
If I remove a package from the list itt best uninstalled, if I add it gets installed, etc
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
alberth 4 hours ago [-]
Agreed, with NixOs - not only can you declare which packages to include, you can declare how those packages are setup.
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.
lrvick 3 hours ago [-]
Thats just all stuff one puts in a containerfile that generates their disk image. We can build any disk image nix can though with different syntax.
8 hours ago [-]
Larrikin 19 hours ago [-]
Nix sounded great, but actually trying to use it for personal use felt like a constant time sink. LLMs made it seem like their bespoke language could be side stepped and one could get all the benefits of the ideas without the time sink. But now they have drama, so I hope someone runs with the idea but for humans and possibly LLMs.
jbstack 12 hours ago [-]
The time sink thing is a trade off. You spend more time up front configuring some aspect of your system. But then you generally don't have to ever think about it again, until your needs change. For example:
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
Alien1Being 15 hours ago [-]
Sounds like our decision to avoid Nix was wise in retrospect...
QwenGlazer9000 19 hours ago [-]
Honestly after seeing the last election results I knew bad things were coming. The worst of the drama instigators managed to get elected.
anglesideangle 19 hours ago [-]
The post has nothing to do with the election drama you cite:
> 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.
QwenGlazer9000 19 hours ago [-]
I did. And half the post was them talking shit about the SC. Maybe you should read the post?
ishanz 19 hours ago [-]
[dead]
talentedcoin 19 hours ago [-]
Why is the Nix community such a dumpster fire?
tkel 18 hours ago [-]
If you've been part of an organization or a community that has undergone a big conflict or a schism, you'd understand. Plus this community largely communicates exclusively over text, which doesn't really work well for community repair. It's difficult to get people to feel OK with each other, or spend time together not arguing, when they only ever write intense letters to each other. Plus social work with technical people that spend most of their lives looking at a computer, not interacting with people face-to-face, does not exactly lend itself to socio-emotional maturity. Seems like in the case of Nix, the more mature people have repeatedly gotten burned out trying to tend to the mess and create a healthy community. It's extremely difficult to get someone to be humble, listen, reflect, and grow, when they are already upset and have their defenses up. And without our normal human tools or other trusted peers to help, like we can call on in real life, it can sometimes be near impossible.
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)
tkel 17 hours ago [-]
Technical people (or people with bad social skills) also love to inadequately and incorrectly try and turn the complexity of social organization into simple laws and rules. This kind of reduction doesn't really do people a service, and is also a bit arrogant and simple-minded. It would be much more interesting to name this as a tendency, and try to describe when and how it might occur, how the structure of the org might influence it, etc. Decontextualized takes projected onto everything like this are kind of misapplied and meaningless.
jbstack 11 hours ago [-]
Aren't you guilty of the same thing by generalising that "technical people <love> simple laws and rules"? Also, calling people arrogant and simple-minded is a great example of behaviour that makes it difficult to hold a community together. We can have discussions without having to resort to insults.
thinking_cactus 16 hours ago [-]
I know that it isn't always (heh) used as literally always and necessarily, but really there are no laws or always with human behavior. It's extremely dynamic and reactive. No organization will always do anything of such sort. I also like the word tendency.
nylonstrung 16 hours ago [-]
I mean this is one case where the "law" is arguably true
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
jitl 18 hours ago [-]
what was the Nix schism? Did something like systemd happen? or like, Determinate/commercial vs Not? Or more like USA culture wars / code-of-conduct flamers (i vaguely recall some drama around a conference sponsor)?
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.
jolux 17 hours ago [-]
The creator of Nix soft-forked it and started a company, that sort of inevitably leads to bad vibes I think
talentedcoin 17 hours ago [-]
Can’t say I blame him, given the tone of some of the convos on the discourse site.
pasc1878 12 hours ago [-]
The fork occured before most of the drama.
__MatrixMan__ 6 hours ago [-]
Technology creates cliques. Some of them formed for good reasons, others maybe not.
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.
nylonstrung 16 hours ago [-]
The most obvious cause was forcing BDFL and creator Eelco to step down
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
This was such a sad period, and I'm still sad at how you were treated. I hope in cooler times that the lifetime ban is lifted.
jonringer117 5 hours ago [-]
That would require assumption of good faith from all participants.
This resignation post reinforces the view that there is little good faith assumptions amongst the broader Nix ecosystem.
vehemenz 6 hours ago [-]
Whatever the legitimate issues were, the letter undermines its own credibility with its overbearing and self-righteous tone. Aside from Determinate Systems and the Anduril bit, the complaints lack specificity. The Blueskyisms thrown around here are just as indicative of "cultural problems" as anything else, assuming these views are representative of the community.
trentnix 8 hours ago [-]
It's a combination of Pournelle's Iron Law of Bureaucracy and the emergence of WokeWare over the past decade.
For too many, building and celebrating things just because they are cool isn't enough.
domenkozar 19 hours ago [-]
Because people who do good work get attacked left and right and noone steps up.
Avicebron 19 hours ago [-]
[flagged]
18 hours ago [-]
internetguy 19 hours ago [-]
will nixpkgs still get updates? how will maintenance work (i am not familiar at all with the nix ecosystem so maybe this is a dumb q)
anglesideangle 19 hours ago [-]
Maintenance and updates will continue as usual. The maintainers formerly on the nixpkgs core team aren't even stopping their individual contributions.
threethirtytwo 19 hours ago [-]
[flagged]
andersonpico 16 hours ago [-]
All the posts about nix always go something like:
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?
elliotec 16 hours ago [-]
You're not helping though. If you want that to be different, focus on different things rather than bringing attention to what you're complaining about.
andersonpico 14 hours ago [-]
Why though?
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.
SpecialistK 13 hours ago [-]
There's an old adage, but without being in the Nix scene I don't know how applicable it is:
"If everywhere you go smells like dog poo, look at your own shoes."
vasco 18 hours ago [-]
Even just reading this has more bureaucracy than at a company with hundreds of people. Holy hell some projects turned open source into committees and committees to decide what committees are needed.
jonringer117 16 hours ago [-]
Nix ran for many years with very little to no structure. This worked fine as long as the community has some cohesion around it being a FOSS project. But political divisiveness happened around 2021 and crept into the community. You're still seeing the fallout of https://github.com/NixOS/rfcs/pull/98
darkwater 14 hours ago [-]
So, looks like that being a good manager and serving it is no that easy for a good engineer in the end.
(I'm not snarking at Nixpkgs core team, just at the many HN readers there that hate engineering managers in general just because they had some bad experience personally)
shevy-java 13 hours ago [-]
Let's not sugarcoat it too much: NixOS is dying.
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.
xarwex 12 hours ago [-]
I doubt this ecosystem is dying, I am pretty sure it has reached the critical mass of software where enough things depend on it that if it is to die out it needs to be replaced by something way better. Some technology is here to stay for better or for worse (Java won't die no matter how hard I'd want it to).
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.
Alien1Being 14 hours ago [-]
[dead]
imadierich 11 hours ago [-]
[dead]
iwontberude 19 hours ago [-]
[dead]
zb3 19 hours ago [-]
[flagged]
periodjet 19 hours ago [-]
[flagged]
tomhow 14 hours ago [-]
We've banned this account for repeatedly posting unsubstantive and inflammatory comments like this. The guidelines require us to be kind, to avoid flamebait, and to comment without sneering/snark among other things. If you don't want to be banned, you can email us at hn@ycombinator.com and commit to observing the guidelines in future. https://news.ycombinator.com/newsguidelines.html
tonnikiki 10 hours ago [-]
[flagged]
icase 14 hours ago [-]
lol i can’t wait to hear the lunduke show about this one
greenhat76 3 hours ago [-]
Lunduke still has an audience? Lol dude is a washed up loser.
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.
https://github.com/nixpkgs-architecture
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 won't believe that until Netcraft confirms it.
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...
This was the elected steering committee doing its job, and a sign of growing health.
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.
> 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.
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.
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.
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.
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.
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.
[1] https://bou.ke/blog/nixos-containers/
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.
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 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.
It's like saying obese people are not attractive. It's just obviously true, but no one likes to talk about it and many people (who are obese or aren't) don't want to hear it.
When you say this: "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."
The godawful truth is, Nix fails at the task above. It sucks at it and does a bad job at it because it's so freaking complex. Plenty of people in denial about this but they just can't stare at the sun. They build their complex convoluted solutions and convince themselves Nix was the way while blindly looking away from the pitfalls.
One commenter literally was talking about how his company adopted nix and how they suddenly backpedalled on nix and he COULD not understand why. If you are one of those people who cannot for the life of you understand I am here to tell you that why a company back pedals on nix is as obvious as the sun. You just can't stare at the sun or you don't understand humans.
bad analogy. It can be very painful to accept the truth, but doing so is always a good thing. Staring directly into the sun can cause permanent damage to your eyes -- not a good thing.
Almost everyone believes in religions. The world lies to themselves on an unprecedented scale. If accepting the truth had an evolutionary benefit then most of the world would not be so delusional. Delusion dominates the population because lying to oneself conveys a survival benefit such that natural selection selects for this trait.
https://youtu.be/KCpxYa5N-OI?is=DahsnZ1_uCzh4Eq0
This short infographic illustrates and proves it. But you know what else proves it? Me getting voted down as I throw the truth down in front of everyone’s faces. I’m a target for selection.
Maybe nix will one day be a tool that’s actually good. It has elements of it but complexity and usability hinder adoption. So overall nix is just shit imo. It’s shit wrapped in a dream, a dream of an ideal way to do things. How do we make that dream a reality?
By lying to ourselves. By claiming nix is already there and that other people can’t see the light such that over the years after enough improvements nix becomes an actual good tool because enough delusional people pushed the dream far enough that it actually happened. But in order to do that… people like me must be culled from the herd.
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. ;-)
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.
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
2: https://github.com/zhaofengli/attic
3: https://github.com/NixOS/hydra
https://vimeo.com/767139940
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:
And if you were hacking on the "base" repo itself, it was very easy to pass flags like --override-input base=ros-base#some-ref or path/to/local for quick iteration.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.
There could be similar issues with NSS but I think more people are ready to bypass NSS altogether.
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.)
Perhaps it is no surprise the earlier adopters were people with rigid views.
DOS was built in a basement. Pretty sure suit and tie wasn't the dejour whilst they were doing it.
Linux was a hobby project. Pretty sure that slacks featured more than a blazer.
I would absolutely not expect a business profile image, regardless of the message. Nor do I get why you think it is so essential.
Half the red team industry are furries. Would you criticise them for not using a mugshot? Because a lot of them don't, whilst posting CVEs that affect half the world.
It's totally wild that you think the only alternative to anime furries are suits and ties.
Just what kind of fucked up environment did your workplace have with such a policy?
:-)
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.
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.
It's Nix on the inside but the language is Guile Scheme instead of Nix.
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.
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)
https://imgflip.com/i/aye90c
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.
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.
If I remove a package from the list itt best uninstalled, if I add it gets installed, etc
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
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.
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.
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.
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.
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...
https://www.youtube.com/watch?v=gp0FI8Gw1iA
This resignation post reinforces the view that there is little good faith assumptions amongst the broader Nix ecosystem.
For too many, building and celebrating things just because they are cool isn't enough.
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."
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.