Live data from Hacker News

Nix – Death by a Thousand Cuts

dgt.is

301–310 of 336 posts

Re: Nix – Death by a Thousand Cuts

#301

Earlier quoted context omitted.

I attended NixconfNA last year as part of SCaLE. I spent quite a while trying to understand what Nix was actually trying to accomplish and how one would actually go about using it. Granted I was trying to do it on a Chromebook, but the idea stands: I should be able to get at least the nix environment set up and the silly gnu hello world built and running, right? Turns out nah. The ergonomics are just that of a hiltle…

Yes, the ergonomics are poor. I endure them for the results, but the ergonomics should be better. Guix has better ergonomics, but it's own set of downsides. I expect the underlying idea of holistic declarative systems is sound, and we're awaiting a polished alternative. Maybe it'll reuse nixpkgs under the hood , but replace the name, the tooling, and the language exposed to the user.

I honestly wish PKGBUILD would get a shout at some point in the world of "Not the worst way to describe a package"

Re: Nix – Death by a Thousand Cuts

#302
Id argure on the desktop its actually easier in some ways. Once you know how to make a configuration.nix and partition a drive its a piece of cake to install a system. Changing an entire DE with one line of code is crazy. Its like going from Windows XP to Windows 11 with a one line change and rebooting.

Re: Nix – Death by a Thousand Cuts

#303
post #280

Earlier quoted context omitted.

>who knows if that'll work ever again Unless you restrict your nix files to specific channel revisions, which when I had to deal with it was poorly documented, and involved searching through specific channel commit hashes in a particularly opaque way, you also can't know that your nix derivations will ever work again. A number of people on my field used nix as a way to make their research code repositories reproducib…

Yeah that's a ux papercut - pre flakes nixpkgs was always the nixpkgs on your machine. There is docs but if you're not expecting that to happen you wouldn't think to look up the docs.

I think expecting everyone to enable a still-experimental feature is more than a papercut.

Re: Nix – Death by a Thousand Cuts

#304

Id argure on the desktop its actually easier in some ways. Once you know how to make a configuration.nix and partition a drive its a piece of cake to install a system. Changing an entire DE with one line of code is crazy. Its like going from Windows XP to Windows 11 with a one line change and rebooting.

Even crazier, changing a line of code and logging out and back in

Re: Nix – Death by a Thousand Cuts

#305
post #95

The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".

Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside…

Nix's core idea is wonderful, but I wish it could be redone from scratch. Why can't we just layer some Flatpaks that have source code in them or something?

But the whole thing seems like it's designed to express more powerful things than you can easily map to an app store style install/uninstall button, rather than solving the problem with the least powerful tools that give the user the highest level interface possible, and leave as much as possible for the computer to figure out.

Re: Nix – Death by a Thousand Cuts

#306

> ZFS on Linux [...] The recommended way to do this is to use LUKS, not native ZFS encryption. FWIW I've been using native zfs encryption on nixos and it works great. It lacks neat features like being TPM-backed or having multiple keys, but if all you need is password-based encryption then I think native ZFS encryption is better since you'll be able to do encrypted zfs send/recv, you'll have granular control over whi…

I’ve also been using ZFS native encryption on my machine. I wouldn’t describe it as flawless- but that’s mainly due to how nixos-unstable works.

There have been several times where the latest “stable” ZFS doesn’t support any of the newest kernels, and the “latest working” kernel goes EOL, and so nixos completely drops it.

And my options every time seem to be

-roll all the way back to latest “LTS” kernel. This sometimes breaks things.

-skip ahead to a beta release of ZFS (this isn’t always an option, and do I really want an unstable file system?)

-just don’t update for like a month and wait for new ZFS to release, supporting a newer kernel.

And there really isn’t a good option here. Theoretically there’s another option where I maybe keep using the EOL kernel version, and update the rest of my system normally, but I haven’t figured out how to configure that. So I just pick whichever option breaks the least amount of things each time. It’s definitely more of a ZFS issue than something NixOS-specific, but it’s annoying when I’m suddenly greeted with “That kernel version is EOL now.” And the update fails. And there is no easy way to ignore that and accept the risk of a slightly-outdated kernel.

Re: Nix – Death by a Thousand Cuts

#307

I'm a NixOS user and contributor. This post is fair. Nix is very flexible, and it hasn't yet stabilised on a firm set of recommendations for a happy path. Going on a whim: * Use nixos-unstable. It's defacto stable, and gets much more attention than nixos-stable. * Use flakes. * Don't use multiple versions of nixpkgs. In the rare case a package is failing to build, then raise an issue, or wait, or rollback. * On NixOS…

I attended NixconfNA last year as part of SCaLE. I spent quite a while trying to understand what Nix was actually trying to accomplish and how one would actually go about using it. Granted I was trying to do it on a Chromebook, but the idea stands: I should be able to get at least the nix environment set up and the silly gnu hello world built and running, right? Turns out nah. The ergonomics are just that of a hiltle…

Yeah, cloud installation is a bit tricky: https://mrbluecoat.blogspot.com/2024/12/nixos-in-cloud.html

https://netboot.xyz/ is probably the easiest way if your cloud provider supports it.

Re: Nix – Death by a Thousand Cuts

#309
I've used too many Linux distributions to list here, last one before NixOS being Arch.

No disto ever came close to giving me what NixOS gives:

- I can try to rebuild my system as many times as I want and it doesn't matter if it fails, as long as I get one to succeed I can switch to it;

- Once I get the system the way I want, I can reproduce the same setup with a single command across a number of different machines;

- I can reuse different parts of the config with different machines and update things incrementally, revision, etc, and every time I improve my shared config on one machine, the improvements are automatically transferred to the other machines upon gir-pull and rebuild.

I've now transfered most of my previous configuration to Nix, and not only that but I have tons of services I never bothered configuring on all machines enabled since it was all this trouble of moving configs back and forth.

I've got my share of issues with Nix, from trying to use submodules with Flakes (nixos-install does not work with it) to tons of headaches when trying to play with specializations - most of the time issues were caused by not understanding how the evaluation works or how to properly abstracting modules - but I cannot imagine myself going back to a regular Linux distribution ever again.

Re: Nix – Death by a Thousand Cuts

#310
post #246

Earlier quoted context omitted.

What's been your strategy for doing this

Well the short answer is: I defined the workflow/process for our team, everyone bought in, and new people don't really have a choice but to follow along. The longer answer is, earlier in my career I ended up spending a not-insignificant amount of time helping people debug things, and about 70% of the time the issue was their local build environment. Everyone did it differently and it was very messy. I only made a few…

Does containerization get you most of the way there? I feel like containerization + one of the tools built on top of nix (e.g. devbox.json) should get teams close to 100% there, that's my goal.
Post reply on HN