post type
Conceptual, architectural explainers — how a subsystem actually works underneath.
A deeper look at FreeBSD's Capsicum framework — cap_rights, the process descriptor model, and how to structure a service around capability mode instead of bolting it on afterward.
How HAST mirrors block devices across two hosts over the network, how Ctl serves them out as an iSCSI target, and where each one actually fits versus ZFS's own replication tools.
How FreeBSD gathers entropy from interrupt timing and hardware sources, feeds it into Fortuna, and guarantees /dev/random never blocks without silently becoming predictable.
How rc.d resolves which service starts before which without a central dependency graph author, and how to write a script that actually plugs into that ordering correctly.
How the Virtual File System abstraction lets FreeBSD run UFS, ZFS, tmpfs, and NFS behind the exact same open()/read()/write() calls, and what that abstraction actually costs.
BFS treats extended attributes as first-class, indexable data — turning ordinary file queries into something closer to a database lookup, decades before this became a mainstream idea.
A walk through what actually happens between powering on a Haiku machine and reaching a usable desktop, and where things most commonly go wrong along the way.
Haiku's driver model inherits BeOS's modular, hot-pluggable design — but as a much smaller, community-driven project, its hardware support has real, practical limits worth understanding upfront.
Haiku's kernel wasn't built as a Unix variant with threading bolted on — it was designed around threads as the fundamental unit of execution from the very beginning.
Haiku's native C++ API isn't one monolithic library — it's a set of separately-scoped 'Kits,' each owning one concern, that together define what writing software for Haiku actually looks like.