Live data from Hacker News

I think it's time to give Nix a chance

maych.in

81–90 of 156 posts

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

#81
post #43

Earlier quoted context omitted.

My last gig was at a place where a guy basically wrote his own job security by reducing a 1hr 40min JS build pipeline down to 2 minutes with Nix caching.

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 domain-specific issue in large enough orgs. I was impressed by this guy's initiative to carve out an equally indispensable niche.

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

#82

What problem(s) does Nix solve that macOS's .app format does not? For that matter, that ad-hoc Linux packaging solutions involving LD_LIBRARY_PATH and included dependencies? Put differently, doesn't the fundamental complexity of Nix come down to the combination of (a) "every app should get its own dependencies" and (b) "don't include dependencies with each app" ?

Building those applications consistently and reliably, e.g. being able to hop on a random Linux box and be able to build and deploy an application without thinking about where to fetch copies of all the dependencies. Nix’s raison d’etre is really to make developer lives easier, IMO.

I don’t use Nix, but I’ve played with other Linux package managers enough to understand the desire for something better, and something that’s actually predictable, especially (emphasis here!) when mixing/matching arbitrary versions of dependencies. I used Gentoo/Gentoo-derivates for several years and it (building random packages with == specific versions) is a sticky problem when using a traditional build system.

Of course, once the packages are built then you can do whatever hacks to bundle the dependencies with it. But the hard part is building them in a consistent, “reproducible” way.

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

#83
post #14

I was so excited to give Nix a chance, but I'd prefer to program in Guile rather than Nix, so now I'm excited to give Guix a chance lol. Going to install it this Wednesday on new laptop, wish me luck

Better check to make sure your laptop's hardware, particularly WiFi, is compatible. Most aren't.

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

#84

What is the supply chain security story with Nix packages? I stick mostly to reasonably popular Debian packages. My thinking is that if one of them has a serious vulnerability it will get fixed quickly or a lot of people have much bigger problems than me. I always worry about niche package systems, where it should be much easier to sneak in something malicious and it could linger there for a long time undetected.

The source code is retrieved from the official source of the package, and checked against a hash that is stored in the package definitions. All the package definitions are stored in a large github repository, and they are "code reviewed". For example, you can see where the xz sources get pulled from in the src section here: https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/tools... As usual, wherever you get you…

> All the package definitions [...] are "code reviewed". [...] with maybe some reviewed patches to get it to work in Nix's environment.

In order for people to review Nix package definitions and patches, do they need to have their keys signed by other Nix contributors they meet in person like Debian contributors do?

https://www.debian.org/events/keysigning

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

#85

I recently installed NixOS on my laptop after years of using Debian, and the main difference I noticed was that it's much easier to keep everything clean. For example with Debian I might do something like try to get my GPU to work by installing nouveau, try various configs, then uninstall nouveau and install the Nvidia proprietary drivers. But then when I finally got the GPU working, I'd worry. Are some of those conf…

I don’t know. My concept for reproducibility with Debian is a backup of /etc and the list of installed packages (the output of `dpkg --get-selections`). It’s also not difficult to diff one’s /etc with a pristine version, though I haven’t actually needed that in many years.

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

#86

Wow. 1) you can python environment with dependencies! (can do that without nix) 2) you can pin dependencies by hash! (can be done with any tool mentioned in article: docker, pip, npm etc) If you can't make reproducible dev environment in 2025 - it is 100% skill issue.

For 1), how? I'm specifically interested in how you handle packages that use C extensions that link system libraries.

In such cases I use either docker or mmdebstrap.

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

#87
post #71
post #61

Earlier quoted context omitted.

Arista, D.E. Shaw, Google are boring big corp Several of those companies (replit) are building their business on nix. With nix, even containers are optional.

From those I only know Google and replit, which is still kind of unicorn, and most businesses will never be 1% of Google size.

The others are big, trust me.

My point was that some businesses are tying their destiny to nix - in my experience this is a sign that an open-source project will gain corporate benefactors keeping it afloat + making it safer for others to adopt.

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

#88
post #39

Earlier quoted context omitted.

Are you suggesting some connection between "most European" and "some areas of concern", and if so what? Or are you just making two completely independent statements? I'm guessing from past comments of yours that it's the former. But if there's an actual connection, it's very not-obvious to me what it is, and a quick look at the "problems" and "crisis" links you gave doesn't suggest to me any connection with Nix's Eur…

[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 of it goes to people who have been involved in the project for ages", etc. -- are ... not exactly unusual in the world of open-source software.

Consider two hypothetical worlds. In one, the Nix project has been corrupted by taking money from the EU, just as you say it has. In the other, the Nix project's flaws are just those of a typical open-source software project, and you're imagining it's caused by the project's taking funds from the EU because you really hate the EU. How could I distinguish between those two worlds?

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

#89

Earlier quoted context omitted.

Welcome to the honeymoon phase. Mine lasted about a year. Eventually you will have to leave the comfortable area of "those who have done it before" and engage with some long, unwieldy, mostly undecipherable stack trace. When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.

Been there. Powered through it. It gets easier when you actually read the Nix manual.

Been there. Powered through it. Read the manuals. Stuck to it for a year before asking why I was behaving like a masochist.

Now I use Debian and LXC and docker.

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

#90
> These hashes are computed using SHA-256

Not so fast! The hash story is actually much more complex than that, as this recent article showed: https://bernsteinbear.com/blog/nix-by-hand/

Regardless, the hash function is irrelevant to end-users, I just thought it was interesting that they cooked up such a convoluted scheme.

Post reply on HN