1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
# Nix Thoughts
## Configuration is all in one place - if you configure Nix correctly (aka anti dendritic)
- Config files are usually all over the place, Nix can organize them all, and makes it very easy to deploy changes to your homelab, etc.
- a recent incident with my ssh autotunnel from my homelab to vps shutting down because I added split horizon dns. The ssh autotunnel relied on the routing for `git.skullheadx.com` to route to the vps. This kind of issue had to be rooted out from being able to quickly turn on and off stuff to figure out what was going on.
## Fearless deployment
I never have to feel scared to upgrade my system because I know that I can
always rollback to a previous change. This allows me to easily bisect issues.
For example on nix darwin (macos), there was a bug when I tried to update
because audacity couldn't build because it wanted newer libraries. Therefore, I
added another input for nixpkgs stable 26.06 which solved the problem and meant
that I could update everything else.
- Actually Solving the Problem
## Problems:
I did a nix store optimise which deletes identical files and replaces them with
hard links to a single copy. I ran it on my laptop which cleared 40 GB of
duplicates. It made me reflect on the problem that Nix is trying to solve: the
package can be reproduced exactly on everyone's computer.
This is a really hard problem to solve and has given rise to many solutions like
containers. Yes they can work, but Nix solve the problem _better_ than
containers because it lockfiles and reproduces the exact byte for byte
dependencies, meanwhile the containers will just download whatever the version
ubuntu latest is which may or may not be the same as your dev environment.
In my opinion, it's pretty overkill to download and install a whole new image
for every single deploy. If you were engineering a proper solution, you should
make the one thing you are trying to deploy into the thing that actually needs
to be reproducible. Therefore, all its dependencies should be able to be
reproduced. Take this to the scale of an entire OS, and Nix becomes the obvious
answer since it tracks all those dependencies.
But taking a step even further back, why is this a problem in the first place?
The whole philosophy of UNIX and linux systems is that it's intended for any
developer to come and add programs and build off of the community's work.
Because there are so many contributors, many anonymous, that makes it extremely
difficult to standardize an environment that everyone should use, and the
culture of replacing the existing program with any of your choice is often
presented as a selling point of Linux. This approach is not fully without
downsides since now we have this whole problem which needs Nix to solve. I've
recently started using OpenBSD as as a router for all my internet traffic
towards my servers. Most of the programs that I use are first party, and they
all just integrate seamlessly with each other. Moreover, the general attitude is
that when you upgrade the system, you upgrade everything along with it. It's a
completely different approach to the goal of achieving a stable operating
system.
# To conclude this reflection,
I still think that NixOS and OpenBSD have their places. For everything that
needs to be rock solid, low resource, and highly secure I've opted for OpenBSD.
my BSD router handles TLS termination, relayd, firewall to the public internet
and static web hosting (my business). Nix is invaluable for trying out new, and
3rd party code. For example, I'm running cgit git web frontend, soju irc
bouncer, ci, split horizon dns, nix bin cache, and nfs. The flexibility and
power from the above points make it a joy to deploy new services quickly and
debug when if they go wrong.
# OpenBSD Router
BIOS settings: Legacy OS Redirection: enabled Boot UEFI only CSM storage to UEFI
|
