NixOS 18.09 Jellyfish Released | Hacker News Reader

NixOS 18.09 Jellyfish Released

discourse.nixos.org

73 pointsgrhmc21 comments

We're using NixOS for production systems for more then 5 years now (I only joined the company last year). and the functional approach has been more than rewarding.

We're strong adopters of the whole Nix ecosystem[1]. Having a reproducible, deterministic build of our applications and a functional configuration of our prod and dev server was a huge win for us. We can provision an exact-and I mean literally exact-copy of a cluster of machines in AWS with a click of button!

[1] My Ex-coworker, Rob Vermaas talked about it in NixCon 2015: https://www.youtube.com/watch?v=nuyuA43q9NE

I've considered using NixOS for production environments at work, but the thing that keeps holding me back is the configuration language. It's neat that it is Turing complete, but it's unique to NixOS, and requires a non-trivial amount of time to learn in order to configure a system (and maintain it..)

I recommend you keep holding back. I've been running NixOS on a personal vps and my laptop for close to two years now and it was a mistake.

The official documentation for the configuration language is as far as I can tell like 20 pages long. Then you are directed to some old blog posts... I realized that I don't want to investing the time to learn some undocumented obscure single use language.

Guix looks way more interesting to me. Compare the Guix manual to the NixOS & Nix manuals combined and they are about the same length. Then look at the Guile manual and it is about 3x longer than either of those. Of course, I have an issue with the whole Guix libre distribution so I'm not going to be installing it. I like working wifi too much.

Nix and Guix are really interesting ideas but they have both made choices that I think are going to keep them very niche.

The laptop is back on Debian, eventually when the burden of maintaining the server becomes too great that will be back to Debian as well.

I agree for your personal computer. I've been using it on my PC for several months, and it was definitely a mistake. Most things work fine, but there are enough problems that it is extremely noticeable. Whether it's the mess that is steam-run and that whole hack, or having to build your own derivations for literally anything that's not widely used or that you need the latest versions of, it's just an endless time sink. And the documentation is non-existent, as you say. You need to go into the git repo to see what actual options are available, despite how comprehensive the options search on the NixOS page looks, it's not.

For a server, where you're typically doing that kind of work anyway (and want to have the specificity and control), I'd say it's pretty good (Guix works too).

I'm actually going back to Mint today.

I've used Ansible and Salt and I've found them much easier than dealing with nix. With nix I always end up digging through the source code to figure out how to anything.

Previous to NixOS I was actually using a simple configuration management system I wrote myself in mawk. Basically a glorified templating dsl that would deploy itself by concatenating all my awk code and a base64 encoded tar.gz of config file templates then ssh itself to the server and bootstrap and run. I don't know what madness possessed me to do that but I would rather go back to that than nix right now.

When I go back to Debian I'm looking at maybe trying out https://propellor.branchable.com/

My Haskell isn't great but I would prefer learning a language I might actually use elsewhere.

I'm excited to see this on Hacker News again.

I've tried it on my MacBook Pro and found it to be a pleasant experience once configured.

On the other hand, the temptation to endlessly configure exhausted me and led me back to macOS.

I'm running macOS Mojave now, and hopefully this will fix some bugs so that I'll be able to use Nix as my package manager until I take another shot at a full NixOS.

I'm running macOS Mojave now, and hopefully this will fix some bugs so that I'll be able to use Nix as my package manager

What bugs are you running into? I have been using Nix on my MacBook with home-manager a couple of months now with relatively little effort. Every now and then I run into a package that does not build, but usually it's easy to fix and submit upstream.

There is also nix-darwin for managing macOS NixOS-style: https://github.com/LnL7/nix-darwin

Of course, nothing beats the real experience, so I am running NixOS on my workstation.

I was previously running into https://github.com/NixOS/nix/issues/2244 but it looks like the problem is now fixed :tada:

I used to run this in a VM on my MacBook Air and use it as my development environment: Xmonad, emacs, stow for config that Nix can't handle, etc. etc. The experience on some level suffered because of it being inside a VM, but the value of having the entire system configured and inside version control was incredible.

My only complaint was that it was difficult to install system packages built in Ruby, NodeJS, etc. without having to submit them to the main repository. It's for a good reason, of course, but back then it was frustrating when some CLI tools could only be installed through rubygems or NPM. Those scripts weren't always so easy to write because the process was largely undocumented, and it just felt weird that it was essentially leading to a separate package repository that was responsible for reproducing many others.

That was a few years back so I'm curious to see how that may have changed, as I would seriously consider working with NixOS for small server deploys in favour of building a K8S cluster or buying into PaaS.

The actual release notes are here: https://nixos.org/nixos/manual/release-notes.html#sec-releas...

I'm really interested in NixOS (and guix), but one thing I don't fully understand is how they handle versioned dependencies.

Say I have a service I run that acts as a frontend for something like nmap. So there is pkgs/tools/security/nmap/default.nix that installs 7.70

How do I 'pin' that version? If I vendor that file into my configuration, that could work, but then the buildinputs are

  buildInputs = with python2Packages; [ libpcap openssl ]
    ++ optionals ...

And the dependencies for libpcap and openssl are themselves not pinned to specific versions, so how exactly do I get a reproducible build?

So the real versions here is in the `import <nixpkgs> {};` You need to pin it to a specific version or even commit from nixpkgs github repo. So instead of that, you can find the commit that has all your desired versions and pin it that way. with import (builtins.fetchTarball https://github.com/NixOS/nixpkgs/archive/9a5f7b1630c138a82cb...) {};

This way, all your versions of packages will be pinned to this specific revision, and you can also use multiple revisions at the same time.

What is this 'pint' term? I thought it was a typo of 'pin' but you used it twice.

It was just a typo twice. Sorry for the confusion.

So reproducible build means that given the same input (ie same hash of dependencies), you get the same output.

The description of the build inputs has references to the definitions of other packages which have references to the exact version of the source code or commit hash or whatever (and hopefully has a hash of whatever is supposed to be downloaded). Therefore to get a full description one must expand all the other definitions. I don’t know how to do this in guix/nix but I suppose one might say “this package definition with this commit of this repo of package definitions.

Pinning to a specific version seems to be a different issue and I don’t really know anything about that

Pinning in the Nix world means pinning an entire Nixpkgs. You pin a program and all its dependencies by pinning the whole root of the "ecosystem."

If you want to deal with N separate programs that are each pinned independently, you will point to N different revisions of Nixpkgs.

One NixOS configuration file can point to several different specific revisions of Nixpkgs. This is done with a so called "import from derivation" in the Nix expression language.

You can look at this page (scroll to the bottom to skip backwards compatibility):

https://nixos.wiki/wiki/How_to_fetch_Nixpkgs_with_an_empty_N...

There "pkgs" becomes defined as a specific Nixpkgs revision regardless of which revision is used by "nixos-rebuild" for example.

This would all be clearer with a real example, sorry...

I've got the same confusion as the parent poster, but going a bit further - so does each revision of Nixpkgs have just one version of say openssl? How about if 2 different programs are built around 2 different version of OpenSSL? How do they coexist in one revision of Nixpkgs?

I actually don't really understand how this is handled in other package-managers as well. B/c in the case of libraries, having 2 versions floating around can lead to double linking and duplicate symbols and all sorts of subtle problems.

Nixpkgs does carry more than one version of some packages, but only when the maintainers deem it necessary. These are treated as separate packages with different names.

In the case of OpenSSL, Nixpkgs currently has two packages named openssl_1_0_2 and openssl_1_1, with openssl being an alias for latter.

Different programs depending on different versions can be installed at the same time without conflict. Full paths to dynamic library files are used in binaries instead of relying on a global library path.

I still dont really understand how this works. Can someone point me to a guide suitable for idiots? I like the idea of how this works I just don't understand how to configure it.

I've found the Nix pills series to be the best introduction to understanding how Nix/NixOS works:

https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-t...

At the same time, we definitely aim to make things work for users behind the scenes without knowing Nix. You still get all of the benefits of functional package management.

Thanks I'll give thema read.

Reply on news.ycombinator.com