Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I think it's time to give Nix a chance

maych.in

Post reply on HN
Print view View original

111–120 of 156 posts

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

#111

Post by PaulDavisThe1st »

__MatrixMan__ wrote: post #101
PaulDavisThe1st wrote: post #92

Earlier quoted context omitted.

"build and deploy" are two entirely different tasks. Both the macOS .app design, and various ad-hoc Linux packaging strategies deal with the deployment step in a relatively trivial, extremely non-invasive way. The build step is something else entirely, and while I can imagine that for some projects what Nix offers has much value, for others the problem is solved by a permanently deployed build stack (or stacks) whose…

I think you're right that it's the build step where nix provides value. It's about replacing: > a permanently deployed build stack (or stacks) with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme. But if it's trivial to reliably instantiate the build stack, w…

> with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme.

> But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package before you distributed it.

This suggests to me that either you don't know how .app packaging works on macOS (or various ad-hoc packaging on Linux, such as Firefox or Ardour), or you're making a point that I'm missing.

The whole point of these non-Nix systems is precisely that you just package up bits of the build stack into the thing you distribute, and you reduce or eliminate system dependencies other than such basics as the system C library or X11.

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

#112

Post by codethief »

johntash wrote: post #108
codethief wrote: post #99

Ubuntu user of 15 years here (+ a couple years of tinkering with RedHat, Arch & Gentoo before that). I tried to learn Nix (the language) a couple years ago, didn't like it and got nowhere. Now, two months ago I heard I would be getting a Windows machine at my new client, so I really wanted a way to deterministically generate a Linux VM that worked & felt exactly the same as my usual setup. So I thought back to Nix(OS…

Are you using NixOS, or are you using Nix + home-manager or something like that to manage your user's stuff?

Just NixOS. When building the VM / live CD I copy my dotfiles into the Nix store and then during first boot-up I copy them into my home dir and set up symlinks.

The main reason I decided against home-manager was that it makes my simple symlink setup (~/.foo -> ~/.dotfiles/foo) virtually impossible: Symlinks will always point to the read-only Nix store in one way or another. See https://github.com/nix-community/home-manager/issues/3514 or one of the countless other tickets on the topic. Through this episode I also learned that home-manager isn't exactly well-documented, either, and also quite opinionated. (Which, to be fair, is not a bad thing – if it works for you, it probably works great.)

Finally, not using home-manager was also a risk management decision in that it's probably best to not go all-in on Nix, NixOS, home-manager etc. all at once. Start with the simplest possible config that gets you running, then iterate.

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

#113

Post by __MatrixMan__ »

PaulDavisThe1st wrote: post #111
__MatrixMan__ wrote: post #101

Earlier quoted context omitted.

I think you're right that it's the build step where nix provides value. It's about replacing: > a permanently deployed build stack (or stacks) with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme. But if it's trivial to reliably instantiate the build stack, w…

> with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme. > But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package be…

I had misunderstood what a .app package was, thanks for clarifying. So do people package things like linters and language servers into the .app also? Like, is it everything I'd need to work on the app, or is just everything I'd need to run the app?

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

#114

Post by PaulDavisThe1st »

__MatrixMan__ wrote: post #113
PaulDavisThe1st wrote: post #111

Earlier quoted context omitted.

> with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme. > But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package be…

I had misunderstood what a .app package was, thanks for clarifying. So do people package things like linters and language servers into the .app also? Like, is it everything I'd need to work on the app, or is just everything I'd need to run the app?

Everything needed to run the application.

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

#115

Post by davidcox143 »

codethief wrote: post #103
davidcox143 wrote: post #77

Earlier quoted context omitted.

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…

Do you have a link that explains what atoms are? This is the first time I'm hearing about them.

Sort of. There’s a summary by the author of atoms in the Twitter thread linked above.

They also link this very lengthy blog post:

https://nrd.sh/blog/atom-anatomy/

My understanding of atoms compared to flakes is that they 1) add toml 2) provide a more precise way to reference remote src.

The author also claims performance benefits. I haven’t used them personally and can’t speak to their stability or ergonomics.

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

#117

Post by microtonal »

packetlost wrote: post #73
sepositus wrote: post #21

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.

Nix Pills are probably the best way to get a deep understanding of Nix and some underpinnings of nixpkgs. I read the pills when I started using Nix in 2018 and never had much difficulty understanding the language or most of nixpkgs.

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

#118

Post by corndoge »

Tractor8626 wrote: post #86
corndoge wrote: post #76

Earlier quoted context omitted.

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.

Nix would work too, and that fact touches on one of the main advantages of Nix - it solves the problem at a low enough level that it works in all cases.

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

#119

Post by swoorup »

Nix is great but the user interface is ugly and cryptic. Debugging dependency issues (what depends on this package of particular hash), installing a particular version of a package is just more trouble than something you would get from the likes of npm or cargo.

Would I use nix for my servers? Yes. Would I also use nix personally to keep my systems in sync? Yes. Will I recommend nix to others? Absolutely not.

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

#120

Post by microtonal »

Modified3019 wrote: post #93

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 package definitions are not in some arcane weird format like RPM spec files or Debian rules. Also, Nix makes it much easier to refine a derivation/package without actually having to install it on your system.

Post reply on HN