Live data from Hacker News

Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

zero-to-nix.com

171–180 of 227 posts

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#171

I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…

> I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet

I have several friends who use Nix and generally recommend it.

I do believe I think enough like them to like Nix for the same reasons (declarative, reproducible).

I've asked them to play devil's advocate, and I generally get the downsides, but...

There is one downside that I feel they can't tell me, but they end up telling me indirectly:

Nix is very complicated and takes a long time to learn. It's the Haskell of package managers.

I love Haskell, so it's not even unreasonable that I'll like Nix. But I won't like the learning curve. I spent a decade becoming productive in Haskell, and a year becoming productive in Rust. Will I like for my operating system to have crutches for months as I reconstruct my neural pathways to perform basic navigation?

This is why I think a tutorial like this is great: A gentle introduction, and a lot of courage to spend time, is all you need.

> It feels like the Kubernetes of package management/build if you will complexity wise.

In terms of learning curve, it might not be as bad as Kubernetes.

Kubernetes has a lot of complexity because of its distributed model.

But in terms of learning a new operating system with its own paradigms, it may seem similarly impairing to learn. (You'll lose the same abilities to run things until you figure out what's going on.)

> "Do we really need this or is it just what everybody else is doing?"

We definitely need reproducible builds.

Nix is the best solution to offer this.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#172

I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…

> I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. Top reasons in my mind: 1. Error messages. Even with my >1 year of experience using NixOS full-time, I've encountered errors that I simply _cannot_ fix. This is getting better (recent nix releases let you introspect probl…

I don't know much about Nix, but I'm planning on reading more about it.

Since you mentioned packer/proxmox/nixos-generators - am I understanding correctly that nix could be used instead of packer to generate a vm image/template for proxmox(or whatever hypervisor)? Is it limited to NixOS or could it create a centos image as an example?

I've used a combination of packer+ansible/chef/salt to create images, but it's always felt a little clunky.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#173

I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…

Some things are much harder in practice than in theory. I recently had to work with a JavaScript project that doesn’t get a lot of maintenance love. It requires a JavaScript version that is no longer part of Nixpkgs. Now try figuring out how to build just that version and also make Yarn use that version. It’s not incredibly hard but the documentation is not obvious to find.

Then go on a very very long walk while your Darwin machine is now compiling node.

Contrast that with something like Volta which just works and takes minutes to setup.

Or take anything in Node with a postInstall script that tries to download binaries.

Even Haskell that ostensibly has good support in Nix has a lot of flaws unless you use some of the third party Haskell tooling such as Haskell.nix

Quite a few Haskell packages are marked as broken and there’s only a single version of every Haskell package in the Nixpkgs Haskell packages. Meaning you will quickly run into lots of errors because of version bound problems.

Then there’s matters such a what if you install a formatter and a linter through Nix as is often suggested in those super neat tutorials on how to quickly set up a dev environment. But now you’re using a version of these tools that’s decoupled from the rest of the project.

The list goes on and on.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#174

I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…

> would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet The daemon needs to be run as root root in a standard multi-user install which rules out HPC-like envs where Nix would actually shine. There are workarounds but none of them official. Tooling and documentation are on the same level as for a random esoteric programming language. I love Nix but have been hesitan…

> The daemon needs to be run as root root in a standard multi-user install which rules out HPC-like envs where Nix would actually shine.

That's an important issue! For those who haven't seen the recent work on it, check it out below.

Théophane Huffschmitt is working on it here: https://github.com/NixOS/nix/pull/5380

and here: https://github.com/NixOS/nix/pull/5226

tracking issue: https://github.com/NixOS/nix/issues/5208

NixCon 2022 talk: https://youtu.be/Gw3LtgbKouc

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#175

Earlier quoted context omitted.

> I think it's 5-10 years out from widespread adoption To quote Andy Warhol, "They always say that time changes things, but you actually have to change them yourself." I don't mean you personally! I mean that it's not clear how time is going to fix Nix's documentation. My guess is that at some point a big company will either clone or copy NixOS and enforce some discipline on the documentation. At that point it'll tak…

> I mean that it's not clear how time is going to fix Nix's documentation. This is my estimate based on the work that has happened over the last two years. There is steady movement in the right direction and the community is organized alongside the NixOS Foundation members to make things happen. Just not at a break-neck pace. Places like Determinate Systems, Tweag, etc are the largest forces currently, but there are…

I have huge respect for those people and I hope you're right.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#176

I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…

Personally, I think because its feature-set is currently very much "scattered".

Nix is in the transition to use 'flakes': a new concept that gives a bit more structure and allows easier reuse of Nix packages, NixOS modules and more. In addition it includes a standardized 'lock' file. Lock files are quite useful (or even essential) for reproducibility.

However, it is in experimental phase for more than 4 years now. It is behind a configuration flag, so it isn't obvious how to use it. A division in community, projects and documentation happens this way.

Because it is still considered an experimental feature, flakes and its surrounding CLI tools aren't mentioned in the official docs.

Even though it is experimental, flakes is considered an essential part of Nix by a large portion of the community.

This makes those people look for and create their own solutions:

This results in multiple documentation sites:

- Official manual (https://nixos.org/manual/nixos/stable/) - https://nix.dev/ - https://nixos.wiki/ - Blog posts - Now https://zero-to-nix.com/

Multiple wrapping tools for development environments:

- `nix-shell` (non-flake style) - `nix develop` (flake style) - https://devenv.sh/ - https://www.jetpack.io/devbox/ - https://floxdev.com/

It makes sense that these are created. I'm still hoping Nix flakes will become the default and UX can be iterated upon. But it doesn't make the future of Nix all bright and beautiful atm.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#177
post #165

Earlier quoted context omitted.

Fragmented documentation. Flakes are still "experimental" and their interface subject to change, but they're also widely acknowledged to be the better way to use Nix. There aren't that many Flakes-first docs, and many existing documents describe things that don't really work with Flakes, so the already incomplete & fragmented docs are even more incomplete & fragmented than it seems at first! AFAICT, there's no way to…

> AFAICT, there's no way to use the Flakes-based tools (`nix develop` and such) in the shebang of a script For now there's nix-runner: https://github.com/clhodapp/nix-runner

Nice, but that appears to need the (non-portable) `-S` option to `env`. POSIX only requires a single argument string to pass to the utility invoked (though the documentation has it as [argument...] the OPERANDS section uses the singular "a string" form)[1]. Further arguments may be ignored (it's implementation dependent). With `nix-shell` your shebang can be `#! /usr/bin/env nix-shell` and subsequent arguments can be on the following lines, and `nix-shell` itself knows to parse that. Busybox's `env` doesn't support `-S`, and Busybox is the standard shell environment in Alpine (for a common use).

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/e...

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#178

I wish guides like these contained screenshots. Do people use Nix for desktop OSes? As a VM they SSH into? A collection of config scripts that they don't directly issue commands to? I certainly can't tell from a quick glance of this guide

Nix is pretty usable for both desktops and headless servers. Personally, I even use it on macOS without much trouble.

My system looks like any other install of Ventura, but all of my configuration, ranging from the terminal and VS Code to macOS-specific system preferences and Safari, is done declaratively in Nix [1]. The overwhelming majority of my installed software also comes from Nix packages, with some exceptions for stuff that is not packaged yet (e.g., I have Podman Desktop, the macOS ZFS port, Lulu, yubikey-manager-qt installed through Homebrew -- fortunately nix-darwin [2] also just lets me have an set of brews/casks in my config).

It was been a bit of a nightmare at first since the error messages are kind of horrific, and there can be a lack of good examples/docs on flakes. But I think the weekend worth of time I invested was worth it since I no longer need to rely on hacky shellscripts or remember to manually configure anything.

[1]: https://github.com/nix-community/home-manager>

[2]: https://github.com/LnL7/nix-darwin>

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#179

Earlier quoted context omitted.

Screenshots of what exactly? Installing packages? Running nixos-rebuild switch? I guess screenshots of a bunch of text.

Yes! Assuming that is what "using Nix" looks like for an expected use case, that would be informative for someone who does not know what using Nix looks like.

You will like nixos.org then :)

https://nixos.org/

Lots of examples if you scroll down!

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#180
post #166
post #159

Earlier quoted context omitted.

Yeah, Home Manager is more redundant if you're using Nix-Darwin for a configuration.nix. Non-NixOS Linux doesn't have an equivalent module system to Nix-Darwin, though, so if you want a module system for declarative config there it's Home Manager.

So Nix does not support system level declarative config on Linux except for NixOS? Oh wow, that sucks.

Yeah. It's an unfortunate gap.

There is some work in NixOS-WSL on a special Systemd shim which allows that NixOS instance to work with the WSL-provided Systemd that Microsoft recently added with their 'native' systemd support. I wonder if that can be extended to port NixOS to systems where it doesn't control the whole stack.

Ideally we'll eventually see existing module systems unified with that of NixOS via some kind of process management abstraction framework, and you'll be able to do NixOS-like things in more places with a shared codebase.

Edited to add: there's nothing as simple as NixOS or Nix-Darwin, but you can use Disnix to deploy configured services via Nix on non-NixOS. Not something I'd go for on desktop, but it's there.

Post reply on HN