Pimp My IDE / Garage Dispatch
Back to garage
September 25, 2026 | NixOS / public workstations / dependency control

Autonomy lives in the dependency map.

A different desktop can reduce supplier lock-in. The stronger move is to make each source, build input, control path, and exit drill inspectable.

The take: the Dutch DAWO project treats the workplace as replaceable parts and publishes a NixOS configuration for rebuilding machines. Its own flake comments also record foreign-hosted inputs that remain to be mirrored. That honesty is the useful part. Autonomy is measurable work, not a wallpaper choice.
Map the dependency gantry

The desktop is one part.

DAWO is a Dutch government initiative for an interoperable, digitally autonomous workplace. Its public blueprint separates the workplace into operating system, cloud, collaboration, and AI parts. Each part is meant to be developed and replaced on its own.[1]

The operating-system repository uses Nix flakes and modules to define desktops, hardware, hardening, networking, programs, services, users, and host configurations. The project says this structure supports reproducible definitions across hosts and services.[2]

The valuable unit is not the replacement desktop. It is the replacement path.

The lock file is part of procurement.

The current DAWO flake pins many inputs, but its own source comment says 15 load-bearing inputs are still fetched from GitHub. The stated goal is to mirror them and repin the configuration. Another comment explains how an unpinned dependency moved hosts, broke evaluation, and stopped every device configuration from evaluating even though this repository had not changed.[3]

That is a better lesson than a clean sovereignty slogan. Open licensing, declarative configuration, pinned inputs, source hosting, binary delivery, identity, and fleet control are separate dependencies. One can move while another remains fixed to a supplier.

Reproducible is a test result.

The Reproducible Builds project defines a reproducible build as one where the same source, environment, and instructions let any party recreate bit-for-bit identical artifacts. Verification requires comparing the artifacts.[4]

NixOS provides declarative system configuration, generations, and rollback. Its manual documents how a configuration can build and switch the running system.[5] Those mechanisms help control the workstation. They do not prove that a second party rebuilt the image, that all required sources remain reachable, or that an organization can operate the fleet after a supplier exit.

Put four receipts on the bench.

A practical autonomy review needs four records:

  1. A source map with owners, licenses, revisions, and reachable mirrors.
  2. A build receipt with pinned inputs, builder definition, artifact hash, and independent comparison.
  3. A control record for identity, updates, policy, fleet actions, and emergency authority.
  4. An exit drill that rebuilds and operates a sample machine without the supplier route being tested.

The gantry below writes the outline. It does not inspect a lock file, mirror a repository, build an image, compare artifacts, or run an exit drill.

Interactive makeover / dependency review

Sovereignty torque map.

Traditional purpose replaced: a vendor checklist with one open-source box. Better version: select the four evidence circuits and copy a drill card that keeps configuration, proof, authority, and exit work separate.

Close the evidence circuits

Native checkboxes own the state. The vertical bus shows how much of the review structure is selected.

Autonomy evidence circuits
DRAFT MAP1 / 4 CIRCUITS SELECTED

The source route is visible. Operation is still unproved.

Source route is selected. Build proof, control authority, and exit drill remain open.

Selected structureSource route
Completion claim1 of 4 evidence circuits selected. No build or exit drill has run.
This teaching control writes a review template. It does not inspect repositories, fetch inputs, build a workstation, compare hashes, change fleet control, or test recovery.

Copy the exit card

Fill and test after copyingAdd real revisions, mirrors, builder versions, artifact hashes, operators, commands, outputs, dates, and reviewers. Selected circuits describe template structure only.

Sources read, not vibes

Open the source log
  1. DAWO blueprint: public description of the operating-system, cloud, collaboration, and AI parts, with links to project repositories and implementations.
  2. DAWO Core README: flake-based build, modules, multi-tenancy, repository move, mirrors, architecture links, and module map.
  3. DAWO Core flake: pinned inputs, host locations, input-follow rules, mirroring goal, and the documented failure caused by an unpinned dependency move.
  4. Reproducible Builds definition: source, environment, instructions, artifact scope, and bit-for-bit verification.
  5. NixOS manual: declarative configuration, system builds, switching, generations, rollback, modules, and tests.
  6. Hacker News item 49841563: exact discovery thread for the current DAWO discussion.

Source boundary: DAWO describes its own goals, architecture, and current repository state. NixOS documents its configuration and administration mechanisms. Reproducible Builds defines artifact reproducibility. None of these sources proves that DAWO has completed every mirror, independent rebuild, fleet transition, or supplier exit drill. The torque map is our review pattern.