Case Study

The 2025 Refresh
Why These Choices

Appendix B walked through the Debian + Fluxbox stack. This page is the companion to a later, real refresh of that exact setup — a write-up published in December 2025 that automated the whole thing into one script. Every choice below has a reason that goes beyond "it's more minimal" — most of them trace straight back to how I already think about systems in my day job, in the air, and on the radio.

7 choices
1 real script
Companion to Appendix B

Section 01

Why write this down at all.

Most "here's my dotfiles" posts stop at what is installed. The interesting part is why — and once you notice the pattern, the same handful of instincts show up over and over: keep the boundary small, keep a way back, and don't trust a config you can't explain out loud. Those aren't Linux ideas. They're just the ideas I already use for a living, applied to a desktop.

Window manager & display
Fluxbox on X11 — not a full DE, not Wayland yet
Assessing a system for a living means being able to say exactly what's running and why. A full desktop environment is a lot of moving parts to account for; a WM you chose component-by-component is a system you can actually reason about — the same instinct behind reviewing a security boundary rather than trusting a bundled default. Wayland has closed most of its gaps in the last few years, but "closed most of" isn't "closed," and swapping a display server is cheap enough to do later. Changing distros is the expensive move — this isn't.
Package policy
APT guardrails — the Cinnamon pin and lean defaults
/etc/apt/preferences.d/no-cinnamon.pref and Install-Recommends false aren't about disk space. They're configuration-drift control — the same reason a monitored system gets checked against its authorized baseline instead of trusted to stay put on its own. An upgrade silently pulling in a full desktop you didn't ask for is exactly the kind of unauthorized state change that should never pass quietly, on a laptop or an aircraft system.
Automation
One data-driven script, PROFILE toggles
workstation, full, minimal, guardrails are named, documented configurations — not a memory of which flags I ran last time. That's the same reason an authorization boundary gets written down instead of inferred from whatever's currently deployed: if you can't reproduce it from a document, you don't actually know what it is. A flight checklist works the same way — the list is the authority, not the pilot's memory of what usually gets done.
Audio
PipeWire by default, ALSA kept as a togglable fallback
Move to the current stack, but never remove the way back until the new one's proven itself. It's the identical shape as keeping a password-only breakglass account around while rolling out FIDO2 login: adopt the improvement, keep a tested rollback path, don't burn the bridge on day one.
Input & control
xterm, and keybindings tuned to exact increments
Backlight and volume move in explicit, named steps (±5%) instead of whatever a slider happens to land on. That's a small thing, but it's the same preference that shows up in ham radio gear — a knob with detents you can count, not a touchscreen you have to eyeball. Precise, repeatable control beats a prettier default.
Release track
Debian Testing — not Stable, not Sid
Current and maintained, not experimental. It's the same standard I'd apply to an aircraft: fly something with up-to-date avionics and active maintenance, not a museum piece and not somebody's homebuilt project. Testing gets fixes faster than Stable and has already been shaken out more than Sid — that middle ground is the point, not a compromise.
Extras
Retro games in the "full" profile
DOSBox Staging, ScummVM, xgalaga, xmahjongg — genuinely lightweight, and genuinely there on purpose. The same deliberate throwback flavor shows up in the training tool's own 1990s-cyber styling: it's not nostalgia for its own sake, it's a reminder that a system can be current under the hood and still have some personality on top.

Section 02

The pattern, if you're looking for one.

None of this is really about Fluxbox. It's about being able to point at any piece of a running system and say what it's for, what happens if it's removed, and how to get back if a change goes wrong. That habit didn't start with Linux — it's just where it's easiest to see, because every piece is visible and every choice is yours to make.

Want the actual script instead of the reasoning behind it? See Appendix B: Debian + Fluxbox — A Real-World Setup for the stack walkthrough, or the original blog post for the full, runnable debian-fluxbox-setup-testing-2025.sh.