NixOS 14.12 released | Hacker News Reader

NixOS 14.12 released

lists.science.uu.nl

135 pointsiElectric231 comments

If you're not willing to install a whole new OS, nix , the package manager of nixos, is standalone and can be run in a single user without interferring with system packages. It's a great way to familiarize yourself with the system. [0]

I use Nix together with ArchLinux now to set up consistent development environments and it has been great. It's also blazingly fast because of Hydra[1], their continious build system.

[0] http://nixos.org/nix [1] http://nixos.org/hydra

I'm currently using the same setup (arch + nix). It's nice.

However, some practical aspects of nix are quite ugly. It lacks decoupling between packages and optional runtime dependencies. You can disable optional dependencies, but this would lead to a different package hash negating the use of prebuilt binaries.

Therefore, the culture seems to have all default package builds with all optional dependencies on. This leads to situations such as installing mutt and getting python too! (mutt -> gpgme -> glib -> python)

Last time I checked, if you installed git, you'd also get subversion, etc. Quite sad, given that nix is full of so many fantastic ideas.

Indeed, it was a neat way to develop in isolation when I needed it (PHP).

> can be run in a single user without interferring with system packages.

Can it? It seemed to require root to install when I last tried.

The default setup requires root, but everything is does is contained to /nix and ~/.nix* . /nix (the part that requires root) is just a cache, and you can actually change the location to somewhere user-local in the settings. However, this affects all the package hashes, which will make Nix recompile everything instead of reusing the prebuilt binaries from Hydra.

How does package security work in Nix? How does security compare to apt?

Many may wonder like me WTF is NixOS?

The key feature is 'declarative system configuration'. Sort of Puppet/Chef/Ansible/CFengine build-in. Heavily oriented on DevOPs culture.

The OS allows you to test package installs without the fear of breaking the system. You can always roll back to a previous known-good state.

I've always thought it was heavily based on the ideas from functional programming (making state explicit, being able to move more freely through time). In any case it precedes the recent hype around DevOps.

Is it really based on devops culture? To me it always made sense to be able to say I want to do X, Y and Z... figure it out. Even distributions that have state-based procedural package managers could at least keep a list of things I actually want to use. I never understood Debian doesn't provide this by default, at the very list let me see the list of packages I explicitly installed. If I accidently install Gnome 3 and then remove it I'm left with a lot of useless junk everywhere bloating up my system.

PS. I know there are some really fickle and obscure commands to get the list of explicitly installed packages

PPS. Maybe Gnome 3 isn't the best example, except that it would definitely be an accident if I installed it.

PPPS. The useless junk floating around probably shouldn't bother me that much, but it does.

apt-get autoremove

As you noted, yes, Debian has a list of the packages you explicitly installed.

The problem is with the recommendations, they are very numerous, and any package that the maintainer thinks should be used together with one of your automatically installed ones will make it stay.

Anyway, NixOS is based on immutable states. It keeps lots and lots of states (much worse than Debian on that), but they shouldn't be a problem for anything (I've not used it enough in practice to be sure).

Not quite. Chef/puppet/ansible are configuration management and server automation tools. While you could design a .nix package that describes the state of the whole sever that would be tedious.

Ansible and nix compliment each other nicely as tools. Nix gets you highly reliable package management using principles from functional languages.

Gnu guix is an alternative to Nix (the package manager).

> While you could design a .nix package that describes the state of the whole sever that would be tedious.

Except this is pretty much what NixOS does (compared to Nix).

It's a Linux distribution. See http://distrowatch.com/table.php?distribution=NixOS .

A list of changes: http://hydra.nixos.org/build/18399157/download/2/nixos/sec-r...

While nix the package manager is obviously the main point of interest in NixOS, could somebody who has actually used NixOS comment on other aspects of it. How's the packaging of software, does NixOS try to follow upstream as closely as possible, or do they push towards some other direction? Do they eg. aim to provide some sensible default configurations or do they expect people to do their own thing? How is the software selection in the repositories, are there lots of packages missing or out-of-date? And so on..

They tend to track upstream closely, but patch stuff to make sure it works well with their relatively novel packaging.

Packages seem to tend to be barebones, but I'm not sure if that's intentional. For example, Vim didn't ship with a default config file for quite a while, contrary to even Arch.

Congrats to the Nix team! A lot of new packages in this release.

See also: GNU Guix, based on Nix. https://gnu.org/s/guix

This is great! Hopefully I can ditch Arch soon.

Would you mind sharing your reasons for switching? I'm currently using Arch as well and only stumbled upon NixOS thanks to this post.

1) My system breaks once every year. Literally just once.

2) NixOS package management is similar to the Arch system because binary installs come first, and AUR installs (source builds) come second.

3) NixOS has an easier/simpler rollback and configuration system than Arch.

4) Manjaro, a more stable Arch distro, doesn't fit me without having to build a custom Linux image. It's been a while, so this might have changed since I've last checked it out.

5) FreeBSD is enticing, but if I have to go BSD, it's OpenBSD or DragonFly. I've been thinking *BSD ever since the switch to systemd...

If you don't pay extra care to updating Arch, it's possible that an update will brick your OS install requiring a fresh install. Granted, they usually tell you on their websites when this happens along with how to not brick your OS, but you have to be diligent to check every time.

You should check pacmatic[1], which checks the official website for you and informs you about breaking updates. Along with this, it informs you of any config files (*.pacnew) you have to manually update.

Which brings me to my second problem with Arch: every other update I have to manually inspect the changes on various config files and merge with my personal changes.

[1] https://wiki.archlinux.org/index.php/Enhance_system_stabilit...

I've never had an arch update brick my system. It's really pretty hard to brick a 'nix.

When I ran arch (and I ran it for quite a while) I had the occasional breakage, but I don't recall ever having a break that I needed to boot into a live environment to fix, let alone require a re-install.

Granted, it might be quicker to re-install if you haven't fermented in linux-land for long enough to know how to figure out what's borked and what you need to do to fix it, particularly if you would need to boot a live usb or something, but I'm struggling to think of things that would actually brick a linux system these days that aren't either hardware failures, some really crazy filesystem corruption, literally rm -rf / for way too long, or being installed on a machine with no alt-boot method.

On the bright side, reinstalling isn't too bad unless you don't use separate partitions.

All that said, there is a pretty hefty active maintenance cost to running Arch. At least they're explicit about it.

From my experience, at most that can go wrong is the update fails or similar non-fatal issue may arise. I haven't been using Arch for very long (not more than a year), but I never had any issues that would break the system. As you already mentioned, they post the the necessary info on the website and even now after the pacman database format upgrade when pacman fails it specifically tells you to run a command to fix this. Oh and don't forget the massive wiki, that one's a killer.

Plus I really like this whole rolling release philosophy with up-to-date packages :)

You can have up to date packages with NixOS too. Just have to change the default channel.

The only update from Arch that has bricked my system was when they reconfigured the whole file system, to unify things (as opposed to it being split up between {/usr{/local,},}/bin) -- that was a nasty shock. In all my years of using Arch (I switched from Gentoo in 2010), I've really had very few problems. It's a very friendly yet powerful and customizable distribution, in my estimation.

Pacman doesn't do transactional upgrades and rollbacks. Nix does.

I quite like Arch. Definitely has the package manager with the coolest command name, although the usage and flags are bit archaic, they should probably steal some more ideas from FreeBSD. It allows me to build relatively minimal systems without having to compile everything from source. (yes, I'm a recovering Gentoo user)

I recently installed the latest Ubuntu just to see where that has gone since I last used it years ago. I had to wipe it after less than one hour.

I really should play around again with NixOS, looks like it has progressed quite a lot since I last encountered it.

"they should probably steal some more ideas from FreeBSD"

Which ideas would you think are worth stealing from there?

I think you mean stole, past tense. If you read much about the rationale of Arch, it was meant to imitate FreeBSD quite closely. This was especially true before the systemd migration, when there were only 1 or a few files in /etc you had to touch to configure almost everything in the system. It is clear they dervied the AUR concept from the ports system of FreeBSD fame.

https://wiki.archlinux.org/index.php/arch_compared_to_other_...

Reply on news.ycombinator.com