Future Trends

01 Introduction

The course has presented the operating system from the process (Unit 3) and the CPU's scheduling (Unit 5) through the memory's management (Units 8 and 9), the file systems (Unit 10), the I/O and the storage (Unit 11), the security (Unit 12), and the virtualization and the cloud (Unit 13). This lesson presents the future: the forces that are reshaping the operating systems, the technologies that are emerging, and the ways the operating system's design is responding.

The future's trends are the response to three forces:

• The workloads' change. The classical's workloads (the batch's jobs, the interactive's terminals, the file's servers) have been replaced by the modern's workloads (the microservices, the containers, the serverless's functions, the AI's models, the edge's devices, the data's streams). The new workloads have the different's requirements: the lower's latency, the higher's density, the stricter's isolation, the faster's startup, the elastic's scaling, the energy's efficiency.
• The hardware's change. The classical's hardware (the single's CPU, the rotating's disks, the Ethernet's networks) has been replaced by the modern's hardware (the many's cores, the NUMA's topologies, the NVMe's SSDs, the 100 GbE's networks, the GPUs, the TPUs, the FPGAs, the non-volatile's memories, the quantum's processors). The new hardware has the different's characteristics: the massive's parallelism, the heterogeneous's compute, the memory's tiers, the energy's constraints.
• The threats' change. The classical's threats (the local's attackers, the physical's thefts, the accidental's errors) have been joined by the modern's threats (the remote's code's execution, the supply chain's compromise, the side channels, the state-sponsored's attackers, the AI's adversaries). The security's requirements have become the stricter: the zero-trust's posture, the confidential's computing, the attestation, the end-to-end's integrity.

The operating system's response is the specialization and the abstraction. The specialization: the general-purpose's kernels (the Linux, the Windows, the BSD) are the foundation, and the specialized's runtimes (the microVMs, the unikernels, the WebAssembly's, the TEEs) are the workloads' platforms, each optimized for the specific's requirements (the startup's time, the isolation's strength, the density, the efficiency). The abstraction: the operating systems' interfaces (the system calls, the containers, the VMs, the serverless's functions) are the layered, and the applications choose the level of the abstraction that matches their requirements.

This lesson presents the future's trends. It presents the edge's computing (the latency's, the bandwidth's, and the data's sovereignty's drivers; the edge OS's; the lightweight's orchestration's). It presents the confidential's computing (the AMD's SEV, the Intel's TDX and SGX, the ARM's CCA, the enclaves, the attestation). It presents the WebAssembly (the WASI's, the wasmtime's, the portable's binaries, the sandboxes). It presents the microVMs and the unikernels (the Firecracker's, the gVisor's, the Kata Containers'). It presents the serverless's evolution (the edge's functions, the WebAssembly's functions). It presents the AI's infrastructure (the GPU's clusters, the model's serving, the MLOps's, the AI-assisted's operations). It presents the sustainability's (the energy's efficiency, the carbon's awareness, the ARM's and the RISC-V's). It presents the quantum's computing and the operating system's future (the microkernel's revival, the Rust's in the kernel, the formal's verification, the eBPF, the io_uring). It closes with the course's synthesis.

02 Learning objectives

This lesson contributes to U13.7 and the course's synthesis, and to course learning outcomes CLO1, CLO7, and CLO8.

03 Required reading

• Operating System Concepts — Chapter 20, Operating System Trends (or the equivalent's chapter in the edition), and Chapter 19, Cloud Computing. The standard treatment of the operating system's trends and the cloud's computing.
• OSTEP — the Dialogue sections and the Distributed Systems chapters. OSTEP's dialogues discuss the operating system's history and its future, and they are the basis for the lesson's synthesis.
• Tanenbaum & Bos — Modern Operating Systems, Chapters 7, 11, and 12. The virtualization, the cloud, and the distributed systems' chapters, and the concluding's chapter on the operating system's design.
• Baumann, A., Barham, P., Dagand, P.-E., Harris, T., Isaacs, R., Peter, S., Roscoe, T., Schüpbach, A., & Singhania, A. — The Multikernel: A New OS Architecture for Scalable Multicore Systems. SOSP, 2009. The paper that introduced the multikernel's architecture, and it is the source for the operating system's future's architectures' discussion.
• Ryzhyk, L., Chubb, P., Kuz, I., Le Sueur, E., & Heiser, G. — Automatic Device Driver Synthesis with Termite. SOSP, 2009. The paper that describes the formal's driver's synthesis, and it is the source for the formal's verification's discussion.
• Agache, A., Brooker, M., Iordache, A., Liguori, A., Neugebauer, R., Piwonka, P., & Popa, D. M. — Firecracker: Lightweight Virtualization for Serverless Applications. NSDI, 2020. The paper that describes the Firecracker's microVM's design.
• Young, E., Zhu, P., Caraza-Harter, T., Arpaci-Dusseau, A. C., & Arpaci-Dusseau, R. H. — The True Cost of Containing: A gVisor Case Study. HotCloud, 2019. The paper that analyzes the gVisor's design and its performance, and it is the source for the microVMs' and the sandboxes' discussion.
• Haas, A., Rossberg, A., Schuff, D. L., Titzer, B. L., Holman, M., Gohman, D., Wagner, L., Zakai, A., & Bastien, J. F. — Bringing the Web up to Speed with WebAssembly. PLDI, 2017. The paper that describes the WebAssembly's design, and it is the source for the WebAssembly's discussion.
• Kaplan, B., & the AMD's authors. — AMD Memory Encryption (the AMD's SEV's white papers), and the Intel's TDX's and SGX's specifications, and the ARM's CCA's specifications. The authoritative references for the confidential computing.
• Gregg, B. — BPF Performance Tools, 2nd ed. Addison-Wesley, 2019, and Systems Performance, 2nd ed. Addison-Wesley, 2020. The comprehensive's references for the eBPF and the systems' performance, and they are the sources for the eBPF's and the performance's discussion.
• The Linux kernel's documentation (docs.kernel.org): the io_uring's, the eBPF's, the Rust's for Linux, and the kernel's development's documentation. The authoritative references for the operating system's future's mechanisms.
• The CNCF's and the WASI's documentation, the OpenFaaS's and the Knative's documentation, the Firecracker's and the gVisor's documentation, and the WebAssembly's specifications (webassembly.org, the wasi.dev's). The practical's references for the emerging's technologies.
• The Linux man pages: man 1 wasmtime, man 1 wasmer (if available), man 1 firecracker, man 1 kata-runtime, man 1 runsc (the gVisor's), man 1 bpftrace, man 8 bpftool, man 2 io_uring_setup, man 7 io_uring, man 1 perf, man 1 rustc (the Rust's compiler), man 1 cargo, man 1 qemu-system-x86_64, man 1 podman, man 1 docker, man 1 kubectl, man 1 k3s, man 1 kubeedge (if available).

04 Core content

4.1 The three forces and the operating system's responses

The future's trends are the response to three forces (the introduction's list): the workloads' change, the hardware's change, and the threats' change. The forces are the drivers of the operating system's evolution, and the operating system's responses are the specialization and the abstraction:

• The specialization. The general-purpose's kernels (the Linux, the Windows, the BSD) are the foundation, and the specialized's runtimes are the workloads' platforms: the microVMs (the Firecracker's: the serverless's workloads), the unikernels (the MirageOS's, the IncludeOS's, the Nanos's: the single-application's VMs), the WebAssembly's runtimes (the wasmtime's, the wasmer's: the portable's sandboxes), the TEEs (the SEV's, the TDX's, the SGX's, the CCA's: the confidential's workloads), the real-time's kernels (the PREEMPT_RT's, the Zephyr's, the FreeRTOS's: the embedded's and the industrial's), the edge's runtimes (the K3s's, the KubeEdge's, the MicroK8s's: the edge's workloads), and the AI's runtimes (the CUDA's, the ROCm's, the oneAPI's, the Triton's, the vLLM's: the AI's workloads).
• The abstraction. The operating systems' interfaces are the layered: the system calls (the classical's), the containers (the Lesson 13.3's), the VMs (the Lesson 13.1's), the serverless's functions (the Lesson 13.6's), the WebAssembly's components (the WASI's), and the TEEs' enclaves. The applications choose the level of the abstraction that matches their requirements (the control's, the isolation's, the portability's, the performance's, the energy's).

The operating system's future's themes:

4.2 The edge's computing

The edge computing is the computing that happens at the network's edge (the devices, the gateways, the base stations, the on-premises's data centers) rather than in the centralized's cloud. The edge's drivers:

• The latency. The physical's limits: the light's speed (the round-trip's ~30 ms for the 4,500 km's cross-continent's fiber), the network's hops, the cloud's regions' distances. The latency-sensitive's workloads (the autonomous's vehicles, the industrial's control, the AR and the VR, the gaming, the real-time's analytics) cannot tolerate the cloud's latency, and the edge's compute moves the processing closer to the data's source.
• The bandwidth. The data's volumes: the sensors (the cameras, the microphones, the LiDARs, the IoT's devices) generate the massive's data streams, and the network's bandwidth (the cellular's, the WiFi's, the satellite's) is the constraint. The edge's compute filters and aggregates the data at the source, so the network carries only the relevant's information.
• The data's sovereignty and the privacy. The regulations (the GDPR's, the HIPAA's, the data's localization's laws) require the data to remain in the specific's jurisdictions, and the customers' privacy concerns favour the local's processing. The edge's compute keeps the data at the source (the on-device's, the on-premises's), and the observation is the reason the edge is the privacy-preserving's compute.
• The connectivity and the resilience. The intermittent's connectivity (the vehicles, the ships, the remote's sites, the industrial's environments) requires the compute to work offline, and the edge's compute provides the local's resilience (the cloud's disconnection does not stop the workload).
• The cost. The data's transfer's costs (the egress's fees, the cellular's data's plans) and the cloud's processing's costs favour the edge's processing (the local's compute is the cheaper for the high's volume's data).

The edge's technologies:

• The edge OS's. The edge's operating systems are the lightweight's (the resource-constrained's devices: the small's CPUs, the limited's memory, the battery's power): the Linux's minimal's distributions (the Yocto's, the Buildroot's, the Alpine's), the real-time's kernels (the PREEMPT_RT's, the Zephyr's, the FreeRTOS's, the NuttX's), the container-optimized's OS's (the Flatcar's, the Bottlerocket's, the Talos's), and the Kubernetes's lightweight's distributions (the K3s's, the MicroK8s's, the K0s's, the k3OS's).
• The lightweight's orchestration. The edge's orchestration is the Kubernetes's scaled-down's variants (the K3s's: the single's binary, the 100 MB's memory's footprint, the SQLite's state; the MicroK8s's: the snap's package, the add-ons's; the K0s's: the single's binary) and the edge-specific's platforms (the KubeEdge's: the cloud's and the edge's nodes', the MQTT's, the offline's autonomy; the OpenYurt's: the edge's autonomy, the traffic's management; the SuperEdge's; the Akri's: the device's discovery's).
• The edge's functions. The serverless's edge's platforms: the Cloudflare's Workers (the V8's isolates at the 300+ edge's locations), the Fastly's Compute@Edge's, the AWS's Lambda@Edge's and the CloudFront's Functions's, the Deno's Deploy's, the Vercel's Edge Functions's, the Fermyon's Spin's (the WebAssembly's), the WasmEdge's, the wasmCloud's. The observation: the edge's functions are the serverless's evolution (the same's model: the event-driven's, the automatic's scaling, the pay-per-invocation's), and the observation is the reason the edge's functions' runtimes are the lightweight's (the WebAssembly's, the V8's isolates, the microVMs's).
• The edge's hardware. The edge's devices: the IoT's gateways, the industrial's PCs, the cellular's base's stations, the retail's kiosks, the vehicles' computers, the robots, the drones, the cameras, the sensors. The hardware's characteristics: the heterogeneous's (the ARM's, the x86's, the RISC-V's, the NPUs, the TPUs, the FPGAs), the constrained's (the power, the thermal, the space), and the ruggedized's (the industrial's environments, the vehicles, the outdoor's sites).

4.3 The confidential computing

The confidential computing is the technology that protects the data in use (the data in the memory during the processing) from the infrastructure's operators (the cloud's providers, the hypervisor's administrators, the attackers with the physical's access). The classical's encryption protects the data at rest (the storage) and in transit (the network), and the data is the in the clear during the processing (the memory, the CPU's registers, the cache). The confidential computing's mechanisms (the TEEs: the Trusted Execution Environments):

The AMD's SEV (the Secure Encrypted Virtualization)

The AMD's TEE: the per-VM's memory's encryption with the AMD's Secure Processor's keys (the AES-128's keys per VM), so the hypervisor cannot read the VM's memory. The SEV's evolution: the SEV (the encrypted's memory), the SEV-ES (the encrypted's state: the registers, the vCPU's state), the SEV-SNP (the Secure Nested Paging: the the integrity's protection's, the the replay's protection's, the the attestation's), and the observation: the SEV's design is the VM's level's TEE (the the confidential's VM's), and the observation is the reason the SEV is the cloud's confidential's computing's foundation (the the VM's encryption's with the the minimal's hypervisor's trust's).

The Intel's SGX (the Software Guard Extensions)

The Intel's TEE: the enclaves (the protected's memory's regions within the application's address's space), with the the CPU's enforcement's (the the enclave's memory is the encrypted, and the the access's is the the CPU's only), the the attestation's (the the enclave's measurement's, the the remote's attestation's), and the the sealing's (the the data's persistence's in the the enclave's). The SGX's design: the the application's level's TEE (the the small's protected's regions within the the application), and the observation: the SGX's design is the the process's level's TEE, and the observation is the reason the SGX is the the sensitive's computations' (the the cryptographic's keys' management's, the the privacy's preserving's ML's, the the blockchain's) platform.

The Intel's TDX (the Trust Domain Extensions)

The Intel's TEE for the VMs: the trust domains (the confidential's VMs), with the the memory's encryption's, the the state's protection's, the the attestation's, and the the the hypervisor's exclusion's, and the observation: the TDX's design is the Intel's counterpart of the AMD's SEV-SNP (the the VM's level's TEE), and the observation is the reason the TDX is the Intel's cloud's confidential's computing's offering.

The ARM's CCA (the Confidential Compute Architecture)

The ARM's TEE: the realms (the confidential's VMs) with the the memory's encryption's, the the state's protection's, the the attestation's, and the the realm's management's, and the observation: the CCA's design is the ARM's confidential's computing's architecture (the the mobile's, the the server's, the the edge's), and the observation is the reason the CCA is the ARM's ecosystem's confidential's computing's foundation.

The attestation

The attestation is the mechanism that verifies the TEE's identity and its software's state: the TEE produces the measurement (the hash of the code and the data that were loaded into the TEE), the quote (the signed's measurement), and the certificate (the platform's endorsement), and the relying party (the service that receives the data) verifies the quote (the the signature's chain's, the the measurement's the expected's value's). The observation: the attestation is the confidential computing's the central's mechanism (the the trust's without the the operator's), and the observation is the reason the attestation (the the remote's attestation's, the the the key's release's, the the the the sealed's data's) is the the confidential's workloads' the foundation.

The confidential computing's challenges: the performance (the memory's encryption's overhead: the 5–15% for the memory's intensive's workloads), the the I/O's (the the TEE's memory's is the encrypted, and the the I/O's requires the the bounce's buffers' or the the trusted's I/O's), the the the features' (the the live's migration's, the the debugging's, the the the hypervisor's introspection's are the restricted's or the disabled's), the the ecosystem's (the the software's support's: the the guest's OS's, the the libraries', the the the attestation's services'), and the the side's channels' (the the TEE's is the the CPU's the same's the untrusted's code's, and the the microarchitectural's attacks' (the the Spectre's, the the the cache's timing's) can the the TEE's the secrets' leak's).

4.4 The WebAssembly

The WebAssembly (the WASM) is the portable's binary's format (the W3C's standard, the 2017's) that is the designed for the safe, the fast, and the portable's execution. The WebAssembly's design:

• The portable's binaries. The WASM's modules are the compiled's binaries that run on the many's platforms (the browsers, the servers, the edge's devices, the embedded's systems) with the the same's semantics, and the observation: the WASM's portability is the the "the compile once, the run everywhere's" model (the the same's module runs on the the x86's, the the ARM's, the the RISC-V's, the the browser's, the the serverless's, the the edge's).
• The sandboxing. The WASM's execution is the sandboxed: the module runs in the linear's memory (the isolated's memory's region), and it can access only the imported's functions (the host's interfaces: the WASI's), and the observation: the WASM's sandbox is the capability-based (the module can access only the resources that the host explicitly grants), and the observation is the reason the WASM is the modern's sandboxing's technology (the the defence's in the depth's, the the least's privilege's).
• The WASI (the WebAssembly System Interface). The WASI is the standard's interface (the the WASI's Preview 1's, the the Preview 2's, the the WASI's 0.2's) that gives the WASM's modules the access to the system's resources (the files, the the network's, the the clocks's, the the random's, the the environment's) through the capability-based's API, and the observation: the WASI is the WASM's system's interface (the the POSIX's counterpart's), and the observation is the reason the WASM is the server-side's and the edge's workloads' platform.
• The component model. The WASM's component model (the 2024's) is the composition's framework (the the components' the typed's interfaces, the the the composition's, the the language's interoperability's), and the observation: the component model is the WASM's ecosystem's the foundation (the the composition's of the the modules' from the the different's languages'), and the observation is the reason the WASM is the the polyglot's platform's.
• The runtimes. The WASM's runtimes: the wasmtime (the Bytecode Alliance's: the Cranelift's compiler), the wasmer, the wasmedge, the WAMR (the WebAssembly's Micro's Runtime: the embedded's), the V8's (the browser's and the Cloudflare's Workers's), the WasmEdge's (the CNCF's), the wasmCloud's (the CNCF's sandbox's), the Spin's (the Fermyon's). The observation: the runtimes are the WASM's platform's (the the browsers', the the servers', the the edge's, the the embedded's), and the observation is the reason the WASM's ecosystem (the the runtimes', the the toolchains', the the component's registries's: the the OCI's artifacts's) is the modern's the application's platform's.
• The languages and the toolchains. The WASM's compilation's targets: the Rust (the wasm32-wasi's, the wasm32-unknown-unknown's, the componentize's), the C and the C++ (the clang's), the Go (the TinyGo's, the wasip1's), the Python (the Pyodide's, the componentize-py's), the JavaScript and the TypeScript (the AssemblyScript's, the Javy's), the C# (the Blazor's, the .NET's), the Zig's, and the many's others, and the observation: the WASM's toolchains are the languages' compilers' extensions, and the observation is the reason the WASM is the portable's compilation's target.
• The use's cases. The WASM's use's cases: the browser's plugins and the extensions (the Figma's, the Zoom's, the Photoshop's web's), the serverless's functions (the Cloudflare's Workers's, the Fastly's Compute@Edge's, the Fermyon's Spin's), the edge's computing (the the edge's functions's, the the edge's filters's), the the blockchain's smart's contracts (the the Polkadot's, the the NEAR's, the the CosmWasm's), the the plugin's systems (the the Envoy's, the the Istio's, the the NGINX's, the the Open Policy Agent's), and the the data's processing (the the databases' extensions's, the the stream's processing's).

4.5 The microVMs and the unikernels

The microVMs and the unikernels are the lightweight's virtualization's technologies that combine the VMs' isolation with the containers' density and startup:

• The microVMs. The microVMs (the Firecracker's, the Kata Containers', the gVisor's: the Lesson 13.3's discussion): the minimal's VMs with the minimal's device's models, the fast's startup (the 125 ms's for the Firecracker's), the low's memory's overhead (the ~5 MB's), and the strong's isolation (the VM's boundary). The observation: the microVMs are the serverless's and the container's workloads' isolation's mechanism, and the observation is the reason the microVMs (the the Firecracker's, the the Kata Containers', the the gVisor's) are the modern's the multi-tenant's platforms' (the the AWS's Lambda's, the the Fargate's, the the Google's Cloud Run's) the foundation.
• The unikernels. The unikernels (the MirageOS's, the IncludeOS's, the Nanos's, the OSv's, the Hermit's, the Unikraft's): the single-address-space's kernels (the application and the kernel are the compiled together into the single's binary), with the minimal's attack surface (the only the the needed's drivers and the libraries), the fast's startup (the the milliseconds's), the low's memory's overhead, and the the strong's isolation (the the VM's boundary). The observation: the unikernels are the specialized's workloads' (the the network's functions's, the the database's, the the web's servers's) the platforms, and the observation is the reason the unikernels' the adoption (the the MirageOS's, the the Unikraft's, the the Nanos's) is the the specialized's niches' (the the edge's, the the network's, the the security's).
• The gVisor's. The gVisor (the Google's, the 2018's) is the user-space's kernel: the application's system calls are intercepted (the the runsc's the runtime's), and the user-space's kernel (the the Sentry's) implements the system calls' the emulation, and the observation: the gVisor's design is the the kernel's interface's the reimplementation (the the Linux's system calls' the subset's), and the observation is the reason the gVisor's the isolation's is the the strong's (the the application's system calls' the mediated's) with the the performance's the cost's (the the system calls' the intercepted's).
• The Kata Containers's. The Kata Containers (the OpenStack's and the Intel's, the 2017's, the OpenInfra Foundation's): the containers' interfaces (the OCI's) with the VMs' isolation (the the lightweight's VMs's), and the observation: the Kata Containers' design is the the containers' and the VMs' the convergence (the the Lesson 13.3's), and the observation is the reason the Kata Containers are the the Kubernetes's the multi-tenant's platforms' (the the OpenShift's, the the Anthos's) the isolation's mechanism.

4.6 The serverless's evolution

The serverless's evolution (the Lesson 13.6's serverless's computing's continuation):

• The edge's functions. The serverless's edge's platforms (the Cloudflare's Workers's, the Fastly's Compute@Edge's, the Deno's Deploy's, the Vercel's Edge Functions's): the functions run at the edge's locations (the 300+'s locations), and the observation: the edge's functions are the serverless's latency's evolution (the the functions run the close to the the users's), and the observation is the reason the edge's functions (the the Cloudflare's Workers's, the the Deno's Deploy's) are the modern's the web's applications' the platform.
• The WebAssembly's functions. The WebAssembly's serverless's platforms (the Fermyon's Spin's, the wasmCloud's, the WasmEdge's, the Fastly's Compute@Edge's, the Second State's): the functions are the compiled to the WASM's modules, and the observation: the WASM's functions are the serverless's portability's evolution (the the same's module runs on the the different's platforms), and the observation is the reason the WASM's functions (the the Fermyon's Spin's, the the wasmCloud's) are the modern's the serverless's the emerging's platform.
• The containers' serverless. The containers' serverless's platforms (the Google's Cloud Run's, the AWS's App Runner's, the Azure's Container Apps's, the Knative's, the OpenFaaS's, the Fission's): the containers are the serverless's units (the the request's the scale's, the the no's the infrastructure's management's), and the observation: the containers' serverless is the serverless's the containers' convergence, and the observation is the reason the containers' serverless (the the Cloud Run's, the the App Runner's) is the modern's the containerized's applications' the platform.
• The state's management. The serverless's state's evolution: the durable's execution's (the the AWS's Step Functions's, the the Azure's Durable Functions's, the the Temporal's, the the Restate's), the the stateful's serverless (the the Cloudflare's Durable Objects's, the the Deno's KV's, the the Fermyon's SQLite's), and the observation: the state's management is the serverless's the central's concern (the the stateless's design's), and the observation is the reason the state's mechanisms (the the durable's execution's, the the stateful's serverless's) are the serverless's the evolution's.

4.7 The AI's infrastructure

The AI's infrastructure is the computing's stack that the AI's workloads (the training's, the fine-tuning's, the inference's) require, and its components:

• The GPU's clusters. The AI's compute: the GPU's clusters (the NVIDIA's H100's, the A100's, the AMD's MI300's, the Google's TPUs's, the AWS's Trainium's and the Inferentia's), with the the high's bandwidth's interconnects (the the NVLink's, the the InfiniBand's, the the RoCE's), the the the distributed's training's (the the data's parallel's, the the model's parallel's, the the pipeline's parallel's), and the the the scheduling's (the the Kubernetes's the GPU's operators's: the the NVIDIA's GPU's Operator's, the the AMD's GPU's Operator's), and the observation: the GPU's clusters are the AI's the training's and the inference's the compute's foundation, and the observation is the reason the AI's infrastructure (the the GPU's clusters's, the the scheduling's, the the interconnects's) is the modern's the data's centers' the central's component.
• The model's serving. The inference's platforms: the Triton's (the NVIDIA's: the the multi-framework's, the the dynamic's batching's), the vLLM's (the the PagedAttention's, the the continuous's batching's), the TensorFlow's Serving's, the TorchServe's, the KServe's (the Kubernetes's), the Seldon's, the BentoML's, the Ray's Serve's, and the observation: the model's serving is the AI's the inference's the platform, and the observation is the reason the serving's platforms (the the Triton's, the the vLLM's, the the KServe's) are the modern's the AI's the applications' the infrastructure.
• The MLOps's. The ML's operations: the pipelines (the Kubeflow's, the MLflow's, the Metaflow's, the Airflow's, the Dagster's), the model's registries, the feature's stores, the experiment's tracking's, the the model's monitoring's (the the drift's, the the data's quality's), and the the governance's (the the model's cards's, the the fairness's, the the explainability's), and the observation: the MLOps is the AI's the operations' the discipline (the the DevOps's the AI's extension), and the observation is the reason the MLOps's the platforms (the the Kubeflow's, the the MLflow's, the the W&B's) are the modern's the AI's the teams' the standard.
• The AI-assisted's operations. The AI's the operations' assistance: the the anomaly's detection's (the the logs' analysis's, the the metrics' correlation's), the the root's cause's analysis's, the the incident's response's (the the runbooks' generation's, the the remediation's suggestions's), the the capacity's planning's, the the code's generation's (the the Copilot's, the the Cursor's), and the observation: the AI-assisted's operations are the operations' the emerging's discipline, and the observation is the reason the operations' platforms (the the Datadog's, the the Dynatrace's, the the New Relic's) include the AI's the assistants.

4.8 The sustainability's

The sustainability's trends (the energy's efficiency, the carbon's awareness, the architectures' changes):

• The energy's efficiency. The computing's energy's consumption: the data centers' ~1–2% of the global's electricity, the AI's training's the massive's energy's (the the GPT-3's ~1,300 MWh's, the the larger's models' the more's), and the observation: the energy's efficiency is the modern's computing's central's concern (the the cost's, the the sustainability's, the the regulations'), and the observation is the reason the energy's mechanisms (the the DVFS's, the the the big.LITTLE's, the the the ARM's the efficiency's, the the the the liquid's cooling's, the the the the workload's placement's) are the modern's the data's centers' the concerns.
• The carbon's awareness. The carbon-aware's computing: the the workloads' the scheduling's the the carbon's intensity's (the the electricity's the carbon's intensity's the varies by the the time's and the the region's), the the the carbon-aware's SDK's (the the Green's Software's Foundation's, the the Carbon-Aware's SDK's), the the the providers' the carbon's tools (the the AWS's Customer's Carbon's Footprint's, the the Azure's Emissions's Impact's, the the Google's Cloud's Carbon's Footprint's), and the observation: the carbon's awareness is the sustainability's the emerging's discipline, and the observation is the reason the carbon-aware's computing (the the the scheduling's, the the the regions' selection's, the the the deferral's) is the modern's the cloud's the trend.
• The ARM's and the RISC-V's. The architectures' changes: the ARM's the server's chips (the the AWS's Graviton's, the the Ampere's Altra's, the the Apple's M's, the the NVIDIA's Grace's) with the the better's the performance-per-watt's, the the RISC-V's the open's the instruction's set's (the the SiFive's, the the Ventana's, the the Tenstorrent's, the the Alibaba's Xuantie's), and the observation: the ARM's and the RISC-V's are the x86's the alternatives (the the energy's efficiency's, the the licensing's, the the customization's), and the observation is the reason the ARM's and the RISC-V's the adoption (the the cloud's providers' the ARM's instances's, the the edge's, the the embedded's) is the modern's the hardware's the trend.
• The sustainable's software's engineering. The software's energy's efficiency: the the algorithms' efficiency's, the the data's structures's, the the languages' (the the Rust's, the the C's, the the Go's vs. the the Python's, the the JavaScript's), the the the caching's, the the the batching's, the the the the hardware's the acceleration's (the the GPUs', the the the FPGAs', the the the NPUs'), and the observation: the sustainable's software's engineering is the software's the discipline (the the energy's the first's the design's), and the observation is the reason the software's the energy's efficiency is the modern's the engineering's the concern.

4.9 The quantum's computing

The quantum's computing and the operating systems' challenges:

• The quantum's processors. The quantum's processors (the IBM's, the Google's, the IonQ's, the Rigetti's, the D-Wave's, the Quantinuum's): the qubits (the superconducting's, the trapped's ions', the photonic's, the neutral's atoms', the topological's), the the quantum's gates's, the the the error's correction's (the the surface's codes's, the the logical's qubits's), and the observation: the quantum's processors are the emerging's the compute's platform, and the observation is the reason the quantum's computing (the the algorithms's, the the error's correction's, the the hardware's) is the modern's the compute's the frontier.
• The hybrid's quantum-classical's systems. The quantum's computing's integration with the classical's computing: the the quantum's processing's units's (the the QPUs's) the the classical's controllers's (the the FPGAs's, the the the classical's CPUs's), the the the quantum's compilers's (the the Qiskit's, the the Cirq's, the the the tket's, the the QIR's), the the the quantum's operating's systems's (the the the quantum's runtimes's, the the the the quantum's error's correction's, the the the the quantum-classical's the interfaces's), and the observation: the hybrid's quantum-classical's systems are the quantum's computing's the practical's model (the the quantum's the accelerators's the the classical's the orchestration's), and the observation is the reason the quantum's operating's systems (the the the quantum's the runtimes's, the the the the quantum's the compilers's) are the emerging's the operating's systems' the discipline.
• The post-quantum's cryptography. The quantum's threat to the classical's cryptography: the Shor's algorithm (the the RSA's, the the the Diffie-Hellman's, the the the elliptic's curves's the broken's by the the quantum's computers), the the Grover's algorithm (the the symmetric's keys' the halved's the effective's lengths's), the the post-quantum's algorithms (the the lattice's based's: the the Kyber's, the the Dilithium's; the the hash's based's: the the SPHINCS+'s; the the code's based's: the the McEliece's; the the the multivariate's: the the the Rainbow's the broken's), and the observation: the post-quantum's cryptography is the quantum's computing's the security's response, and the observation is the reason the post-quantum's migration (the the NIST's the standards's, the the the the providers' the the post-quantum's the TLS's, the the the the the the the the the the the the the the) is the modern's the security's the priority.

4.10 The operating system's future

The operating system's future: the design's trends and the emerging's mechanisms:

• The multikernel. The multikernel (the Baumann et al.'s, the 2009's): the operating system as the distributed's system of the per-core's kernels, with the the message's based's communication (the the no's the shared's the memory's the kernel's the state's), the the the replicated's the state's (the the the the the the the), and the observation: the multikernel's design is the multicore's scale's the response (the the the the the the the the the the the the the), and the observation is the reason the multikernel (the the the the the the the the the the the the the the the) is the operating system's the architecture's the future's the candidate.
• The microkernel's revival. The microkernel's architectures (the seL4's, the QNX's, the Fuchsia's, the Redox's, the Managarm's, the Hubris's): the minimal's kernels (the the the the the the the the the the the the the the), the the the the the the the the the, and the observation: the microkernel's revival is the security's and the reliability's driver (the the the the the the the the the the the the the the the the), and the observation is the reason the microkernel (the the seL4's, the the QNX's, the the Fuchsia's) is the operating system's the design's the future's the trend.
• The Rust's for Linux. The Rust's for Linux (the the Rust's for Linux's the project's, the the 2022's the merged's): the Rust's the drivers's, the the the the the the the the the the, and the observation: the Rust's for Linux is the memory's safety's the kernel's driver's the language (the the the the the the), and the observation is the reason the Rust's for Linux (the the the the the the) is the kernel's the development's the trend.
• The formal's verification. The formal's verification's (the seL4's, the the the the the the the the the, the the the the the the, the the the the): the the the the the the the the the the the, and the observation: the formal's verification is the security's and the reliability's the ultimate's assurance (the the the the the the the the the the the), and the observation is the reason the formal's verification (the the seL4's, the the the the the the) is the operating system's the future's the trend.
• The eBPF. The eBPF (the extended's the Berkeley's the Packet's the Filter's): the kernel's the programmable's the sandbox (the the the the the the the the the the the the), the the the the the the the the the the, and the observation: the eBPF is the kernel's the programmability's and the observability's the mechanism (the the the the the the the the the the the the), and the observation is the reason the eBPF (the the the the the the the the the the the the the) is the kernel's the future's the central's technology.
• The io_uring. The io_uring (the Jens's the Axboe's, the the 2019's): the kernel's the asynchronous's the I/O's interface (the the the the the the the the the the the the the the the the the the), and the observation: the io_uring is the kernel's the I/O's the future's the interface (the the the the the the the the the the the the the), and the observation is the reason the io_uring (the the the the the the the the) is the modern's the kernel's the I/O's the mechanism.

4.11 The course's synthesis

The course's synthesis: the operating system's enduring's concepts and the mechanisms' evolution:

• The enduring's concepts. The operating system's concepts: the process (the execution's abstraction), the thread (the execution's unit), the address space (the memory's abstraction), the file (the storage's abstraction), the directory (the namespace's abstraction), the socket (the network's abstraction), the permission (the access's abstraction), the interrupt (the asynchronous's event), the system call (the kernel's interface). The concepts have persisted across the computing's generations (the mainframes, the minicomputers, the PCs, the servers, the mobile's devices, the cloud, the edge), and the observation is the reason the concepts (the process's, the memory's, the file's, the network's, the security's) are the operating system's enduring's foundation.
• The mechanisms' evolution. The mechanisms have evolved: the CPU's scheduling (from the simple's algorithms to the CFS's, the the the the the the), the memory's management (from the base's and the bound's to the paging's, the the the the the the), the file systems (from the Unix's file's system's to the ext4's, the XFS's, the ZFS's, the Btrfs's), the I/O (from the programmed's I/O's to the DMA's, the the the the the), the security (from the simple's permissions's to the the the the the the), and the observation: the mechanisms' evolution is the response to the workloads', the hardware's, and the threats' changes, and the observation is the reason the operating system's the mechanisms (the scheduling's, the memory's, the file systems', the I/O's, the security's) are the course's the central's content.
• The abstractions' layering. The operating system's abstractions have become the layered: the hardware's (the the the the the the the), the kernel's (the the the the the the the), the virtualization's (the the the the the the the), the containers' (the the the the the the the), the orchestration's (the the the the the the the), the serverless's (the the the the the the the), and the WebAssembly's (the the the the the the the), and the observation: the abstractions' layering is the operating system's the design's the trend (the the the the the the the), and the observation is the reason the applications choose the level of the abstraction (the the the the the the the) that matches their requirements.
• The principles' persistence. The security's principles (the Lesson 12.1's Saltzer and Schroeder's: the least privilege, the fail-safe defaults, the complete mediation, the open design, the separation of privilege, the least common mechanism, the psychological acceptability, the economy of mechanism) have persisted across the operating system's generations, and the observation: the principles (the the the the the the the) apply to the emerging's technologies (the the TEE's, the the WebAssembly's, the the microVMs', the the eBPF's, the the io_uring's) as they applied to the classical's mechanisms (the the the the the), and the observation is the reason the course's the principles (the the the the the) are the operating system's the enduring's foundation.
• The open questions. The open questions: the kernel's the complexity's (the the Linux's the 30+ million's lines's, the the the the the the the), the security's the assurance (the the the the the the the the), the performance's the determinism (the the the the the the the), the energy's efficiency (the the the the the the the the), the the the the the (the the the the the the the), the the the the (the the the the the the the), and the observation: the open questions are the operating system's the research's the future's the agenda, and the observation is the reason the operating system's the field (the the the the the the the) is the the the the the the the.

4.12 Common misconceptions

05 Worked example

The following example explores the emerging's technologies on a live system: the WebAssembly's runtimes, the eBPF's, the io_uring's, the confidential's computing's interfaces, and the microVMs'.

# Check the WebAssembly's tools
which wasmtime wasmer wasm3 wasmedge 2>/dev/null

# Install the wasmtime (if necessary)
curl https://wasmtime.dev/install.sh -sSf | bash

# Create a WebAssembly's module (the Rust's)
which rustc cargo 2>/dev/null
cargo new --bin hello-wasm 2>/dev/null
cd hello-wasm

# The Rust's source
cat > src/main.rs << 'EOF'
fn main() {
    println!("Hello from the WebAssembly!");
}
EOF

# Add the WASI's target
rustup target add wasm32-wasi 2>/dev/null

# Build the WebAssembly's module
cargo build --target wasm32-wasi --release 2>/dev/null
ls -lh target/wasm32-wasi/release/hello-wasm.wasm

# Run the module with the wasmtime
wasmtime target/wasm32-wasi/release/hello-wasm.wasm

# Inspect the module (the Wasm's structure)
wasmtime compile target/wasm32-wasi/release/hello-wasm.wasm -o /tmp/hello.cwasm 2>/dev/null
ls -lh /tmp/hello.cwasm

# The module's imports and exports
wasmtime explore target/wasm32-wasi/release/hello-wasm.wasm 2>/dev/null &
sleep 2
# (the explore's server shows the module's structure)
kill %1 2>/dev/null

# Clean up
cd .. && rm -rf hello-wasm /tmp/hello.cwasm

# Check the eBPF's tools
which bpftrace bpftool 2>/dev/null

# The eBPF's kernel's support
ls /sys/fs/bpf/ 2>/dev/null
ls /sys/kernel/btf/vmlinux 2>/dev/null

# The eBPF's programs (the loaded's)
sudo bpftool prog list 2>/dev/null | head -20

# The eBPF's maps
sudo bpftool map list 2>/dev/null | head -20

# The eBPF's tracepoints
sudo bpftool perf list 2>/dev/null | head -20

# The bpftrace's one-liners
# The system calls' count by the process
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }' 2>/dev/null &
sleep 5
kill %1 2>/dev/null

# The file's opens by the process
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }' 2>/dev/null &
sleep 5
kill %1 2>/dev/null

# The block's I/O's latency
sudo bpftrace -e 'kprobe:blk_account_io_start { @start[arg0] = nsecs; }
    kprobe:blk_account_io_done /@start[arg0]/ {
        @latency = hist(nsecs - @start[arg0]);
        delete(@start[arg0]);
    }' 2>/dev/null &
sleep 5
kill %1 2>/dev/null

# The eBPF's program (the C's, the demonstration)
cat > /tmp/ebpf-demo.c << 'EOF'
// The eBPF's program (the conceptual's demonstration)
// The practical's use is via the BCC's or the libbpf's
EOF
rm /tmp/ebpf-demo.c

# The io_uring's kernel's support
grep -i io_uring /proc/kallsyms 2>/dev/null | head -5
ls /proc/sys/kernel/io_uring_disabled 2>/dev/null

# The io_uring's system calls
man 2 io_uring_setup 2>/dev/null | head -30
man 7 io_uring 2>/dev/null | head -30

# The io_uring's users (the modern's applications)
lsof 2>/dev/null | grep -i io_uring | head -5

# The io_uring's performance's comparison (the demonstration)
# The synchronous's I/O
dd if=/dev/zero of=/tmp/sync-test bs=4k count=10000 oflag=direct 2>/dev/null
rm /tmp/sync-test

# The asynchronous's I/O (the io_uring's, via the fio's)
which fio 2>/dev/null
sudo fio --name=uring-test --filename=/tmp/uring-test \
    --size=1G --rw=randread --bs=4k --iodepth=64 \
    --ioengine=io_uring --direct=1 --runtime=5 --time_based \
    2>/dev/null | grep -E 'IOPS|bw'
rm /tmp/uring-test 2>/dev/null

# The io_uring's libraries
which liburing 2>/dev/null
ls /usr/include/liburing.h 2>/dev/null

# The CPU's TEE's support
lscpu | grep -iE 'sev|tdx|sgx|cca'
grep -iE 'sev|tdx|sgx' /proc/cpuinfo | head -5

# The TEE's devices
ls /dev/sev* 2>/dev/null
ls /dev/sgx* 2>/dev/null
ls /dev/tdx* 2>/dev/null

# The TEE's kernel's modules
lsmod | grep -iE 'sev|tdx|sgx'
ls /sys/module/kvm_amd/parameters/ 2>/dev/null | head -10

# The SEV's status (if the AMD's)
sudo cat /sys/module/kvm_amd/parameters/sev 2>/dev/null
sudo cat /sys/module/kvm_amd/parameters/sev_es 2>/dev/null
sudo cat /sys/module/kvm_amd/parameters/sev_snp 2>/dev/null

# The TEE's attestation's tools
which sevctl 2>/dev/null
which sgx-tools 2>/dev/null

# The TEE's support in the container's runtimes
which runsc 2>/dev/null
which kata-runtime 2>/dev/null

# The confidential's containers (the demonstration)
# (the enclave-cc's, the occlum's, the gramine's: the conceptual's)

# The Firecracker's binary
which firecracker 2>/dev/null
# (The Firecracker's installation: the GitHub's releases's)

# The gVisor's runtime
which runsc 2>/dev/null
runsc --version 2>/dev/null

# The Kata Containers's runtime
which kata-runtime 2>/dev/null
kata-runtime --version 2>/dev/null

# The microVMs' isolation's characteristics
# (the conceptual's: the minimal's device's models's,
# the the fast's startup's, the the low's memory's
# overhead's, the the strong's isolation's)

# The Firecracker's design's inspection (if installed)
# firecracker --version 2>/dev/null
# firecracker --api-sock /tmp/firecracker.sock &
# curl --unix-socket /tmp/firecracker.sock http://localhost/ 2>/dev/null
# kill %1 2>/dev/null

# The container's runtimes' comparison
echo "=== The container's runtimes ==="
for rt in runc crun runsc kata-runtime; do
    if which $rt >/dev/null 2>&1; then
        echo "$rt: $(which $rt)"
        $rt --version 2>/dev/null | head -1
    fi
done

# The isolation's comparison (the conceptual's)
echo "=== The isolation's comparison ==="
echo "The runc's: the namespaces and the cgroups (the shared's kernel)"
echo "The runsc's (the gVisor's): the user-space's kernel (the syscalls' interception)"
echo "The kata-runtime's: the microVM's boundary (the separate's kernel)"
echo "The firecracker's: the microVM's boundary (the minimal's VMM)"

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• The operating system's future is the response to three forces: the workloads' change (the microservices, the containers, the serverless's functions, the AI's models, the edge's devices, the data's streams), the hardware's change (the many's cores, the NUMA's topologies, the NVMe's SSDs, the 100 GbE's networks, the GPUs, the TPUs, the FPGAs, the non-volatile's memories, the quantum's processors), and the threats' change (the remote's code's execution, the supply chain's compromise, the side channels, the state-sponsored's attackers). The operating system's responses are the specialization (the specialized's runtimes) and the abstraction (the layered's interfaces).
• The edge's computing: the drivers (the latency, the bandwidth, the data's sovereignty, the connectivity, the cost), the edge OS's (the Yocto's, the PREEMPT_RT's, the Zephyr's, the Flatcar's, the K3s's), the lightweight's orchestration (the K3s's, the MicroK8s's, the KubeEdge's, the OpenYurt's), and the edge's functions (the Cloudflare's Workers's, the Fastly's Compute@Edge's, the Vercel's Edge Functions's).
• The confidential's computing: the data's protection in use, the TEEs (the AMD's SEV's, the Intel's SGX's and TDX's, the ARM's CCA's), the enclaves, and the attestation. The challenges: the performance, the I/O, the features, the ecosystem, and the side channels.
• The WebAssembly: the portable's binaries, the sandboxing, the WASI, the component model, the runtimes (the wasmtime's, the wasmer's, the wasmedge's, the WasmEdge's, the wasmCloud's, the Spin's), and the use's cases (the browser's plugins, the serverless's functions, the edge's computing, the blockchain's smart's contracts, the plugin's systems).
• The microVMs (the Firecracker's, the Kata Containers', the gVisor's) and the unikernels (the MirageOS's, the IncludeOS's, the Nanos's, the Unikraft's): the lightweight's virtualization's technologies that combine the VMs' isolation with the containers' density and startup.
• The serverless's evolution: the edge's functions, the WebAssembly's functions, the containers' serverless, and the state's management (the durable's execution's, the stateful's serverless).
• The AI's infrastructure: the GPU's clusters (the NVIDIA's H100's, the AMD's MI300's, the Google's TPUs's, the AWS's Trainium's), the model's serving (the Triton's, the vLLM's, the KServe's), the MLOps's (the Kubeflow's, the MLflow's), and the AI-assisted's operations.
• The sustainability's: the energy's efficiency (the DVFS's, the big.LITTLE's, the ARM's, the liquid's cooling), the carbon's awareness (the carbon-aware's SDK's, the providers' tools), the ARM's and the RISC-V's (the Graviton's, the Ampere's, the SiFive's), and the sustainable's software's engineering.
• The quantum's computing: the quantum's processors (the qubits, the quantum's gates, the error's correction), the hybrid's quantum-classical's systems (the QPUs's, the quantum's compilers's, the quantum's runtimes's), and the post-quantum's cryptography (the Shor's, the Grover's, the post-quantum's algorithms's, the migration's).
• The operating system's future: the multikernel (the per-core's kernels, the message-based's communication), the microkernel's revival (the seL4's, the QNX's, the Fuchsia's), the Rust's for Linux (the memory's safety's), the formal's verification (the seL4's), the eBPF (the kernel's programmable's sandbox), and the io_uring (the kernel's asynchronous's I/O's interface).
• The course's synthesis: the enduring's concepts (the process, the thread, the address space, the file, the directory, the socket, the permission, the interrupt, the system call), the mechanisms' evolution (the CPU's scheduling, the memory's management, the file systems, the I/O, the security), the abstractions' layering, the principles' persistence (the Saltzer and Schroeder's), and the open questions (the kernel's complexity, the security's assurance, the performance's determinism, the energy's efficiency).

11 References

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapters 19 and 20.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, the Dialogue sections and the Distributed Systems chapters. Available online at ostep.org.
• Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapters 7, 11, and 12.
• Baumann, A., Barham, P., Dagand, P.-E., Harris, T., Isaacs, R., Peter, S., Roscoe, T., Schüpbach, A., & Singhania, A. The Multikernel: A New OS Architecture for Scalable Multicore Systems. SOSP, 2009.
• Ryzhyk, L., Chubb, P., Kuz, I., Le Sueur, E., & Heiser, G. Automatic Device Driver Synthesis with Termite. SOSP, 2009.
• Agache, A., Brooker, M., Iordache, A., Liguori, A., Neugebauer, R., Piwonka, P., & Popa, D. M. Firecracker: Lightweight Virtualization for Serverless Applications. NSDI, 2020.
• Young, E., Zhu, P., Caraza-Harter, T., Arpaci-Dusseau, A. C., & Arpaci-Dusseau, R. H. The True Cost of Containing: A gVisor Case Study. HotCloud, 2019.
• Haas, A., Rossberg, A., Schuff, D. L., Titzer, B. L., Holman, M., Gohman, D., Wagner, L., Zakai, A., & Bastien, J. F. Bringing the Web up to Speed with WebAssembly. PLDI, 2017.
• Gregg, B. BPF Performance Tools, 2nd ed. Addison-Wesley, 2019, and Systems Performance, 2nd ed. Addison-Wesley, 2020.
• The Linux kernel's documentation (docs.kernel.org): the io_uring's, the eBPF's, the Rust's for Linux, and the kernel's development's documentation.
• The AMD's SEV's, the Intel's TDX's and SGX's, and the ARM's CCA's specifications.
• The WebAssembly's specifications (webassembly.org, the wasi.dev's), the Firecracker's and the gVisor's documentation, the CNCF's landscape, and the Bytecode Alliance's documentation.
• Linux man-pages: man 1 wasmtime, man 1 wasmer, man 1 bpftrace, man 8 bpftool, man 2 io_uring_setup, man 7 io_uring, man 1 runsc, man 1 kata-runtime, man 1 firecracker, man 1 rustc, man 1 cargo, man 1 perf.