5 ms·

NixOS 16.09 released

151 points by xaduha 10y ago

bkjsbkjdnf 10y ago
The main issue I had while using NixOS is that it has a small and somewhat broken set of packages. This is compounded by the very incomplete Nix documentation - its way too hard to create new packages.
- grhmc 10y ago
  I agree the documentation needs work. It can be a real exercise in institutional knowledge sometimes to piece things together. I'd love to help you package something new, or fix an existing package if you would like. The thing that kept me going is how easy it was to fix ... after learning the incantations. I think the project as a whole would welcome suggestions on where to improve docs as well, and would _definitely_ appreciate some new docs being written. It is hard to do this once you're too familiar :(.
  - voltagex_ 10y ago
    I don't use NixOS, but would raising documentation bugs the same way you raise bugs against code help?
    - grhmc 10y ago
      I would imagine so :)
- mjhoy 10y ago
  > its way too hard to create new packages Perhaps it is hard to discover how to, but I was about to post here and say one of the best things about nix is how easy it is to hack and add packages. It does require a bit of learning about how it works, but once you do the whole system is quite understandable. It's also very easy to test out things locally, overriding and extending the nix package collection. It is fairly straightforward to set up, build and install your own local projects as nix packages. Even I -- a mere web developer, who mostly uses OS X -- got a package definition merged into the main repository, it was that simple. One series of blog posts that is good in this regard is the Nix pill series: http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-should-give-it-try.html http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-sho...
- oever 10y ago
  but you get the benefit of having you package on OS X, BSD and most Linuxes (except Android) too.
agumonkey 10y ago
Quick question, the url https://nixos.org/nixos/download.html https://nixos.org/nixos/download.html lists the same url for both 32 and 64bits iso, I wonder if these are multiarch images or just an error.
- grhmc 10y ago
  An error for sure, we're on it!
  - agumonkey 10y ago
    Aight, have fun. And thanks for the rest.
- rokgarbas 10y ago
  an error (i think) https://github.com/NixOS/nixos-homepage/commit/70bcfbb64a0e3ab8aa78d994ad8eefe2088880cd#diff-8265195d7d798d6666a3df086f7a24f9R46 https://github.com/NixOS/nixos-homepage/commit/70bcfbb64a0e3...
- grhmc 10y ago
  Fixed, thank you for the report!
  - agumonkey 10y ago
    Cool, I half contributed to NixOs. My life's now complete.
jxy 10y ago
If you found out through gdb that your code compiled with -O0 was still somehow optimized by gcc, or if you found out that your gcc did not optimize your code aggressively enough although you gave it -Ofast, check out this issue [0]. [0] https://github.com/NixOS/nixpkgs/issues/18995 https://github.com/NixOS/nixpkgs/issues/18995 Yeah. The devs believed it was okay to make gcc -O2 by default and impossible to override from the command line you gave to gcc. If you encountered this issue I hope google could quickly bring you to that issue on github. Good luck and don't waste hours to figure out why.
- secure 10y ago
  Related: enabling debug symbols for all packages by default (in a separated output): https://github.com/NixOS/nixpkgs/issues/18530 https://github.com/NixOS/nixpkgs/issues/18530
  - oever 10y ago
    Having debug symbols enabled should be the default in my opinion. Especially in a partially self-compiled distribution like NixOS. The threshold to submitting bugs should be low. Unf I'm seeing a unicorn (GitHub fail whale) currently, so I cannot see the issue.
- grhmc 10y ago
  It looks like there is a workaround. I'm sorry this broke your optimizations :(
- AndyKelley 10y ago
  Meanwhile, if you were me, you spent weeks wondering what was happening before finally tracking the problem down and filing the issue :-) I still love NixOS! A little hiccup here and there but it's still a great idea that I am happy to support.
ramblenode 10y ago
If I had to give a one sentence summary of this release, it would contain "security" and "closure size". Thanks to the core devs who made this possible.
rdtsc 10y ago
> the closure size of a minimal NixOS container went down from ~424 MiB in 16.03 to ~212 MiB in 16.09 Oh nice. Very impressive.
danharaj 10y ago
I use NixOS for my personal development and on professional projects that are live on NixOS right now. AMA
- tikhonj 10y ago
  What do you do for Haskell development?
  - danharaj 10y ago
    At work we use nix+cabal, not nix+stack. Not for any compelling reason other than we've been in business longer than stack has integrated with nix. We have a repo for our consolidated framework that implements our workflow and ops infrastructure parameterized on the project we're building, so we check this in as a submodule in a new project. One thing we do in particular is that we generate nix expressions from cabal files at build time, so we only need to maintain one without updating the other with cabal2nix with every change. With all this in place in a project, building is as easy as nix-build. Development is as easy as nix-shell. For convenience we have scripts that wrap the workflow for activating a ghci or ghcid shell and some other functions. Deploying to AWS is easy, even though I've never done it myself. One problem we have is build times with nix. In order to ameliorate this, we have a build server set up with the out of the box nix infrastructure. A developer only needs to build when they make their own changes; within a few minutes of a push the build server will compile the new project derivations and they'll be available to everyone else as binaries. It all Just Works. As for specifics, the currently implemented Haskell infrastructure in Nix is pretty good. For my personal development I have a few auxiliary scripts a friend of mine cooked up to do very streamlined development. I'm still getting used to it so I can't say much on that front, but it's a very thin wrapper over the stuff in nix. The nix language is really gnarly, but if you can grok it then you can program your build environments in a purely functional way, and that's amazing! I would recommend to every developer that they set up their environment the way they want it. Nix is very flexible and robust. It will handle everything for you, you just need to tell it what you want.
- seagreen 10y ago
  Can you share your NixOS config?
edude03 10y ago
Just did the upgrade an hour ago (from 16.03) super fast and easy and everything still works. Great job nixos team. For those wondering the procedure is basically nixos-channel add /path/to/16.09 nixos-rebuild switch --upgrade
- cgdub 10y ago
  Because of how Nix works, upgrading should leave your system in an identical state as if you had done a fresh install. You can even downgrade if you want. I've switched to unstable and back to 16.03 (and now to 16.09) without a reinstall and everything still works perfectly.
ris 10y ago
Hardened builds. Excellent work.

151 points by xaduha 10y ago

The main issue I had while using NixOS is that it has a small and somewhat broken set of packages. This is compounded by the very incomplete Nix documentation - its way too hard to create new packages.

grhmc 10y ago
I agree the documentation needs work. It can be a real exercise in institutional knowledge sometimes to piece things together. I'd love to help you package something new, or fix an existing package if you would like. The thing that kept me going is how easy it was to fix ... after learning the incantations. I think the project as a whole would welcome suggestions on where to improve docs as well, and would _definitely_ appreciate some new docs being written. It is hard to do this once you're too familiar :(.
- voltagex_ 10y ago
  I don't use NixOS, but would raising documentation bugs the same way you raise bugs against code help?
  - grhmc 10y ago
    I would imagine so :)
mjhoy 10y ago
> its way too hard to create new packages Perhaps it is hard to discover how to, but I was about to post here and say one of the best things about nix is how easy it is to hack and add packages. It does require a bit of learning about how it works, but once you do the whole system is quite understandable. It's also very easy to test out things locally, overriding and extending the nix package collection. It is fairly straightforward to set up, build and install your own local projects as nix packages. Even I -- a mere web developer, who mostly uses OS X -- got a package definition merged into the main repository, it was that simple. One series of blog posts that is good in this regard is the Nix pill series: http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-should-give-it-try.html http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-sho...
oever 10y ago
but you get the benefit of having you package on OS X, BSD and most Linuxes (except Android) too.

agumonkey 10y ago

Quick question, the url https://nixos.org/nixos/download.html https://nixos.org/nixos/download.html lists the same url for both 32 and 64bits iso, I wonder if these are multiarch images or just an error.

grhmc 10y ago
An error for sure, we're on it!
- agumonkey 10y ago
  Aight, have fun. And thanks for the rest.
rokgarbas 10y ago
an error (i think) https://github.com/NixOS/nixos-homepage/commit/70bcfbb64a0e3ab8aa78d994ad8eefe2088880cd#diff-8265195d7d798d6666a3df086f7a24f9R46 https://github.com/NixOS/nixos-homepage/commit/70bcfbb64a0e3...
grhmc 10y ago
Fixed, thank you for the report!
- agumonkey 10y ago
  Cool, I half contributed to NixOs. My life's now complete.

jxy 10y ago

If you found out through gdb that your code compiled with -O0 was still somehow optimized by gcc, or if you found out that your gcc did not optimize your code aggressively enough although you gave it -Ofast, check out this issue [0]. [0] https://github.com/NixOS/nixpkgs/issues/18995 https://github.com/NixOS/nixpkgs/issues/18995 Yeah. The devs believed it was okay to make gcc -O2 by default and impossible to override from the command line you gave to gcc. If you encountered this issue I hope google could quickly bring you to that issue on github. Good luck and don't waste hours to figure out why.

secure 10y ago
Related: enabling debug symbols for all packages by default (in a separated output): https://github.com/NixOS/nixpkgs/issues/18530 https://github.com/NixOS/nixpkgs/issues/18530
- oever 10y ago
  Having debug symbols enabled should be the default in my opinion. Especially in a partially self-compiled distribution like NixOS. The threshold to submitting bugs should be low. Unf I'm seeing a unicorn (GitHub fail whale) currently, so I cannot see the issue.
grhmc 10y ago
It looks like there is a workaround. I'm sorry this broke your optimizations :(
AndyKelley 10y ago
Meanwhile, if you were me, you spent weeks wondering what was happening before finally tracking the problem down and filing the issue :-) I still love NixOS! A little hiccup here and there but it's still a great idea that I am happy to support.

ramblenode 10y ago

If I had to give a one sentence summary of this release, it would contain "security" and "closure size". Thanks to the core devs who made this possible.

rdtsc 10y ago

> the closure size of a minimal NixOS container went down from ~424 MiB in 16.03 to ~212 MiB in 16.09 Oh nice. Very impressive.

danharaj 10y ago

I use NixOS for my personal development and on professional projects that are live on NixOS right now. AMA

tikhonj 10y ago
What do you do for Haskell development?
- danharaj 10y ago
  At work we use nix+cabal, not nix+stack. Not for any compelling reason other than we've been in business longer than stack has integrated with nix. We have a repo for our consolidated framework that implements our workflow and ops infrastructure parameterized on the project we're building, so we check this in as a submodule in a new project. One thing we do in particular is that we generate nix expressions from cabal files at build time, so we only need to maintain one without updating the other with cabal2nix with every change. With all this in place in a project, building is as easy as nix-build. Development is as easy as nix-shell. For convenience we have scripts that wrap the workflow for activating a ghci or ghcid shell and some other functions. Deploying to AWS is easy, even though I've never done it myself. One problem we have is build times with nix. In order to ameliorate this, we have a build server set up with the out of the box nix infrastructure. A developer only needs to build when they make their own changes; within a few minutes of a push the build server will compile the new project derivations and they'll be available to everyone else as binaries. It all Just Works. As for specifics, the currently implemented Haskell infrastructure in Nix is pretty good. For my personal development I have a few auxiliary scripts a friend of mine cooked up to do very streamlined development. I'm still getting used to it so I can't say much on that front, but it's a very thin wrapper over the stuff in nix. The nix language is really gnarly, but if you can grok it then you can program your build environments in a purely functional way, and that's amazing! I would recommend to every developer that they set up their environment the way they want it. Nix is very flexible and robust. It will handle everything for you, you just need to tell it what you want.
seagreen 10y ago
Can you share your NixOS config?

edude03 10y ago

Just did the upgrade an hour ago (from 16.03) super fast and easy and everything still works. Great job nixos team. For those wondering the procedure is basically nixos-channel add /path/to/16.09 nixos-rebuild switch --upgrade

cgdub 10y ago
Because of how Nix works, upgrading should leave your system in an identical state as if you had done a fresh install. You can even downgrade if you want. I've switched to unstable and back to 16.03 (and now to 16.09) without a reinstall and everything still works perfectly.

ris 10y ago

Hardened builds. Excellent work.