
NixOS 16.09 released - xaduha
https://nixos.org/nixos/manual/release-notes.html#sec-release-16.09
======
jxy
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
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
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.

------
ramblenode
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
> 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
I use NixOS for my personal development and on professional projects that are
live on NixOS right now. AMA

~~~
tikhonj
What do you do for Haskell development?

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

------
agumonkey
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
An error for sure, we're on it!

~~~
agumonkey
Aight, have fun. And thanks for the rest.

------
edude03
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
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
Hardened builds. Excellent work.

------
bkjsbkjdnf
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
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_
I don't use NixOS, but would raising documentation bugs the same way you raise
bugs against code help?

~~~
grhmc
I would imagine so :)

