Live data from Hacker News

What Is Nix?

engineering.shopify.com

251–260 of 344 posts

Re: What Is Nix?

#251
post #83

Earlier quoted context omitted.

So the auditors said that the system was hard to audit?

Considering that “difficult to audit” overlaps with: difficult to understand, difficult to deploy, difficult to onboard, and a bunch of other things that are also very important to non-auditors, that seems like an entirely reasonable and informative complaint. If you hire a financial auditor and their report was basically an nicer version of “‘books‘ were written in pencil on napkins, many food stained, some illegibl…

"books written in pencil on napkins" is analogous to how most web application projects are organised today. Nix would be the formalisation of this.

Re: What Is Nix?

#252
We use Nix for all our developer tooling at CircuitHub. It's not the easiest thing to get into - but once you do - it solves so many problems! Great to see a large company like Shopify get in on this.

Re: What Is Nix?

#253
post #89

This article suffers from the same problem every nix article I read suffers from: it dives in too deep from the get go. When you sit somebody down in front of a computer for the first time in their life, you're not going to explain what it is composed of, what happens in when your mouse button is clicked and why Windows vs Mac vs Linux is a thing. Please, first tell me what nix is, provide me with a few commands to g…

That's kind of the approach I took in this playlist: https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4... However, there is really an important and subtle set of concepts to grasp in order to actually understand Nix, and not just mess around with a package manager tool incidentally built with it. It's fine to not understand them, but they are what this article tries to explain.

That's a nice playlist. Thank you.

I'll try running those commands in a nix docker to follow along.

Does this playlist exist by any chance on peertube?

Re: What Is Nix?

#254
post #226

I like the idea of Nix. It's definitely the future of package management and build systems. But it's solving a problem we knew how to solve in the 80s: dependency hell is solved by statically linking everything. In fact in the Windows world it's still like this. If you need OpenSSL, for example, it should be in your source tree and compiled in the same build pipeline as your application.

Static linking is unfortunately broken for many projects though, primarily because every C/C++ dependency has a slightly different incantation to make it work. It also doesn't address the problem of languages which expect dependencies to be files on the filesystem, like python or ruby.

Re: What Is Nix?

#255
post #247

Is Nix only handling the build part (with configure flags etc.) or is it also used to configure services, for example? I'm not versed in devops/provisioning etc., but say, I had a NixOS system with some server software (mail server, DNS server, whatever). Would I still want to use Chef/Puppet/Ansible, or is that included in the Nix ecosystem?

NixOS exposes config options as variables you can set in your configuration.nix file. Also, external config management tools generally interact poorly with nixOS, because they assume a system which is managed imperatively.

Re: What Is Nix?

#256
post #68
post #63

Earlier quoted context omitted.

Unfortunately there's a pretty annoying bug with MacOS which resulted from Apple making /nix non-writable by default. And since /nix is hard coded in all the cached packages it's not easy to fix. This is one big thing that's preventing us from adopting nix https://github.com/NixOS/nix/issues/2925

I'm trying to understand why macOS can't use a different path (since it's a different OS anyway, and you can't run Linux Nix binaries on macOS). From the end of the thread, it sounds like > The main consequence of using a separate prefix for macOS is that you can't have Hydra jobsets anymore containing jobs for macOS and Linux. It would also make it harder to deploy from macOS to Linux. i.e., if the same package buil…

You can use a different path, but then you don't have access to the binary cache, because of the mismatch between your path and the path found in the cached binaries. That's how I understand it.

Re: What Is Nix?

#257
post #246
post #242

Earlier quoted context omitted.

The problem here really seems to be with nix. The /nix path shouldn't be hard coded. (Security concerns aside, I don't want a package manager to clutter up my root directory.)

It's necessary to hardcode paths in order to ensure that the exact version of a dependency is linked into the executable. Without this mechanism, nix packages would not be reproducible and self-contained. Also, the path isn't really hardcoded. You can use a custom path, but that means you can't use binary caches.

I'm sure there are reasons for it, but it still sucks.

It ought to be possible to use binary caches and still swap out the path. (Modifying a string in an ELF executable isn't that hard.)

Re: What Is Nix?

#258

Earlier quoted context omitted.

Your criticism misses the mark because nix users have the ability to update a dependency and rebuild all of the dependees. With nix, I can update openssl in one place and be sure that everything that depends on it gets re-evaluated. How can I be confident that everything is linking the patched openssl I want when I'm using aptitude, pip, npm, docker, etc?

But what if they're using different versions of OpenSSL?

It'll only rebuild the packages that depended on that particular openssl. This is an area where Nix shines, because all packages are explicitly bound to their dependencies, it means it's no longer relevant what one file happens to be occupying `/usr/lib/libssl.so`, or even `/lib/x86_64-linux-gnu/libc.so.6`, so you can be running different apps that rely on totally different glibc versions alongside each other with no problems.

Re: What Is Nix?

#259
post #63
post #20

Earlier quoted context omitted.

It's kind of a mess. Nix is a collection of tools and systems that together form a highly reproducible build system. Nix is also a declarative, largely pure and lazy programming language that you use to design and specify the different build outputs for the Nix build system. Nixpkgs is, more or less, the only project written using Nix (and a lot of shell). It's a collection of many thousands of "derivations", many of…

Unfortunately there's a pretty annoying bug with MacOS which resulted from Apple making /nix non-writable by default. And since /nix is hard coded in all the cached packages it's not easy to fix. This is one big thing that's preventing us from adopting nix https://github.com/NixOS/nix/issues/2925

Hardcoding /nix is a very big downside of Nix for me. I understand why this makes other things easier, but it's a huge compromise on flexibility.
Post reply on HN