NixOS 16.09 released | Hacker News Reader

NixOS 16.09 released

nixos.org

151 pointsxaduha30 comments

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

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.

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.

Related: enabling debug symbols for all packages by default (in a separated output): https://github.com/NixOS/nixpkgs/issues/18530

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.

It looks like there is a workaround. I'm sorry this broke your optimizations :(

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.

> 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.

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

What do you do for Haskell development?

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.

Can you share your NixOS config?

Sure! I need to scrub some bits that have to do with work, but I can paste it up and link it here tomorrow morning.

Here it is!

http://pastebin.com/hSF1zbr9

Dvorak! And nice to see you've got fonts working, that's not something I've messed with. Thanks!

You'll also notice that I put my nix configuration in a shared /home directory instead of /etc/nixos. I think I'm the only person to ever do this because I am neurotic and having to sudo to use version control on my OS config isn't my fave workflow.

Quick question, the url 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.

An error for sure, we're on it!

Aight, have fun. And thanks for the rest.

an error (i think)

https://github.com/NixOS/nixos-homepage/commit/70bcfbb64a0e3...

Fixed, thank you for the report!

Cool, I half contributed to NixOs. My life's now complete.

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

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.

Hardened builds. Excellent work.

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.

> 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-sho...

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 :(.

I don't use NixOS, but would raising documentation bugs the same way you raise bugs against code help?

I would imagine so :)

but you get the benefit of having you package on OS X, BSD and most Linuxes (except Android) too.

Reply on news.ycombinator.com