Preparation: Setting it all up

Ok, dear reader, I have to confess something. I am neither as agnostic nor am I more free with my choices than other hackers out there. Not to say that I am rather prejudiced and already knew what technology I will be using for this project. Sorry if I have lead you on. But - maybe, probably - unlike many others, I can come up with good reasoning for my choices and - attention, here comes the gist of it all - I can argue on why you should at least consider my reasoning for your next projects. But I will explain as we get going.

In this post I will set up the project, set up my tooling and - of course - explain why I do what in which way.

the (obvious) essentials

As previously mentioned, I am not a big fan of wildly throwing resources at things until they become something between useful and ok-ish. This is on one hand driven by the years of enshitification and the gain of computing resources in combination with Wirth's Law, on the other hand driven by the zeitgeist of my generation, being risen in a time where we all know that we can not forever go on as we do. I here speak - of course - about natural resources, the environment and our going on as a species on this gradually heating and sooner rather than later inhospitable planet.

So I tend to make better use of tools I came to use instead of using new tools for each and every new task. And no, I am not a software minimalist¹ - not even close!

The bare necessities for this project are interchangeable, so I will only specify which tools I am going with where I feel it being necessary or the choice being interesting.

source code repository setup

I have mentioned the dependency on proprietary solutions, which I try to omit as far as I can. This extends not only to software that I use on my workstation, phone or laptop, but also onto services I use through the web. So it was clear to me that I wouldn't want to host one of the core pieces of my development work flow (git and project related stuff) on a service owned by one of the big guns in data aggregation and surveillance technology. Instead I went with sourcehut, which I really like for its minimalist but still feature-rich user interface. There are other, equally viable options out there - including self hosting the infrastructure.

VPS

Then I went on an bought some virtual private server (VPS) - since they are all more or less equal choice does not really matter. I went with one of the cheaper options.

text editor

Getting to learn vi key bindings was crucial for my professional development in two aspects: a) I was able to edit files swiftly in any new/minimal/bare-bones (server) setup and b) I was able to do so quickly and in a what feels like ergonomic fashion. Unfortunately I watched a video of some guy presenting his Emacs setup at a vi conference - the showcase of magit and org-mode proved to be gateway drugs, since evil-mode allowed me to preserve all the keybindings that I now consider part of the ossified regions of my brain.

HTML publishing

At the start of this project I wondered if I should invest time to get to know the cool new kid on the block of static-site-publishing - Hugo - but just thinking about it (especially adding another dependency to my project) felt wrong. It is cool that Hugo can parse org files - but org-mode is able to export static HTML just as well - so I will stick with Emacs (and org-mode).

GNU Guix

To keep my sanity both in terms of managing the (production) operating system and because I already know that I will be reproducing the environments for development, testing and production with this fancy tool called GNU Guix, I install Guix System on that host with this configuration.

What is this Guix, anyways?

Guix is some descendant of the actually quite genius ideas Eelco Dolstra had for their thesis and the Nix package manager. I have no experience with Nix, except for the parts that are equal in Guix, but I prefer Guix for

the use of a beautiful programming language for all things (GNU Guile scheme),
Guix' governance model,
the way major design decisions are discussed and transparently communicated,
the core idea that it is easier to "spoil" a pure system, than to clean up one that is rotten from the core.

The last point, of course, is about the use of non-free, proprietary software. While this is the reason for many new users to be afraid to give Guix a try - for, yes, it is next to impossible to get graphics and networking running on modern hardware without proprietary software - Guix excels other solutions by providing simple, clean and easy to use means to extend the Guix core with whatever you may want. Also, what used to be a difficult argument to make in the previous years, the issues that have risen in the Nix project earlier² this year hint towards community and governance related questions to shape the longevity of a project far more than whether or not to ship linux-libre or the upstream, blobby version.

That being said, GNU Guix is the tool of choice (which can, of course be replaced by any other, similar tool) for the following use cases:

reproduction of (development, testing, production) environments,
(remote) management of target operating systems (reproducible),
ensuring bit-by-bit reproducibility of all software in use and
management of the software supply-chain (from bootloader to end-product).

Now, for users not yet familiar with this new kind of meta-OS, most of these were not original design goals of projects like Nix or Guix, but rather by-products, that, once bit-by-bit reproducibility was achieved for arbitrary software, were relatively easy to implement. They both started as (reproducibility ensuring) package managers, and have since evolved into these huge tool-sets that I would not want to miss in my workflows. If you are interested more on the topic of reproducibility, there's reproducible-builds.org that explains everything necessary in-depth. I will mention remarkable stuff as we go along.

Setting up the VPS

I build the initial system to my taste with

guix system image src/guix/system.scm

and flash it onto the root disk of my VPS - now Guix System is installed.

Further changes to `system.scm` can be deployed with

guix deploy machine.scm

or - in this case -

guix -L src/guix deploy machine.scm

since `machine.scm` needs the operating-system definition that resides in `src/guix/system.scm`.

The real miracle of it all lies here: I now am able to test my deployment setups without actually deploying anything. The `guix system` subcommand allows for emulating the system in VM or creating an ad-hoc docker container that can be spawned at ease. Once the whole application is finished and the operating-system definition has come to a final state, interested users can simply copy the definition and deploy it themselves.

bit-by-bit reproduction

When we intend bit-by-bit reproduction, we need to make use of yet another Guix subcommand:

guix time-machine -C src/guix/channels.scm -- deploy -L src/guix machine.scm

The `time-machine` guix sub-command makes use of a certain checkout of one or more channels and executes another guix sub-command (the one starting after `–`) in that environment.

Domain

We need a domain, so I bought one. For now I just configure `teil.space` to point to the VPS and create a CNAME entry for `mit.teil.space` to point to `teil.space`. I will add the relevant entry for the app under `ver.teil.space` as soon as I get ready for it.

Development environment

To actually start with the coding project, I need a development environment. Guix provides simple ways to spawn ad-hoc environments through the `guix shell` command.

guix shell python python-django

Whenever we feel like persisting an environment, Guix lets us pin it with the `–export-manifest` option, and re-use the same environment by specifying the file we saved the definition in with `-m`.

guix shell python python-django --export-manifest > manifest.scm
guix shell -m manifest.scm

Together with pinning the current (or whichever desired) checkout of guix itself in a channels file, we are then able to bit-by-bit reproduce this environment among machines and other contexts.

guix describe --format=channels > channels.scm
guix time-machine -C channels.scm -- shell -m manifest.scm

Raw Django Project

So - since we are now all ready and set - we are finally able to start coding. Yay! We initialize an empty project and a new app with Django's `django-admin` tool like so:

guix time-machine -C channels.scm -- shell -m manifest.scm
django-admin startproject mitteiler
django-admin startapp sharer

Footnotes:

Software minimalist actually mean the /minimal/ist part of the name, and regard unnecessary features, such as helpful messages in command-line-utilities as bloat. In their philosophy the use of the GNU standard library is already an anti-pattern. I do share some of the criticism with the movement, though, and am astonished by the amount my horizon is broadened just by thinking about the questions raised.

After some internal differences, a bunch of alternatives, spin-offs and other forks emerged.