Redefining the Operating System: When Boundaries Begin to Dissolve

An Old Question With a New Answer

"What even counts as an operating system?" This seemingly fundamental question has become increasingly difficult to answer. A blog post titled What even is an OS now? published on sockpuppet.org sparked intense debate on Hacker News, earning 213 points and nearly 300 comments — a sign that the topic struck a nerve with many in the tech community.

Traditional textbooks offer a fairly clear definition of an operating system: an abstraction layer that manages hardware resources, schedules processes, and provides file systems and device driver interfaces. But when we examine today's computing landscape, that definition is being shattered by a wave of new system architectures. From container orchestration to WebAssembly runtimes, from serverless cloud platforms to the browser itself, the boundaries of what constitutes an "operating system" are growing increasingly blurry.

The Ever-Growing Stack of Abstractions

The complexity of the modern software stack far exceeds anything that came before. An application might run inside a container, orchestrated by Kubernetes, which runs on a virtual machine, which is managed by a hypervisor on the host, all of which ultimately rests on physical hardware.

In this deeply nested hierarchy, which layer is the "operating system"? When a developer deploys a function to a serverless platform, they're almost entirely unaware of the underlying kernel — resource scheduling, scaling, and isolation are all handled by the platform. From the developer's perspective, that platform is their operating system, even though it's conceptually nothing like a Linux kernel.

This shift in perspective surfaces a core insight: the essence of an operating system may lie not in its specific technical implementation, but in the role it plays — providing resource abstraction and a runtime environment for the layers above it. Whoever takes on that role, at any given layer, is the "OS" at that level.

A hypervisor (virtual machine monitor) is a critical component in this nested architecture, and comes in two varieties: Type 1 hypervisors (such as VMware ESXi and Microsoft Hyper-V) run directly on bare-metal hardware, while Type 2 hypervisors (such as VirtualBox) run on top of a host operating system. Kubernetes, as a container orchestration layer, does not directly manage hardware — instead, it achieves resource isolation and allocation by invoking underlying container runtimes (such as containerd) and Linux kernel mechanisms like cgroups and namespaces. cgroups limit resource usage such as CPU and memory, while namespaces give processes an isolated view of the system (including independent network stacks, filesystem mount points, and process ID spaces). These two kernel features are what enable containers to achieve lightweight isolation without requiring a full virtual machine. Because containers share the same Linux kernel, however, their security boundaries are inherently weaker than those of virtual machines — a fundamental trade-off in any architectural decision about which layer the "OS" should live at.

The Browser: A De Facto Application Platform

The browser is the most striking example in this discussion. Today's web browsers have long outgrown their original purpose of displaying web pages. They now possess process isolation, memory management, graphics rendering pipelines, network stacks, and even sandboxed file access. Combined with WebAssembly, browsers can run complex applications at near-native performance.

In this sense, the browser has become a cross-platform application runtime — shielding web applications from the differences between underlying operating systems, allowing the same code to run consistently on Windows, macOS, Linux, and mobile devices alike. This is precisely the "write once, run anywhere" promise that operating systems once made but never fully delivered.

Many developers in the comment thread pointed out that for a large segment of end users, the "operating system" they actually interact with is the browser — the underlying Windows or macOS is merely a bootloader that launches it.

WebAssembly (Wasm) is the key technology behind the browser's evolution into an OS-like platform. It is a binary instruction format designed for a stack-based virtual machine, intended as a compilation target for languages like C, C++, and Rust, enabling code written in those languages to run in the browser at near-native speeds. Wasm uses a sandboxed execution model — by default, it cannot access any resources outside its own memory and must interact with the outside world only through interfaces provided by the host environment (the browser). This design gives it inherent security isolation properties. Notably, WebAssembly's ambitions extend well beyond the browser. The WASI (WebAssembly System Interface) specification attempts to provide Wasm modules with a standardized system call interface, enabling them to run on servers, edge nodes, and even embedded devices. Docker co-founder Solomon Hykes once remarked: "If Wasm+WASI had existed in 2008, we would never have needed to create Docker." This comment speaks volumes about Wasm's potential as a new general-purpose runtime.

Why the Definition Actually Matters

Why does it matter what we call an operating system? This is not a purely academic debate. The blurring of the definition reflects a profound shift in computing paradigms.

As traditional kernel responsibilities — resource management, isolation, scheduling — are distributed across orchestration systems, runtimes, and cloud platforms, security boundaries, performance bottlenecks, and failure domains shift along with them. Understanding "where the OS is" is really about understanding "where control lives" and "where trust boundaries lie." For system designers, getting this right has direct architectural implications: at which layer to enforce isolation, at which layer to build observability, and at which layer to apply security policy.

Another angle worth considering: as AI inference becomes a central computing workload, will we see a new kind of "operating system" built around model scheduling? When the primary unit of resource allocation shifts from processes to models and tensors, do the abstractions of the traditional kernel still apply? These questions remain open, but they are already entering the conversation in technical communities.

The new challenges that AI inference poses for the "operating system" have concrete technical manifestations. Scheduling for GPU accelerators and other specialized hardware is fundamentally different from traditional CPU process scheduling: CUDA streams, tensor parallelism, KV cache management, and swapping model weights in and out of GPU memory are all semantic units that a traditional kernel scheduler is completely blind to. Some projects are already trying to fill this gap — vLLM's PagedAttention mechanism, for instance, borrows the virtual memory paging concept from operating systems to manage KV caches, while Triton Inference Server plays the role of a model-level "process scheduler." From a broader perspective, when the subject of a "compute request" shifts from "running a piece of code" to "using a model to infer a token sequence," the granularity and semantics of resource abstraction need to be redesigned from the ground up — and that is precisely where the "AI-native operating system" discussion begins.

A Question Without a Standard Answer

This article resonated so widely precisely because it doesn't offer a closed answer — instead, it reveals an evolving reality. The operating system has never been a static concept. It continuously reinvents itself in response to changing computational needs.

From mainframe time-sharing systems, to the graphical interfaces of personal computers, to today's cloud-native and edge computing environments, the "operating system" has always been an answer to one fundamental question: how do people use computing resources? Today, that answer has become plural and distributed — perhaps a sign that computing itself has permeated more layers and contexts than ever before.

Rather than insisting on a single unified definition, it may be more useful to accept this: "operating system" functions more like a role label. Whoever, in a given context, takes on the responsibility of resource abstraction and management — that is the operating system for that context. This fluid understanding may be the one that best reflects the true nature of today's technical landscape.