An author of the original book, Allen B. Downey, has released a third edition if his updates that is also available online at no cost and in Allen B. Downey's words:
The book is now entirely in Jupyter notebooks, so you can read the text, run the code, and work on the exercises – all in one place. Using the links below, you can run the notebooks on Colab, so you don’t have to install anything to get started.
The text is substantially revised and a few chapters have been reordered. There are more exercises now, and I think a lot of them are better.
It's interesting to see how the same source material has grown into two differently maintained and similar resources.
A git commit is a snapshot. The node-based tree structure is an artifact of recording pointers to other snapshots and labeling snapshots with a branch name.
Most of this article is not purely about that question, but I dislike clickbait, so I’ll actually answer the question from the title: Two reasons.
First of all, I like to be independent - or at least, as much as I can. Same reason we have backup power, why I know how to bake bread, preserve food, and generally LARP as a grandmother desperate to feed her 12 grandchildren until they are no longer capable of self propelled movement. It makes me reasonably independent of whatever evil scheme your local $MEGA_CORP is up to these days (hint: it’s probably a subscription).
It’s basically the Linux and Firefox argument - competition is good, and freedom is too.
If that’s too abstract for you, and what this article is really about, is the fact that it teaches you a lot and that is a truth I hold to be self-evident: Learning things is good & useful.
Turns out, forcing yourself to either do something you don’t do every day, or to get better at something you do occasionally, or to simply learn something that sounds fun makes you better at it. Wild concept, I know.
Contents
IntroductionMy ServicesWhy I self hostReasoning about complex systemsThings that broke in the last 6 monthsThings I learned (or recalled) in the last 6 months
You can self host VS Code
UPS batteries die silently and quicker than you think
Redundant DNS is good DNS
Raspberry PIs run ARN, Proxmox does not
zfs + Proxmox eat memmory and will OOM kill your VMS
The mystery of random crashes (Is it hardware? It’s always hardware.)
SNMP(v3) is still cool
Don’t trust your VPS vendor
Gotta go fast
CIFS is still not fast
Blob storage, blob fish, and file systems: It’s all “meh”
We considered toolkits like GTK, Flutter, and QT, and though the team was already experienced working with GTK for Pop!_OS, eventually landed on the Rust-based toolkit, Iced.
I’ve been comparing crates on crates.io against their upstream repositories in an effect to detect (and, ultimately, help prevent) supply chain attacks like the xz backdoor1, where the code published in a package doesn’t match the code in its repository.
The results of these comparisons for the most popular 9992 crates by download count are now available. These come with a bunch of caveats that I’ll get into below, but I hope it’s a useful starting point for discussing code provenance in the Rust ecosystem.
No evidence of malicious activity was detected as part of this work, and approximately 83% of the current versions of these popular crates match their upstream repositories exactly.
How well NixOS and Nixpkgs are maintained absolutely affects users of NixOS. This may have just saved NixOS from becoming an unmaintained or at best slowly maintained project that people advise against using for anything serious.
Disinvestment into Python, Flutter, and Dart is a clear signal that those tools are unimportant to Google. I won't be recommending that anyone use Dart or Flutter on new projects.
Creative people consistently say that they don't spend a lot of time thinking about what they want to create. They just work on something. Often something nonsensical and useless. Sometimes something that's meant to practice something they want to improve upon. Sometimes it's half of an idea. Almost always it's something that won't ever be finished. In the process of working on whatever it is they're engaged in, they get ideas for the next thing they want to work on. That's how ideas come. Not from thinking about what the next idea will be, but by being engaged with an existing idea.
An easy way to start is to start journaling. Write down something good that happed during your day. Elaborate on it. Write your thoughts. Don't edit them or care about spelling or grammar. Just engage with your existing thoughts.
I think that Nix flakes have some considerable benefits, such as:
Convenient pinning of evaluation-time dependencies
Eliminating pointless rebuilds of code by only including tracked files in builds
Making Nix code, on average, much more reproducible by pervasive pinning
Allegedly caching evaluation
Possibly making Nix easier to learn by reducing the amount of poking at strange attribute sets and general NIX_PATH brokenness
However, at the same time, there are a few things that one might be led to think about flakes that are not the most effective way of doing things. I personally use flakes relatively extensively in my own work, but there are several ways I use them that are not standard, with reason.
Flakes are optional, and as much as some people whose salary depends on it might say otherwise, they are not the (only) future of Nix: they are simply a special entry point for Nix code with a built in pinning system, nothing more, nothing less.
Nix continues to gather a reputation for bad documentation, in part because the official documentation for nixpkgs and NixOS is de facto not allowed to talk about flakes, as a policy. This situation is certainly partially due to a divide between Nix developers and nixpkgs developers, which are groups with surprisingly little overlap.
Flakes also are a symptom or cause of much intra-community strife between "pro-flakes" and "anti-flakes" factions, but this situation is at some level a sign of broken consensus processes and various actors trying to sidestep them, an assumption by many people that the docs are "outdated" for not using flakes, and the bizarre proliferation of flakes everywhere in blog posts or tutorials leading to a belief that they are required for everything.
This post is about how to architect Nix projects in general, with a special eye on how to do so with flakes while avoiding their limitations. It tries to dispel misconceptions that can develop in such a monoculture.
An author of the original book, Allen B. Downey, has released a third edition if his updates that is also available online at no cost and in Allen B. Downey's words:
It's interesting to see how the same source material has grown into two differently maintained and similar resources.