Linux: My Private Life. OpenBSD: My Public Exposure

There is a recurring disconnection in operating system debates: the urge to crown a single distribution or kernel to solve the entirety of one’s digital existence. For many, you either become a monastic free-software purist struggling to get an audio interface working, or you surrender to the over-engineered complexity of corporate infrastructures that nobody fully understands.

My stance is pragmatic and unequivocal. After decades designing architectures, auditing networks, and living in front of the terminal, my ecosystem is divided along a sharp boundary:

Linux is my private trench; OpenBSD is my shield against the world.

This is neither a contradiction nor a sysadmin’s whim. It is the direct application of an elementary engineering principle: the right tool for the right threat vector.

+---------------------------------------------------------------------------------------+
|                         DUAL ARCHITECTURE & THREAT VECTORS                            |
+---------------------------------------------------------------------------------------+
|  PRIVATE ZONE (Local Workstation)             |  EXPOSED ZONE (WAN Edge / Perimeter)  |
|  Base: Debian GNU/Linux                       |  Base: OpenBSD                        |
|-----------------------------------------------|---------------------------------------|
|  * Rapid development in Go, Python & C        |  * httpd(8) in native /var/www chroot |
|  * Pentesting, auditing & packet dissection   |  * relayd(8) for TLS termination      |
|  * Wayland, multi-monitor, pro audio gear     |  * Deterministic Packet Filter (PF)   |
|  * Local virtualization & container engines   |  * pledge(2) & unveil(2) mitigations  |
|  * Daily life free from corporate telemetry   |  * Audited codebase & strict W^X      |
|-----------------------------------------------|---------------------------------------|
|  Vector: Raw power, flexibility & creation    |  Vector: Zero attack surface          |
+---------------------------------------------------------------------------------------+

1. The Internal Workshop: Why Linux Powers My Daily Life

In my workspace, on my local workstations, and across everything that constitutes my daily routine, there is no room for any system other than Linux. Specifically, a solid, clean, uncompromising Debian base.

My workstation is not a museum display; it is an anvil where I forge code daily in Go, spin up system utilities, automate tasks in Python, and deploy environments driven by specification-first development. It is the environment where I audit infrastructure, run penetration testing toolchains, inspect packets, and dissect network traffic.

Yet my personal machine is also my life outside the shell. It is the space where I write, read, tinker with consumer electronics, curate my archive library, organize my engineering projects, and consume media without seeking permission from proprietary licensing models or corporate telemetry.

Key Factors Behind Linux on the Local Side

• Hardware Support & Versatility: I need to squeeze high-performance workstations, drive multiple high-DPI displays under Wayland, run external USB audio interfaces, leverage GPU acceleration, and handle specialized peripherals without absurd friction.
• Development & Testing Ecosystem: The speed at which modern software is built, compiled, and tested in a GNU/Linux environment remains unmatched. Containers, local virtualization sandboxes, and modern toolchains are natively optimized for this kernel.
• Absolute Operational Freedom: My local operating system does precisely what I command. If I need a quick script to mutate a network socket on the fly or a custom kernel configuration to capture traffic in monitor mode, Linux hands over the keys to the engine without hesitation.

Linux in my private life represents horsepower, malleability, and creative freedom. It is the workshop where things get dirty, built, and battle-tested.

2. The Hostile Frontier: Why OpenBSD Faces the Internet

The threat landscape shifts radically the second a socket listens on a public IP address.

The Internet is not a friendly neighborhood. It is a hostile territory, saturated with continuous automated sweeps, botnets hunting for zero-day vulnerabilities at 3:00 AM, and malicious actors weaponizing the smallest memory leak. When I expose a service to the public—whether a Go API, a reverse proxy, a secure gateway, or a client’s edge infrastructure—flexibility ceases to be an asset and becomes a hazardous liability.

This is where OpenBSD steps in.

This decision does not stem from believing Linux is inherently insecure. A Linux installation configured by experienced hands—with hardened AppArmor or SELinux profiles, isolated namespaces, stripped kernel capabilities, and a meticulous firewall—can be exceptionally robust. The issue lies in the attack surface and architectural complexity.

The Linux kernel spans tens of millions of lines of code. Thousands of drivers for architectures you will never run on a server, layer upon layer of legacy subsystems, and a relentless release cadence where shiny new features often take precedence over architectural simplicity. Hardening Linux is an active, continuous, and human-error-prone process: you have to remember to turn off everything you don’t need.

In OpenBSD, the equation is inverted: it is secure by default.

Pillars of OpenBSD Resilience

1. Relentless Simplicity & Code Audits: The OpenBSD team does not engage in feature-bloat races. Their focus is code correctness, readability, and structural simplicity. If a feature introduces unnecessary complexity at the expense of robustness, it is discarded without compromise.
2. Proactive Mitigation Primitives: OpenBSD does not wait for a vulnerability to be discovered to protect you. Groundbreaking kernel mechanisms such as pledge(2) (which restricts the specific system calls a process can issue once initialized) and unveil(2) (which restricts filesystem visibility strictly to explicitly permitted paths) transform daemons into airtight vaults. Even if an attacker achieves arbitrary code execution inside a daemon, they find themselves locked in an empty room with zero syscalls available to escalate privileges.
3. The Native Edge Stack: Packet filtering with PF (Packet Filter) on OpenBSD is a masterclass in syntax, clarity, and logical consistency. There is no baroque syntax or confusing translation layers. Combined with native daemons like relayd(8) and httpd(8), you can stand up load balancers, reverse proxies, and static web servers with microscopic memory footprints and minimal attack surfaces.
4. Operational Peace of Mind: When I deploy an edge service on OpenBSD, I know exactly which processes are executing, which ports are open, and how every base daemon behaves. You sleep better knowing your firewall does not rely on a bloated web of auxiliary dependencies.

3. Technical Comparison Matrix

4. Two Philosophies, One Standard

Attempting to run OpenBSD as your daily workstation for multimedia production or rapid GUI-driven prototyping can be an exercise in needless friction. Conversely, deploying a generic Linux installation cluttered with layers, daemons, and bloated subsystems on the exposed edge of a critical infrastructure is often an act of unjustified optimism.

Drawing this boundary is not a contradiction. On the contrary: it represents technical maturity.

On my local machine, I demand horsepower, universal compatibility, adaptability, and total control to create, investigate, and live. On servers exposed to the world, I demand mathematical rigor, kernel-level mitigation, audited code, and an unbreakable defensive stance.

Linux in my private life to build without limits. OpenBSD facing the network so nobody tears down what I built.