This video features a series of presentations from a Plan 9 conference, covering diverse topics in operating system development and historical context. The first speaker details enhancements to a Fluidigm Polaris biotech instrument, focusing on its optical system and CCD camera, highlighting efficient illumination, precise filtering, and the intricate sensor technology, as well as the low operational runtime discovered. The second speaker introduces "VMs as Threads," a novel approach to running virtual machines as standard user-level threads in Plan 9, simplifying VM management and potentially improving performance by isolating OS tasks. The third presentation unveils "Nile," a new Plan 9 window system that aims for greater transparency by simplifying mouse interactions, eliminating most menus, and improving scrolling behavior, alongside discussions of design choices like darker themes and thinner borders. The fourth talk introduces "Uglandics," a user-mode Plan 9/Linux hybrid that leverages Linux's syscall user dispatch to run Plan 9 binaries, addressing hardware support limitations and simplifying the user experience. The fifth presentation, "Nyx," details efforts to revive a Plan 9 project for multi-core systems, aiming to provide unperturbed execution for applications by offloading OS tasks to dedicated "time sharing cores." Finally, a presentation on Web PKI discusses the complexities of web certificate validation and proposes a new Plan 9 service for handling X.509 certificates. Another talk provides a historical overview of Plan 9's evolution, from its Unix roots to its current state, touching on key innovations, hardware adaptations, and community efforts, concluding with a controversial stance on git.
The event kicks off with a welcome and thanks to attendees and the host institution, ENAC (an evening school), emphasizing quiet conduct in corridors.
Logistics are provided for coffee breaks, smoking, and a museum visit scheduled for tomorrow night (some room left for attendees).
The schedule includes lightning talks (no registration yet, informal sign-up at the board).
An unpresented paper by Alisa is highlighted, encouraging attendees to read the proceedings for more information.
Attendees are reminded that Sunday's events will be at a different location, as the current venue is closed.
A Plan 9 Foundation board meeting is scheduled for Saturday morning (open to all).
The museum visit is a guided tour and does not include dinner.
Attendees are requested to vacate the room by 6 PM, putting chairs and tables back, and not leaving personal items as the room cannot be locked.
Lunch arrangements are explained, with the foundation covering costs for some attendees and a €30 payment required for others at the restaurant, offering one main dish and a shared dessert for efficiency. Dietary restrictions are noted.
All talks will be recorded and broadcast; attendees are advised on photo policy (implied consent if they remain in frame).
Toilet location and a reminder not to eat pastries in the main room.
0:05:30 - 0:08:12 The Plan 9 Foundation: A Five-Year Retrospective and Future Goals:
The speaker (Ron Minnick) introduces the Plan 9 Foundation, highlighting its role in bringing back the annual conference since 2023.
The foundation is celebrating its fifth anniversary this fall, with key founders Skip and Anthony acknowledged.
Early efforts focused on stabilization: achieving 501c3 non-profit status to accept tax-deductible donations, recovering Plan 9 source code from Nokia, and moderating the 9fans mailing list.
Future goals include growing funding, establishing labs in Europe and Canada to host Plan 9 systems, and acquiring donated hardware (leveraging 501c3 status for tax write-offs).
Anthony is specifically thanked for his tireless work on financial soundness and achieving the 501c3 status, while Skip is commended for managing the IWP9 series and paper reviews.
0:08:44 - 0:43:53 VMs as Threads: A Novel Approach to Virtualization in Plan 9:
Ron Minnick introduces his work on "VMs as Threads," aiming to integrate virtual machines (VMs) as standard libthread processes in Plan 9.
Key Concept (0:09:03): The VMthreadinit library call establishes a memory model where a low part of memory is copied (like fork) and a high part is shared between VM threads. VMthreadcreate allows running arbitrary code (e.g., an infinite loop) in a virtual machine in ring zero.
Ease of Use (0:11:47): This method is presented as significantly easier than traditional VM systems like Xen or KVM, or even GVisor (Google's YouTube video encoder VM).
VM vs. Process (0:12:05): VMs share many characteristics with processes (memory, registers, page tables, exit types) but have additional state and capabilities (setting up page tables, handling interrupts, running in modes like x86 16-bit real mode).
Page Table Handling (0:15:10): The core of the approach involves a "two-dimensional pagewalk" for address translation (guest virtual to guest physical to host physical). A key innovation in Plan 9 is "page table pairing," using a single lock for both the VM and process page tables, simplifying complex nested locking.
Acros Inspiration (0:18:21): The design draws from Google's research kernel, Acros, which treated processes and VMs identically, achieving a compact (600 lines of code) and very fast VM monitor.
Plan 9 VMX Device (0:25:30): The existing Plan 9 VMX device (#x) is praised for its elegant, text-oriented interface, allowing VMs to be paused and resumed with detailed exit statuses.
#Z Device (0:29:33): A new #Z device maps VM calls to the host's filesystem, eliminating the need for guest drivers (disk, network) and significantly speeding up console I/O (up to 700x faster).
Future and Challenges (0:42:05): The project aims to enable multiple page sizes (64K optimal) and requires debugging of issues like image smearing when running certain applications concurrently.
1:21:32 - 2:06:56 Nile: A Transparent Window System for Plan 9:
Introduction (1:21:32): Anthony introduces Nile, a new Plan 9 window system derived from Rio, emphasizing its goal of "increasing transparency" by getting out of the user's way. The name "Nile" (a river) is a clever nod to Rio (river).
Menu Elimination (1:24:09): A core feature of Nile is the elimination of most menus, deemed "least transparent" due to their opaque nature, cognitive load, and potential for user error.
Cut, Paste, and Snarf are handled by existing mouse cording.
Button 2 now always "sends" (replaces its menu).
Button 3 "plums" (replaces its menu functionality in text windows).
New windows are created by sweeping out an area with Button 3 on the background, making creation more direct.
Delete and Hide functions are offloaded to helper programs (e.g., windatch) or scripts, simplifying the window manager itself.
Hidden windows can be accessed via windatch or an optional Button 1 background menu (the only menu left, disabled by default).
Scroll Mode Elimination (1:31:01): Inspired by Larry Tesler's work on modeless interfaces and Plan 9 from User Space, Nile's scrolling behavior is now context-dependent: if the bottom of the output is visible, it scrolls; otherwise, it stops. This provides a visual indicator and removes the need for a user-managed "scroll mode."
Window creation and resizing revert to an older behavior (drawing only the border outline) to avoid "janky blocky redraws" that occurred with full window redraws, especially over networks.
Nile has a darker theme (personal preference for dimly lit environments), which is a mixed bag, as it can be harder to read in bright light.
Thinner borders (1:40:05) were an experiment for small handheld devices but are now considered a "net loss" on high-DPI displays, making windows harder to grab. This change will be reverted.
A per-window font file is added, allowing individual windows to have different fonts, which helps with issues like misaligned columns when CPUing into remote systems.
A "non-interactive mode" for small devices (no borders, fixed window sizes) is mentioned but likely to become a separate project.
Future Work (1:42:51): Writable font files (to change fonts dynamically), further theming options, and integrating "look" (search) functionality into the window system are planned. The possibility of extracting common window system file system code into a shared library is also discussed.
4:56:33 - 5:26:36 Uglandics: A User-Mode Plan 9/Linux Hybrid:
Project Introduction (4:56:33): Aradus Kodra introduces Uglandics, a project aiming to create a user-mode Plan 9/Linux hybrid. It is inspired by the older Glendix but focuses on entirely user-space implementation.
Motivation (4:57:26): Addresses Plan 9's limitations in hardware support (e.g., Wi-Fi, touchpad on laptops) and Linux's overly complex user space.
Core Technology (4:58:24): Leverages Linux's syscall user dispatch feature, which allows intercepting system calls in user space without kernel patches, making it more robust against kernel upgrades and enabling use in containers (e.g., Docker).
Previous Efforts (4:59:17): Mentions existing projects like "9" and "9out," but notes their incompleteness, particularly in implementing directory reads (readdir) and wstat (for chmod).
Implementation Approach (5:01:27): Written from scratch in Linux-style C, prioritizing user-space implementation, minimal FD wrapping, and avoiding dynamic path rewriting.
Progress (5:02:32): Successfully runs basic programs (echo, cat), more complex ones (ls, 6c C compiler, mk), and integrates concepts from UNFS (Unix to 9P API translation) and drawterm (network stack).
Adds /srv support (for srvfs) using a FUSE-based helper and proc_fd_open.
Adds /net functionality extracted from drawterm.
Benchmarks (5:07:38): Uglandics can rebuild Ninefront distributions, typeset its own paper, mount and manipulate 9P file servers, and make simple HTTP 1.0 requests.
Linux's V9FS (Plan 9 filesystem in kernel) is buggy, requiring kernel patches for full functionality (e.g., transparent directory reads).
Limitations in Linux namespace manipulation necessitate using unshare.
V9FS has issues with short reads, write errors, and handling special files, making it unreliable for complex operations.
Future Work (5:17:59): Improve networking (CPU server, drawterm connectivity), bootstrap from T9 port, enhance /srv, parallel builds, and address the "single responsibility principle" for Plan 9 applications (advocating for separate, focused apps for network, graphics, audio, rather than large monolithic ones like drawterm).
5:26:36 - 5:55:31 Nyx: Reviving a Multi-Core Plan 9 Kernel for Unperturbed Computing:
Introduction (5:26:36): Paul introduces Nyx, a revived Plan 9 project aimed at optimizing performance on modern multi-core CPUs by providing an "unperturbed" execution environment.
Motivation (5:27:17): Traditional time-sharing operating systems (like Unix or even Plan 9) perturb processes with OS housekeeping, interrupts, and core migrations. Nyx seeks to avoid this.
Core Concept (5:29:23): Nyx designates certain cores as "time sharing cores" (TCs) to handle all OS work (interrupts, system calls, scheduling) and "application cores" (ACs) for unperturbed application execution. The TC will be idle when the AC is running an application.
The boot code (Squid Boy) is modified to identify and configure ACs based on a Nixaac config line.
The AC kernel is minimal, only handling essential traps (e.g., double faults, machine checks) and forwarding all other requests (even page faults) back to a TC for processing.
Process migration to an AC can occur via sys_execac (optimized for HPC with pre-paging to reduce startup latency) or via fork (for general use).
The communication mechanism between ACs and TCs involves the TC sending a function pointer work request to an idle AC, blocking, and then resuming upon trap, system call, or function return, receiving a "continuation."
Currently, returning a process from an AC requires ending the process, as RF_CANCEL_CORE is crashing due to kernel error handling issues.
Fast communication primitives between ACs (e.g., shared buffers with monitormwwait instead of spin-waiting) are needed.
Reliable interrupt delivery without perturbing ACs is a problem.
Crucially, performance measurements are needed to validate the benefits of this approach over standard Plan 9 execution.
Applications (5:46:17): Potential applications include high-performance computing (HPC) and complex software implementations like a GPU in user space.
Status (5:52:53): Two versions exist (Nine legacy and Ninefront), which are not forks but parallel development efforts. The project is actively seeking contributors for development and measurement.
5:57:55 - 6:20:17 Web Assembly on Inferno: Bridging Modern Web Binaries to a Plan 9-Inspired OS:
Introduction (5:57:55): The speaker introduces his project "Aeron," a WebAssembly (Wasm) runtime for Inferno OS. Inferno is described as a lightweight Plan 9 derivative that can run as an application on Linux, providing a full OS environment without a VM.
WebAssembly Explained (5:59:54): Wasm was created for performance in web browsers, providing a compact bytecode for applications (unlike JavaScript's runtime complexities). It allows "write once, run everywhere" for web apps, but within the browser's "walled garden" (security, privacy concerns with Google's dominance).
WASI (WebAssembly System Interface) (6:04:06): To break free from the browser, WASI normalizes how Wasm modules can access host operating system features like files, enabling Wasm to run outside browsers in other runtimes as normal programs.
Inferno is seen as a missed opportunity for what the browser became: a universal platform with strong name-spacing for tightly contained environments.
Aeron aims to bring Wasm to Inferno to mix and match services securely on a local machine (e.g., integrating bank and accounting APIs).
It makes Inferno more accessible for programming by allowing use of languages other than Limbo (Inferno's native language), aiding teaching.
Demo (6:06:39): A quick demo of "Hello World" written in Wasm (textual representation, 16 lines) running successfully on Inferno via Aeron. A C-compiled "Hello World" Wasm (1600 lines) is shown but not yet functional due to unimplemented instructions.
The Wasm binary format is optimized for size, leading to complex, indirect referencing (e.g., function types referenced by index, which is another index). This makes parsing difficult.
The parser (written using yak) has to manage state and context due to non-context-free grammar.
Execution is currently a naive switch-statement interpreter, which is slow. The goal is to translate Wasm instructions into Inferno's native Dis instructions for better performance.
External Wasm functions (like write) are implemented as Limbo modules, providing a flexible interface that allows easily switching underlying implementations (e.g., writing to a serial port instead of sys->write).
Future Steps (6:17:41): Load C-compiled Wasm, implement full WASI for file interaction (opening up Inferno's name space for Wasm apps), graphics (dev/draw), and potentially run Doom.
Q&A (6:18:28): Discusses the choice of yak for parsing (a default choice, but not ideal for Wasm's format), and the possibility of copying existing Wasm parsers.
6:24:03 - 6:52:27 Web PKI and Plan 9: Challenges and Proposed Solutions for Secure Communication:
What is PKI (6:25:19): Public Key Infrastructure provides the "green lock" in browsers, handling both encryption (secure channel) and authentication (verifying identity). Both are crucial for security (e.g., preventing man-in-the-middle attacks).
Certification Authorities (CAs) (6:27:43): The current model relies on trusted CAs (e.g., Verisign, Let's Encrypt) to issue certificates that vouch for identities. Systems (browsers, OS) ship with a "root of trust" of pre-approved CA certificates.
Verification Process (6:34:15): A client receives a website's certificate chain, verifies each link back to a trusted root, and then verifies the name in the certificate matches the host it's connecting to.
X.509 Complexity (6:35:55): The X.509 certificate format is "a disaster"—extremely complicated, lacking direct signer public key references (requiring iterative guessing from the trust store), and encoding names as sequences of strings with varying internal encodings (e.g., punycode for international domains).
Current Plan 9 Handling (6:38:07): Plan 9's current approach is deemed "poor." It uses "thumbprint files" (hashes of public keys) in sys/web/tls. These must be manually added by the user and break if the server's public key changes (e.g., when a new certificate is issued for Gmail). Few programs actually use these for validation (Mothra, the browser, only encrypts, doesn't validate endpoint).
Proposed Solution (auth/pki) (6:41:10): A new file system, auth/pki, is proposed to mirror auth/factotum's agent-based model. Clients would interact with auth/pki to send certificates and verify hostnames, receiving an "okay" or an error.
Implementation Status and Missing Pieces (6:43:18):
A proof-of-concept for auth/pki exists (800 lines of code).
Major missing piece: Name verification (RFC 6125), estimated to take another 5,000 lines due to its complexity (parsing various name formats, handling punycode, etc.).
The existing TLS client API is "unfixable" because it discards intermediate certificates, leaks memory, and doesn't know the target hostname, making proper verification impossible.
New libsec/libc APIs are needed, potentially modifying dial strings (e.g., tls!host) or introducing new tlsclient/tlsserver functions that explicitly pass hostname and configuration.
Future (6:49:50): Implement certificate revocation lists (CRLs, but not online verification for privacy), and client certificates. The core challenge is balancing security needs with the immense complexity of the X.509 standard.
7:17:40 - 7:59:54 ENIAC Simulator: Visualizing History on a Raspberry Pi with Plan 9:
Project Overview (7:17:40): Brian Stewart from Drexel University presents his ENIAC simulator, with the core in Go, and its visualization and control interfaces running on a Raspberry Pi under Plan 9. The project is rooted in his historical research on the ENIAC.
ENIAC Control Box (7:19:32): A 3D-printed model of the original portable control box is used. It features a three-position toggle switch (continuous, one add time, one pulse clocking modes) and four push buttons (clear, reader start, initial pulse, one pulse one add).
Clear: Resets all accumulators and counters to zero.
Reader Start / Initial Pulse: Initiates a computation (either by reading an input card or directly starting computation).
One Pulse One Add: The single-step button for both modes.
Raspberry Pi Interface (7:24:00): The control box connects via GPIO lines. Plan 9's /dev/gpio interface allows reading all GPIO states as a single 64-bit value. Debouncing is implemented by reading every 10ms and confirming 4 consistent reads before acting. Commands are sent to the simulator as strings (e.g., "clear").
LED Display (7:26:50): A 16x64 LED matrix (comprising 8x8 monolithic modules) is used for visualization. It's multiplexed: one row at a time is lit by shifting 64 bits into a shift register, latching, setting the row address via a 4-bit decoder, and enabling. A 60 FPS refresh rate (1ms per row) is necessary for a stable appearance.
Initial attempts as a timeshared process resulted in flickering due to heavy CPU load from the simulator.
Switching to Plan 9's real-time scheduling (configuring period and cost to 1ms, using sleep 0) improved stability, but some flickering still occurred under heavy load.
The most stable display was achieved by implementing a minimal kernel device driver that hooks into the timer and directly updates one row every 100 microseconds, using polling for SPI I/O within the interrupt handler (incurs only 1% CPU overhead).
Conjecture on Flickering (7:44:49): The persistent flickering with user-mode real-time scheduling might be because a real-time process doesn't immediately preempt a running timeshared process, waiting instead for a timeslice.
Future Work (7:46:00): Investigate scheduler preemption, and potentially reserve one core specifically for real-time processes and interrupt handling.
Q&A (7:48:01): Discussion on coordinating with the Nyx project for dedicated cores, using adaptive sleep/frame skipping, the choice of Pi as microcontroller, the scarcity of original ENIAC programs, and the display's representation of ENIAC accumulators (10 digits + sign per accumulator).
7:59:54 - 8:41:53 The Evolution of Plan 9: A Personal History and Future Outlook:
Unix Foundations (7:59:54): The speaker, Jeff Collier, reflects on Unix's early days (50 years to Unix), highlighting its novel features like pipes and contrasting it with larger, less interesting contemporary systems. His personal journey with Unix began with the sixth edition.
The Vision of Plan 9 (8:01:48): Introduced to Plan 9's vision by Rob Pike in 1986, it was conceived as a terminal-centric OS that imports resources and devices from the network to customize a user's namespace. The UK EUG papers (1995) were a major revelation, presenting Plan 9 as an evolution of research Unix for modern, distributed hardware.
Early Plan 9 and Bell Labs (8:03:26): Jeff experienced early bootable PC distributions and later joined Bell Labs in 1994, working on the Home Center set-top box and contributing to Plan 9's development (e.g., second edition components like 8.5 and Acme).
Multi-Processor and Memory Challenges (8:04:55): Discusses the evolution of multi-processor systems (Pentium Pro onwards) and the challenges of memory ordering and cache coherence, noting the improvements in modern RISC-V systems.
Key Innovations and Projects:
Brazil: Phil Winterbottom's project for efficiency and uncompressed raster graphics, later merged into Plan 9.
Inferno (8:07:07): A Plan 9 kernel with Limbo bytecode for user-mode applications, developed for set-top boxes, and hosted on various OSes (including Windows).
Mesa (8:07:40): A multimedia message system (fax, mail, voice) built on Inferno.
Pathstar (8:09:05): A combined telecom/IP router built on Plan 9, later canceled.
9P2000 & Venti (8:10:42): The new file server protocol and Venti (a hash-addressed block store for deduplication) were introduced in Plan 9 Third Edition (2000).
Fossil (8:12:00): A user-mode file server (using Venti or disk) that provided automatic backup, history, and versioning.
Personal Contributions and Hardware Adapations (8:12:18): Jeff recounts his work on gigabit Ethernet drivers, 64-bit file server kernel modifications, greylisting for spam, and ports to various architectures (Alpha, Xeon, RISC-V). He details the complexities of managing different hardware models and the challenges of early multi-core systems.
System Improvements and Maintainability (8:18:43): Efforts to reduce maintenance load by using standard PC device drivers, compressing bootstraps, and improving IPv6 support.
Year 2038 Problem (8:24:25): The system was converted to use ulong for times, extending time stamps to 21106 without requiring disk format changes.
Foundation and Legacy (8:26:48): Highlights the formation of the Plan 9 Foundation in 2020, which secured ownership of Plan 9 from Nokia and re-licensed historical releases under the MIT license.
Future Outlook (8:27:19): Continued work on RISC-V, avoiding jumbo packets (preferring larger RPC size for performance), and advocating for Plan 9's distributed nature over web browsers.
"We must defeat Git" (8:34:05): Jeff elaborates that Git is a "lousy" and "bureaucratic" version control system that enables "randomly" combining code from many people, leading to untrustworthy results.
He directs interested users to his website for his Plan 9 tree and RISC-V software, and to Adrian for a more "shaken down" installer image.
He admits to not knowing much about Ninefront.
Discusses private data in the historical Plan 9 tree (proprietary source, licensing issues) and the challenges of making it publicly available.