Following my March reflection on diversity arguments, I have been trying to honestly assess what running multiple operating systems actually costs in practice. My own setup runs Slackware Linux, OpenBSD, and a small amount of Solaris. The cost of the diversity is real. Worth writing about.
What the cost actually is
Three categories.
Knowledge maintenance. Each platform has its own commands, conventions, file layouts, package management. I have to remember which OS uses which init system, which one has /usr/local/etc versus /etc/local, which one's ifconfig syntax is which. Most of the time the differences are minor. Some of the time they are not. The cumulative cognitive overhead is real.
Tooling overhead. A monitoring tool or an automation script that works on one platform may need adjustment for another. Some of my structured-log helpers had to be modified when I added OpenBSD; specific assumptions about syslog format did not hold.
Patching cycles. Each platform has its own advisory channel, its own update mechanism, its own patching cadence. I have three separate patching workflows. The discipline to maintain all three reliably is non-trivial.
The marginal incident is more complex. When something goes wrong on the network, the diagnosis sometimes spans platforms. Tracing a bad packet from a Linux server through an OpenBSD firewall to a Solaris client requires familiarity with all three. The investigation cost is higher than for a homogeneous network.
What the cost is in concrete terms
For my setup specifically:
- Three patching cycles per month, each about an hour of attention.
- Two or three small incidents per quarter where the multi-platform aspect adds investigation time.
- Approximately 10% of my operational time is platform-translation overhead — solving the same problem on multiple platforms, or translating concepts between them.
This is bearable. It is also not free.
What the benefit is
Three concrete benefits.
Each platform's worms have stopped at the platform boundary. Ramen and Lion targeted Linux; my OpenBSD perimeter was unaffected by those. The IIS Unicode bug targeted Windows; my Linux servers were unaffected.
My understanding of each platform is deeper. Comparing how OpenBSD does something against how Linux does it reveals the design choices each made. The compare-and-contrast is itself educational.
The structural defence is real. A compromise of any single host on my network does not propagate to the rest by virtue of the platform difference. The Microsoft compromise pattern — flat homogeneous network with extensive lateral movement — does not apply to my setup.
When I would advise diversity
For an operator deciding whether to take on the cost:
Yes, if your threat model includes platform-targeted attacks. Internet-facing servers, email gateways, environments where worms and trojans are realistic threats — diversity is a meaningful defence.
Yes, if you have the operational depth to maintain multiple platforms well. Large-enough teams that can specialise; small-enough teams where every member is expected to be cross-platform.
No, if the maintenance discipline on your primary platform is already strained. Adding a second platform when the first is undermaintained makes both worse.
No, if the operational model assumes a homogeneous environment. Some shops are built around tooling and processes that assume homogeneity; retrofitting diversity is expensive.
The right answer is contextual. The wrong answer is to recommend diversity universally without acknowledging the costs.
What I am taking from the exercise
For my own writing: be more careful about how I recommend diversity. The advice in my old monoculture posts was too unconditional.
For my own setup: continue the multi-platform discipline. The cost is bearable; the benefits are real; the trade-off is, for my circumstances, favourable.
More as the year develops.