My experience with NixOS (opens in new tab)

> I recently switched to NixOS and have essentially configured my OS from scratch in less than a week

That doesn't exactly scream ease of use.

> manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo

I've been trying to do this for ages with a dotfiles repo and some git aliasing. I really want to try it out, though. Any gotchas or hidden pitfalls I should look out for?

Our organization tried Nix for many years. Most of our problems were around usability, lack of documentation (including zero docstrings or type annotations in nixpkgs), and the overt unfamiliarity of the Nix expression language (asking a whole organization to learn something that seems deliberately cryptic isn't a recipe for success), and a long tail of other things. Still, at its core Nix for package management seems like the future; I just have no confidence that they're going to iron out those issues in the next 4-5 years.

Of course, none of that speaks to Guix as I haven't used it, but hopefully it's awesome and solves all of those problems.

I don't see why you say that NixOS does not have enough documentation, a commonly cited problem is the lack of tooling rather than the lack of documentation which would be fair. NixOS has the most extensive documentation out there for any linux distribution which I've used [0] and each package is documented and contains the information of any option it offers from the nix code itself and the tooling [1].

Furthermore I do not think you can compare Guix to Nix for commercial work as Nix is LGPL [2] with the packages being MIT [3] where Guix is GPL [4] allowing for Nix derivative work to be used commercially with little restriction.

I wish Guix had stayed as a guile layer for Nix and not gone off in its own direction because of the licensing ambiguity (as far as I can tell this is the reason) in Nix packages. If anyone has more insight on why this split happened or the possibility of making such layers for Nix I'm very interested in this topic.

[0] https://nixos.org/learn.html [1] https://nixos.org/nixos/packages.html?channel=nixos-19.09 [2] https://github.com/NixOS/nix#license [3] https://github.com/NixOS/nixpkgs/blob/master/COPYING [4] https://guix.gnu.org/about/

GNU Guix 1.1.0 was released just hours ago, so now is a good time to try it: https://news.ycombinator.com/item?id=22877788 :-)

Rumor has it that Guix will be included in a future Debian release too. It is already available in Arch, Gentoo, and OpenSUSE.

Guix looks really cool. I wish that it used Lisp rather than Scheme (because IMNSHO Lisp is better-suited to this kind of system software), but that ship has sailed.

It’s a real shame that rms had such a dislike of Common Lisp. The mind boggles at where the cutting edge of computing would be today had Emacs upgraded from Elisp to Common Lisp twenty or thirty years ago. Instead GNU has spent 27 years trying to turn Scheme into a sufficient systems programming language, once again illustrating the truth of Greenspun’s Tenth Law: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I would add a corollary: this also applies to any sufficiently complicated Scheme program.

I recently read that Guix was dropping support for the Linux kernel, but apparently that was a Apr 1 joke. Argh.

https://guix.gnu.org/blog/2020/deprecating-support-for-the-l...

How is Shepherd broken with LXC?

Is it sufficient to run Guix atop another distribution, or run Guix SD in a qemu VM?

Check out the NixOS for existing sysadmins workshop over at — https://github.com/ghuntley/workshops/tree/master/nixos-work...

If you want a TL;DR overview of NixOS then start here — https://github.com/ghuntley/workshops/tree/master/nixos-work...

For an advanced example of overriding nixpkg and usage of pinning/override layers (ie some mandate or reason to run super old version of grpc) — https://github.com/digital-asset/daml/blob/master/nix/nixpkg...

I used a Ansible for years before switching to NixOS. The problem with ansible is it is an imperative configuration tool that makes efforts to be declarative, but is not fully. Most runs fail to be declarative, eg even something as basic as “apt update” is irreversible. Ultimately, Ansible requires you to write code that is (State, Code) -> New State, whereas NixOS is truly Code -> State

It's similar n some way, but totally rethinking the problem.

Ansible or saltstack are essentially programs that configure your system in specific way. Ansible takes more of a list of things what to change and how, while saltstack tries to be declarative.

NixOS is essentially a Linux system described using Nix language. Whenever you make change and run nixos-rebuild, as name suggests it actually rebuilds your entire system from scratch, it is just smart enough to not do work that was already done.

Benefits of it is that you will always get to the same state no matter what. Another benefit that is quite annoying with saltstack/ansible if you remove specific application/service/whatever once you rebuild the system, it is gone, like it was never there.

You also get Nix benefits, nix never leaves anything in half state changes are atomic, either they are applied successfully or not, if a change broke something, you can easily rollback. Things like for example changing KDE to Gnome or replacing Xorg with Wayland is no harder than replacing emacs with vim (or vim with emacs, if I upset you).

The way how Nix works allows different packages using even conflicting libraries. For example you can have two applications using different openssl version etc.

If you have one application and you need to apply a custom patch to it or maybe even use a different version. In traditional OS good sysadmins would create a custom RPM package an install it. In Nix you just override the definition, and if a cached build is not available, Nix will be smart enough to compile the code (this means no need for artifactory and uploading custom packages there, though to prevent recompiling every time, you should set up a caching server (there's also caching as a service option if you don't want to manage it) or you can even use S3 bucket.

Basically Nix and NixOS is rethinking how building/deploying/packaging does it offers many benefits, CMS like ansible/saltstack/chef/puppet/cfengine etc are no longer needed. It can be used for having comon developement environment, can be used for building, ci/cd etc.

NixPkgs amongst other things replace rpm/deb packages - and having a package install declared in a git repo is awesome compared to installing a pre-packaged compressed blob.

Nixos keeps the entire system state based on a declaration and lets you move back/forward on whole system configurations super quick.

Ansible and salt does not really declare a complete system state but rather try to manipulate the underlying system. Ansible keeps no state at all actually.

Nixos+pkg is all about declaring and keeping a state of a machine as much as reasonably possible. It has it’s flaws but the end result is still much more coherent and predictable compared to traditional configuration management.

I would say Nix's cloud native story is "best in class".

you can take any nixos configuration and turn it into a cloud image https://github.com/nix-community/nixos-generators

You can take any nix package and turn it into a docker image https://news.ycombinator.com/item?id=20720922 https://news.ycombinator.com/item?id=18111954

You can even use Nix to create and deploy cloud resources ala Terraform:

github.com/nixos/nixops

Some other notable uses of Nix in cloud native landscape:

https://github.com/saschagrunert/kubernix - a KIND alternative

https://github.com/xtruder/kubenix a Nix DSL for defining and deploying entire kubernetes clusters + deployments (combines nix's docker image building support and deployment support for and end to end cloud-native solution)

I personally think Nix should heavily market itself to the CLoud Native buzzword hype train. as it's my favourite weapon in this space

You can build docker images with Nix (https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools), but right now it wouldn't make much sense to use the NixOS modules (like nginx) for that. The modules in NixOS assume a systemd based environment and are thus not suitable for use in containers (in the end, most service modules generated systemd units).

What you can do, though, is use Nix to build a container image with an nginx config. You just can't use the abstractions present in NixOS as-is to generate the nginx config, you'd have to write the nginx config yourself (just as you would if you use a Dockerfile). You could perhaps re-use parts, or modify the NixOS modules, though.

Not having used it, maybe NixOps is the thing you want.

Chef Habitat might be more what you're looking for in that regard, it very much feels like an intellectual derivative of NixOS and focuses on the cloud native story

You might be interested in lamdera. It abstracts away database access, data transport and data encoding between client end server. Here is a talk about it: https://www.youtube.com/watch?v=nSrucNcwlA8

If you're interested, you can probably get an invite from @supermario on the elm slack, or on: https://lamdera.app/

Disclaimer: I'm not affiliated with the project, but I've met Mario in person and he's a cool dude with great ideas ;)

> doesn't push her to make unneccessary database calls for each request when business logic becomes significantly complex.

Are you objecting to holding all state in a database, or something else? If so, the only real alternative is to have individual servers hold state, which seems like a poor choice; one way or another you're going to hit the CAP theorem, and databases are well-optimized for getting you the best results from CAP that you're going to.