Conceptual, architectural explainers — how a subsystem actually works underneath.
A live query doesn't just return files matching a condition once — it keeps the result set current automatically, as files are created, changed, or deleted, for as long as the query stays open.
Haiku applications don't poll for events in a manual loop — they define Handlers, and let a Looper thread dispatch messages to the right one automatically.
Haiku's Media Kit models audio and video processing as a graph of connected nodes passing buffers to each other in real time — the same conceptual model professional media software still uses today.
Haiku runs on POSIX-like conventions and supports plenty of Unix software, but underneath that compatibility layer, it isn't descended from Unix at all — its kernel, API, and core assumptions come from somewhere else entirely.
Installing a package on Haiku doesn't copy files onto disk at all — it mounts the package itself as part of a virtual file system, which is exactly what makes activation and rollback instant.
How Linux capabilities split root's monolithic power into dozens of independent privileges, and why that's a meaningfully better security model than the traditional all-or-nothing setuid-root pattern.
Why io_uring's shared ring-buffer design eliminates most of the syscall overhead that made previous Linux async I/O interfaces disappointing in practice.
The badness scoring the kernel actually uses to pick a victim process when memory is exhausted, and why the process that gets killed is often not the one that caused the problem.
Why 'free' memory on a Linux system is mostly a lie in the useful direction, and how dirty pages actually get from RAM to disk without every write() blocking on it.
The path from a kernel detecting new hardware to a predictably-named device node appearing in /dev, and why udev's naming rules exist at all instead of just using whatever the kernel calls a device.