I've been critical of Nix for a variety of reasons along the way but one of those reasons is how so many people (and consultancies) seem hell-bent to set up their own little fiefdoms within the community.
The community is already niche, we certainly didn't need people purposely driving further fragmentation and incompatibility with these frameworks with bad bus factor and NIH designs.
I've seen a lot of tribalism and cargo culting around some of the other efforts in this vein, too.
Unfortunately, he's also part of the mob that chased the founder out of the Nix project and decided it should be yet another battleground for identity politics.
Like you, seeing the community entertain these stupid political fiefdoms makes me want nothing to do with NixOS.
However, I might stick with it out of laziness though until SteamOS runs on 3rd party hardware. The Jovian project is a Nix-based SteamOS clone that's been working well on my Legion Go, and I don't want to spend the time back in tinkerland finding something to replace it.
I resented people building fiefdoms because they're often commercially motivated and used to drive consulting engagements. They fragment the community on a deeply technical level, ruining code reuse and interoperability, for negligible technical improvements. I don't have any idea what the authors' views on project governance or human rights are, that wasn't a factor for me.
Just let people do their thing. You’re not a bad person if you have nothing wise to say about people being hurt, and lots to say about resolving dependency constraints.
> fragment the community on a deeply technical level, ruining code reuse and interoperability
Most Nix consultancies I encounter make highly reusable flakes. flake-parts, flake-utils, fenix. They have a small commercial spot in their package’s namespace, and the first reason you look them up is “I wonder if they’re doing other smart Nix things that I can copy”, and they usually do.
> might be a poor leader in that situation
FUD.
https://discourse.nixos.org/t/nixos-foundation-board-giving-...
> While the foundation board was never intended to lead the community, we cannot deny that it is perceived to be in that role by many, and we therefore take full accountability. [...] Eelco is the principal author of Nix and undoubtedly a central figure in the ecosystem that grew around it. We confirm that Eelco showed no intention to be perceived as or act like the BDFL of the Nix ecosystem, or the Nix code base. *To commit to that in a timely manner, he has decided to formally step down from the board. This decision was made amicably and in mutual agreement with the board that this is the right thing to do.* Our collaboration was always characterised by our deep respect for Eelco’s work and our awareness of his lasting impact on our lives.
That said, as a complete outsider, the quote "the foundation board was never intended to lead the community" is wild to me. It sounds like the director of NASA going "I never intended this role to have anything to do with space". I think I understand the meaning behind the sentence - they wanted to support the community, but that the community leads itself in some way - but I can also see why the community would see them as having that leadership role that they apparently wanted to avoid. I also don't understand why someone who wanted a purely technical role would ever be on that board in the first place.
Like I said, I'm not really following this debacle, and I don't know the details. I'm just amazed at that quote, which seems very revealing to me.
Presumably you reject everything supported by money from DARPA?
Yet you can be on the internet and make things a bit better by rejecting military sponsorship/influence in things you're involved in today.
Sponsorships are generally acknowledged with quid-pro-quo advertising opportunities - otherwise they'd be called silent donations.
In the case of tech conferences like the inciting incident, that means your logo everywhere, maybe an ad spot in between talks, and booth space. You might get some intangible reputational benefits from whatever other sponsors are present if they are viewed as highly prestigious or respected. Might even have opportunities to do a talk by one of your employees, we've all been to conferences where a vendor conspicuously also has a talk that coincidentally features their products heavily. All in all, it can elevate your perceived legitimacy in various ways.
Advertising might get you more business or more applicants and thereby grow your reach and success.
In terms of my personal values I'm a pacifist. I don't want to see something I like(d), something I made modest code contributions to, used to advertise for a commercial military organization that manufactures equipment for violence. It's the same way a vegan probably doesn't want to see advertisements by the beef farming industry or that someone who cares about renewable energy and sustainability doesn't want to see sponsorship by someone whose holdings are a huge stake in coal mining and fossil-fuel power plants.
In the case of the inciting incident, it wasn't a case of massive dollar amounts, it was ~$5k USD and it wouldn't have jeopardized the conference at all to say no thank you.
I'm more of a pragmatic pacifist myself, which allows or even carefully supports violence for suppressing violence. I believe the USAF is generally speaking aligned with me on that. Which is why I'm not unhappy when they work with FOSS.
I'd like to think that I'm pragmatic as well, which is why I won't deny that NixOS would likely get used in conflict with or without event sponsor deals promoting it. However, if your in-person events pivot from a technically-focused gathering of like-minded individuals to a war council bankrolled by Anduril, I'd expect most attendees to be angry. Especially once you consider that the United States sponsors the export of weapons to countries that don't use violence for justifiable or proportional causes.
The NixOS Conflict in Under 5 Minutes
* it reads like the result of 'there was a power struggle and my side lost'
* it falls back constantly to overly simple cause-and-effect answers to complicated problems
* it clearly is trying to paint certain people as villains and dissecting their imagined motivations while excusing or ignoring the motivations of others
Individual union organisers might also be social activists, but effective union organisers know that they need to a appeal to all employees regardless of their politics. And historically unions have been just as socially unreconstructed as companies, and subject to the same process of social activists pushing for their reform.
One need only look at labor's reaction to the Teamster's president's speech at the RNC to realize that this is clearly not the case.
Do you think an outsider (ie. an impartial person) be able to provide a better summary?
Even as outsider has to get his info somehow, usually by interviewing those involved and then filtering stuff.
> At a properly run company, if you are caught eating someone else's sandwich from the fridge, your boss will confront you and say "hey, Bob, don't eat Ted's sandwiches." That will be the end of it. In an organization with weak leadership, however, the entire company will receive an email from HR in the afternoon dictating a company-wide seminar on sandwich theft prevention, a #sandwich-theft chatroom will be created, posters depicting sandwich thieves in an encircled red X will appear on the walls, etc. The latter is more akin to what happened in the Nix case I outlined. There was no leadership in place to deal with an isolated sandwich theft, so it now needed to discuss policies with the goal of ending sandwich theft forever and punishing all sandwich thieves globally.
As an outsider, it looks like Nix had a weak leader who refused to mediate differences between people. He didn’t do what was right and just. His problem, and his irresponsibility, became everyone else’s problem and responsibility. A power vacuum but also a moral vacuum.
As someone who closely observed all of this over the months, I can confirm that this was exactly the root cause of the whole issue. 4 out of 5 of these leaders eventually burnt out and quit.[^1]
The new governance structure, despite the rough start[^2], hopefully will solve that and create an actually caring leadership.
[^1]: https://old.reddit.com/r/NixOS/comments/1dqn9os/4_out_of_5_n...
[^2]: https://shealevy.com/blog/2024/05/08/broken-promises-the-nix...
Rather, I see the problem as character. The chosen leader(s) need the internal, personal qualities necessary for getting volunteers to cooperate well. External structure won't save the project if leaders lack character, it will just slow the damage they can wrought.
Relatedly, I was uncharitable before in emphasizing the weakness of Nix's leader. I think we all lack the moral (apolitical) education necessary for just leadership.
It's unofficial and I've not personally tried it, but isn't that https://github.com/HoloISO/releases ?
I do wish there was some slightly better platform specific documentation though.
The issue is that: Nix/NixOS is here and JUST good enough. So replacing it will be hard. What is come up with has to solve things so much better that the community who has invested in NixOS and others sees enough light that it is worth moving over.
That's gonna be rough. Given how hard nix (the language) is to deal with, I won't call it impossible, but... I will say, the successor is more likely to succeed if NixOS totally implodes, and I might go as far as to say... only if it implodes or offers substantial back compatibility so people can migrate.
In my time I very often had to go read raw source to understand how to properly use some less-trivial constructs.
I have enough of an FP background to find the language tolerable but not yet pleasant, or even particularly capable. It's absolutely a fair thing to not enjoy.
The other major criticism that I think is even more defensible and less subjective is that incremental adoption is not very fun. Many things that are well supported on a mainstream Linux distro will not work OOTB in NixOS until some kind soul contributes the Nix-specific implementation of that thing. In some cases that's not even fundamentally possible. So you run into lots of cases where the first hit on a Google search will solve this thing if you're on Debian, but you're looking at hours of triage to do the same thing on NixOS instead.
I have plenty of examples about things that are uniquely possible with NixOS too, but I don't like to evangelize anymore.
So until you learn to read nix, have a nix LSP etc. It is a major PITA.
You can be reading a .nix file and be like... "What the ... is that?"
And sadly, you know you'll inflict it on some poor person later.
Some of the problems he encounters may be outdated, as Nix and its documentation have both evolved since the start of the series. His experience is also somewhat shaped by his decision to rely solely on the documentation and the software itself for guidance, which he held to for quite a long time-- if you seek help from others earlier on you may get stumped less often. But overall it captures very well what getting to know Nix and its docs is like, including the emotional reactions to sharp edges.
1. The community is extremely polarizing. Not just politically, but even from just being a general contributor. Depending on who reviews your PR, you can have a very pleasant experience to a downright demeaning one. I get that every community isn't perfect, but after years of dealing with generally the same problem people, I just quit contributing.
2. The Nix language itself is relatively simple to grasp, but for one reason or another people tend to build it up into a rat's nest that becomes nigh impossible to reverse engineer. Because of it's laziness, the error messages are generally unhelpful, and debugging is nothing but pure pain.
3. The thing that makes Nix great (reproducibility) is also it's greatest pain point. Depending on your language, your packaging experience may be simple to downright infuriating. At one point I just stopped packaging NodeJS/Typescript applications and resorted to other means (and this, of course, tended to anger the fanatics). Bottom line is that most software wasn't built with Nix's constraints in mind which means it's generally always a battle to get things packaged correctly.
4. The kingdom building has continued to be a major problem. Just watch the Nix Discourse for a week and you'll likely see the same problem space reinvented at least a few times. For whatever reason, in the Nix world, it feels like _everyone_ thinks they can do it better. This becomes a serious problem when it comes time to actually producing things in Nix. In my time using it professionally, I had to change "libraries" dozens of times due to lack of maintenance/abandonment. I swear each programming language must have a dozen different libraries for packaging, each with strange bugs and missing implementations.
I am one of the hopeful that something new and better will come out of Nix, but I have high doubts it will come from the community itself.
Immutability and reproducibility are nice, but not nice enough to put up with the crazy.
God, I feel this. I ended up just stop trying to seek help because most of the time I'd come across the MOST self-righteous people I've ever met.
I don't think Nix will ever be easy to use because half the community genuinely does not care about their fellow human beings enough to write software for their fellow human beings.
This matches my experience as well. I’ve been trying to use nix either as a system package manager, package manager, or OS since 2019. It was first recommended to me in 2016.
I’ve tried to use it for C++, Python, and Flutter development. I’ve tried to use it on MacOS and NixOS.
There doesn’t seem to be any use case where it’s usable for regular people. I can use it, sometimes, but more often than not it breaks and fixing it becomes the project over the project I was trying to use it for, before I have to give up and abandon it for conventional, less aspirational but actually usable tools.
Just the other day it broke because of a MacOS beta update. The suggested fix in a PR to reinstall it didn’t work. The uninstall instructions didn’t work. In the end, after some manual fidgeting and more ad hoc suggestions on PRs plus some informed guesswork on my part having to do with the ca store at various stages, I was able to restore my install to functioning.
Every time I ran the install it was text-based and filled my screen with intermediate commands and asked me whether it should execute some command that nobody but a POSIX skilled person would understand. Even after trying to tell it not to bother me.
The community has seemed obsessed with flakes that will fragment the ecosystem and lock nixpkgs into backwards compatibility (to some practical degree). Meanwhile when I tried to contribute back to nixpkgs, and an update broke my patch (a derivation that made specifying application derivations roughly as easy as homebrew), no one on the forums could tell me how to fix it.
Now it seems like the community, or some fraction of it, is chasing social perfection while their own tool is in such a half-baked state that I can’t recommend it to anybody, and almost nobody technical that I interact with recognizes it.
Meanwhile, in the time that nix has been…doing whatever it’s been doing, docker has become the de facto standard for reproducible environments. It’s hypothetically not as good, but practically it’s a whole lot easier to use, so now nix has to push back an entrenched competitor if it wants to become more than just this weird niche tool that nobody’s heard of.
I guess if the community doesn’t care if people use their work or not, I can’t blame them if they want to spend their free time on theoretical solutions. But it seems more inability to recognize other people’s hardships and arrogance rather than intentional neglect.
Someday I really hope someone figures this out, because having a cross-platform cross-purpose cross-language declarative package manager would be awesome.
EDIT: Also, one thing that’s bothered me about the recent Nix drama has been how they treat their “own” people. What I’ve heard or seen project leadership or moderation doing has come across as capricious, spiteful, and entitled towards people who have invested huge amounts of time into Nix; regardless of the politics of the individuals involved.
It’s turned me off from continuing to invest in Nix either as a contributor or a user (I was even questioning fixing my preexisting install, but I figured deciding on an alternative and switching right then would take more time). I’m hoping an alternative comes to light, or somehow I’ve misjudged the situation.
If you've used a normal linux distro and installed GNOME.. and then decided "That was dumb." and wanted to go back...and realize, you can't. There is no real way to get rid of Gnome sanely. (I can say the same of KDE and other massive packages.)
On Nix, I can, I just remove it from the configuration, and basically reapply my config. No damage done.
For tools I'll want to try out or maybe use 2 times in my life, I can just run them in shells that have them, and not add them.
This all adds up to a much more pleasant experience. I won't say flawless, but... it beats much of what is out there.
I do think people can take it to an extreme which isn't useful. I still have declarative dotfiles, unlike some.
But, for just managing the OS and packages. I've found nothing better. Realize: Things that are clusterfucks to package like python are still clustefucks. But... otherwise... 9/10 would install again, language can take a long walk off a short pier.
Yeah, at this point, any successor would have to be compatible with nixpkgs, which means to embed the nix language in some way.
My best migration experience is the vim->neovim one. It (almost) fully supports vimscript and yet runs Lua side-by-side, paving a great way to the full Lua adoption.
I replaced it by never using it, and just using traditional Linux and traditional configuration management.
Or for every use case where that setup sucks, using the containerization ecosystem of my choice instead.
I personally struggle to figure out where the combination of those tools is failing anyone where Nix comes in and saves the day. All I ever hear about it is that it's a great concept and a great thing ruined by excessive difficulty and too many downsides. In that sense I'd rather stick to the devil I know.
Same for me. We were exploring the use of it across our company for doing the building part of our containers, but the seeping in of identity politics made me rip the whole initiative up, it's simply too risky as you can see very likely paths towards fragmentation and disruption if you use this tech. Such a shame.
"seeping in of treating everyone decently made me rip"
FTFY
I tried using it, but the slow-repos, and weird bugs on my laptop (which needs proprietary blobs) put me off. I very much would prefer using scheme to Nix lang but the eco-system is far smaller.
I wish they had a separate spinoff that just made sure their software can run on Windows and MacOS, something like exists for emacs, but I think that the challenges are pretty big as they appear to rely on Linux-only APIs?
However, I've run into a GUIX person or two who frame it as a technical issue because something like macOS lacks a completely verifiable build chain (i.e., needing to use XCode to bootstrap). This is a factual statement, but not the real reason why support for macos/windows is absent.
You can use Guix on macOS with https://superkamiguru.org/projects/msg.html, but it's probably not what people want when they ask for macOS support.
Unwillingness to compromise, as you might recall from our last conversation on the topic. This is your right, but framing it as a technical problem is incorrect.
> there is no glibc port for macOS
https://formulae.brew.sh/formula/glibc clearly proves otherwise. It just can't be built to your satisfaction with complete verifiability.
> Using XCode for everything
You don't have to use it for everything, that's a straw man. If Guix-darwin was willing to accept some impurity, you could probably use XCode just enough to bootstrap a glibc and compiler chain, and then dispense with it.
Having a completely verifiable toolchain is a laudable political goal, not a technical requirement.
nix-darwin's existence clearly shows there are no technical obstacles to an equivalent guix-darwin.
Believe me, I wanted to like Guix. I'd prefer a Lisp over the nix language, easily. But I'm losing respect for the project based on its messengers.
(If you're referring to "identity of who we're talking to", I can link you to our previous HN conversation, which is pretty similar to this one.)
Humans already have ways to build software on macos, so why bother doing it with something called "Guix" if the thing that we would necessarily --- and for technical reasons --- end up with bears little resemblance to Guix? If someone sees value in that, enough to warrant converting resources to realize this value, they are welcome to do just that.
Note that we also have a way of using Guix as it is on macos via virtualization of Guix System. It also sits atop a large binary blob (the size of the native bits of the qemu closure), just like a macos-native bootstrap of the roots of the Guix graph does.
And yet, the nature of identity is always in flux. You are not made up of the same atoms as when you were an infant. Many lines of code in a software project change, and yet it remains the same, ship-of-Theseus style.
Guix's identity could encompass a guix-darwin side project and still remain guix. You think of it as a technical issue, but it's only your choice of what guix means that entails that view. Which comes right back around to my assertion that no macOS support is fundamentally a political choice of guix's devs, not a technical problem.
> end up with bears little resemblance to Guix
Based on my experience with nix-darwin, this seems like exaggeration, and I think most others would agree.
> Note that we also have a way of using Guix as it is on macos via virtualization of Guix System. It also sits atop a large binary blob (the size of the native bits of the qemu closure), just like a macos-native bootstrap of the roots of the Guix graph does.
You are possibly the only person who is using "binary-blob-at-root" as equivalency criteria. Are you genuinely confused why macOS users aren't just using the Qemu Guix? Part of the appeal of nix/guix on mac is not having to pay the virtualization cost.
If Nix disappeared overnight I'd probably be using chezmoi to fill in somewhat for Home Manager and mise to fill in somewhat for devShells, and some ansible to try to fill the gaps, and fairly bitter about it.
I'm philosophically opposed to containers in the dev feedback loop, as I want native installation and performance for my language toolchains and editor and such.