4 ms·

NixOS 18.09 Jellyfish Released

73 points by grhmc 8y ago

0xb100db1ade 8y ago
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.
- danieldk 8y ago
  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 https://github.com/LnL7/nix-darwin Of course, nothing beats the real experience, so I am running NixOS on my workstation.
  - 0xb100db1ade 8y ago
    I was previously running into https://github.com/NixOS/nix/issues/2244 https://github.com/NixOS/nix/issues/2244 but it looks like the problem is now fixed :tada:
Jeaye 8y ago
The actual release notes are here: https://nixos.org/nixos/manual/release-notes.html#sec-release-18.09 https://nixos.org/nixos/manual/release-notes.html#sec-releas...
justinsaccount 8y ago
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?
- kiloreux 8y ago
  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/9a5f7b1630c138a82cb9ae0d6a513c4358c1dc10.tar.gz 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.
  - topspin 8y ago
    What is this 'pint' term? I thought it was a typo of 'pin' but you used it twice.
    - kiloreux 8y ago
      It was just a typo twice. Sorry for the confusion.
- dan-robertson 8y ago
  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
- mbrock 8y ago
  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_NIX_PATH 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...
ljm 8y ago
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.
chakerb 8y ago
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 https://www.youtube.com/watch?v=nuyuA43q9NE
- craftyguy 8y ago
  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..)
  - profsnuggles 8y ago
    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.
    - trylist 8y ago
      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.
orcs 8y ago
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.
- matthewbauer 8y ago
  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-try.html 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.
  - orcs 8y ago
    Thanks I'll give thema read.

73 points by grhmc 8y ago

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.

danieldk 8y ago
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 https://github.com/LnL7/nix-darwin Of course, nothing beats the real experience, so I am running NixOS on my workstation.
- 0xb100db1ade 8y ago
  I was previously running into https://github.com/NixOS/nix/issues/2244 https://github.com/NixOS/nix/issues/2244 but it looks like the problem is now fixed :tada:

Jeaye 8y ago

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

justinsaccount 8y ago

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?

kiloreux 8y ago
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/9a5f7b1630c138a82cb9ae0d6a513c4358c1dc10.tar.gz 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.
- topspin 8y ago
  What is this 'pint' term? I thought it was a typo of 'pin' but you used it twice.
  - kiloreux 8y ago
    It was just a typo twice. Sorry for the confusion.
dan-robertson 8y ago
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
mbrock 8y ago
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_NIX_PATH 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...

ljm 8y ago

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.

chakerb 8y ago

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 https://www.youtube.com/watch?v=nuyuA43q9NE

craftyguy 8y ago
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..)
- profsnuggles 8y ago
  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.
  - trylist 8y ago
    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.

orcs 8y ago

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.

matthewbauer 8y ago
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-try.html 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.
- orcs 8y ago
  Thanks I'll give thema read.