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

20 years of Nix

20th.nixos.org

Post reply on HN
Print view View original

101–110 of 113 posts

Re: 20 years of Nix

#101

Post by troutwine »

earthling8118 wrote: post #95
troutwine wrote: post #53

Earlier quoted context omitted.

Two of the major differences between terraform and Nix that I see are 1. it’s possible to muddle through in terraform and 2. Hashicorp has put a non-trivial amount of effort into documentation for all levels of users. I’ve taken a stab at using Nix for Rust projects and could not even get to a point where I had something that functioned. I found plenty of material online but was it out of date, idiosyncratic, did it…

I don't think it's very valid to compare the two. It is a little bit just to compare the experiences using them bit they aren't meant to solve the same set of issues. In fact, they are better together in my experience. I use nix to manage my terraform configurations with a lot of success. It reduces my boilerplate and helps me build abstractions on top of HCL. If you ever decide to take a stab at nix again, consider…

Crane is one of the libraries(?) I came across. Couldn’t get it to work on an existing multi-crate workspace project. The crane documentation as-is didn’t provide enough context to debug the errors I saw in the process of trying to muddle through. And then looking further afield ran into all the documentation, bootstrapping issues I alluded to above. Although I don’t doubt I could start a new project the point was to add new capability to existing work, for me.

Re: 20 years of Nix

#102

Post by Ferret7446 »

Realistically speaking, Nix will never become widespread. Instead, I foresee immutable OSes like Steam OS, Chrome OS and Fedora Silverblue combined with something like flatpak for installing applications.

The evolutionary strategy of reproducible snapshots of state has historically been far more successful than "pure" functional approaches; see Docker for example, or reproduction of DNA based lifeforms.

Re: 20 years of Nix

#103

Post by anon291 »

EntrePrescott wrote: post #98
anon291 wrote: post #88

Earlier quoted context omitted.

No. The nix store is a graph. Oci images are a tree. This is terrible for code ruse. Nix is superior. Oci should adopt a nix based approach.

The choice of topology of the package and layering system - be it a tree as in OCI or a more general graph topology as in Nix - is only a very small part of either of these systems. I agree that the general graph topology is superior in some points. My point though was that at the implementational level, the old symlink-based way of implementing it in Nix is severely lacking the isolation and more general security ca…

Okay, well it's trivial to adapt nix to use hard links or whatever. Nix just runs bash at the end of the day

Re: 20 years of Nix

#104

Post by ptman »

biggestlou wrote: post #84
bsder wrote: post #77

Earlier quoted context omitted.

The problem with Nix is that I still have to start with a Linux system--so I still need Docker, Terraform, something to give me a stable base for Nix to work against. At that point--why should I add Nix to the mess since I still need those other things anyway?

This is not true. Nix is supported on several non-Linux platforms, including macOS and Windows WSL.

WSL2 is very much Linux. Microsoft got tired of trying to reimplement Linux kernel interfaces so they just ship the Linux kernel in a VM.

Re: 20 years of Nix

#105

Post by vilunov »

midchildan wrote: post #94
EntrePrescott wrote: post #83

I like the principle of Nix that one can simultaneously install different versions of the same software and make layered choices of what version to use with what or depending on the use case. Nix has spearheaded that principle and that's great. That being said, that fine-grained layering selection is done via symlinks in Nix afaik, whereas a couple newer packaging systems (e.g. OCI containers or flatpak) can do such…

Treating packaging boundaries and runtime isolation as the same thing is exactly the problem with Docker and similar solutions. Just because some package didn't require another package at build time doesn't mean we don't ever want to use them together at runtime. Yet Docker conflates the two, introducing all sorts of unnecessary friction all over the place. This is why something as simple as getting more than one pro…

> Just because some package didn't require another package at build time doesn't mean we don't ever want to use them together at runtime. Yet Docker conflates the two, introducing all sorts of unnecessary friction all over the place.

But Docker in fact doesn't have compiletime dependencies, it needs you to specify runtime deps only. If you want to build something in Docker, you use two-stage builds and the runtime deps of the first stage become your compiletime deps.

> This is why something as simple as getting more than one process to work with each other on Docker is such an overcomplicated mess

I don't get this, why is it considered an overcomplicated mess? If you want to run several processes in one container, you just launch it with a lightweight process manager, if you want to run it in separate containers -- well, that's even easier, just launch separate containers and configure the communication between them with a network.

> Nix gets this right with better design and composable packages

Nix actually implements it worse than Docker in some sense. Particularly, the exact problem that you described:

> Just because some package didn't require another package at build time doesn't mean we don't ever want to use them together at runtime

is not solved in Nix, runtime deps must be a subset of compiletime deps.

> that's neither composable nor customizable

Compositionality is a completely different issue on which I do have problems with Docker. DAG-oriented environment building is strictly better than inheritance-oriented, but that's all orthogonal with compiletime-runtime separation.

Re: 20 years of Nix

#106

Post by vilunov »

tadfisher wrote: post #99
EntrePrescott wrote: post #98

Earlier quoted context omitted.

The choice of topology of the package and layering system - be it a tree as in OCI or a more general graph topology as in Nix - is only a very small part of either of these systems. I agree that the general graph topology is superior in some points. My point though was that at the implementational level, the old symlink-based way of implementing it in Nix is severely lacking the isolation and more general security ca…

Bind-mount, namespaces and cgroups are runtime properties, completely orthogonal to the problem Nix (the build system/package manager) is meant to solve. NixOS is the configuration layer on top that encodes those properties via systemd units, and that is where you'll find the concept of a "service" and where you can isolate the runtime parts of the system.

It's not orthogonal, Nix goes far out of its way to fix compositionality issues with hacks and dubious conventions, when instead namespaces (bind-mounts) could be used to deliver expected environments.

Re: 20 years of Nix

#108

Post by pxc »

striking wrote: post #100
earthling8118 wrote: post #97

Earlier quoted context omitted.

Is the direnv integration custom or do you base it off of something? I use direnv extensively but I don't have it start any project daemons currently and I've been shipping scripts via devShell for managing them. I'd be very interested in this

We use nix-direnv mostly for the caching support and we use s6 as basically an init system but per project. Besides that it's all custom. We're looking to replace s6 with our own supervisor soon. Edited to add, direnv just gets installed via `nix-env` but I wish it were using nix-darwin. I'll probably get to write a blog post about this in a couple months.

> We're looking to replace s6 with our own supervisor soon.

Why? Anything of interest to other Nix users here?

Re: 20 years of Nix

#109

Post by takeda »

carapace wrote: post #28
tomberek wrote: post #24

Earlier quoted context omitted.

There are two sides to this problem, the first is to improve the UX, but the second is to clearly describe a compelling reason for people to adopt. It is very tempting to only blame the first, but I think we need to also need to tell a better story and highlight the values in a better way. This would then give people a reason to get past the UX issues in the hopes of achieving those desired values. For example; peopl…

I disagree, I think the value proposition for reproducibility is clear, it's just that the learning curve "is too damn high!" I'm highly motivated to learn and use Nix (or Guix for that matter) but I've bounced off of it three or four times now, and I'm the kind of weirdo who learns new PLs for fun. Someone once said that you don't learn Nix, you reverse engineer it.

I think the reason why Nix is hard isn't the language (although lazily evaluated functional language is definitively a part of it), but the paradigm shift, but this is necessary for reproducibility.

Imagine if you had a distro where you couldn't depend on existing state (so you couldn't just compile something to /usr/local). Where you had to create package definition with all dependencies explicitly defined.

Kind of like using FreeBSD ports (or Gentoo) without precompiled packages and you were forced to add every package manually before using. You would also complain it is hard even if you would have to just use Makefile and shell script.

I don't think this will get easier until Nix would get embraced by other package s, making it easy to specify those components as dependencies. Now with flakes with can be composable this is possible.

Re: 20 years of Nix

#110

Post by striking »

pxc wrote: post #108
striking wrote: post #100

Earlier quoted context omitted.

We use nix-direnv mostly for the caching support and we use s6 as basically an init system but per project. Besides that it's all custom. We're looking to replace s6 with our own supervisor soon. Edited to add, direnv just gets installed via `nix-env` but I wish it were using nix-darwin. I'll probably get to write a blog post about this in a couple months.

> We're looking to replace s6 with our own supervisor soon. Why? Anything of interest to other Nix users here?

People who are writing software in Nix-based dev envs would be interested in what we're working on, but the featureset is tightly bound to resource limitations and needs, so I can't really say any more without making promises I might not be able to keep, and I would feel bad badmouthing s6 if I couldn't do any better myself.
Post reply on HN