
My experience with NixOS - matsutsu
https://blog.patchgirl.io/nixos/2020/03/31/nixos.html
======
rudolph9
I recently switched to NixOS and have essentially configured my OS from
scratch in less than a week and now use it as my main system.

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.

~~~
downerending
> 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_.

~~~
chongli
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.

~~~
nialv7
> 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.

~~~
takeda
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](https://nixos.org/nixos/options.html)

------
dragonsh
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/](https://guix.gnu.org/help/)

~~~
throwaway894345
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.

~~~
lidHanteyk
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](https://edolstra.github.io/pubs/phd-thesis.pdf)

~~~
rkangel
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.

~~~
lidHanteyk
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!

~~~
throwaway894345
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](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).

~~~
beefee
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.

~~~
berti
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.

~~~
takeda
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](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...](https://github.com/takeda/example_python_project/blob/master/nix/python-
packages-overrides.nix#L17-L21) because PyPI packages don't specify any system
dependencies.

------
exdsq
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.

------
gt565k
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](https://www.youtube.com/watch?v=nuyuA43q9NE)

------
ghuntley
Here's my dotfiles for some of my nixos servers and home computers.

[https://github.com/ghuntley/dotfiles-
nixos](https://github.com/ghuntley/dotfiles-nixos)

Steal away and enjoy.

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

If you want a TL;DR overview of NixOS then start here —
[https://github.com/ghuntley/workshops/tree/master/nixos-
work...](https://github.com/ghuntley/workshops/tree/master/nixos-
workshop/modules/01-introduction-to-nixos)

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...](https://github.com/digital-
asset/daml/blob/master/nix/nixpkgs.nix#L10)

------
gt565k
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...](https://iohk.io/en/blog/posts/2019/02/06/how-we-use-nix-at-iohk/)

------
DethNinja
Could someone summarise what is the advantage of NixOS compared to something
like Ansible or Saltstack + any other Linux distribution?

~~~
tbenst
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

------
haolez
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?

~~~
arianvanp
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](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=20720922)
[https://news.ycombinator.com/item?id=18111954](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](https://github.com/saschagrunert/kubernix)
\- a KIND alternative

[https://github.com/xtruder/kubenix](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

~~~
kalium-xyz
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)?

~~~
catern
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.

~~~
arianvanp
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...](https://github.com/NixOS/nixops/issues/1242#issuecomment-607947127))
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.

------
golergka
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.

~~~
yjftsjthsd-h
> 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.

~~~
golergka
Absolutely not. On the contrary, I'm one of those developers who prefer to do
things in SQL rather than application logic.

