Hardware and Internet

Every machine is different — different processor, different graphics, different disk. The differences are real and cannot be wished away.

What can be arranged is where they are allowed to appear. IOSHI isolates them into per-device modules so the layers above never encounter them. The same intelligence interface should run on a laptop, a headless server or a machine under WSL, and it should not know which.

The failure this prevents is the common one: a driver quirk that leaks upward until it is referenced in three unrelated places, and the stack quietly becomes unportable.

A framework that never names a machine is difficult to evaluate. The reference below is the workstation-class machine this layer is developed against. It is an example of the preference, not a requirement — IOSHI runs on whatever NixOS runs on.

Lenovo ThinkPad T14 Gen 5 (AMD)

The specification matters less than the properties that make it a good hardware layer:

• Serviceable. Two memory slots and a replaceable drive mean the machine can be upgraded rather than replaced. A layer whose job is to absorb physical differences is undermined by hardware that cannot change.
• Mainline support. Integrated AMD graphics are supported by the upstream kernel with no proprietary driver, so the substrate above stays clean.
• Documented and repairable. A business chassis has published service manuals and long parts availability. That is a property of the layer, not a preference about brands.
• 16:10. A taller panel is more text, and this whole stack is text.
• Attainable. A mainstream business laptop, bought new for under $1,000 in 2026 — not exotic hardware, and not workstation-class pricing.

The stack is lean by construction rather than by tuning, and the reasons are structural:

• There is no desktop environment. The compositor is the editor process, so the entire graphical layer is one program rather than a session manager, a panel, a settings daemon and a notification service.
• Packages are declared, not installed. A build contains nothing that was not asked for. A headless host does not hide the graphical applications — it never contains them.
• Nothing depends on a per-application runtime. The tools are native, and the interface is one long-lived process rather than several browsers wearing hats.

The practical consequence is worth stating plainly: a used business laptop at roughly a quarter of the reference budget runs this comfortably. Older silicon, 8–16 GB of memory and any SSD is a genuinely pleasant machine for this stack, and the substrate alone runs well below even that — the headless role is happy on hardware nobody would call current.

So why name a newer machine as the reference at all? Because it runs and it is worth building on are different questions. The T14 platform is proven and well understood, serviceable by design, supported by the mainline kernel without proprietary drivers, and likely to have parts available years from now. It is chosen as a long-term platform, not as a minimum specification.

If the budget is the constraint, buy used and lose nothing that matters here. If longevity is the constraint, this is the class of machine to buy.

A concrete example, because the principle is easy to state and easy to violate.

The compositor launches from a text console at boot. On a machine with integrated graphics, the graphics driver must therefore be initialized in the initial ramdisk — otherwise the compositor loses the race for display control and the session never starts.

That is a fact about one machine. It belongs in that machine's hardware module, in one line, and nothing above it should ever mention it. A headless host needs none of it and carries none of it.

Network position is physical reality too. Machines join a private mesh, so they address each other directly rather than through a third party, and files replicate between them without a hosted service in the middle.

The layer's principle applies unchanged: the intelligence interface does not know which physical machine it is running on, or by what route it reached the others. It gets the same editor, the same shell, the same tools.

Hardware is not an implementation detail to be abstracted into irrelevance. It is the ground the rest stands on, and pretending otherwise is how stacks become unportable.

Name it, isolate it, and let the layers above stay ignorant of it on purpose.