My experience with NixOS(blog.patchgirl.io)
blog.patchgirl.io
My experience with NixOS
https://blog.patchgirl.io/nixos/2020/03/31/nixos.html
94 comments
> 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.
That doesn't exactly scream ease of use.
NixOS isn’t easy to use. It’s very powerful though. It gives you the ability to configure your whole OS, including all of your packages and configurations, in one declarative file. It reproduces the entire installation from this file in a way that’s fully immutable and hash-perfect (with minimal building from source). Very cool.
> in one declarative file
Which is not always up to date, and exposes all the available options. I found myself often need to dig into nixpkgs and add missing options myself during the time I was trying out NixOS.
And believe me, that wasn't a pleasant experience.
Which is not always up to date, and exposes all the available options. I found myself often need to dig into nixpkgs and add missing options myself during the time I was trying out NixOS.
And believe me, that wasn't a pleasant experience.
Not sure if it was available when you tried, but this is useful when configuring, it is processed from nixpkgs and indexes all options that are available: https://nixos.org/nixos/options.html
It does sound pretty awesome. Maybe I'll try a hit with VirtualBox.
I tried that initially but never spent enough time using it in a VM to really learn it.
In the end, I just decided to take the plunge and set it up as my main OS after a year of procrastinating around trying it out. I've been using it for about 4 years now, and wouldn't go back to a traditional distro.
And finally, 4 years on, I just set up a new laptop and it was much easier than its ever been before. I just had to copy over my existing nix config, and nix built out the whole configuration and my user environment (with home-manager [0]). It's always been a bit of a pain setting up my profile before this, and maintaining my .emacs.d, etc; now it's all managed.
[0] https://github.com/rycee/home-manager
In the end, I just decided to take the plunge and set it up as my main OS after a year of procrastinating around trying it out. I've been using it for about 4 years now, and wouldn't go back to a traditional distro.
And finally, 4 years on, I just set up a new laptop and it was much easier than its ever been before. I just had to copy over my existing nix config, and nix built out the whole configuration and my user environment (with home-manager [0]). It's always been a bit of a pain setting up my profile before this, and maintaining my .emacs.d, etc; now it's all managed.
[0] https://github.com/rycee/home-manager
What he said.
You can get up and running in probably a day (you need to learn a few things), I'm guessing what they mean is, configured exactly how they want.
I had a similar experience with NixOS and I love it.
I had a similar experience with NixOS and I love it.
And getting things like bluetooth/screen light adjustment/and a list of annoying things right on a laptop.
> 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?
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?
My tip: don't use nix-env to install packages like it's Aptitude or Pacman, use `nix run` if you need a package temporarily, home-manager if you need a user-level package permanently, or just straight up change the configuration.nix to include the package as a system-wide one.
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.
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.
To distill that to one sentence, home-manage is NixOS for dotfiles and you can use it on Non-NixOS Linux, I believe, too.
One common beginner mistake is attempting to modify files in the immutable store directly. Don't do that. The system is read only for a reason.
Also make sure you allocate enough space on your root partition so you don't have to run garbage collection all the time.
Also make sure you allocate enough space on your root partition so you don't have to run garbage collection all the time.
I made the switch from Arch about a week ago. So far, great experience. I love the fact that my system state is reproducible and if I use version control on my dotfiles, I basically have a full backup of the look and feel of my workstation. VFIO with GPU passthrough works flawlessly. Setting up FDE with LUKS during and after the install was a breeze as well. Really enjoyed the whole experience.
Being able to switch between wildly different possible system configurations like xorg+i3 and wayland+sway by executing a few commands and having version control while doing so is incredible.
However one thing I'm struggling with now is "overlays". Simply trying to get "electrum" to install but nixpkgs has 3.3.8, I am looking to build 4.0.0a from HEAD of master. This should be simple to do with something like overlaying this portion from file electrum/default.nix [0]
Python, NodeJS and Ruby development might also be slightly frustrating if you are used to installing things globally.
[0] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...
Being able to switch between wildly different possible system configurations like xorg+i3 and wayland+sway by executing a few commands and having version control while doing so is incredible.
However one thing I'm struggling with now is "overlays". Simply trying to get "electrum" to install but nixpkgs has 3.3.8, I am looking to build 4.0.0a from HEAD of master. This should be simple to do with something like overlaying this portion from file electrum/default.nix [0]
src = fetchurl {
url = "https://download.electrum.org/${version}/Electrum-${version}.tar.gz";
sha256 = "1g00cj1pmckd4xis8r032wmraiv3vd3zc803hnyxa2bnhj8z3bg2";
};
fetchFromGitHub {
owner = "spesmilo";
repo = "electrum";
sha256 = "LATESTHASH";
};
Python, NodeJS and Ruby development might also be slightly frustrating if you are used to installing things globally.
[0] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...
What you are trying to do doesn't look like an overlay, but an override[1].
you can do something like this:
[1] https://nixos.org/nixpkgs/manual/#sec-pkg-overrideAttrs
Edit: looks like the version is on GitHub, and after I posted seems like you already figured it out, but maybe it can help someone else, typically that's the way to override.
you can do something like this:
let
new_electrum = pkgs.electrum.overrideAttrs (oldAttrs: rec {
name = "${oldAttrs.pname}-${version}";
version = "4.0.0a";
src = fetchurl {
url = "https://download.electrum.org/${version}/Electrum-${version}.tar.gz";
sha256=pkgs.lib.fakeSha256;
};
})
in
<then use "new_electrum">
[1] https://nixos.org/nixpkgs/manual/#sec-pkg-overrideAttrs
Edit: looks like the version is on GitHub, and after I posted seems like you already figured it out, but maybe it can help someone else, typically that's the way to override.
You can use GitHub's automatic generation of archives even for specific git commits.
There is no version 4.0.0a of Electrum, it has not been released, it is misleading to refer to it.
There is no version 4.0.0a of Electrum, it has not been released, it is misleading to refer to it.
There's actually fetchFromGitHub which takes care of it, looks like parent already figured it out:
https://news.ycombinator.com/item?id=22883382
He also needed to change some dependencies so it's more complex than what I wrote.
https://news.ycombinator.com/item?id=22883382
He also needed to change some dependencies so it's more complex than what I wrote.
I have something like this in my overlays.nix:
self: super:
let
callPackage = super.callPackage;
in {
darktable = callPackage
./pkgs/darktable { inherit (super) darktable; };
}
{ darktable, fetchurl, ... }:
darktable.overrideAttrs (_: rec {
version = "3.0.0";
src = fetchurl {
url = "https://github.com/darktable-org/darktable/releases/download/release-${version}/darktable-${version}.tar.xz";
sha256 = "7195a5ff7ee95ab7c5a57e4e84f8c90cc4728b2c917359203c21293ab754c0db";
};
})Thank you. I was able to move forward similarly as well. Good to see the solution I arrived at isn't too far from yours.
self: super:
{
electrum = super.electrum.overrideAttrs(old: rec {
preBuild = old.preBuild + ''
# Patch unnecessarily tight dependency on ecdsa version
substituteInPlace ./contrib/requirements/requirements.txt --replace 'ecdsa>=0.14' 'ecdsa>=0.13'
additionalInputs = with super.python37Packages; [
python-jsonrpc-server
];
propagatedBuildInputs = old.propagatedBuildInputs ++ additionalInputs;
src = super.fetchFromGitHub {
owner = "spesmilo";
repo = "electrum";
rev = "223b62554ead397bb94013c0d9c95b63a0708ea6";
sha256 = "05djndhdggsw0r9pqn3gnb31nvzghgcsg05r3f7b6hwz84zbl22r";
fetchSubmodules = true;
};
});
}how do you know the dependency bound is too tight?
yes, it's possible that there was reason for requiring newer version, especially since it is a bitcoin wallet and this looks like a cryptographic library.
The better way would be to also update that package to required version.
The better way would be to also update that package to required version.
Can you share the passthrough setup?
Of course. Here it is.
And that's about it really. All you need to do after this is to go to virt-manager and create a new VM and add your GPU.
boot.kernelModules = [ "kvm-amd" "vfio_virqfd" "vfio_pci" "vfio_iommu_type1" "vfio" ];
boot.extraModprobeConfig = "options vfio-pci ids=10de:1e04,10de:10f7,10de:1ad6,10de:1ad7";
boot.kernelParams = [ "amd_iommu=on" /*"video=efifb:off" if you have only one GPU and want to keep the vBIOS intact*/ ];
virtualisation = {
lxc.enable = true;
lxd.enable = true;
libvirtd = {
enable = true;
qemuOvmf = true;
qemuVerbatimConfig = ''
namespaces = []
dynamic_ownership = 0
'';
};
};
And that's about it really. All you need to do after this is to go to virt-manager and create a new VM and add your GPU.
You might want to enable automatic gc either way just so it's cleared out every now and then.
https://nixos.org/nixos/options.html#nix.gc
https://nixos.org/nixos/options.html#nix.gc
[deleted]
NixOS is good, if you found not enough documentation, try Guix and may be GuixSD. It uses guile (scheme) and has fantastic documentation. [1]
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.
[1] https://guix.gnu.org/help/
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.
[1] https://guix.gnu.org/help/
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.
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.
My problem with Nix was not the language, but the very confusing CLI and the way updates were done (nix-channel) and the difficulty of pinning dependencies or documenting how to do that. However, they have been hard at work at a nix CLI 2.0 which is much better, and a new uddating mechanism that is way easier to understand: https://github.com/NixOS/rfcs/pull/49
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
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 worked at the company that "started" Nix, and I can assure you that we had those same issues internally, even when the whole Nix dev team was on our payroll.
To me, this is a success story; your organization wasn't sufficiently flexible to adopt new technologies which require rethinking the fundamentals of package management. Take this as a warning sign and re-orient your organization.
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.
[0] https://edolstra.github.io/pubs/phd-thesis.pdf
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.
[0] https://edolstra.github.io/pubs/phd-thesis.pdf
Do you have any evidence to support your assertion that it was an issue with an organisation rather than the technology?
Not all technologies are good. Not all organisations are good. Sometimes it's one. Sometimes it's the other.
Not all technologies are good. Not all organisations are good. Sometimes it's one. Sometimes it's the other.
> Not all technologies are good. Not all organisations are good. Sometimes it's one. Sometimes it's the other.
And sometimes it's neither; some organizations are perfectly competent at what they do, but for whatever reason are poorly suited to a particular technology that would work fine elsewhere. (Dumb example: a company overwhelmingly built with Microsoft technologies that only has expertise working with that particular stock has basically no chance of being a good fit for nixos)
And sometimes it's neither; some organizations are perfectly competent at what they do, but for whatever reason are poorly suited to a particular technology that would work fine elsewhere. (Dumb example: a company overwhelmingly built with Microsoft technologies that only has expertise working with that particular stock has basically no chance of being a good fit for nixos)
Sure. Given code which works for a lot of people, versus some organization composed of people, the fault is probably with people and not with code. This follows from the formal properties of code as mathematical objects, plus the property of probabilistically-checked proofs: If code works for a lot of people, then the code is expected to work generally with high probability.
Moreover, there are lots of folks having professional success with Nix, and having consumed enough of their stories, I think that the stumbling blocks that the parent identified are faults of their organization and not of Nix in particular. To see this, first replace "Nix" with "Brand X" and note that the complaints are generic to any community-developed software which doesn't have B2B resellers. Then, consider your own experience learning Nix, and note that usability, poor documentation, and a feeling that things are deliberately cryptic are all common to learning any new tool or programming language.
We can comfortably conclude that Nix did not prevent itself from being adopted by the parent's organization. Indeed, it would seem that Nix made itself extremely attractive and adoptable, else it would not have been under consideration!
Moreover, there are lots of folks having professional success with Nix, and having consumed enough of their stories, I think that the stumbling blocks that the parent identified are faults of their organization and not of Nix in particular. To see this, first replace "Nix" with "Brand X" and note that the complaints are generic to any community-developed software which doesn't have B2B resellers. Then, consider your own experience learning Nix, and note that usability, poor documentation, and a feeling that things are deliberately cryptic are all common to learning any new tool or programming language.
We can comfortably conclude that Nix did not prevent itself from being adopted by the parent's organization. Indeed, it would seem that Nix made itself extremely attractive and adoptable, else it would not have been under consideration!
I don't think Nix works for a lot of organizations as a package manager. It works for a lot of individuals for a different use case (NixOS). If you're mostly installing existing packages from nixpkgs onto a NixOS box, that probably works very well--users don't need to know much about the expression language or the nature of their dependency tree. If you're using it as a development tool, users are going to need to intimately understand Nix, its expression language, and their entire dependency tree. Further, how well Nix works for your development use case largely depends on which language you're using, how well that language is supported by Nix (is it compiled or interpreted, does nixpkgs have good coverage for your language's ecosystem, etc). Notably, working with Haskell or Go in Nix is probably quite easy, while working with Python is quite hard.
As an example, I recall trying to build a package for psycopg2 (it wasn't in nixpkgs at the time, and even if it were, for one reason or another we couldn't directly use many packages from nixpkgs), the most popular Python library for interacting with a Postgres database; however, that required me to write packages for a bunch of C libraries that I didn't understand at all, including fishing random header files out of the Postgres source code. No one in our organization including our Nix veterans could figure out how to build it correctly, and it ultimately caused us to move away from Nix (it was among the last straws).
Besides, just because it didn't work for us doesn't imply that there's a problem with our personnel (by several industry key metrics, our devops capability is excellent), but rather that the effort required to implement Nix successfully was greater than the work required to use other tooling. We could use C++ instead of Python for our organization, but just because we don't doesn't imply that our organization is incompetent; rather that Python's tradeoffs are more appropriate for our problems. In effect, Nix creates more problems than it solves for us, which is unfortunate because the problems it solves are really important problems, and many of the problems it creates are utterly unnecessary (add docstrings, use a more familiar expression language--maybe Starlark [https://go.starlark.net], provide and document 'escape hatches' so users can use system dependencies where it's prohibitively difficult to hermetically package things, etc).
As an example, I recall trying to build a package for psycopg2 (it wasn't in nixpkgs at the time, and even if it were, for one reason or another we couldn't directly use many packages from nixpkgs), the most popular Python library for interacting with a Postgres database; however, that required me to write packages for a bunch of C libraries that I didn't understand at all, including fishing random header files out of the Postgres source code. No one in our organization including our Nix veterans could figure out how to build it correctly, and it ultimately caused us to move away from Nix (it was among the last straws).
Besides, just because it didn't work for us doesn't imply that there's a problem with our personnel (by several industry key metrics, our devops capability is excellent), but rather that the effort required to implement Nix successfully was greater than the work required to use other tooling. We could use C++ instead of Python for our organization, but just because we don't doesn't imply that our organization is incompetent; rather that Python's tradeoffs are more appropriate for our problems. In effect, Nix creates more problems than it solves for us, which is unfortunate because the problems it solves are really important problems, and many of the problems it creates are utterly unnecessary (add docstrings, use a more familiar expression language--maybe Starlark [https://go.starlark.net], provide and document 'escape hatches' so users can use system dependencies where it's prohibitively difficult to hermetically package things, etc).
Nix has a way of exposing complex and low-quality build systems. Many pieces of the Python ecosystem fall into this category. For example, it wasn't Nix's fault that psycopg2 had a dependency on postgresql C header files, nor was it Nix's fault that the postgresql headers had to be rearranged for psycopg2's build to work. Nix basically reveals the full complexity of the package's actual build environment, and for some packages the work required to make a reliable build is overwhelming. Some easier to use systems have people doing this work for you, like the Debian project. Others rely on luck to supply dependencies. The thousands of Dockerfiles that run "apt-get update" are a great example of this.
After using Nix for a while you start to reflexively shy away from software with low-quality build systems. Nix is not easy to use, but it's best of breed in terms of software supply chain auditability and malleability (anything in the system can be trivially modified or patched). If you can move to an "easy" system, that may be the appropriate trade-off for you, but it means you may be in a domain where these properties are unimportant.
After using Nix for a while you start to reflexively shy away from software with low-quality build systems. Nix is not easy to use, but it's best of breed in terms of software supply chain auditability and malleability (anything in the system can be trivially modified or patched). If you can move to an "easy" system, that may be the appropriate trade-off for you, but it means you may be in a domain where these properties are unimportant.
Read your way down this thread and note that every defence of Nix is merely shifting the blame in it's entirety to some other part of the ecosystem. Rightly or wrongly that's a big problem for Nix if it intends to gain widespread acceptance.
It's true somewhat though, but it's a problem is not easy to solve for Python.
The problem is that Python supports C extensions, and for example the psycopg2 package has an extra dependency on a libpq which it expects to have installed on the system i.e. if you were using a docker you would do something like yum install postgresql-devel otherwise it will fail. Python won't install it for you and it doesn't even have a way to relay (except for error message) that such package is needed.
Many people actually get stuck with this and won't know what to do, but quick google show that package is needed they install and everything works. Nix is functional and doesn't have state so you can't just invoke nix-env -i postgresql and now everything will start to work, that behavior would actually ruin reproducibility. Nix instead expects that the C dependency is also provided otherwise it will refuse the build.
That's what OP meant where he said Nix exposes weak build systems.
Anyway, there was significant progress in making things better in python, it is still not awesome, but it is very close. Actually the biggest pain point right now is to setup a build environment that's convenient to use.
I recently created a template that shows how to do it: https://github.com/takeda/example_python_project
It uses pip2nix and it can automatically figure out all python dependencies, the packages like psycopg2 need an additional entry like this: https://github.com/takeda/example_python_project/blob/master... because PyPI packages don't specify any system dependencies.
The problem is that Python supports C extensions, and for example the psycopg2 package has an extra dependency on a libpq which it expects to have installed on the system i.e. if you were using a docker you would do something like yum install postgresql-devel otherwise it will fail. Python won't install it for you and it doesn't even have a way to relay (except for error message) that such package is needed.
Many people actually get stuck with this and won't know what to do, but quick google show that package is needed they install and everything works. Nix is functional and doesn't have state so you can't just invoke nix-env -i postgresql and now everything will start to work, that behavior would actually ruin reproducibility. Nix instead expects that the C dependency is also provided otherwise it will refuse the build.
That's what OP meant where he said Nix exposes weak build systems.
Anyway, there was significant progress in making things better in python, it is still not awesome, but it is very close. Actually the biggest pain point right now is to setup a build environment that's convenient to use.
I recently created a template that shows how to do it: https://github.com/takeda/example_python_project
It uses pip2nix and it can automatically figure out all python dependencies, the packages like psycopg2 need an additional entry like this: https://github.com/takeda/example_python_project/blob/master... because PyPI packages don't specify any system dependencies.
Almost every language build system ecosystem does someting quite wrong---it's irked me for a while. I hope to within the next year or two find the time/budget to pick one language and make it work properly, and integrate with Nix perfectly.
I think not everything knows what they are missing, and by doing one complete demo we'll be able to raise the bar and give the other languages a good jolt.
I think not everything knows what they are missing, and by doing one complete demo we'll be able to raise the bar and give the other languages a good jolt.
It's not Nix's fault, but that doesn't make it cheaper to deal with. Whatever you want to say, `pip install psycopg2` just works because someone else already dealt with the packaging problem.
That's the cost of full reproducibility though. If Nix would not expect the postgresql package listed in dependencies and instead relied on what's currently installed on your system we would get to the starting point. Where something works on one person's computer but doesn't on another.
Yes it is harder, but if you incorporate nix definitions in your source code (you need to pin nixpkgs though) then everyone will get exact same versions of the packages and your code works on everyone's computer.
Yes it is harder, but if you incorporate nix definitions in your source code (you need to pin nixpkgs though) then everyone will get exact same versions of the packages and your code works on everyone's computer.
There are other ways to get enough reproducibility without the headaches of Nix, however, so that’s what we ended up doing. Reproducibility is nice, but if we need to be able to develop software quickly and for the time being, Nix is an impediment. As previously mentioned, this doesn’t have to be the case; it’s mostly an artifact of lack of documentation and a strong preference for the novel and unfamiliar over the familiar, but also for lack of escape hatches.
What other ways?
If you don't specify essential dependency and rely on the dependency to be installed that by definition is not reproducible.
The fix in Nix for psycopg2 is specify that it also depends on postgresql, and that's all what's needed.
Here's definition of psycopg2 from NixPkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen... (the highlighted part is the only thing that's needed everything else is just informational, doCheck is to control whether unit tests should be run during build and disabled = isPyPy tells that psycopg2 doesn't work with PyPy, which it doesn't work with, because PyPy doesn't support C extensions)
If you don't specify essential dependency and rely on the dependency to be installed that by definition is not reproducible.
The fix in Nix for psycopg2 is specify that it also depends on postgresql, and that's all what's needed.
Here's definition of psycopg2 from NixPkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen... (the highlighted part is the only thing that's needed everything else is just informational, doCheck is to control whether unit tests should be run during build and disabled = isPyPy tells that psycopg2 doesn't work with PyPy, which it doesn't work with, because PyPy doesn't support C extensions)
You're right about Python, is harder than it needs to be, it took me a while before I understood how it could be seamlessly integrated with it.
If it helps anyone, here's example where I put my Nix understanding to make it seamlessly usable: https://github.com/takeda/example_python_project
If you use direnv + lorri you just need to enter directory (if not just type nix-shell) and suddenly you have everything you need and the application is installed (try executing "hello" which will execute the python code, if you modify hello.py it immediately takes effect as if you were using "pip -e")
If you call "nix build" you'll get a result directory with "result/bin/hello" that just works as if it was a binary program (don't need to worry about dependencies)
I think nix needs a tooling that does all of the ground work of setting up dev environment for the most popular languages, because it gets really confusing.
If it helps anyone, here's example where I put my Nix understanding to make it seamlessly usable: https://github.com/takeda/example_python_project
If you use direnv + lorri you just need to enter directory (if not just type nix-shell) and suddenly you have everything you need and the application is installed (try executing "hello" which will execute the python code, if you modify hello.py it immediately takes effect as if you were using "pip -e")
If you call "nix build" you'll get a result directory with "result/bin/hello" that just works as if it was a binary program (don't need to worry about dependencies)
I think nix needs a tooling that does all of the ground work of setting up dev environment for the most popular languages, because it gets really confusing.
I think you are too confident about Nix's usability.
I maintain a few open source projects. I have made packages for Redhat, Ubuntu and Arch and updated one Nix package. I love the idea of Nix, but have quit trying to support it and have removed myself as a maintainer.
I maintain a few open source projects. I have made packages for Redhat, Ubuntu and Arch and updated one Nix package. I love the idea of Nix, but have quit trying to support it and have removed myself as a maintainer.
Agree, nix itself is actually fairly simple. What it is hard though is functional programming, an that's the biggest road block for developers that are used to imperative programming.
Places that use functional language for their code base don't have problems picking it up. It is especially big in Haskell community, because Haskell is also lazily evaluated.
People might wonder why not use language that more people are familiar? The reason for it is that purely functional and lazily evaluated language is basically behind Nix's biggest strengths. Purely functional means for the same inputs(architecture + source code + dependencies + configuration options + etc) you should get the same output, there's no mutable state the languages always starts the evaluations from a known state.
Why lazily evaluated? That makes the Nix only evaluate things that are necessary to obtain given derivation.
I think when people talk about Nix being confusing they really mean NixPkgs. Which is like a stdlib of Nix. The thing is that Nixpkgs in a constant flux people who work on it work on different components somewhat independently. Also often they realize better ways of doing things, and often the documentation doesn't keep with it. I think that Nix needs some kind of mechanism for literate programming where documentation would live together with the code and would be updated at the same time. There are some effort for example like the NixOS options page is generated from the source, but that's just just small part of Nix and only applies to NixOS.
I also would love if nix would standardize on how to pin nixpkgs. I recently discovered Niv[1] and it makes reproducible builds so much easier. I think Nix also needs some opinionated tooling to create dev environment for each supported languages, currently people need to do it themselves, and it takes a lot of research.
I think Niv + lorri + direnv make dev experience extremely enjoyable. For example a python project set up that way. Once you enter the directory, you have the exact version of Python installed that has all the dependencies (of course with locked versions) and all extra development tooling that developers need with exact same versions. All you need is just run the application and it just works every time. If somebody broke something you can easily use git bisect to find when and why it broke.
Nix fails to document though how a new user get to that point, and desperately needs help there.
[1] https://github.com/nmattia/niv
Places that use functional language for their code base don't have problems picking it up. It is especially big in Haskell community, because Haskell is also lazily evaluated.
People might wonder why not use language that more people are familiar? The reason for it is that purely functional and lazily evaluated language is basically behind Nix's biggest strengths. Purely functional means for the same inputs(architecture + source code + dependencies + configuration options + etc) you should get the same output, there's no mutable state the languages always starts the evaluations from a known state.
Why lazily evaluated? That makes the Nix only evaluate things that are necessary to obtain given derivation.
I think when people talk about Nix being confusing they really mean NixPkgs. Which is like a stdlib of Nix. The thing is that Nixpkgs in a constant flux people who work on it work on different components somewhat independently. Also often they realize better ways of doing things, and often the documentation doesn't keep with it. I think that Nix needs some kind of mechanism for literate programming where documentation would live together with the code and would be updated at the same time. There are some effort for example like the NixOS options page is generated from the source, but that's just just small part of Nix and only applies to NixOS.
I also would love if nix would standardize on how to pin nixpkgs. I recently discovered Niv[1] and it makes reproducible builds so much easier. I think Nix also needs some opinionated tooling to create dev environment for each supported languages, currently people need to do it themselves, and it takes a lot of research.
I think Niv + lorri + direnv make dev experience extremely enjoyable. For example a python project set up that way. Once you enter the directory, you have the exact version of Python installed that has all the dependencies (of course with locked versions) and all extra development tooling that developers need with exact same versions. All you need is just run the application and it just works every time. If somebody broke something you can easily use git bisect to find when and why it broke.
Nix fails to document though how a new user get to that point, and desperately needs help there.
[1] https://github.com/nmattia/niv
Yes people often blame the Nix langauge when they should blame Nixpkgs. I needs some more refactoring than we've been able to give it (though thankfully we've been able to give a lot of refactoring in absolute terms). I think static types what's needed to get us over the hill on this one.
I lay the blame with the arcane and inconsistent design patterns in nixpkgs, and with the usability of the nix toolset. for instance, a number of times I've had packages fail to build due to 404s. I first tried to git clone nixpkgs and fix it there, but I had to set it up as a channel for that to work. next I wasted a day setting up an overlay, but I couldn't get the hang of the self: super: construct. finally I found that for this package it had a flag I could pass for a custom source package, but another package didn't have that, so I had to use overrideAttrs and worry about what builder phase that would apply to etc. etc.
I shouldn't have needed to do this anyway - the nix team should run a mirror for external URLs, except there's no way I see to tell nix to use a mirror without editing all the URLs to point there.
making mirroring bots or connectors to other package indexes, e.g. npm2nix, is a painful experience. it's also frustrating to have to inline bash scripts to build packages.
one of the things Guix got right that Nix didn't, IMO, was using a capable language where implementing these patterns is easy, and using guile scheme instead of bash to actually build the packages. a Guix-like OS with the breadth of nixpkgs would take over the world - I hope both projects can learn from each other.
I shouldn't have needed to do this anyway - the nix team should run a mirror for external URLs, except there's no way I see to tell nix to use a mirror without editing all the URLs to point there.
making mirroring bots or connectors to other package indexes, e.g. npm2nix, is a painful experience. it's also frustrating to have to inline bash scripts to build packages.
one of the things Guix got right that Nix didn't, IMO, was using a capable language where implementing these patterns is easy, and using guile scheme instead of bash to actually build the packages. a Guix-like OS with the breadth of nixpkgs would take over the world - I hope both projects can learn from each other.
> mirrors
Indeed it is a problem. I hope we will soon solve it.
> instead of bash
Totally agreed bash needs to go. I was thinking lua for sake of also supporting Windows.
Indeed it is a problem. I hope we will soon solve it.
> instead of bash
Totally agreed bash needs to go. I was thinking lua for sake of also supporting Windows.
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/
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/
In the blog post if you read the person complained about it, so said can give a try to Guix. I think both Nix and Guix are good, personally I like Guix being familiar with lisp and scheme feels very natural to work with Guix, with Nix need to learn new declarative syntax.
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...
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...
The vanilla Linux kernel contains many proprietary firmware blobs, which is why GNU and Guix uses the "Linux-Libre" fork.
There is a maintained nonfree Guix channel here if you don't care about such blobs or need other proprietary software: https://gitlab.com/nonguix/nonguix
There is a maintained nonfree Guix channel here if you don't care about such blobs or need other proprietary software: https://gitlab.com/nonguix/nonguix
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.
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 really great that functional package managers are getting all this attention! Nix package manager can run on Arch and Gentoo and OpenSUSE also.
It's one of the things you just can't do without once you become accustomed to it. I can not imagine going back to needing root privileges just to install or try a package, or being unable to roll back to earlier revisions.
I hear Nix even works on macOS too! :-)
I hear Nix even works on macOS too! :-)
How does using nix on other distributions work? Can it access their local packagemanagers and install the distribution-packages, or is it a parallel world that just happens to live on the same machine?
It's a parallel world. The other package managers are too imperative to deal with in a declarative manner and would just be painful, though there are attempts to do so (outside of Nix). Nix installs everything to /nix.
nix doesn't have a package on OpenSUSE so you need to manually instlal, guix does have one though
Nix doesn't really come with packages to be installed, you can create one though.
You install it by running this installation script: https://nixos.org/nix/install
It should work on any Linux and OS X.
You install it by running this installation script: https://nixos.org/nix/install
It should work on any Linux and OS X.
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.
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...
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?
Is it sufficient to run Guix atop another distribution, or run Guix SD in a qemu VM?
GuixSD does not work without making changes within a LXD container (not VM). One of the details on how to do it is in mailing list. [1]
[1] https://lists.gnu.org/archive/html/help-guix/2018-10/msg0006...
[1] https://lists.gnu.org/archive/html/help-guix/2018-10/msg0006...
I moved to NixOS the other week and love it. Being able to play about and roll back to previous configurations is honestly amazing once you get into a position that you need it. I tinker with my OS and this happens more often than I’d care to admit!
Nix as a build tool is also quite nice, but honestly NixOS is the main attraction for me.
Nix as a build tool is also quite nice, but honestly NixOS is the main attraction for me.
We used their build system Hydra at a previous company and all of our deployments were on NixOS.
Check this video out from Rob Vermaas. It's a decent case study of how Nix was applied at LogicBlox
https://www.youtube.com/watch?v=nuyuA43q9NE
Check this video out from Rob Vermaas. It's a decent case study of how Nix was applied at LogicBlox
https://www.youtube.com/watch?v=nuyuA43q9NE
Here's my dotfiles for some of my nixos servers and home computers.
https://github.com/ghuntley/dotfiles-nixos
Steal away and enjoy.
https://github.com/ghuntley/dotfiles-nixos
Steal away and enjoy.
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...
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...
There's a good write up of how Cardano, the blockchain project, uses Nix.
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...
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...
Could someone summarise what is the advantage of NixOS compared to something like Ansible or Saltstack + any other Linux distribution?
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.
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.
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.
Forgive me for using buzzwords, but what's the "cloud native" story on NixOS? Can I easily create containers and update my orchestrator's deployment? Can I abstract things like AWS Lambdas into this immutable build structure?
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 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
I switched to using Pulumi from NixOps because of the lack of tooling in the Nix ecosystem (also NixOps is frequently broken in all sorts of ways due to not having as large a community). Is there some ideal way to work with it to get it to behave without having to make your own tooling or would you consider my approach to instead create support for Nix in Pulumi (which I have not done as of yet but there are terraform packages so I'm hopeful on the feasibility of this project)?
I think it would be great to have a Pulumi-based Nix deployment stack.
I think Nix/Nixpkgs/NixOS are great, and by far the best way to package applications. But NixOps, I think, is a mistake - it's an over-extension, the technologies behind Nix are perfect and way better than anything else for package management, but merely OK for host management. I actually think Pulumi has some better ideas for this, so it would be cool to use Pulumi to orchestrate deployment of Nix/NixOS stuff.
I think Nix/Nixpkgs/NixOS are great, and by far the best way to package applications. But NixOps, I think, is a mistake - it's an over-extension, the technologies behind Nix are perfect and way better than anything else for package management, but merely OK for host management. I actually think Pulumi has some better ideas for this, so it would be cool to use Pulumi to orchestrate deployment of Nix/NixOS stuff.
I think I might agree. I've been experimenting with making NixOps piggyback on terraform providers (https://github.com/NixOS/nixops/issues/1242#issuecomment-607...) in my spare time. I think this is the same mechanism as Pulumi uses now that I'm reading up on it. Perhaps I should create a Nix frontend for Pulumi instead... Interesting.
I used NixOps myself as well. The way it was designed it's more like equivalent of Vagrant, and to me it was only useful to work locally for testing before deploying it properly.
I haven't tried it but perhaps the teraform plugins are more useful for actual deployment. I wish there was some kind of integration with CloudFormation.
I haven't tried it but perhaps the teraform plugins are more useful for actual deployment. I wish there was some kind of integration with CloudFormation.
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.
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.
We are using Continix[0] to package up regular NixOS modules in docker
[0] https://github.com/notgne2/continix
[0] https://github.com/notgne2/continix
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
I'm yet to see a backend app architecture that both is elegant and effective from developer perspective and at the same time doesn't push her to make unneccessary database calls for each request when business logic becomes significantly complex.
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 ;)
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.
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.
Absolutely not. On the contrary, I'm one of those developers who prefer to do things in SQL rather than application logic.
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.