Blog

No time to tinker tinker tinker


I have long suspected that the operating system a person chooses functions as a kind of personality test. Show me your dotfiles and I will show you the architecture of your assumptions about how computers should behave.

tl;dr I am good, bro. Maybe I do have a life? But just look how long the post is!

I first wandered into NixOS territory back in 2020, spending over half a year with the system. The package collection impressed me then and impresses me now. The concept remained lodged in my mind like a splinter of possibility. Recently I decided to give it another chance as my daily driver, thinking perhaps the ecosystem had matured, perhaps the rough edges had been sanded down.

The pitch sounds absolutely seductive to a certain type of mind: define your entire system in a declarative configuration file, and the machine shall reproduce itself with perfect fidelity. Your laptop dies? No matter. Clone the config to new hardware and everything returns exactly as it was.

The promise whispers: reproducibility. The promise whispers: rollback your mistakes. The promise whispers: you shall never again lose your system to the chaos of accumulated cruft.

The promise, it turns out, contains some rather significant omissions.

Everchanging target and tinkgering tinker tinker tinker

Here is what I discovered during my time in the Nix monastery:

The system breaks. Not occasionally. Not rarely. Constantly. And surely your working machine is still fine but your configs to update your machine might be outdated. One does not simply run nixos-rebuild and proceed with one's day. One runs the rebuild, receives an error, adjusts the configuration, runs it again, receives a different error, adjusts again, runs again. The rebuild/fix/rebuild/fix cycle becomes the primary experience of using the system.

I have broken Arch Linux exactly once in five years. NixOS breaks before I even attempt an update. Something always requires changing in the configuration before the build will consent to run.

The error messages deserve special mention. They emerge from the machine like communiques from a dimension where clarity is considered impolite. Twenty lines of stack traces referencing files in /nix/store/ with names that look like someone rolled their face across a keyboard, and then at the very bottom, almost as an afterthought: "logseq has been removed."

The package you use daily? Gone. No alternative suggested. No migration path offered. Simply… removed due to lack of maintenance. As if the system itself had decided you needed practice in adapting to sudden loss.

Hard Things Easy, Easy Things Impossible

There is a saying about NixOS that circulates among those who have tried it: it makes hard things easy and easy things hard. This is, in my experience, precisely correct.

Want to define your entire system state in a version controlled file? NixOS handles this elegantly. Want to quickly install a package so you can get on with your actual work? Prepare to learn why your particular use case requires an overlay, or why the package exists but is marked broken, or why you need to add an additional input to your flake, or why the version you need conflicts with something else in your dependency tree.

/en/blog/2026/01/28/corporate_software_nix.jpg

And then there are proprietary binaries. Corporate software. Anything not packaged for NixOS. This is where the immutable dream collides with the messy reality of software distribution.

On a traditional Linux distribution, you download a binary, make it executable, and run it. On NixOS, you enter a world of workarounds: steam-run, buildFHSUserEnv, patchelf, autoPatchelfHook, manually specifying interpreters and library paths. The StackExchange thread documenting these methods reads like a catalog of incantations, each with its own trade-offs and failure modes. Yes, this is the cost of running an immutable system. But when running a downloaded binary requires consulting documentation and selecting from multiple incompatible approaches, something has gone wrong with the user experience.

A computer, at the end of the day, should be a tool for getting work done. This seems obvious, yet NixOS has a way of inverting this relationship. The computer becomes the work. The configuration becomes the project. The tool demands more attention than the tasks you acquired the tool to accomplish.

My own dream was modest: atomic project directories with nix-shell, containing all dependencies, activated automatically when I enter the directory. I already use direnv quite effectively for this. The NixOS vision promised something even more sophisticated, a world where each project carries its complete environment specification, perfectly reproducible across machines and time.

The reality? When I start a new project, I want to get it running as soon as possible. I do not want to spend an afternoon figuring out how to declare dependencies in Nix. I do not want to debug broken overlays. I do not want to discover that some package I need will never be officially maintained because it fell on the wrong side of a political dispute within the community. (Xlibre, the Firefox fork, provides a useful example of how ideology can trump utility in package inclusion decisions.)

More and more of my actual work lives in Emacs or on the shell. Once a system is configured and running, I have little need to tinker with it. The operating system should fade into the background, a substrate upon which real work occurs. NixOS refuses to fade. It demands constant attention, constant maintenance, constant appeasement.

The Governance Situation, Or: When Your Package Manager Becomes A Political Battleground

Here is where the story becomes genuinely strange.

NixOS has developed what might charitably be called an "intense political culture." The project has been convulsed by governance disputes that make ordinary open source drama look quaint by comparison.

In April 2024, a faction proposed creating dedicated voting seats for specific demographic categories on a project committee. Some contributors suggested this might constitute discrimination against groups not granted such seats. The response was not a measured discussion of competing values. The response was what project leaders explicitly called a "purge." Contributors were banned. The founder, Eelco Dolstra, was pressured to sign an abdication letter that others had drafted for him.

Now, I want to be careful here. Reasonable people can disagree about representation policies. The question of how to make open source communities more welcoming admits multiple answers, and thoughtful people hold different views.

What seems less reasonable is labeling everyone who disagrees with your specific implementation a "Nazi" and removing them from the project. The word has a meaning. It refers to adherents of a specific ideology responsible for industrial genocide. Using it to describe someone who thinks committee seats should not be allocated by demographic category does not clarify anything. It obscures. It transforms a policy disagreement into an accusation of monstrous evil, which conveniently exempts one from having to engage with the actual arguments.

This rhetorical move, I should note, works equally well when deployed by any faction. Once you have established that your opponents are not merely wrong but wicked, any action against them becomes not just acceptable but morally required. The technique is old. It is effective. It does not produce good software or healthy communities.

The situation continued deteriorating into 2025. In September, five of seven moderators resigned, accusing the Steering Committee of interference. Or perhaps the Steering Committee was attempting to address problems with moderation bias. The accounts diverge depending on who you ask. LWN covered the fallout, and the commentary reveals just how deep the divisions run. What seems clear is that a Linux distribution has become a venue for political conflict that has little to do with package management, and the fallout is not producing better software.

The Paradox of the Immutable Dream

/en/blog/2026/01/28/config.webp
The need to add more Users to the Nix Hive.

Here is what makes all of this so frustrating:

The idea of NixOS is genuinely excellent. An immutable, declarative operating system. Define your reality in a configuration file. Reproduce it anywhere. Roll back mistakes effortlessly. This is not foolish. This is, in fact, exactly what many of us want from our computers.

I should note: I love immutable, declarative systems in the right context. On the server side, systems like Talos and Bottlerocket Linux demonstrate the genuine value of this approach. When you need security, reproducibility, and minimal attack surface, declaring your system state and preventing runtime drift makes perfect sense. These systems work because servers have constrained, well defined purposes. You know in advance what the machine needs to do.

A personal workstation operates under different constraints. You do not always know what you will need tomorrow. A new project appears. A client requires some obscure tool. You want to experiment with a technology you read about this morning. The freedom to simply install something and proceed with your work has real value. NixOS trades this freedom for theoretical reproducibility, and the exchange rate is unfavorable for daily use.

The execution has problems. Significant, practical problems that make daily use a trial rather than a pleasure.

The political situation introduces additional uncertainty about the project's future direction and whether it can maintain the contributor base necessary for a healthy ecosystem.

And yet nothing quite like NixOS exists elsewhere. You can approximate its features: BTRFS snapshots for rollbacks, git repositories for dotfiles, aconfmgr for declarative package management, Docker for development environments. These solutions work. They do not require learning a pure functional configuration language or monitoring mailing lists for political developments.

But they are not the same thing. They are workarounds, not the integrated vision NixOS promises.

I find myself wishing for a project with NixOS's conceptual ambition, maintained by people capable of distinguishing between technical disagreements and moral emergencies, documented clearly enough that the Arch Wiki does not remain the superior reference for basic tasks. Something perhaps built on Gentoo's foundations, for those who appreciate that sort of thing, but with governance that prioritizes building software over enforcing orthodoxies.

Such a project does not appear to exist yet. Perhaps someone will fork the technology and rebuild the community on different foundations. Perhaps someone like DHH will stumble into this space and create enough noise to force a reckoning. Perhaps a new project will emerge that captures the declarative dream without the accompanying dysfunction as Ubuntu did back then with Debian.

Until that day, the NixOS concept remains in a peculiar limbo imho: too broken for daily use, too unique to ignore entirely, too politically fraught to recommend without extensive caveats. It is not ready for personal use. Perhaps it will be someday. Perhaps not. And I do have my doubts about companies really using it besides as a Homebrew alternative for a package manager on Mac OS.

The Return to Simplicity

So where does this leave me? Not necessarily back to Arch, though the Arch Wiki remains one of the finest pieces of technical documentation ever assembled (and, ironically, often explains NixOS tasks better than NixOS documentation does).

My time with NixOS taught several lessons again:

Reproducibility has value, but not at the cost of hours lost to rebuilds and debugging. Error messages should communicate what went wrong, not recite the internal state of a lazy evaluation engine. A community more interested in political purity than functional software will produce neither purity nor functional software. Sometimes the boring solution (Arch with BTRFS snapshots, version controlled dotfiles, containerized development environments) accomplishes most of the goal with a fraction of the friction.

What I actually want is simple: a configuration file that describes my system for easy setup. Something that installs my packages and applies my dotfiles when I set up a new machine. This should not be revolutionary. But there are already too many dotfile managers out there. This should not require learning a pure functional programming language. This should not force me to engage with political disputes about which software is ideologically acceptable.

Do I recommend NixOS? Not for daily use on a machine where you need to get work done. Do I recommend paying attention to NixOS? Absolutely. Something interesting is happening there, even if the interesting thing is primarily a demonstration of how technical projects can be consumed by non-technical conflicts.

The declarative, immutable operating system remains a worthy goal. The path to achieving it may require starting fresh, with different governance, different priorities, and perhaps a willingness to learn from NixOS's mistakes rather than repeating them.

Until then, there are distributions that simply work. There is the accumulated wisdom of decades of Unix documentation.


Enochian Chess: The Complete Guide to Victorian Occult Chess


Update: I originally wrote this post to earn a chess.com achievement, but I thought it might be worth sharing here in a combined form. I also added some much needed SVG graphics. You’re welcome. Is this more understandable? I highly doubt it. But at least it’s more visible.

Chess variants are sometimes created and played in particular subcultures outside the chess community itself. Star Trek gave us Tridimensional Chess. Gary Gygax and the Dungeons & Dragons phenomenon spawned dragonchess. And the world of Victorian occultists, bless their elaborately robed hearts, gave us Enochian Chess.

The Origins

It was around 1887 (give or take a few astral fluctuations) when three gentlemen of dubious respectability founded the Hermetic Order of the Golden Dawn in London. One of them, Dr. William Wynn Westcott, was a coroner by trade and an occultist by disposition, which tells you something about Victorian England that the tourism boards prefer not to mention.

Westcott claimed the foundational documents of the Golden Dawn had been transmitted to him from a mysterious Fräulein Sprengel in Germany, representing an even older occult order. Whether this German connection actually existed or was (as seems rather more likely) a convenient bit of mythmaking to give the whole enterprise a patina of Ancient Authenticity™, we shall probably never know. The universe is not in the habit of answering such questions directly.

Westcott has been suggested as the inventor of Enochian Chess, but some (including Westcott himself) claimed the documents describing it were among those supplied from that older German group. The authorship remains unclear, at least partially because the Golden Dawn considered Enochian Chess to be a secret teaching. And secrets, by their nature, tend to be incompletely transmitted.

"Enochian" refers to the Biblical patriarch Enoch, father of Methuselah, who "walked with God" (Genesis 5:24) and "was taken from this life, so that he did not experience death" (Hebrews 11:5). In occult tradition going back to Queen Elizabeth I, Enoch is considered a source of hidden mystical knowledge. The variant was also called Rosicrucian Chess, after the Order of the Rosy Cross, a continental mystic fraternity from which the Golden Dawn claimed descent.

More specifically, the name refers to the magical system of Dr. John Dee, Elizabeth's court astrologer, who spent years conversing with what he believed were angels through a scryer named Edward Kelley.

Kelley was either a genuine medium, a spectacular con artist, or (and pay attention here, because this is the important bit) both at once. Reality tunnels, you understand, are not mutually exclusive. The angels gave Dee an entire language, a hierarchy of spirits, and enough diagrams to wallpaper a cathedral. Dee's diaries, preserved in the British Museum, remain objects of fascination and controversy four centuries later.

The Golden Dawn took this material and did what occultists always do: they systematized it, cross-referenced it with everything else (Kabbalah, Tarot, astrology, Egyptian mythology, and probably their breakfast menus), and eventually decided it needed a game.

Enter Enochian Chess: a variant designed for two or four players, wherein each player (or team) commands pieces corresponding to one of the four classical elements (Fire, Water, Air, and Earth). The pieces themselves were identified with Egyptian god-forms: Osiris as King, Isis as Queen, Horus as Knight, Aroueris as Bishop, and Nephthys as Rook.

The Invisible Partner

Documentary evidence for the game's existence (in the form of a Golden Dawn paper dating from no later than 1897) has come to light, but no historical documents discovered so far have given the complete rules for gameplay.

Nobel Prize-winning poet William Butler Yeats (yes, that Yeats) records in his memoirs that in 1894 he played "a curious form of chess at which there should be four players" with two other Golden Dawn members. One was MacGregor Mathers, a founding father of the order.

Westcott apparently never finished the rules. Mathers finalized the game around 1890, writing what Israel Regardie later called the "Official Ritual" describing piece movements. But Mathers was known for many things beyond rule-writing, including feuds with Aleister Crowley and playing Enochian Chess with what he called an "invisible partner," a spirit who occupied the empty chair across the board.

Joseph Hone, Yeats's biographer, described it thus: Mathers would shade his eyes with his hands and gaze at the empty chair before moving his partner's piece.

Let that image settle in your mind. A man in late Victorian London, playing a chess game derived from angelic communications, with a ghost as his teammate.

Was Mathers actually communing with spirits? Was he accessing his unconscious? Was he just very good at entertaining himself? I don't know. More interestingly, I'm not sure anyone can know from the outside.

In his book The Golden Dawn, Regardie provides a description of the boards and pieces, gives two arrays, and explains the occult methodology for deriving others. He attributes the movement rules to Mathers's "Official Ritual." But Regardie's publication lacked complete gameplay rules. For decades, people stared at these fragments, tantalized.

Which brings us to Chris Zalewski, who spent years in the 1980s reconstructing coherent rules from Regardie's publications, original manuscripts, and the Indian game Chaturanga (upon which the variant was based). When Regardie visited New Zealand in 1983, he was "astounded at the development to which Chris had taken the game."

The result was Enochian Chess of the Golden Dawn, first published in 1994, which remains the definitive text.

How To Play

The magical practices of the Golden Dawn are of no concern to the chess variant community. So says the Chess Variants website, and they're not wrong. You can play Enochian Chess purely as a game, ignoring every mystical attribution, and still find it strategically fascinating.

But isn't it more fun to know the weird stuff? I think so. Your mileage may vary.

Enochian Chess can be played on a standard FIDE 8x8 board, though Golden Dawn members did not use orthodox equipment. Play is facilitated by making the corner spaces at least twice as large as other squares, because those corners (the "throne squares") have special properties.

The four throne squares are a1, a8, h1, and h8. Remember them. They'll matter.

Divide the board conceptually into four quadrants: the fiery red of the Fire angle, the watery blue of the Water angle, the airy yellow of the Air angle, and the earthy black of the Earth angle.

/en/blog/2026/01/26/enochian_board.svg
The board divided into four elemental quadrants, with throne squares at each corner

Place four armies upon this board, one in each corner. Each army consists of: a King (Osiris), a Queen (Isis), a Knight (Horus), a Bishop (Aroueris), a Rook (Nephthys), and four special Pawns.

The Teams

Teams are always fixed: Blue and Black versus Red and Yellow. There is no individual winner. If the blue army is eliminated but black captures both enemy kings, the blue-black team has won.

/en/blog/2026/01/26/team_alliances.svg
Fixed alliances — Blue+Black (Water+Earth) vs Red+Yellow (Fire+Air)

Teammates are normally forbidden from capturing each other's pieces (with one spectacular exception we'll get to). Allied pieces don't threaten each other. Blue and black kings can be adjacent without giving check.

Play proceeds clockwise around the board.

The Throne Square Problem

In all eight possible starting arrays, each throne square is occupied by two pieces: a King and one other piece (which piece depends on the array). This double occupancy is only allowed at the start. Once either piece moves, only one piece may sit on that throne square for the rest of the game.

And here's the brutal part: both pieces are captured if an enemy piece moves into a throne square while it's still doubly occupied.

/en/blog/2026/01/26/throne_mechanics.svg
Throne mechanics — move one piece quickly or lose both to a single capture

Your most important piece starts the game sharing space with another piece, and if you don't move fast enough, you lose both. This is not a game designed for the strategically timid.

The Eight Arrays

There are eight different starting configurations, each named by elemental combination: "Air of Air & Water," "Fire of Fire & Earth," etc. The array determines which piece shares the throne with each King.

/en/blog/2026/01/26/starting_array.svg
Example starting position — "Air of Air & Water" array with all four armies

Regardie indicated sixteen possible arrays, but Zalewski concluded there are functionally only eight, since pairs like "Air of Fire" and "Air of Earth" have identical piece arrangements.

The choice of array also connects to which elemental board you're theoretically using:

  • Air board: Yellow moves first
  • Fire board: Red moves first
  • Water board: Blue moves first
  • Earth board: Black moves first

If playing on Fire or Earth boards, only "…of Fire & Earth" arrays may be selected. On Air or Water boards, only "…of Air & Water" arrays.

The Pieces

The King (Osiris) moves one square in any direction, same as standard chess. But kings are not mated in Enochian Chess. They are captured. You must declare "check" when threatening an enemy king. A king in check MUST be moved, even if that means putting it in check again. You may move another piece only if the king is completely blocked by friendly pieces.

The Queen (Isis) moves by leaping exactly two squares in any direction, orthogonal or diagonal, jumping over intervening pieces like an alibaba. She controls only 16 of 64 squares from any position, all of her own color.

/en/blog/2026/01/26/queen_movement.svg
The Queen leaps exactly 2 squares in any direction, jumping over pieces

(The Chess Variants essayist speculates that in an earlier version the queen may have moved like a ferz, one square diagonally, and the bishop like an alfil, leaping two squares diagonally. But Regardie and Mathers both support Zalewski's leaping queen. Take your pick of which reality tunnel to inhabit.)

The Rook (Nephthys) moves orthogonally as in standard chess. No castling.

The Bishop (Aroueris) moves diagonally as in standard chess.

The Knight (Horus) behaves exactly as in standard chess.

The Pawns (the four Sons of Horus) move one square forward only, capturing diagonally forward. "Forward" differs by color: Yellow toward row 1, Blue toward column A, Red toward row 8, Black toward column H. No initial double step, no en passant.

Pawn promotion has restrictions: it only occurs after a player has lost at least one pawn. If all four survive, promotion must be delayed. And a pawn may only promote to its type: Pawn of Rook becomes Rook, Pawn of Knight becomes Knight.

When A King Falls

When a king is captured, all pieces of that color become frozen. They remain on the board but cannot move, don't threaten other pieces, and cannot be captured. They simply sit there as blocking terrain.

/en/blog/2026/01/26/frozen_pieces.svg
A captured king freezes the entire army — pieces become impassable terrain

The game ends when both kings of one alliance have fallen.

Seizing The Throne

Moving your king onto the throne square of a friendly player transfers control of their army to you. Both armies still take separate turns, but you command both. Frozen pieces can be reactivated this way.

You retain control even if you later move the usurping king off the throne. But if your usurping king is captured, control reverts to the original player (assuming their army still has a king). Otherwise both armies are kingless and those players have lost.

Exchange Of Prisoners

Two opposing players who have both captured enemy kings may agree to exchange them. Both must agree, and neither can have lost their own king. Returned kings go on their throne squares (or nearest empty square). Frozen pieces revert to normal.

Zalewski doesn't indicate what happens if the throne is occupied and multiple alternative squares are equidistant. House rules, I suppose.

The Concourse

Opposing bishops are bound on opposite colors, so they can never capture each other normally. The Concourse of Bishoping is the exception.

By completing a 2x2 square formation involving all four bishops, the moving bishop captures all three others. This is similar to the "triumph of the boat" in Chaturanga for Four Players. It's the rare case where capturing a teammate's piece is legal.

/en/blog/2026/01/26/concourse_positions.svg
The five Concourse positions — forming a 2×2 here captures all four pieces

Unlike triumph of the boat, the concourse can only happen at five positions: the central squares (c4, c5, d4, d5) or the four corner clusters (b2-b3-c2-c3), (b6-b7-c6-c7), (f2-f3-g2-g3), (f6-f7-g6-g7).

The Concourse of Queens works identically. Bishops and queens cannot be combined; all four pieces must be the same type.

Privileged Pawn

If reduced to minimal forces (king and pawn, king-queen-pawn, or king-bishop-pawn), the pawn becomes "privileged" and can promote to any piece type, like a standard chess pawn.

However, if you promote to a piece type you already have, the original is demoted to a pawn of its type. Want a second queen? Your existing queen becomes a pawn of queen.

(What if you promote a pawn of queen to queen while having a queen? Zalewski is unclear. Presumably the original avoids demotion. Otherwise you'd be penalized for having privilege, which seems perverse even by Golden Dawn standards.)

Other Rules

Bare King Draw: Both teammates reduced to bare kings = draw.

Withdrawing: A player may withdraw at any time, leaving pieces to their teammate.

Stalemate: No legal move except putting your unchecked king in check = skip turns until another player's move alleviates it. Drawn if stalemated while teammate is also out.

Two Or Three Players

With fewer than four players, one or both command two armies. Each color still takes its own turn. A player operating both armies may not withdraw.

This is not simple. It models the complex, shifting, alliance-laden nature of… well, either elemental forces in an interactive universe, or just really interesting four-player dynamics. Depends on your preferred reality tunnel.

Why Bother?

Here's a question that has bothered philosophers since Plato: What is a game for?

The standard answer (entertainment, passing time, competition) explains chess clubs but not Enochian Chess. Nobody constructs a variant with Egyptian god-forms, throne-seizure mechanics, and concourse captures just to pass time.

Then again, maybe they do. Fun is underrated as a motive.

The Golden Dawn, however, had a specific additional answer: Enochian Chess subsumes other passive systems of divination and has "powerful prophetic properties."

Here's how divination worked: before the game, a question was formulated. A special piece called Ptah (the creative principle, "the Opener") was placed on a square corresponding to the query's nature. The game was played, and the outcome interpreted as the oracle's answer.

Think about what this means. Unlike Tarot, where cards are drawn randomly, or the I Ching, where yarrow stalks determine hexagrams, Enochian Chess divination is active. The querent participates. Strategy matters. Skill affects outcome.

The Golden Dawn claimed you could use the game "for practical ACTIVE divination, to alter and influence events as well as to simply predict."

Bold claim. Does it work?

I have no idea. Neither do you. But here's what I can say about the game's benefits, regardless of your metaphysical commitments:

The mechanics create situations you won't find elsewhere. The leaping queen. The throne vulnerability. The frozen armies becoming terrain. The concourse that can take your own teammate's piece. The prisoner exchange negotiations. You don't need to believe in anything to enjoy complex four-player dynamics.

The fixed alliance structure with throne-seizure, prisoner exchange, and withdrawal creates a simulation of complex multi-agent relationships. You might capture an enemy king, then be offered a prisoner exchange. Do you take it? Your ally might seize your throne if your king falls. Is that good or bad? These decisions model strategic thinking that most games don't require. You're coordinating with allies whose interests partially but not completely align with yours. Sound like anything in real life?

The Concourse can only happen at five specific positions. Four pieces from four players must converge into a 2x2 formation, and whoever completes it captures all three others, including their teammate's. You learn to see these configurations forming. You develop peripheral awareness of what's developing across the whole board, not just your immediate tactical concerns. Whether this trains you to see "elemental configurations" in daily life or just makes you better at complex board games, either way it's useful.

Mathers played with an invisible partner. Yeats reported games conducted with "Mathers, his wife, and a spirit." Was Mathers communing with actual disembodied intelligence? Accessing deeper unconscious layers? Randomizing moves through a process that felt like guidance? I don't know. The experience of sitting across from an empty chair, waiting for the move to become clear, does something to consciousness. Whether "something" involves angels, archetypes, or neurology is a question I leave to specialists.

What can be said: the game changes the player. It trains attention. It forces multi-perspectival thinking. It offers structured engagement with uncertainty that is neither passive reception nor anxious control.

And it's fun. Never discount fun.

The Modern Scene

Here's something that might surprise you: people are still talking about Enochian Chess.

A Chess.com forum thread from 2012 (still occasionally revived) contains this observation: "Enochian Chess is the Occultist's Chess. It can be used both for Competition AND Divination."

Someone replies: "I just purchased my 4 boards. Just currently learning how to actually play it."

And then the inevitable lament: "If someone set up a website to play Enochian chess online, I would 100% sign up."

The Chess Variants community has taken notice too. Their essay strips away mystical elements to present Enochian Chess as pure game mechanics, concluding diplomatically: "Golden Dawn practitioners may take this essay to task for the method of presentation used, whereby the mystical nature of Enochian chess has been stripped away wherever possible. No offense is intended. Nor is it the design of this essay to endorse or refute anyone's belief system. Enochian Chess has been submitted to the Chess Variant Pages so that it may take its rightful place in the broader outline of chess variant history."

This is exactly right. The game belongs to chess history as much as occult history. It sits alongside Star Trek's Tridimensional Chess and Gygax's Dragonchess as a variant born from a particular subculture.

Steve Nichols has been supplying Enochian Chess sets, books, and software since 1982, starting with support from Israel Regardie himself and a grant from the Prince's Trust. His Windows software allows one to four players to engage without constructing elaborate boards or carving Egyptian deities.

Nichols published a trilogy through Mandrake Press: Rosicrucian Chess of the Golden Dawn includes Moina Mathers's Alpha et Omega papers, play strategy, and Active divinatory methods. Celtic Chess presents Yeats's sixteen-board sub-elemental extension, developed with Maud Gonne and George Pollexfen from a notebook dated December 1898. Khemetic Chess (Hypermodern Magick) explores recent variants, Crowley's relationship to the system, and "No Self" Enochian Chess.

Modern practitioners have proposed Looney Pyramid adaptations, DIY approaches with "two cheapo chess sets and colored electrical tape," digital implementations, simplified two-player versions, and four-dimensional expansions.

Does the game work? As divination? I genuinely don't know. As entertainment? Absolutely. As training for complex multi-agent thinking? Yes. As something that changes how you perceive pattern and possibility? The people who play regularly say so. Whether that change is "magical" or "psychological" or "just getting better at a complicated game" depends on vocabulary preferences more than observable facts.

Getting Started

All right. You're either intrigued, confused, or both. Now you want to actually do something. Here's how.

The Chess Variants website confirms: "Enochian chess can be played on the 8x8 board of FIDE chess." You need two standard chess sets (thrift stores work), colored tape or paint (red, yellow, blue, black), a printed board diagram with enlarged corners, and a rules summary (free at chessvariants.com). Color-code your pieces by element. Mark your corners larger. You're playing. The traditional equipment (paper stand-ups with Egyptian god designs, four-triangle squares painted in elaborate color schemes) is beautiful but unnecessary for learning mechanics.

Alternatively, Steve Nichols' software makes the game "immediately playable" without physical construction. This solves the biggest problem: finding opponents who know the rules.

Or go full immersion: purchase Zalewski's book, construct proper boards, paint attributions, create god-form pieces. This takes months but is, in Golden Dawn tradition, part of the training. Or just use colored tape. The game doesn't care.

Pick "Air of Air & Water" for first games. It's most commonly illustrated. Remember: Fire or Earth board associations require "…of Fire & Earth" arrays. Air or Water boards require "…of Air & Water" arrays.

For the traditional starting procedure: select elemental board (determines who moves first), select compatible array, players throw dice and from highest to lowest each chooses their color. The Chess Variants essayist notes this seems odd: "The player who won the die roll gets the privilege of choosing which army to operate (and whether or not that player gets the first move), but the 'winner' is then at the mercy of others in regards to choosing a teammate." Poor game design? Or deliberate teaching about limits of individual agency? With the Golden Dawn, it's genuinely hard to tell.

Start with two players. Each controls two allied elements. Each color still takes its own turn, so you alternate. Graduate to four when you have friends who've learned the system. Or just play all four positions yourself while conversing with invisible partners. Mathers did.

Do you have to believe in magic? No. "The magical practices of the Golden Dawn are of no concern to the chess variant community." Many play Enochian Chess purely as an interesting four-player variant. The throne-seizure rules, concourse captures, and frozen armies create emergent situations unavailable elsewhere. The Egyptian gods are flavor. The game is the thing. (Though if you find yourself having unusually vivid dreams after extended play, or noticing "concourse formations" in workplace politics, don't say you weren't warned. Or don't attribute it to anything supernatural. Your call.)

Where to find opponents: Chess.com forums, Reddit's r/occult and r/GoldenDawn, chess variant communities, local esoteric study groups, or yourself with an invisible partner.

First games will be confusing. The Queen's leap takes adjustment. Four armies feels chaotic. Frozen pieces create strange board states. Fifth game: patterns emerge. Tenth game: you have opening preferences. Twentieth game: you understand why this has fascinated people for over a century. Whether that fascination is "mystical insight" or "appreciation for elegant game design" or "both" is entirely up to you.

The Deep End

You've learned the rules. You've played some games. The Queen's leap no longer surprises you. You've watched for concourse formations, protected your throne, maybe seized an ally's. Now you want to know what's underneath.

You don't have to look. The game works fine without it. But if you're the kind of person who wants to know why the manual has extra chapters, read on.

The Chess Variants website describes original equipment: "Enochian chess was traditionally played on one of four specially constructed boards. Each board represented one of the classical elements. Each square of each board was divided into 4 triangles, which were painted one of four different colors. These triangles were not game spaces themselves, merely components of the larger square cells used to play the game. Although confusing to the eye, an Enochian chessboard is functionally identical to a FIDE 8x8 board."

Read that again. Each square divided into four triangles. You're not looking at a flat surface. You're looking down at a truncated pyramid.

/en/blog/2026/01/26/pyramid_square.svg
Each square represents a truncated pyramid with four elemental faces plus Spirit

In Golden Dawn conception, each of the 64 squares is the apex of a four-sided pyramid extending into dimensions that ordinary geometry doesn't acknowledge. Each triangular face carries different attributions: the element of the board (red/Fire, blue/Water, yellow/Air, black/Earth), the element of the angle (the quadrant), a color from column position via Tetragrammaton formula, and a color from rank position via the same formula. The truncated top was left blank or marked with Spirit.

Every square carries four elemental attributions simultaneously, plus Spirit. Moving a piece isn't just changing location. It's navigating interpenetrating elemental forces. Or it's just moving a piece. Depends on how you want to think about it.

The four Hebrew letters YHVH (Yod-Heh-Vav-Heh) provide structure: Yod = Fire, Heh = Water, Vav = Air, Heh final = Earth. Columns and ranks cycle through this pattern. Every square has column and rank attributions combining with board and angle attributions. Fire of Water of Air of Earth. Sixty-four unique elemental combinations.

The traditional pieces were generally stiff paper stand-ups much like the paper dolls and paper toy soldiers of the era. Each major piece had a unique name and design taken from Egyptian mythology and all the pieces were painted in four-color paint schemes. Each mounted on a base colored for affiliation. Backs painted solid by type: Kings white, Knights red, Queens blue, Bishops yellow, Rooks black. Color-coding served practical and symbolic purposes. You could identify piece type from behind. Each piece carried elemental signature interacting with square attributions.

Interestingly, original boards did not include Enochian letters from John Dee's tablets, despite the game's name. Why? Because the chessboards derive from "Servient Squares" of the Angelic Watchtowers with binding structural elements removed. Without those binding forces, placing all Enochian letters would invoke "slightly chaotic" unbound angelic forces. The game was considered dangerous enough without that variable. (Or they just thought it looked cleaner. Hard to say with Victorians.)

Those five positions where Concourse can occur? They're not arbitrary. The central squares and four corner clusters represent specific configurations where elemental forces can combine catastrophically. Four pieces of the same type, from four different armies, converge into a 2x2 formation at these positions. The moving piece captures all three others. Alliances don't matter. Intentions don't matter. The configuration produces the effect. This is the Golden Dawn teaching: certain patterns have intrinsic power regardless of who creates them. It's also just good game design. Interesting emergent mechanics from simple rules. Both can be true simultaneously.

According to Zalewski, four approaches to construction: minimal (colors only, safest for beginners), Regardie's method (omit truncated pyramid top, four triangular faces carry attributions, center left plain), spirit-bound (add Spirit symbol to top, binding elemental forces), and full attribution (paint all planetary, zodiacal, and geomantic symbols, each board becomes complete magical diagram). Most use the first or second approach. The game works fine mechanically. But knowing the deeper structure exists changes how you think about what you're doing. Or doesn't. Your reality tunnel, your choice.

Even for pure materialists: the pyramid square system encodes multiple variables into single locations. Board identity (1 of 4), angle identity (1 of 4), column position (1 of 8), rank position (1 of 8). That's 4 × 4 × 8 × 8 = 1,024 unique combinations across 256 positions (64 squares × 4 boards). Modern game designers call this "information density." The Golden Dawn called it "correspondences."

When you capture an opponent's Knight on the Watery part of the Fiery angle of the Earth board, you're asserting dominance over a specific elemental configuration. Or you're just taking a piece. Or both.

If you want deeper understanding: learn Tetragrammaton correspondences, understand column/rank cycles, know which angle you're in, consider how pieces interact with square attributions. A Fire piece on a Water square may be weakened. An Earth piece on an Earth square may be strengthened. These correspondences can inform strategy. Or ignore all this and just play. The pieces don't actually care about their mythological names. They move the same either way.

What you make of the structure is up to you. The Victorians who designed this thought it mattered enormously. Modern chess variant enthusiasts think it's interesting historical flavor. Practicing occultists think it's technology disguised as entertainment. All three groups play the same game.

Closing

Whose move is it?

Whether anything is underneath besides wood and paint is your call. Whether the invisible partner is real is your call. Whether the pyramid squares matter is your call.

The game works either way.

If you’ve read this far, thanks for letting me confuse you. I don’t think my introduction was enough to make you fully understand the game, to be honest. Especially if you just read it and didn't actually tried to play it. And there are different varieties of the game itself too. So yes, the title was a lie.

Sources


Switching from F-Droid to Obtainium


For years, my Android app strategy was simple: Google Play for mainstream apps, F-Droid for open source alternatives. When going Google-free, Aurora Store filled the Play Store gap. But I've recently switched to Obtainium and wanted to share why.

The F-Droid Problem

F-Droid sounds perfect in theory. A curated repository of open source apps, built from source, free from trackers. What's not to love?

Quite a bit, actually.

Signature Mismatch Hell

F-Droid rebuilds every app from source and signs it with their own keys. This means the APK signature differs from the developer's original release. Sounds like a security feature, right? In practice, it causes headaches.

If you ever want to switch from F-Droid to the developer's direct release (or vice versa), you have to uninstall and reinstall. All your app data? Gone. This isn't a minor annoyance when you're dealing with apps that store local data or have complex configurations.

Update Delays

Because F-Droid rebuilds everything, updates can be delayed by days or even weeks. When there's a security fix in an app you rely on, waiting for F-Droid's build pipeline isn't ideal. The developers push a fix, but you're stuck on the vulnerable version until F-Droid gets around to building it.

Editorial Decisions

This one frustrated me the most. There have been cases where F-Droid maintainers made questionable editorial decisions about what belongs in the repository. At one point, religious apps were being flagged as inappropriate content. Whether you're religious or not, that's an odd stance for what should be a neutral software repository.

Enter Obtainium

Obtainium takes a different approach. Instead of being a repository, it's an update manager that pulls apps directly from their sources: GitHub releases, GitLab, F-Droid, or wherever the developer publishes.

The Initial Hassle

I won't lie, setting up Obtainium takes effort. For each app, you need to:

  1. Find the source URL (usually the GitHub/GitLab releases page)
  2. Add it to Obtainium
  3. Configure any filters if the project has multiple release variants

For your first ten apps, this feels tedious compared to just searching F-Droid. But once you're through the initial setup, the benefits start showing.

/en/blog/2026/01/18/obtainium.png

Fortunately, there's a community-maintained app configurations site that makes adding apps much easier. You can browse pre-configured apps and add them with a single click. Hopefully in the future there will be some sort of app store integration again, not for the sake of centralization, but so that if a source URL changes, the fix would be instantly available as an update.

Direct Updates

Apps update as soon as the developer releases them. No waiting for a third party to rebuild. No signature mismatches. The APK you get is the exact same one the developer published.

Source Flexibility

Obtainium supports multiple sources:

  • GitHub Releases
  • GitLab Releases
  • F-Droid (yes, you can still pull from there if you want)
  • Direct APK URLs
  • And more

This means you can grab apps that aren't in F-Droid at all. That niche tool with only 50 GitHub stars? You can track it.

Export and Backup

Your app list can be exported and imported. Setting up a new phone becomes: install Obtainium, import your config, let it download everything. Much cleaner than manually hunting through F-Droid or remembering what you had installed.

The Remaining Concerns

Obtainium isn't perfect.

Repository Migration

If a developer moves their repository from GitHub to somewhere else, you'll need to update the source URL manually. I'm not aware of any automatic notification for this. Then again, this is a problem with most software distribution, it's just more visible here.

Trust Model

With F-Droid, you trust F-Droid's build process. With Obtainium, you trust each individual developer's release process. For popular projects with proper release signing, this is arguably better. For random projects? You're trusting that their GitHub account hasn't been compromised.

No Curation

F-Droid's curation has downsides (see the editorial issues above), but it does mean someone has at least glanced at what's in the repository. With Obtainium, you're on your own for vetting apps.

My Current Setup

I'm now running Obtainium as my primary source for open source apps. The apps I use regularly all have GitHub releases, so the setup was straightforward once I invested the initial time.

I'm not fully Google-free yet. Some apps I've purchased over the years (like Genius Scan Pro) or apps that depend on Google Play Services still force me to keep the Play Store around. The first thing I do when getting a new smartphone is debloating it via adb, removing as much Google cruft as possible while keeping the bare minimum functional.

Once GrapheneOS becomes available on OEM devices, I'll probably make the full switch and use Aurora Store for anything that still requires Play Store access. There's been promising news about a major OEM partnership, so hopefully this year will be the year.

The comfort of getting updates directly, without signature issues or arbitrary delays, has been worth the setup effort. If you're already questioning your app sources, Obtainium is worth trying.


Rethinking Dotfiles (Nix)


After years of accumulating a messy collection of dotfiles, I'm finally ready to take the plunge into declarative configuration management with Nix home-manager.

The Problem with Chezmoi + Ansible

My current setup relies on chezmoi combined with shell scripts and Ansible. What started as a clean solution has grown increasingly complicated over time.

On openSUSE, local Ansible playbooks worked reasonably well. But after switching back to Arch, the approach completely fell apart. Ansible on Arch forces you to configure too much through raw shell commands. What was once a playbook is now a collection of shell scripts calling other shell scripts. The simplicity is gone.

Chezmoi handles the dotfiles themselves fine, but it doesn't solve the broader problem: setting up the environment around those dotfiles. Installing packages, configuring services, managing project-specific contexts. All of that still requires brittle scripting.

The 39C3 Spark

What reignited my interest in Nix was attending 39C3 and subsequently diving into the NixCon 2025 recordings on media.ccc.de. Watching talks about reproducible builds, declarative system configuration, and the matured home-manager ecosystem made me realize how far the Nix community has come since my first encounter with NixOS back in early 2020.

The tooling has improved significantly. Flakes provide a standardized way to define inputs and outputs. Home-manager has grown into a robust solution for managing user environments. The documentation and community resources are vastly better than they were back then.

Direnv: My Current Workflow

My development workflow is heavily influenced by direnv. Each project has its own .envrc that sets up the environment: language versions, tools, environment variables. It's been a game-changer for context-switching between projects.

# Example .envrc
use nix
export AWS_PROFILE=project-x
export KUBECONFIG=~/.kube/project-x.config

Direnv + nix-shell already gives me per-project tooling. But managing the non-project-specific parts of my environment (shell configuration, editor setup, CLI tools) remains manual and messy.

What Nix Home-Manager Offers

Home-manager takes the declarative approach beyond development environments to your entire user configuration:

  • Modular Configuration: Split your config into logical modules. A git.nix for version control settings, a shell.nix for zsh/bash configuration, an editor.nix for Neovim or Emacs.
  • Project-Specific Contexts: This is where it gets interesting. Instead of scattered AWS config files and manual profile switching, I can define project-specific modules that set up everything needed for a particular client or project.
# modules/work/project-x.nix
{ config, pkgs, ... }:
{
  programs.awscli = {
    enable = true;
    profiles.project-x = {
      region = "eu-central-1";
      sso_account_id = "123456789";
    };
  };

  home.sessionVariables = {
    PROJECT_X_CONFIG = "${config.home.homeDirectory}/.config/project-x";
  };
}
  • Reproducibility: The same configuration produces the same environment on any machine. No more "it works on my laptop" for my own setup.
  • Rollbacks: Made a configuration mistake? Roll back to the previous generation. This safety net makes experimentation less risky.

The Plan

I'm not planning to switch to NixOS on the host system. Arch will remain my base. But home-manager works perfectly fine on non-NixOS systems, managing just the user environment while leaving the system configuration to pacman.

The migration will be gradual:

  1. Start with the basics: shell configuration, common CLI tools
  2. Move editor configuration into home-manager
  3. Gradually add project-specific modules
  4. Eventually have a fully declarative, version-controlled user environment

Combining Direnv and Home-Manager

The beauty is that direnv and home-manager complement each other. Home-manager handles the baseline, the stuff I need everywhere. Direnv handles project-specific overrides and development shells. Together, they provide both consistency and flexibility.

Will I end up using HRT and become a Furry? I hope not!


2026: The Year of Solder


Coming back from 39C3, my hands still smell faintly of flux and I couldn't be happier about it.

Soldering Workshops at 39C3

One of the highlights of Congress was attending the soldering workshops run by Mitch Altman. If you've never had the chance to learn from him, you're missing out. The man has been teaching people to solder for decades and has a knack for making electronics accessible to complete beginners.

He's also the author of a fantastic comic called Soldering is Easy that explains the basics in a way that actually sticks. No dry technical manuals, just clear illustrations showing proper technique, common mistakes, and how to fix them. If you're starting out, find that comic. Also I always wanted to have a Brain Machine. I was looking forward to this years ago when being addicted to the books of Robert Anton Wilson but got scared off when knowing you have to assembly it yourself. This was my chance to learn from the inventor himself!

I did three additional ones on the Congress. One with Mitch too based on Arduino and his TV-B-Gone project (a TV remote shutting off all possible TVs haha) and one about Lora building an own ground station. So I guess all in all I was so happy to spark some more excitement about Tech.

Getting Hooked

There's something deeply satisfying about soldering. The smell of burned stuff, the precision required, the immediate feedback of a shiny joint versus a cold one. It's a meditative process that results in something tangible. A stark contrast to the ephemeral nature of most software work.

At the workshops I built a few kits and finally understood why my previous attempts at soldering had been so frustrating. Turns out, a decent iron and proper flux make all the difference. Who knew.

Plans for 2026

This year I want to do more electronic projects. Not just soldering kit builds, but actually designing and creating things:

  • Experiment with microcontrollers beyond the usual Arduino blink sketches
  • Something something ESP32 magic
  • Maybe finally tackle that custom macro pad idea I've had for years
  • Learn to read schematics properly
  • Learn how to do my own PCB designs (Because why not!)
  • Ordering way tooooo much stuff on aliexpress
  • Creating blinking stuff
  • Own programmable christmas lights for my Homeoffice plan/tree "Nain"

The hacker spaces and assembly halls at Congress were full of inspiration. People building everything from synthesizers to badge add-ons to art installations. That energy is contagious.

Time to heat up the iron.