The thing to remember about NixOS is it’s not a distribution of KDE or Gnome or manager of anything, it’s a declarative way of configuring those things and allows you to easily roll back changes to entire OS.
It’s a little bit of investment to get started but one you get rolling it’s such a breath of fresh air to be able to manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo.
That doesn't exactly scream ease of use.
I had a similar experience with NixOS and I love it.
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?
If you use nix-env you're just polluting your environment in an imperative way and that is pretty much going against Nix' declarative nature.
Also make sure you allocate enough space on your root partition so you don't have to run garbage collection all the time.
Earlier Nix had additional NixOps but that too now is available with Guix deploy. I am waiting when I can run Guix within a lxd container, shepherd init still has some rough edges with LXD container init.
Both are great piece of software and a new take on building OS and distribution. They are ahead of their time might take another 4-5 years before they become more mainstream.
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.
This gives me hope things are getting better.
Also recently I funded a project for improving error messages in Nix https://opencollective.com/nix-errors-enhancement
Ther is also now a dedicated Nix Marketing team which are working on improving the website and the documentation
I do wonder about the "deliberately cryptic" nature of Nix's expression language. It is, in fact, deliberately designed for simplicity, to be a basic syntax for a language that is purely functional and lazy but not much else ([0] p69). When folks complain about the Nix expression language, as they often do, I ask them: What would you change? How would you do it?
I think that it is bad that an entire team does not have the bandwidth to learn an entirely new language, but good that the team is not willing to spend time on things which they don't think are important.
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/
Linux kernel itself is GPL, so not sure what’s the issue with Guix. Obviously Guix package repository only support libre software, but if you need to use proprietary repository try Guix-nonfree[1].
I am happy Guix and GuixSD exist. Check the gnu Guix mailing list archive both have same roots but are sufficiently different[2].
[1] https://github.com/guix-users/guix-nonfree
[2] https://lists.gnu.org/archive/html/guix-devel/2019-09/msg002...
Rumor has it that Guix will be included in a future Debian release too. It is already available in Arch, Gentoo, and OpenSUSE.
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.
https://guix.gnu.org/blog/2020/deprecating-support-for-the-l...
Is it sufficient to run Guix atop another distribution, or run Guix SD in a qemu VM?
[1] https://lists.gnu.org/archive/html/help-guix/2018-10/msg0006...
Nix as a build tool is also quite nice, but honestly NixOS is the main attraction for me.
Check this video out from Rob Vermaas. It's a decent case study of how Nix was applied at LogicBlox
https://github.com/ghuntley/dotfiles-nixos
Steal away and enjoy.
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...
Not surprising, given that Nix was a academic research project, and Cardano has a good network of academic researchers working to solve hard blockchain problems.
https://iohk.io/en/blog/posts/2019/02/06/how-we-use-nix-at-i...
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.
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.
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
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.
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 ;)
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.