Live data from Hacker News

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

zero-to-nix.com

71–80 of 227 posts

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

#71

> echo "Hello Nix" | nix run "nixpkgs#ponysay" why on earth would you make # any kind of a special character in commands. who thought of that

Are you complaining because it's not on some latin keyboards, or for some other reason? A lot of other characters are already taken either by shell or by the nix expression language.

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

#72

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

People use Nix on desktop a ton, but the GUI tools in the ecosystem are still largely marginal and incomplete. The screenshots here would just be images of text, which is probably why there aren't any.

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

#73

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

All of the above.

NixOS is actually fairly well suited to a full desktop OS. They package-up basically everything you would expect. You can even pull in Steam its proton environment without much hassle.

It is also perfectly workable as simple server OS running on bare metal or a VM.

One can use it on other OSes as a way to create fully deterministic environments for developing. (Like the python virtualenv concept, but for any language, pulling any arbitary tools you might need). Almost like a docker container, but without isolating the filesystem.

Using just nix tool not as part of NixOS, can be an underwhelming experience, as the default does not quite give the fully declarative environment setup you might want. For example, under the default you can imperatively request packages to be added to the nix store. But if you chose to use the "correct" versions of commands, you can get the intended result. Alternatively, using it in conjunction with tools like direnv (which enables you to configure your shell to ask nix for a specific environment when you cd into it, or alternatively when you run a specific command within it). This environment can have exactly the set of tools you need for developing the project that lives in this folder, even if the rest of your OS has a different and incompatible version of the compilers installed, or whatever.

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

#75
post #67
post #39

Earlier quoted context omitted.

It is: using Flakes you're thrusted into a more pure evaluation mode by default, and it creates a (standard) artifact of the revision you're on: the flake.lock. You can get almost all the benefits Flakes brings without Flakes using alternatives like niv.

> It is: using Flakes you're thrusted into a more pure evaluation mode by default, and it creates a (standard) artifact of the revision you're on: the flake.lock. Can you name a specific example of the kind of nondeterminism/nonreproducibility I risk by simply pinning Nixpkgs itself (or to be more principled, using Niv)?

Certain environment variables at the time "nix-build" is executed can affect the nix configuration. Nix flakes default to ignoring those environment variables.

Flakes are also the way forward for pinning nixpkgs; it autogenerates a list of revisions used to pin, and allows easy updating. Flakes and niv, to a large degree, are about solving the same problem.

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

#76
post #2

I read of Nix now and then. Seems its more than a fad. Why should I invest time? What makes it stand out?

I think the nix community is doing an increasingly-better job at addressing several outstanding issues, and although the OP link resolves one of them - the getting-started experience - the "why" that you highlight here is still a hard one to answer without getting into the technical weeds. I ran an informal Twitter poll a few months ago and this question (the "why" instead of "how") was the most-requested kind of content.

One potential answer to this is, "imagine building and running software with lockfiles for _literally everything_". I'm not just talking about _versions_ of dependencies or shared libraries - which nix does - but also things like:

- Locking the current point in time (nix resets the build sandbox to the unix epoch)

- Locking out network conditions (all build dependencies need to be fetched and therefore expressed as part of the instructions and not left to "at some point during the build")

- Locking out access to any system state (again, builds occur in a sandbox populated only with what you indicate within the build instructions)

That's what's behind the marketing for reproducability and repeatability. If you lift those principles into new and interesting applications, the various other uses for nix fall out of it:

- NixOS takes the principle of those nix builds and applies to it building not just packages, but the system entirely, like the files it places in /etc or the running kernel.

- Projects like devenv[1] or flake devShells in general re-use the portability of a fully-defined nix package to ship hard-to-break executables into share-able devshells so your peers can work with the bit-for-bit same version of Terraform or python (without worrying about what version of /lib/libssl.so they may have)

- Since nix "owns" the _entirety_ of the inputs and outputs to a piece of built software, shaping it into different artifacts becomes trivial. For example, as long as you're able to build a rust project with nix, nix easily lets you kick out a minimal OCI container (without needing to write a `Dockerfile`), or produce a tiny qemu clone of your system (or any system) by feeding your NixOS configuration into a function that produces images instead of configuring your running system.

Hopefully that's helpful, sorry if it isn't - but nix is sort of alien software, and nix people are still learning how to best share its potential with others!

edit: list formatting

[1]: https://devenv.sh/

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

#77
post #36

UX feedback: for an opinionated guide targeted at newbies, I think the 'concepts' page should be much more of a guided introduction. I click on it and have a big basket of things in _alphabetical order_. I think it should be a top-to-bottom ordering of how a user should read them if encountering for the first time. Maybe have a separate glossary page if thats what you are going for with the alphabetical order.

Thanks for this. Our goal is to keep people on the "rails" of the quick start, with the Concepts as a way to fill out knowledge people are curious about. I wonder if we should downplay the concept docs in service of that? Or put more CTA's to go take the quickstart?

If thats the intent, then it seems the Quick Start is what I'd adjust to be more linear then : )

Again, it looks like a basket of equally-weighted links that a user is free to click into at leisure. It seems more like a directory of useful links rather than a "highly opinionated" guide to get me from zero to proficient.

Compared to something like the sveltekit docs [1] (randomly pulled because I was viewing it today) its much easier to understand the flow of topics, and I think a user can assume they should read them in the presented order unless they understand a given topic already.

[1] - https://kit.svelte.dev/docs/introduction

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

#78
post #60

Just my two cents: Nix doesn’t guarantee “reproducible”, just “repeatable”. (I think it’s helpful to keep these technical concepts distinct, and to introduce the right terminology when teaching, since it makes elaboration easier in the future.)

Can you elaborate? From what I understand, Nix packages are mostly reproducible as they are running great lengths for that, to the point where every time in Nix land is the exact same.

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

#79
If you don't mind, a shameless plug:

https://drakerossman.com/blog/nixos-for-apt-yum-users-a-gift...

I am doing a similar series of NixOS-related stuff, currently got only a single article out, yet quite "meaty".

You may want to check it out for a more streamlined approach in learning nix/NixOS which also compares it to familiar concepts from other Linux distributions. Will be releasing way more complete articles in the nearest future, hopefully within the next 2-3 weeks.

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

#80

What does opinionated mean is this case? I read through a bit and didn't see any strong opinions.

The most obvious example is that using the installer in the quick start enables the flakes and nix-command features automatically, even though they are still considered experimental by upstream.
Post reply on HN