
NixOS Linux - MarcScott
http://nixos.org/
======
shared4you
NixOS has been discussed many times on HN already. However, Nix 1.9 was
released today (/yesterday for the some):

Release Notes: [https://nixos.org/releases/nix/nix-1.9/manual/#ssec-
relnotes...](https://nixos.org/releases/nix/nix-1.9/manual/#ssec-relnotes-1.9)

Downloads:
[https://hydra.nixos.org/release/nix/nix-1.9](https://hydra.nixos.org/release/nix/nix-1.9)

~~~
chriswarbo
> nix-shell can now be used as a #!-interpreter. This allows you to write
> scripts that dynamically fetch their own dependencies. For example, here is
> a Haskell script that, when invoked, first downloads GHC and the Haskell
> packages on which it depends:

Wow, that sounds super useful! I'm finding more and more default.nix and
shell.nix files scattered through my hard drive, along with wrapper scripts
for invoking nix-shells.

I can probably replace a lot of these with appropriate shebangs :)

~~~
mateuszf
This is a great idea. It would be cool if Docker supported something like
this.

------
iamcurious
I have been using it for a while as my main OS. So far it has been great.
There are a few warts, like any distro, but with NixOS the fixes tends to get
written in the main configuration file, instead of scattered among many files.
That meant a lot when I had to install it in another machine. 1) Install NixOS
with my configuration file. 2) Copy dot files to home 3) There is no step 3) !

~~~
dmix
How have you found package support? The quality/breadth of packages available
in ArchLinux AUR would stop me from using any other distro.

Arch's primary package set contains the standard set - which I assume is
similar to NixOS - but all of packages requiring tricky/custom configuration
tend to be in AUR. Which has saved me on a number of occasions from having to
follow pages of tutorials that you'd normally have to follow in order to
install things when using Linux for a desktop.

For example, setting up nice fonts with great default settings in Arch is a
single AUR package away.

~~~
asddubs
Arch is great. The only reason I switched away from it were the occasional
manual intervention updates which could just mess up your system if you
weren't paying attention.

~~~
lallysingh
Eventually I kept the install ISO on a USB key for those situations. My main
issue is how often I felt like I had to update.

~~~
agumonkey
I do have a rescue USB like you. We should write something for arch to get
rollbackable system.

ps: while googling for it, I discovered
[https://wiki.archlinux.org/index.php/Arch_Rollback_Machine](https://wiki.archlinux.org/index.php/Arch_Rollback_Machine)

------
nickpsecurity
I just commented on one IT segment not learning from the past. NixOS deserves
praise for doing the opposite: seeing various problem involved, identifying
proven ways for solving them, and implementing them into a usable solution.
Combining declarative and transactional properties into the package system as
effectively as they do is _very_ smart. I hope to see more distro's follow
suit.

~~~
vezzy-fnord
I agree wholeheartedly. However, I sincerely doubt most distros will adopt it,
for the simple reason that unifying the packaging infrastructure means more-
or-less obsoleting the concept of a distribution.

~~~
regularfry
A "distribution", at its core, is simply a (nominally curated) collection of
software which works well together. The packaging system is, or should be, a
red herring.

------
krick
Many people pointed out that NixOS has been discussed here many times already,
but nobody mentioned Guix, so here it is, for reference:
[https://news.ycombinator.com/item?id=9127679](https://news.ycombinator.com/item?id=9127679)

------
davexunit
See also GNU Guix and the associated distro GuixSD, which is based on the same
underpinnings of NixOS: [https://gnu.org/s/guix](https://gnu.org/s/guix)

~~~
technomancy
I'm much more interested in guix since it has all the same upsides but uses
scheme instead of a weird NIH language, and it also has some standards when it
comes to the licenses of the packages. (Nix disappointingly gives you the
Adobe Flash plugin when you ask it to install Firefox, etc.) Still grateful
for the solid foundation Nix provides.

~~~
chriswarbo
> it has all the same upsides but uses scheme instead of a weird NIH language

The packaging language is great, but I agree that it would make more sense to
embed it in an existing language like Scheme.

Is guix compatible with nixpkgs, or do all package definitions need to be
translated into scheme first?

> Nix disappointingly gives you the Adobe Flash plugin when you ask it to
> install Firefox, etc.

Really? I've had Nix refuse to install stuff, telling me to override the
"allowUnfree" option if I want it to work (this happens when a Haskell project
doesn't specify a license in its cabal file, for example).

I use NixOS, so maybe the defaults are different from standalone Nix.

~~~
technomancy
> I've had Nix refuse to install stuff, telling me to override the
> "allowUnfree" option if I want it to work

Oh awesome. My experience with this was quite a while ago; it sounds like they
may have fixed it since then. Glad to hear it.

------
agumonkey
Similar effort in debian :
[https://wiki.debian.org/ReproducibleBuilds](https://wiki.debian.org/ReproducibleBuilds)

(one of the project lead,
[https://people.debian.org/~lunar/blog/](https://people.debian.org/~lunar/blog/),
is a haskeller, so no surprises)

Read his blog, very interesting to see how tiny things matter.

~~~
thoughtpolice
It's worth clarifying this a bit because there are a lot of subtle
implications about what it means to be 'reproducible' or 'deterministic'.

To make the terminology clearer, I like to use the term 'deterministic' vs
'reproducible'. A deterministic build is one which, if it works, will _always_
work, and follow the same steps. A reproducible build is one that you can
reproduce identically, down to each individual SHA1-hash. This is what Debian
has spearheaded, and what they mean by 'reproducible build'.

At the moment, Nix packages are deterministic - but they are not reproducible.

If I have a specific git revision of nixpkgs (the repository containing all
package descriptions), and I say 'install mutt', I'm guaranteed that I will
always get the same build results. No matter when/where I do it. That means
I'm always going to get mutt version x.y, with dependencies A, B, and C, all
with their own exact versions, and features enabled. The same optimization
levels. The steps the compiler uses to build everything will be the same, etc.

You can essentially think of a 'nix expression' as a program that gets
compiled to a shell script, which does a build, and you run the shell script.
So if you have git revision DEADBEEF of the 'nixpkgs' set, and you 'run the
compiler', so to speak, to generate a 'builder' from a Nix expression - it
seems very obvious it will do the exact same thing, every time, regardless if
you run it today or next week.

The thing is, this is a pretty nice property. In Debian for example, if I
'apt-get install' something, I may _not_ get the same program if I do it today
and then do it tomorrow, because it may get updated. This, in practice, is
kind of a big deal actually. It means it's impossible (unless you use your own
mirror) to actually have things like prod/development environments the exact
same without imaging them like Docker. And of course, this makes rollbacks
impossible because the set of packages on your system is really a bunch of
mutable variables.

For example I used to do security research, and it was a massive pain in the
ass when I would try to 'apt-get install' mysql and get a patched version
already. I needed to write code to find this vulnerability, AND I want to
regression test that code in the future. But I can't. It makes it very hard to
do things like write automation to make sure you can detect if mysql is
vulnerable (because where will you get the pristine package you originally
tested with?)

Similarly, because of this property, you can be sure a developer's computer is
_exactly_ the same as a production or staging environment for example. Because
the 'state' of your whole computer is really a function of two arguments - a
function of your configuration.nix and your nixpkgs package set. This is what
it means to be a 'purely functional' distribution!

But the builds aren't reproducible yet. There's all kinds of actual 'non-
determinism' in the build process for any one specific project that makes bit-
for-bit reproductions difficult. For example people use `__DATE__`, or they do
weird things like rely on build mtimes, or other crazy stuff. Debian has
tracked tons of these down - so it's doable!

There is a branch of Nixpkgs that aims to fix this. Hopefully it will be
solved for NixOS 15.10.

~~~
agumonkey
So reproducible is mostly bitstream equality ? One thing I liked in the debian
effort, is, IIRC, they tried to define some form of equivalence classes to
express binaries with or without debug symbols, etc etc.

------
r0naa
I have been thinking about switching to NixOS because of the great things I
keep hearing about it. I would enjoy reading reviews from HNers, has anyone
used it as a desktop?

~~~
davidrusu
NixOS is really nice, what I enjoy most about it is it gives you the tools to
be explicit about the state of your system.

We know that implicit state and mutation are terrible in the programming world
why not extend that philosophy to your entire OS?

You might be missing some packages so make sure to check this:

[http://nixos.org/nixos/packages.html](http://nixos.org/nixos/packages.html)

before installing.

It's still early for NixOS, the OS is solid but it's likely you'll need to
package up a program or two (but it's not difficult)

~~~
imsofuture
Yep, I echo this experience. It is my main desktop OS, I am very happy with
it. Myself + another developer at my company both use it, and it's starting to
gain interest from others, seeing as it's mostly a panacea to all sorts of
environment and configuration issues.

I was pretty unhappy learning how to write the strange config language at
first, but I've made my peace with it. You will almost certainly need to write
a package or two, but there's a lot of active development to learn from, and
lots of example to cargo cult.

~~~
bdimcheff
Other developer here. I've been running nixos as my main OS since about
November after running Funtoo for a year or so before that. My tolerance for
hacking on my distro is maybe slightly above average. ;)

On the cool side: Nix is the first linux distro I've contributed to, because
it's the standard "hack, fork, pull request" process that most github-hosted
open source projects use these days.

The biggest thing is that you absolutely have to drink the nix koolaid if
you're going to run nixos. You can't really do the normal ./configure && make
&& make install, because paths to libraries are all non-standard. But once it
all really clicks, it's pretty great.

As far as desktop goes, the rest of this thread rings true for me too: most of
the important things are there, like desktop environments, window managers,
browsers, etc. There are occasionally niche/older packages that are not
available. If you're willing to learn a little bit of nix language, it's
relatively straightforward to add most packages.

------
millstone
I'm intrigued by the "atomic upgrades and rollbacks" claim. Let's say that
deploying a package requires placing two files somewhere, e.g. vmlinuz and
initrd. How can this be done atomically?

~~~
sp332
The package manager could just flock() a specific file before making any
changes.

~~~
millstone
From svn's red book:

 _By atomic transaction, we mean simply this: either all of the changes happen
in the repository, or none of them happens. Subversion tries to retain this
atomicity in the face of program crashes, system crashes, network problems,
and other users ' actions._

Does Nix mean the same thing? Is it atomic in the face of program or system
crashes?

~~~
cwp
Yes. In many cases, switching to the new version of the package is nothing
more than rewriting a symlink. Sometimes it's more involved, like restarting a
service. Either way, the cut over happens _after_ building the new package has
completed successfully. If building the package fails, it has no effect on the
running system.

I suppose there _is_ still a window in which an error could leave the system
in an inconsistent state, but it's pretty narrow, and the error would have to
be a kernel panic or something like that.

~~~
millstone
Err, are there any systems that try to cut over to a new package before it's
been built successfully?

~~~
cwp
Yes. Almost all of them, actually. By "build" I mean the whole package
installation process, including moving the compiled files into their final
destinations.

If you're upgrading an existing package, and that involves overwriting one
binary in /usr/bin and another in /usr/lib, a crash in the middle of that
process leaves the package partially upgraded, and very likely broken.

Nix never overwrites an existing package installation. Instead, it installs
the new version in a separate directory, then overwrites a symlink that
pointed to the old version with a symlink pointing to the new version.

------
lobster_johnson
NixOS would be awesome on the server, but I'm worried about security updates.
Debian/Ubuntu have a lot of resources and protocols set up for this; for users
like me, I can follow the mailing list where every package updated with
security fixes is announced, and the updates seem to meticulously follow
announcements about known vulnerabilities. How is NixOS in that regard?

------
marcosdumay
Has anybody here got the experience of running NixOS in production or on the
desktop (as the main OS, not in a never booted partition)?

~~~
cwp
Yeah, I've been running NixOS on production servers for about a year. I'm at a
small startup, so it's not huge scale (yet!) but it works great.

~~~
marcosdumay
Got any problems with package availability?

I imagine those should be very easy to fix, is that true at daily use?

~~~
cwp
All the packages I need have been part of nixpkgs, except for node packages
from npm. For those, I run npm2nix to generate nix expressions from the
package.json files. That's occasionally tricky when npm packages do "clever"
things that don't work when translated to nix. Generally, though, npm2nix
works pretty well.

I also have about 3K lines of nix code for packaging my apps, configuration,
cluster definitions for nixops etc. There's a bit of a learning curve, but I
find it really pleasant, now that I have the hang of it.

------
thrownaway122
Does this not lose the major advantage of a traditional package manager?
Namely that I update openssh in one location and all my packages are now
secure. Rather than having to update every package that depends upon openshh
separately?

~~~
ambrop7
Generally, all packages depending on that library will need to be rebuilt. But
that is automatic when you do an update, it just may take time (either for
packages to be rebuild locally, or by the build farm if you're using
channels). But you can manually do a hack to substitute a patched version when
you want the fix _right now_ :
[https://nixos.org/wiki/Security_Updates](https://nixos.org/wiki/Security_Updates)

------
bluejekyll
I'm really intrigued by NixOS, but I have to wonder if it's too much too fast,
and the Atomic project isn't a better stepping stone.

------
Profpatsch
I have been writing a guide on how to set up a desktop system with NixOS, but
I’m not quite finished yet.

I wonder how high the interest in something like that would be? I can throw up
an unfinished beta version of it if people are interested.

------
nodivbyzero
Is it better than ArchLinux?

------
_RPM
Is this proprietary? I can't find a link to the source anywhere.

~~~
ebzzry
[https://github.com/NixOS](https://github.com/NixOS)

~~~
_RPM
That doesn't have the source code to the operation system on here. So, agin, I
ask, is this damn thing GPL'd or is it on some prop. bullshit?

~~~
sondr3
[https://github.com/NixOS/nixpkgs/tree/master/nixos](https://github.com/NixOS/nixpkgs/tree/master/nixos)

If you had bothered looking in the wiki everything is listed there.

------
tormeh
At the start of this year, I tried to install various Linux distros on my
laptop using a USB drive. Only Ubuntu and OpenSUSE worked. Why is this? Is the
desktop really that irrelevant? This is not a bug report. I'm wondering what
the institutional reasons are.

~~~
robertfw
This isn't really the best place for the question, and besides that you'd need
to provide a hell of a lot more information for anyone to help you.

