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

91–100 of 113 posts

Re: 20 years of Nix

#91

Post by vilunov »

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…

OCI is based on Linux namespaces, which provide a way to create isolated filesystem trees for processes. You probably want that, and I agree with you, but probably forcing this into OCI itself is a lost cause, since its tooling is too based on layers.

Re: 20 years of Nix

#92

Post by soraminazuki »

orbisvicis wrote: post #68
Zurrrrr wrote: post #56

Earlier quoted context omitted.

> Its unique ability to treat packages as programmable data (i.e., derivations) How is this useful in practice?

I'm surprised that nix never ended up using augeas for package configuration because last I checked every upstream build option has to be reproduced in nix script by the packager.

It's easy enough for users to extend existing packages in Nix that it's never necessary for packagers to explicitly add support for every conceivable upstream build option out there. For example, the following three lines will create a new package based on an existing one with custom configure flags added.

    existingPackage.overrideAttrs (old: {
      configureFlags = old.configureFlags ++ [ "--custom-build-option" ];
    })
Package options that tweak the build flags are there for convenience and not a requirement. Many of them are there for internal use in the Nixpkgs repo to provide variants of the same package.

Re: 20 years of Nix

#93

Post by soraminazuki »

bsder wrote: post #77
amardeep wrote: post #4

I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns. I sincerely hope that nix community improves the UX to make it more accessible to ne…

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?

For what reason do you "still need Docker?"

With Linux, the only stable base required for Nix to function is the kernel. Nix packages all the required dependencies right down to glibc. Since the Linux kernel famously "doesn't break userspace," any sufficiently new kernel would suffice. Until recently, I've been able to get the latest Nix packages working on an ancient Linux 2.6 kernel. And even the kernel can be managed with Nix if you use NixOS. But Docker can't, so it's no use here.

As for Terraform, I don't see how it's relevant to this discussion. Nix-based SSH deployment tools can replace some of its functionality, so perhaps that's what you're talking about?

Re: 20 years of Nix

#94

Post by midchildan »

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 process to work with each other on Docker is such an overcomplicated mess. The runtime isolation boundary set by Docker doesn't represent any sort of logical component or security boundary in your system. It merely reflects how the underlying image was built.

This is a classic anti-pattern of mixing up policy with implementation. Runtime isolation policy should be independent of build time implementation. Nix gets this right with better design and composable packages. It's trivial to create a container that includes only the packages you want, with dependencies handled automatically by Nix. Docker, on the other hand, leaves you with a binary blob (i.e., Docker image) that's neither composable nor customizable.

Re: 20 years of Nix

#95

Post by earthling8118 »

troutwine wrote: post #53
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…

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 looking at https://github.com/ipetkov/crane and using flakes. I've got it down to the point that I can get a new rust project set up with nix in about 30 seconds with linting, package building, and test running all in the checks

Re: 20 years of Nix

#96

Post by earthling8118 »

chriswarbo wrote: post #79
comfypotato wrote: post #74

Earlier quoted context omitted.

Docker serves the basic functionality of a container as well as any other. The workflows that forced you to migrate away from it are more complicated, I’m sure, than a procedurally defined dev environment. What you’re calling a snapshot is what I meant when I said reproducible. Images allow me to have reproducible starting points to add other parts to my environment. Over time they get out of date depending on exactl…

> Docker serves the basic functionality of a container as well as any other I disagree. We've had multiple production outages caused by the Docker daemon misbehaving (usually causing us to run out of disk space). It also makes operations far more difficult than necessary; e.g. want to copy a .tar.gz file to AWS? Sorry, Docker's gonna insert itself in the workflow, and over-complicate the authentication[1]. Instead, I…

On the other hand Docker was quite easy for me to install... because I used nix to do it.

Re: 20 years of Nix

#97

Post by earthling8118 »

striking wrote: post #58
tmountain wrote: post #57

Earlier quoted context omitted.

Do they run NixOS or just use the package manager? What’s the host OS?

They run macOS, pull a repo, run a setup script. They get a multi-user Nix install with a direnv integration that boots up project-local daemons. Think Postgres, Redis, and so on; those are all available, along with the Nix packages the env needs, while their current working directory is that of a project folder. Very few things live outside of the project, but the things that do are unfortunately stateful. We'll be…

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

Re: 20 years of Nix

#98

Post by EntrePrescott »

anon291 wrote: post #88
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…

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 capabilities of the bind-mount, namespaces and cgroup-based approach of OCI and other newer packaging systems. And Nix needs to implement that.

My impression is that the OCI package spec isn't what would be in the way of implementing a system that would combine the isolation and security of a system based on bind-mount, namespaces and cgroups like OCI with a graph topology like Nix and that there would thus be an opportunity to combine the two, which would help Nix take over the dominating position in that space. If OCI turned out to be impossible to use with the more graph-based approach of Nix, then that would mean a much higher implementational work - not that it couldn't be done, but it still would need to be done then. But either way, Nix cannot stay with its old symlink-based layering: Failing to implement the security features that are now expected from modern packaging systems (isolation, bind mounts, cgroups, namespaces etc) is a surefire way to progressively maneuver into irrelevance.

Nix has a window of opportunity here due to the current weakness of the big players in the field. But it can't afford to let that slip.

Re: 20 years of Nix

#99

Post by tadfisher »

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…

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.

Re: 20 years of Nix

#100

Post by striking »

earthling8118 wrote: post #97
striking wrote: post #58

Earlier quoted context omitted.

They run macOS, pull a repo, run a setup script. They get a multi-user Nix install with a direnv integration that boots up project-local daemons. Think Postgres, Redis, and so on; those are all available, along with the Nix packages the env needs, while their current working directory is that of a project folder. Very few things live outside of the project, but the things that do are unfortunately stateful. We'll be…

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.

Post reply on HN