Linux

TL;DR I maintain workstations for people who are never going to run git pull — so the config lives in a repo I own and they never see. It is a reference/restore repo, not config management: per-machine folders hold snapshots of what’s actually installed, and restore is a deliberate install -Dm755, not a sync. The no-auto-sync part is the whole point. Silent convergence across machines that are supposed to differ is how you break someone else’s laptop from your desk. The boring 40 minutes — partitioning, encryption, sudo, base packages — is an unattended installer (a Debian preseed, now on its eleventh revision). The interesting 20 minutes is the per-machine folder. The agent’s job isn’t to apply config. It’s to read the repo, diff it against the live box, and tell me what drifted — then write the restore commands for me to approve. What I’d do differently: put the agent’s own profile in git before you have three machines copying it from each other over SSH. The problem with managing other people’s computers I run a handful of machines that aren’t mine. A couple of family desktops, a bench box at the office, and a laptop belonging to someone who does knowledge work and would rather not learn what a dotfile is. ...

TL;DR The Linux kernel is 36 million lines of C. Rust has been slowly entering the kernel since Linux 6.1, but progress is measured in individual drivers and abstractions – a few thousand lines per release cycle. What if you skipped the incremental approach and asked Claude to rewrite major subsystems wholesale? I spent a weekend scoping this as a serious project plan: breaking the kernel into translatable units, estimating token costs, identifying the hard walls, and testing Claude’s ability to produce correct Rust translations of real kernel C. The conclusion: Claude can translate isolated, well-bounded kernel modules with surprising accuracy. It cannot translate the kernel. The difference between those two statements is the entire lesson. ...