Live data from Hacker News

NixOS: Declarative Builds and Deployments

nixos.org

71–80 of 83 posts

Re: NixOS: Declarative Builds and Deployments

#71
post #37
post #22

I think the idea is good but execution is poor to reach mass adoption because: 1. It tries to replace ALL package managers due its extreme philosophy. I had a lot of issues when it tries to replace Cargo for example 2. It uses a functional language, which will lose 95% of users 3. It never had a great user experience especially if you’re new and trying to learn or if you’re not using linux or if you bring your own to…

I need to do some reading up on Nix, because I don't think I understand it. I thought NixOS was an operating system and Nix an operating system-level package manager, so why is it trying to replace Cargo, a package manager for a specific programming language in Rust?

The same reason Bazel builds avoid using Cargo when building Rust software, so I'll describe why Bazel would do this:

- Bazel wants to cache remote resources, like each respective crate's source files.

- Bazel then wants to build each crate in a sandbox, and cache the build artifacts. Because bazel owns this process, instead of Cargo, it can trivially distribute those build artifacts to other developers, or in CI, etc -- instead of everyone having to build everything from scratch.

This is an established practice, and Nix wants to drive the build for the same reasons.

See:

- https://github.com/bazelbuild/rules_rust

- https://github.com/google/cargo-raze

Re: NixOS: Declarative Builds and Deployments

#72
post #22

I think the idea is good but execution is poor to reach mass adoption because: 1. It tries to replace ALL package managers due its extreme philosophy. I had a lot of issues when it tries to replace Cargo for example 2. It uses a functional language, which will lose 95% of users 3. It never had a great user experience especially if you’re new and trying to learn or if you’re not using linux or if you bring your own to…

What exactly would this "cleaner base" look like? A main goal of Nix is a completely reproducible deployment, and many tools are not built for declarative usage, so Nix must add a layer on top in order to make them declarative. If you only go part way, then the entire point of Nix is nullified. Might as well use Ansible. That being said, it's really not that difficult to use tools in their original form on Nix is you…

> What exactly would this "cleaner base" look like?

My interpretation would be something like: the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix.

This commit message (from one of my commits) details some of the struggles supporting Ruby under Nix:

https://github.com/NixOS/nixpkgs/commit/b6c06e216bb3bface40e...

Each of those problems is due to either:

1. Some unmotivated contrivance in Bundler, where the maintainers refused to make their stuff less needlessly broken, or

2. Ruby programmers in general not programming with packaging in mind (haven't touched Ruby/Rails professionally in a while, but when I did, it was par for the course to rsync/capistrano files around -- no one saw the utility of any sort of packaging)

And the two really reinforce each other. Bundler is the de facto way to declare and pin dependencies at the app level, but then Bundler makes it nearly impossible (see the commit message for details) to package software using Bundler, which reinforces the "fuck it, we'll just rsync files around over SSH", which means no one pressures Bundler to Do The Right Thing.

It's the same thing everywhere else. There are complaints elsewhere in this comment section about the nodejs/npm experience on Nix: same underlying problem. The design behind npm is so unnecessarily shit-tacular that it kinda sorta just barely works on its tier 1 platforms. I don't envy the brave souls that have worked on supporting npm packages on Nix.

Re: NixOS: Declarative Builds and Deployments

#73

Earlier quoted context omitted.

Docker is not reproducible, you just apt-get install what you want hoping that the RUN commands get you a version that is still compatible with your software and doesn't break anything. With NixOS, you can pin the specific hash of every software, and you don't need the entire Ubuntu 20.04 in a container to deploy a webapp.

You can pin versions with apt-get install...

My experience with apt is that, while you can pin versions of packages once they're installed, they may not exist indefinitely in the mirrors.

Whereas Nix keeps binaries around longer, but also includes the ability to automatically and reproducibly build from source.

Re: NixOS: Declarative Builds and Deployments

#74

Earlier quoted context omitted.

What exactly would this "cleaner base" look like? A main goal of Nix is a completely reproducible deployment, and many tools are not built for declarative usage, so Nix must add a layer on top in order to make them declarative. If you only go part way, then the entire point of Nix is nullified. Might as well use Ansible. That being said, it's really not that difficult to use tools in their original form on Nix is you…

> What exactly would this "cleaner base" look like? My interpretation would be something like: the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix. This commit message (from one of my commits) details some of the struggles supporting Ruby under Nix: https://github.com/NixOS/nixpkgs/commit/b6c06e216bb3bface40e... Each of those problems is due to either: 1. Some u…

The Nix community can try to boil the ocean, or they can create a platform that can be a stepping stone to better things. With the recent upswing in Nix usage, many new systems and packages are built with Nix and Nix-like declarative systems in mind. It's a positive feedback loop. It's not possible to rebuild literally everything from scratch to work in the "nix way", so older systems are supported with a wrapper layer, and newer ones should hopefully work in a more natural way.

Guix and Hurd and whatnot try to be more pure about things and look how far it got them. There are tens of thousands of projects that would basically need to be redesigned and written from the ground up to achieve what you desire, and I think the best approach is to build the platform and prove its value and create a path and model for new projects to follow. There are only so many open source developers out there.

Re: NixOS: Declarative Builds and Deployments

#75
post #39
post #35

Earlier quoted context omitted.

nix is so powerful precisely because it takes a pure functional approach. You don’t get that level of reproducibility if you allow side effects.

Avoiding side effects does not require inventing a brand new purely functional language programming language.

> inventing a brand new purely functional language programming language.

ISTM that if you dislike that, then there's GUIX.

https://guix.gnu.org/

Very briefly, AFAICT, it's "Nix but using Scheme".

Re: NixOS: Declarative Builds and Deployments

#76

I first looked at nix-shell which you can use to create ephemeral environments just like Docker, with the difference that they are 100% reproducible and you don't need containerd or like. It is awesome to create scripts which run the same on EVERY system. Then looked at NixOS. I geht the point of having a deklarative like OS which you can rebuild in a couple of minutes, BUT the nix language is kind of unituitive and…

The nix language itself is fairly simple and it is intuitive. It's the abstractions on top of it that can be more confusing. Particularly nixpkgs.

Re: NixOS: Declarative Builds and Deployments

#77
post #75
post #39

Earlier quoted context omitted.

Avoiding side effects does not require inventing a brand new purely functional language programming language.

> inventing a brand new purely functional language programming language. ISTM that if you dislike that, then there's GUIX. https://guix.gnu.org/ Very briefly, AFAICT, it's "Nix but using Scheme".

or garn (https://garn.io/) which is a typescript interface to nix.

Re: NixOS: Declarative Builds and Deployments

#78
post #23

NixOS is honestly the single most game-changing thing I've been introduced to in my last decade of experience in tech. If you're interested in trying out NixOS I highly recommend either running it as an WSL2 VM[1] if you have a Windows machine or deploying it on a cheap VPS[2] to play around with. I personally still use a Win11 desktop for compat with Adobe software and a few other bits and pieces, but I do all my se…

I keep seeing this from people online but I have yet to see Nix in the wild at any large organization. For such a "game-changing" thing, it certainly doesn't have the meat space following you see online. To me, I tried Nix, got frustrated with packages, realized I'm just using someone else's abstractions for defining configuration files (with the same kind of quality you'd find on Ansible galaxy), and realized it's n…

We love it at Anduril.

Re: NixOS: Declarative Builds and Deployments

#79

Earlier quoted context omitted.

> What exactly would this "cleaner base" look like? My interpretation would be something like: the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix. This commit message (from one of my commits) details some of the struggles supporting Ruby under Nix: https://github.com/NixOS/nixpkgs/commit/b6c06e216bb3bface40e... Each of those problems is due to either: 1. Some u…

The Nix community can try to boil the ocean, or they can create a platform that can be a stepping stone to better things. With the recent upswing in Nix usage, many new systems and packages are built with Nix and Nix-like declarative systems in mind. It's a positive feedback loop. It's not possible to rebuild literally everything from scratch to work in the "nix way", so older systems are supported with a wrapper lay…

I agree with all of the above.

And I just realized: I should probably clarify what I meant when I suggested "the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix" as the means for a "cleaner base".

While that would make things cleaner in some sense, it's not what I'm suggesting Nix should do. I was mostly trying to clarify that the majority of what needs cleaning is extrinsic, rather than some intrinsic failing of Nix itself (though things could certainly be improved there, too).

The greatest source of difficulty for packaging/running things under Nix (having contributed at least a couple dozen packages, and the entirety of the Ruby/Bundler support) is software violating well established principles. To pick one silly example: say you need to get the home directory for the current user. Yes, you could do the equivalent of "/home/${USER}", and while that might coincidentally work on 99.999% systems, that's still wrong -- there's nothing keeping someone from having their home dir be something arbitrary like "/home_is_where_the_heart_is", and now your software will break. The funny thing is that the right way to handle this is also the easy way: use "${HOME}" if it exists, and failing that, fall back to `getpwuid` (or whatever your language calls it). It's easier/simpler because you no longer need to make any assumptions about how the file system is laid out -- either the user tells you through $HOME or you consult the password entry. Easy. But what happens when you send a pull request to fix the objectively wrong logic of the first example? You get push back saying "well, it works on my machine, and this is the first complaint we've heard, so no, I don't think I'll merge your request".

So, I guess I'm being kind of roundabout, but the takeaway I'd like for everyone to have is this: if working with your programming language is difficult on Nix, please go look for (and upvote) open issues in your language's issue tracker (they're probably there) from other Nix maintainers begging for fixes that would not only make it easier for Nix users, but would also remove latent correctness problems that have gone unnoticed solely due to the coincidental uniformity of all other commonly used distros. Just because something works everywhere other than Nix doesn't mean that the code in question isn't needlessly complicated/fragile and/or dependent on non-standardized assumptions that just so happen to be common on other systems.

Re: NixOS: Declarative Builds and Deployments

#80

I work on Nix and think this paradigm has already impacted and will continue to influence software devopment in general. I want to make it easier for organizations/companies/groups to adopt it. Ideas and questions are welcome.

I'd start with getting some sort of working governance structure going. The sheer number of duplicate libraries all competing with each other has to be hurting Nix. Trying to figure out a TS/NodeJS build was an utter nightmare a year ago as I ended up going through five different projects, including the new "internal" solution, none of which worked reliably. I contributed to the community for about a year and have si…

Governance has been a difficult thing to make progress on. I can say that we did discuss recently cleaning up some of these old solutions and making official approaches clearly marked as such.
Post reply on HN