Live data from Hacker News

I think it's time to give Nix a chance

maych.in

131–140 of 156 posts

Re: I think it's time to give Nix a chance

#131

My recent experience being tech support for family and trying to make available some sort of digitized preservation of family photos/history, has been impressing upon me the need to get away from Rube Goldberg systems that only I could possibly understand and modify. My primary filesystem being ZFS already makes having my stuff be accessible to others after my death a bit unrealistic. (Part of my strategy, will be ph…

The nix language is fundamentally at odds with general purpose usability. I have contributed or tried to contribute to many distributions (heck, I even worked for a commercial Linux distribution when I was young) and contributing to nixpkgs was an order of magnitude easier than other distributions. Part of it was the GitHub/PR-centered workflow, but the other part is that Nix is a small functional language and the pa…

I want to second this experience. I've never actually submitted my contributions upstream for other distros, but I've maintained repositories for personal use for Ubuntu, openSUSE, Arch, Gentoo, CentOS and Fedora.

Writing a new package from scratch based on Nixpkgs is far easier than for other distros, and easy packaging tasks are much easier with Nixpkgs than with other distributions.

(It's also much easier to distribute packages without standing up new infrastructure with Nix, since it's source-based and will fall back to source-based builds if you have no established mechanism for distributing binaries.)

Re: I think it's time to give Nix a chance

#132

Something I have always wondered about is how Nix interacts with my editor and language servers. I use emacs. The emacs LSP mode starts up a language server process for a language like Python or Go. If I use Nix to manage development dependencies like my compiler, linting tools, and even language-specific dependencies, then how do I get the LSP and emacs to use the correct Nix-y set of dependencies? To make things ex…

I use the envrc package to integrate my Nix-powered development environments via direnv: https://github.com/purcell/envrc

My Emacs then sets up an LSP per project, and just picks up the correct LSP implementation by PATH.

No per-project Emacs madness. (Though I guess you could do that if you wanted by including copies of Emacs with all the appropriate packages in your development environments.)

Re: I think it's time to give Nix a chance

#133

Something I have always wondered about is how Nix interacts with my editor and language servers. I use emacs. The emacs LSP mode starts up a language server process for a language like Python or Go. If I use Nix to manage development dependencies like my compiler, linting tools, and even language-specific dependencies, then how do I get the LSP and emacs to use the correct Nix-y set of dependencies? To make things ex…

I have never tried Nix, but read about it a lot, and I agree that this part is most of the time completely glossed over in tutorials. I get that nix-shell is cool, and I can get the shell with everything configured to run, let's say, Python with specific deps, very easily - but... then what? Can I run, let's say, IDEA or vscode from there and get all the PATH stuff right? Or does it require extra magic? Not everyone…

> Can I run, let's say, IDEA or vscode from there and get all the PATH stuff right?

Yes.

But if you use an editor for many projects at once, it'll work better if different projects can have different PATHs set, in which case you can use direnv + an appropriate direnv plugin for your editor. That way you don't have to worry about launching your editor from inside nix-shell or whatever.

IIRC IDEA is still defective in this way, not allowing per-project environment variables, but Emacs, Vim/Neovim, and VSCode all handle this nicely.

Re: I think it's time to give Nix a chance

#134
post #43

Earlier quoted context omitted.

FYI by calling it "job security" you imply that this nix caching approach is unmaintainable.

It's implied because it's true. Throw away the content-adressable cache index and you're back to 2 hour development velocity, so the Nix guy probably gave himself a decade and a half of runway for a workload that mostly amounts to periodically running `nix flake update` and shuffling around version hashes. We already saw this same trend happen where "the CMake guy" or "the Xcode guy" gets wheeled in to solve their do…

In truth, the "job security" thing is often as much a matter of personality as it is explicit strategy. The "XYZ guy" often becomes that person simply by being someone who is stubborn enough to tackle integration problems most people would rather avoid, and by being willing to deeply embrace "RTFM".

To say they've established "job security" can sometimes seem like a cynical read on their roles, but I think it's always good for teams to have a few devs with this sort of personality.

Re: I think it's time to give Nix a chance

#135

Earlier quoted context omitted.

Yeah I think this is a big flaw of declarative systems. I see a Nix derivation that contains `foo: bar`. How do I know what this does? It's pretty much impossible to know without learning all of Nix, because anything can access it. If it was a function call you could just go-to-definition. Environment variables have a similar issue. It's often hard to know what they do because they could be used by basically anything…

I find this to be a real issue with environment variables. I am trying to create a tool to help see exactly where and by which program any environment variable was set/exported since boot. This is still in the conceptual phase but I'm looking into linux' ftrace to achieve this. Any ideas or pointers are welcome.

Yeah I think you can definitely find which process sets environment variables (I think you just need to intercept execve or whatever). The real problem is finding which processes use the environment variables. That's extremely difficult, if not impossible.

Re: I think it's time to give Nix a chance

#136
post #52

Earlier quoted context omitted.

Mainly the mindshare. Nix has a massive set of packages. You’ll have to build more derivations for guix.

Guix already has as many packages as Nixpkgs did back when I started using it, and like Nixpkgs, the package set is growing exponentially. What you say is true but it also seems to me like for many, Guix already provides a very useful starting point.

I hope you’re right. I love nix and NixOS, but I really don’t enjoy the nix language. A lisp would be so much more pleasant.

Re: I think it's time to give Nix a chance

#137
post #88

Earlier quoted context omitted.

[flagged]

Do you have some concrete evidence that the Nix project has made bad decisions because it gets money from the EU? I mean, it's not as if other projects, open source or otherwise, funded by companies or lots of random individuals' donations or governments or no one at all, don't make bad decisions all the time. And the specific complaints you make -- "it has bad UX and bad documentation", "when money's available, most…

> Do you have some concrete evidence that the Nix project has made bad decisions because it gets money from the EU?

As if governance meltdowns and bureaucratic capture announce themselves with flashing lights and notarized confessions? The evidence lies in the patterns, the incentives, the quiet substitutions of purpose.

Take the Foundation's bylaws. They are a masterclass in ambiguity. Article 2.1's lofty mission to "develop, propagate, and promote" is conveniently elastic, stretching to accommodate whatever grant-funded side quest Brussels dreams up next. The board's unchecked authority (Article 15.1's "in all cases not provided for, the board decides") is a blank check for mission drift. And why wouldn't it drift? When your funding depends on pleasing the EU's "Next Generation Internet" bureaucrats, "supporting open-source projects" morphs into herding grantees into Nix's ecosystem whether their code belongs there or not. The NLnet grants aren't altruism; they're a colonization program dressed as philanthropy.

Then there's the governance vacuum. The Foundation's refusal to define its relationship to the very projects it claims to steward. Is Nixpkgs independent? A "workgroup" under Article 11? The silence is deafening. This isn't oversight; it's strategic opacity. When maintainers resign en masse, protesting Foundation overreach, the board's response isn't clarity. It's the sound of crickets. Meanwhile, the Summer of Nix churns out metric tons of low-quality packages (1200+ and counting!) because grantors measure success in volume, not maintainability. The result? A dependency graveyard where "supported" projects go to die, abandoned the second the funding cycle ends.

As for the money trail: follow the jobs. The "volunteers" touted in press releases aren't the ones landing paid gigs writing grant proposals or "mentoring" NLnet's captive projects. Those roles go to the usual suspects, the insiders who've turned grant-chasing into a career. The Foundation's financial disclosures (if they exist) won't show a line item for "compromised priorities," but the pattern's clear: when salaries depend on EU grants, the roadmap becomes a dance to Brussels' tune. The docs stay broken, the UX stays hostile, but look at all those shiny "tested examples" for the Commission's reports!

The Foundation's Dutch legal structure: a stichting, deliberately designed to be unaccountable. No members, no oversight, just a self-perpetuating board that answers to no one but itself. When the community revolts? Tough luck. The bylaws grant them no leverage, just as the EU grants leave no room for dissent. The real tragedy isn't that NixOS sold its soul; it's that it did so for the pettiest of reasons: the bureaucratic equivalent of pocket change. But hey, at least the metrics look good on paper. Until 2027.

Re: I think it's time to give Nix a chance

#138
post #38

Earlier quoted context omitted.

I think Nix is getting an unfair reputation for being too hard. Simple things are IMHO simpler in Nix than in any other distribution, and what one needs to know to accomplish them is tiny. It has basically reduced my sysadmin maintenance tasks to zero. In case of regressions, Nix makes it trivially easy to go back in time 2 or 3 years, cherrypick some packages and install them, or change your entire desktop environme…

I've been using Nix and NixOS since 2022. I can't imagine not using Nix at this point and agree that the reputation for "being too hard" is not quite accurate. Nix is different - that's the point. The learning curve is a thing, although I'd argue that it's nowhere near as steep as the tools many of us use every day (C++, Rust, AWS/GCP, etc.) Nix's "difficulty" IMO comes from defaults that are not sane and a split com…

I like your Atoms idea and will follow along

IMO 80% of Nix's shortcomings are due to 20 years worth of tech debt that we're all very conscious of

By 2030 all the rust rewrites and new tooling will have finally saved us from it

Re: I think it's time to give Nix a chance

#139
post #38

Earlier quoted context omitted.

I think Nix is getting an unfair reputation for being too hard. Simple things are IMHO simpler in Nix than in any other distribution, and what one needs to know to accomplish them is tiny. It has basically reduced my sysadmin maintenance tasks to zero. In case of regressions, Nix makes it trivially easy to go back in time 2 or 3 years, cherrypick some packages and install them, or change your entire desktop environme…

I think the reputation is fair. Why is flakes still experimental, for example? That's a subtle bit of encouragement to do things the old way and as a result, documentation is always mixed and you end up "but how do I do that in a flake". Something that is in theory nice is using the same packages in development and production. But "everyone" uses Mac OS for development and Linux for production, and if you want to gua…

Hopefully Nix and Bazel can learn to play nice. There have been 5 talks on this in the last year alone, so I think many others are in your same boat

https://youtu.be/2wI5J8XYxM8?si=HS0YKewPz-Mmhptn

https://youtu.be/6xWr8f2RhX0?si=sNjkJ-rwLfTI97AP

https://youtu.be/FoSCSQO5xhI?si=pHmZJjKS-mX87iyn

https://youtu.be/6qOoOsjmyZ0?si=sVppXxb1E3ml7TBk

https://youtu.be/s801fgQOGnw?si=E--1aVJyUDjjOFWW

Re: I think it's time to give Nix a chance

#140

This article felt like a strong argument against Nix rather than in favor of it. The complexity it brings is just not worth the gains for the majority of people that I know. No, most people won't be happy that Nix breaks dynamic linking. Docker with a Debian Stable base will solve the problems listed for most users, with 1% of the time investment. The author used Nix for 8 years, and I'm not surprised it looks a bit…

> No, most people won't be happy that Nix breaks dynamic linking. True. In my case I just enabled nix-ld[0,1] and now everything works flawlessly. [0]: https://github.com/nix-community/nix-ld [1]: https://wiki.nixos.org/wiki/Nix-ld

This is one area where Nix needs a sane default

I wish Nix-ld was just bundled into Nix

Post reply on HN