FreeBSD Developer Rice Backs systemd, Declares Traditional UNIX Dead

linux.conf.au

Rice argues that modern dynamic operating systems require unified, event-driven service supervision rather than 1970s shell scripts, urging open-source developers to adopt systemd's architectural advances instead of clinging to vintage UNIX dogma.

AI-assisted summary of The Tragedy of systemd — original source. Check the original for full context.

Source published: 2019-01-24

Key ideas

Traditional UNIX init conflated static system configuration with ongoing service supervision, leading to fragile shell scripts that could start daemons but lacked the ability to track or recover them on crash. (4:57)
Lennart Poettering drew heavily on Apple's launchd for systemd's socket activation and event-driven model to address modern runtime volatility across Linux environments. (10:49)
Rather than acting as a simple init daemon, systemd evolved into a comprehensive 'system layer' bridging user space and the kernel by absorbing udev, network state, and logging into a cohesive architecture. (13:45)
The fierce controversy surrounding systemd stems from cultural resistance to outside disruption and an empathy deficit between maintainers navigating conflicting demands and users defending familiar workflows. (25:12)

Detailed notes

## Background Published on YouTube by linux.conf.au on January 24, 2019, this presentation features FreeBSD developer Benno Rice examining the fraught controversy surrounding systemd. Drawing on the history of operating system bootstrap architectures and contemporary UNIX alternatives, Rice explores why an integrated system manager became necessary and why its adoption provoked such deep-seated community outrage.

## TL;DR Rice traces the historical evolution of init systems from the minimalist shell scripts of early UNIX to modern service managers like Apple's launchd and Linux's systemd. He argues that modern hardware volatility, cgroups, and stateful services necessitated an intermediate 'system layer' rather than static sequential bootstrap scripts. Addressing common grievances around bloat, bugs, and POSIX portability, he separates implementation flaws from architectural concepts while highlighting genuine breakthroughs such as user units and predictable hardware naming. Ultimately, he frames the ongoing hostilities as a toxic byproduct of contempt culture and developer-user empathy deficits, urging technologists to move past reflexive resistance and adopt modern design principles.

## Atmosphere & style The presentation blends sharp technical history with disarming wit, philosophical reflection, and self-deprecating humor, adopting the five-act structure of classical tragedy to contextualize community suffering. Speaking with the grounded perspective of an experienced FreeBSD contributor, Rice maintains a measured and fair-minded posture that avoids dogmatic tribalism. Watching the talk feels like participating in an engaging, cathartic post-mortem on software culture that turns bitter engineering debates into an earnest appeal for mutual empathy and architectural ambition.

## Bulletin - [04:57](https://www.youtube.com/watch?v=o_AIw9bGogo&t=297s) Traditional UNIX init conflated static system configuration with ongoing service supervision, leading to fragile shell scripts that could start daemons but lacked the ability to track or recover them on crash. - [10:49](https://www.youtube.com/watch?v=o_AIw9bGogo&t=649s) Lennart Poettering drew heavily on Apple's launchd for systemd's socket activation and event-driven model to address modern runtime volatility across Linux environments. - [13:45](https://www.youtube.com/watch?v=o_AIw9bGogo&t=825s) Rather than acting as a simple init daemon, systemd evolved into a comprehensive 'system layer' bridging user space and the kernel by absorbing udev, network state, and logging into a cohesive architecture. - [25:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1512s) The fierce controversy surrounding systemd stems from cultural resistance to outside disruption and an empathy deficit between maintainers navigating conflicting demands and users defending familiar workflows.

## Key takeaways - [01:48](https://www.youtube.com/watch?v=o_AIw9bGogo&t=108s) UNIX originally succeeded via brutal simplicity, but its early init model assumed static workloads that failed under modern internet-scale service demands. - [07:57](https://www.youtube.com/watch?v=o_AIw9bGogo&t=477s) Operating systems like Windows NT and macOS implemented dedicated service management and process supervision decades ahead of classic UNIX init scripts. - [07:57](https://www.youtube.com/watch?v=o_AIw9bGogo&t=477s) Apple's launchd demonstrated that socket and Mach port activation could dramatically accelerate boot times and minimize power consumption by launching daemons purely on demand. - [10:49](https://www.youtube.com/watch?v=o_AIw9bGogo&t=649s) systemd's primary objective was not merely raw boot speed, but providing a unified supervisor capable of reacting dynamically to hardware and software state shifts. - [13:45](https://www.youtube.com/watch?v=o_AIw9bGogo&t=825s) Modern dynamic computing environments require an intermediate 'system layer' to manage hotplug devices, dynamic addressing, and time synchronization without fragile third-party glue code. - [16:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=972s) Debian's adoption of systemd triggered high-profile resignations on its Technical Committee due to debates over coupling the OS to Linux-specific kernel interfaces. - [17:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1038s) Criticisms claiming systemd violates the Unix philosophy mistake a modular multi-binary monorepo for a single bloated binary. - [17:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1038s) All software contains bugs, but systemd's catatonic failure mode prevents the entire operating system from immediately panicking during fatal internal errors. - [20:26](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1226s) Abandoning lowest-common-denominator POSIX abstractions enabled systemd to fully exploit Linux-specific primitives like cgroups and autofs. - [22:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1338s) The computing industry has moved from historical UNIX fragmentation to a Linux-centric monoculture, altering standard portability expectations. - [24:14](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1454s) systemd delivers superior operational capabilities through granular cgroup process tracking and native unprivileged user-level system units. - [25:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1512s) Technologists frequently celebrate change when driving it themselves, but resist it vehemently when external paradigms disrupt familiar workflows. - [29:04](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1744s) Incoming generations of developers conceptualize infrastructure through cloud APIs and containers rather than traditional UNIX file hierarchies and shell scripts. - [29:04](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1744s) Structured messaging transports, predictable device naming, and append-only binary logs represent durable architectural advancements over ad-hoc UNIX text parsing. - [36:17](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2177s) Porting Apple's launchd to Linux was never feasible because launchd is deeply coupled to macOS-specific Darwin and Mach port architectures. - [45:14](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2714s) Resolving the cultural rift in the systemd ecosystem requires mutual empathy, recognizing both the challenges of managing conflicting user demands and the disruption experienced by administrators. - [46:16](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2776s) Elevating messaging and RPC transports directly into the operating system kernel could establish uniform security policies and equal-footing IPC across userland and kernel components.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=o_AIw9bGogo&t=0s) Introduction: Tragedy, Contempt Culture, and Change

Benno Rice opens by warning the audience that he has opinions. When assembling the talk, the title fell into place once he looked up Wikipedia’s definition of a tragedy: a drama based on human suffering that invokes catharsis or pleasure in the audience. Given the subject matter of systemd, Rice notes there has been more than enough suffering to go around, and he hopes to deliver the accompanying pleasure. Another major influence on the talk is an essay by Aurynn Shaw titled *Contempt Culture*, which examines how groups use contempt as a social signifier—a pattern frequently observed across programming communities where Python developers deride Perl, Perl developers mock PHP, and so on.

Rice emphasizes that the same tribal dynamics apply broadly across computing culture, particularly when confronted with change. Change inherently threatens familiarity, and while the familiar feels comfortable, that does not mean it is still good. Because traditional dramatic tragedies are structured into five acts, Rice formats his presentation into five distinct acts, starting with the origins of UNIX.

As Benno Rice observes regarding the discomfort of moving away from long-established tools: > “Change is a tricky thing because change threatens what we find familiar, and familiar is nice, familiar is comfortable, but that doesn't always mean that it is good, and it certainly doesn't mean that it is still good now if it's been around for a long time.”

---

[01:48](https://www.youtube.com/watch?v=o_AIw9bGogo&t=108s) Act I: The Brutal Simplicity of Early UNIX Init

Rice begins Act I by describing UNIX as a “happy accident.” It emerged as a direct reaction against contemporary operating systems that were seen as attempting to do far too much. UNIX took a brutally simple approach by focusing on small components and bootstrapping userspace in the simplest way possible. Looking at the manual page for `init` from Seventh Edition UNIX (1979), its documented role was straightforward: invoked as the final step of the boot procedure, it spawned a process for each terminal typewriter, and when transitioning to multi-user mode, it ran a shell script from `/etc/rc` to execute housekeeping functions such as mounting filesystems and starting daemons.

```mermaid flowchart TD accTitle: Seventh Edition UNIX Boot Flow accDescr: Simple sequence showing 1979 UNIX booting through init to run housekeeping and spawn terminal listeners. subgraph Boot ["Kernel Boot"] K["Kernel Initialized"] --> I["init (PID 1)"] end subgraph InitTasks ["Housekeeping & Terminals"] I -->|"runs script"| RC["/etc/rc (Mount fs & start daemons)"] I -->|"forks"| T1["Typewriter / TTY 1"] I -->|"forks"| T2["Typewriter / TTY 2"] end ```

Inspecting the process table of a PDP-11/70 running Seventh Edition UNIX (accessed courtesy of the Living Computers Museum and Labs) illustrates how little was actually happening: `init` forked a few times to handle terminals, alongside `cron` and `update` (whose only task was periodically flushing the filesystem superblock to disk). Very little had changed even by the time of 4.3BSD on a VAX-11/730. That system introduced `getty` for serial consoles, `routed`, `inetd`, and a couple of `telnetd` processes. Among these, `inetd` served as a service "super-daemon." Instead of leaving dozens of background daemons running persistently, `inetd` listened across network sockets and forked off an ephemeral handler process (such as `telnetd` or `ftpd`) only when an inbound connection arrived.

Describing the original philosophical design of early UNIX bootstrap routines, Benno Rice explains: > “They looked at a whole lot of the other systems that were on offer at the time and went, ‘You know what? This is just trying to do too much. We can be better than this, we just start with the small stuff and work from there,’ and it takes this brutally simple approach to bootstrapping itself and especially in bootstrapping user space.”

- `init` in Version 7 UNIX ran `/etc/rc` sequentially to perform housekeeping functions before handing control to terminal typewriters. - `update` periodically flushed filesystem metadata so unsaved disk blocks would not be lost during a crash. - `inetd` listened on behalf of multiple network services, delegating actual traffic handling to short-lived child processes on demand.

---

[04:57](https://www.youtube.com/watch?v=o_AIw9bGogo&t=297s) The Evolution from Daemons to Services

The `inetd` design functioned smoothly when network traffic was light and protocols were ephemeral. If a Telnet or FTP connection dropped, the client simply reconnected without losing significant persistent server state. However, the explosion of the World Wide Web broke this model; forking a distinct process for every individual HTTP connection became unsustainable at scale. Furthermore, complex stateful systems such as relational databases required persistent in-memory state across requests and could not be started and torn down per connection. This shift produced the modern concept of a "service"—a contiguous collection of behaviors and processes, often spanning multiple daemons or worker pools.

Traditional SysV-style `init` was never designed to manage services in this sense. While `getty` was actively supervised and restarted by `init` as terminals connected and disconnected, standard daemons were merely launched via shell scripts during boot. `init` simply stood them up and walked away; if a daemon crashed later, `init` did nothing to recover it. Even the introduction of `/etc/inittab` in System V provided only crude restart capabilities without fine-grained lifecycle awareness.

Rice argues that the historic UNIX manual conflated two fundamentally distinct tasks under the banner of "housekeeping functions": system configuration and service bootstrap. Configuration involves placing the host into an operational posture—much like a pilot adjusting flaps and slats into a landing configuration—by mounting filesystems and assigning network addresses. These tasks are set once and largely left alone. Service bootstrapping, by contrast, requires ongoing operational oversight, monitoring, and automated lifecycle management. Conflating these two concepts obscured the need for dedicated service managers, eventually paving the way for tools like Upstart and systemd.

Highlighting the fundamental limitation of traditional UNIX init scripts, Benno Rice points out: > “Old-school init can start these things, but they don't really get involved with managing them after that, they just kind of stand them up and then walk off and if it falls over they go, ‘[shrug].’”

---

[07:57](https://www.youtube.com/watch?v=o_AIw9bGogo&t=477s) Service Models in Other Operating Systems and the Birth of launchd

Looking outside the classic UNIX lineage, Rice notes that other operating systems approached background tasks with structured service models much earlier. Windows NT built a robust service framework directly into the platform from its inception. While relying heavily on shared host wrappers like `svchost.exe` introduced its own share of security challenges, the NT service manager included native capabilities for starting, stopping, dependencies, and automatic crash recovery—a design influenced by the complex minicomputer OS architectures that UNIX had originally rebelled against. Similarly, Apple developed a structured application execution model in Mac OS and iOS centered around application delegates, allowing the operating system to notify programs directly when events occur, such as application lifecycle shifts or low-memory warnings.

```mermaid flowchart LR accTitle: launchd Socket Activation Flow accDescr: launchd listens on multiple socket types and launches daemons on demand rather than at boot. subgraph Supervisor ["launchd (PID 1)"] L["launchd Socket Listener\n(UNIX sockets, TCP, Mach ports)"] end subgraph OnDemand ["Managed Daemons"] D1["System Service A\n(Spawned on access)"] D2["System Service B\n(Spawned on access)"] end L -->|"incoming connection"| D1 L -->|"Mach message"| D2 D1 -.->|"supervised / auto-restart"| L ```

In Act II, Rice turns to Apple's creation of `launchd`, introduced in Mac OS X Tiger. `launchd` consolidated almost every disparate event-handling and scheduling utility on the system, replacing `init`, `cron`, `at`, and `inetd` with a single unified daemon. Expanding the core concept of `inetd`, `launchd` listened on UNIX domain sockets, TCP ports, and Mach ports simultaneously. Instead of starting every background service during system boot, `launchd` held open their communication channels and launched the underlying daemons on demand when messages arrived, dramatically accelerating boot times. In addition, `launchd` provided continuous process supervision, monitoring service processes and automatically restarting them if they exited unexpectedly.

Summarizing how Apple’s `launchd` restructured service execution in macOS, Benno Rice states: > “So the idea of launchd was to move as many system services as possible into these daemons that could then be started as needed, because when you think about it, the actual underlying system when you're talking about a system like Mac or...”

- Windows NT shipped with native service lifecycle management and auto-restart from its earliest releases. - Apple platforms rely on application delegates to allow the host operating system to signal state transitions like memory exhaustion directly to running programs. - Introduced in Mac OS X 10.4 Tiger, `launchd` unified the duties of `init`, `cron`, `at`, and `inetd`. - `launchd` deferred service startup by holding open network sockets and Mach IPC ports, instantiating services only when traffic was directed to them.

[10:49](https://www.youtube.com/watch?v=o_AIw9bGogo&t=649s) The Legacy of launchd and the Birth of systemd

```mermaid flowchart TD accTitle: Evolution from launchd and Upstart to systemd accDescr: Diagram illustrating how Apple's launchd and Ubuntu's Upstart influenced Lennart Poettering to create systemd as an event-driven system manager.

subgraph Precursors ["Earlier Event-Driven Systems"] Launchd["Apple launchd (Demand-driven, Mach ports)"] Upstart["Ubuntu Upstart (Event-driven, shell scripts)"] end

subgraph SystemdGenesis ["systemd Architecture"] Poettering["Lennart Poettering (Blog announcement)"] SysdCore["systemd (Socket activation & dependency ordering)"] end

Benno Rice contrasts the traditional startup model with macOS, where services start purely on demand when something requests them. This approach yields immediate advantages: it slashes boot times, curtails power consumption, and elevates security by enforcing granular access controls. Apple pulled this off because macOS relies pervasively on underlying Mach ports and messaging systems. Rice points out the irony when speaking to fellow BSD enthusiasts: while BSD adherents often dismiss systemd, they enthusiastically endorse Apple's `launchd`, seemingly oblivious to the fact that “systemd is basically a ripoff of launchd.”

Five years after Apple deployed launchd, Lennart Poettering examined the existing Linux landscape—including Ubuntu’s Upstart. While Upstart was event-driven and could handle far more event triggers than traditional SysV init, it still depended on shell scripts and, in Poettering's view, failed to handle dependency ordering effectively. Setting out his vision in a seminal blog post introducing systemd, Poettering argued: “For a fast and efficient boot up, two things are critical: to start less and to start more in parallel.” Although systemd is often associated with raw boot speed, shaving seconds off boot was merely a secondary perk; the real priority was creating a supervisor responsive to hardware and software shifts: “An init system that is responsible for maintaining services needs to listen to hardware and software changes.”

- Poettering explicitly cited Apple's launchd as a direct inspiration for systemd's socket activation and event-driven model. - Poettering's prior open-source initiatives heavily tracked Apple's ecosystem: Avahi mirrored Apple's Bonjour (ZeroConf), while PulseAudio drew direct architectural comparisons to Apple's Core Audio. - Modern operating systems, whether on laptops, bare-metal servers, or virtual machines, operate in highly volatile runtime environments that require an event-driven supervisor rather than a static sequential script runner.

---

[13:45](https://www.youtube.com/watch?v=o_AIw9bGogo&t=825s) The Emergence of the "System Layer"

Rice observes how systemd naturally broadened its scope, transitioning from a basic init daemon into a full-scale system manager. Rather than maintaining the classic, rigid division between user space (applications and daemons) and the kernel (hardware drivers and network stacks), modern operating environments demand an intermediate tier. In the early days, compiling a custom FreeBSD kernel meant manually hardcoding hardware resources—designating specific motherboard slots and IRQs. Today, almost every element of operating system state is volatile and renegotiated on the fly: hotplug devices, dynamic DHCP leases, IPv6 autoconfiguration, and network time synchronization.

Rather than forcing system administrators to glue together fifteen disparate third-party packages—each with conflicting configuration files, unique daemon behaviors, and independent failure states—systemd absorbed these chores into a cohesive tier. Rice terms this the "system layer": a unified body of software (spanning both user and kernel space, such as udev, NetworkManager, and systemd daemons) that underpins core operational facilities below the end-user application level. While this absorption broke long-established expectations and sparked considerable community angst, it answered the operational need to stop continuously reinventing baseline platform glue.

---

[16:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=972s) Adoption Across Distributions and the Debian Schism

Despite the friction, systemd gained rapid, sweeping adoption across the Linux ecosystem, ultimately running on the overwhelming majority of the Linux installed base. The transition was far from painless, and Debian's adoption process proved particularly traumatic. Because Debian historically supported alternative kernels—such as Debian GNU/kFreeBSD—switching to an init system tied exclusively to Linux-specific kernel interfaces provoked an intense, prolonged debate. Although Debian ultimately voted to adopt systemd, the fallout was severe: the rancor and personal friction of the debate drove multiple members of Debian's Technical Committee and governance leadership to resign.

``` Distribution Adoption Timeline: • Fedora 15 (May 2011) • Arch Linux (October 2012) • Red Hat Enterprise Linux 7 (June 2014) • Debian 8 "Jessie" (April 2015) • Ubuntu 15.04 (April 2015) • openSUSE 12.1 / Leap ```

---

[17:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1038s) Refuting Common Critiques: The Unix Philosophy and Software Bugs

Rice systematically dismantles the most common grievances leveled against systemd:

1. **"It violates the Unix philosophy."** Opponents frequently allege that systemd violates the principle of "do one thing and do it well" by acting as an all-encompassing binary. Rice dismisses this as factually incorrect: systemd is not a single executable doing everything from DHCP to NTP, but a modular suite of distinct binaries developed within a single unified source tree. Coming from FreeBSD, Rice notes that BSD developers have used central monorepos for decades to coordinate userland utilities. 2. **"It is bloated and monolithic."** While acknowledging why people feel unsettled when one upstream repository inhales so many separate utilities, Rice explains that unifying configuration schemas and service lifetimes across the operating system requires shared architectural plumbing. 3. **"It is buggy."** Addressing the claim that systemd is too unstable for core infrastructure, Rice argues: “All software has bugs, some bugs are gonna be security issues.” While critics demand that an init replacement must be virtually flawless, imposing an impossible bar simply locks systems into antiquated designs. Furthermore, systemd possesses a sensible failure mode: when it hits a fatal internal state, it goes catatonic rather than immediately panicking the entire machine, allowing administrators to access recovery tools and reboot on their own terms.

To illustrate how bug debates devolve into tribalism, Rice recounts an exchange involving developer Matthew Garrett regarding a memory corruption vulnerability in `systemd-journald` caused by allocating dynamic memory directly on the stack:

| Speaker | Argument / Context | |:--- |:--- | | **Matthew Garrett** | Commented on the journald stack vulnerability: “The moral is not don't use systemd, the moral is you know maybe don't use C for these things.” | | **OpenLDAP Advocate** | Retorted that the true takeaway was simply never to adopt or rely on systemd. | | **Matthew Garrett** | Replied silently with a link to the long historical catalog of CVEs in OpenLDAP, whose chief architect is Howard Chu, underscoring that legacy C codebases are equally prone to severe memory errors. |

Rice insists that engineers must maintain an intellectual boundary between code flaws and system architecture: “There's an important distinction to be drawn between systemd the implementation and systemd as a set of ideas.”

---

[20:26](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1226s) Personality Clashes and Non-Portability

Rice moves to the interpersonal backlash surrounding Lennart Poettering's combative persona on GitHub and mailing lists. While declining to defend Poettering's abrasive community management, Rice highlights the sheer persistence required to overhaul the Linux plumbing layer: > “You have to admire the willpower and determination of someone who at work one day goes, ‘I'm gonna write my own init system—actually no, it's going to be a full-on system layer for Linux,’ and takes it to his management and goes, ‘Hey, I'm gonna do this,’ and they go ‘No,’ and he goes ‘No way,’ and then he comes back with it and it works, and then he gets it put into pretty much every major Linux distribution.”

Lastly, Rice addresses the grievance closest to his background as a FreeBSD developer: portability. Systemd deliberately rejects POSIX-agnostic abstraction in favor of deep, aggressive integration with Linux-specific kernel primitives, most notably cgroups, autofs, and specialized process-tracking hooks. Rice acknowledges that this tight coupling risks stranding non-Linux operating systems that lack matching kernel APIs. However, systemd reaps immense functional capabilities precisely because it abandons generic compatibility. Dismissing the argument that software should forever adhere to lowest-common-denominator Unix APIs, Rice provocatively concludes: “The reality is that UNIX is dead.”

[22:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1338s) From Pathological Diversity to Monoculture

In the early days of UNIX and the emergence of POSIX, system design was driven by the imperative to maintain portability across an extraordinarily fragmented computing landscape. Code written on 4.3BSD running on a VAX had to be able to compile and run on SunOS, AIX, Digital UNIX, and numerous other vendor implementations. Today, however, that computing landscape has shifted dramatically. As Benno Rice remarks:

> “These days I think you've basically got Linux and some rounding errors.”

Speaking as someone who has devoted a significant part of his life and career to FreeBSD, Rice notes that FreeBSD is no longer in a position to push a proposed interface onto the broader community; if it tries, the Linux ecosystem simply moves on without caring. Conversely, Linux can introduce innovations like control groups (cgroups) on a take-it-or-leave-it basis. While this evolution marks a transition from pathological diversity to a pathological monoculture where a single platform dictates the terms, Rice argues that this break from tradition does not have to be a net negative. Freed from the constraints of maintaining strict adherence to vintage UNIX dogma, alternative operating systems like FreeBSD could similarly feel liberated to experiment and invent whatever they want without constantly worrying about what historic UNIX standards dictate.

```mermaid flowchart TD accTitle: Evolution of UNIX Diversity accDescr: Diagram contrasting historical multi-platform UNIX portability with modern Linux dominance and cgroups.

subgraph Hist["Historical UNIX Landscape"] V["4.3BSD on VAX"] S["SunOS"] A["AIX"] D["Digital UNIX"] P["POSIX / Portability Consensus"] V --- P S --- P A --- P D --- P end

subgraph Mod["Modern Landscape"] L["Linux Kernel & systemd"] CG["cgroups & native APIs"] L --> CG CG -.->|"Take it or leave it"| O["Other OSes / Rounding Errors (FreeBSD, Solaris)"] end ```

[24:14](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1454s) Features systemd Got Right: cgroups and User Units

Rice emphasizes two particular technical design decisions that make systemd compelling: its deep integration with Linux cgroups and its first-class support for user-level system units. While FreeBSD pioneered lightweight containerization through jails long ago, Rice views jails as considerably less flexible and far less granular than the resource-partitioning and process-tracking primitives afforded by modern Linux cgroups.

The other major operational victory in systemd is its native handling of user-space daemons. On systems like FreeBSD, setting up a daemon that starts and runs automatically under an unprivileged user account without requiring root intervention is notoriously awkward—often forcing administrators into convoluted wrapper shell scripts using `sudo`, `su`, or cron jobs. Under systemd, an unprivileged user can simply drop a service definition file into a configuration directory within their home folder, and the system supervisor manages its execution cleanly.

[25:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1512s) The Psychology of Change and the "Tired Old Blankie"

The intense controversy surrounding systemd ultimately boils down to how technologists react to disruptive change. Rice observes that technical communities have an intrinsically fraught relationship with new methodologies:

> “Nerds especially have a really complicated relationship with change: we love it to pieces, change is awesome when we're the ones doing it.”

The moment change is imposed from the outside, it is viewed with deep suspicion because it disrupts the comfortable and familiar. For decades, system administrators grew up with the paradigm of `/sbin/init` executing `/etc/rc`, which in turn stepped through a succession of shell scripts. Rice likens this deep emotional attachment to shell-scripted bootstrap systems to a “tired old blankie that we maybe should have handed off about 20 years ago.”

Because systemd represented a massive, disruptive shift championed by figures like Lennart Poettering—whose empathy toward those he was asking to change did not always appear to be his strongest suit—the pushback turned toxic. Rice unequivocally condemns the harassment directed at Poettering, stressing that no piece of software justifies sending someone death threats. At the same time, he criticizes the smug contempt displayed by parts of the BSD community who treated systemd as a punchline. He points out that ridiculing Linux users for running systemd, or adopting the attitude of *"come join FreeBSD, we'll never change,"* is actively harmful because it frames stagnation as a virtue rather than treating systemd as a valuable source of architectural ideas.

- The backlash against systemd revealed an empathy deficit on both sides: developers driving disruptive changes without sympathy for existing users, met by disproportionate venom and abuse from the community. - Contemptuous dismissal of systemd blinds alternative OS communities to genuine engineering advances and discourages constructive competition. - Rice argues that detractors should ask why systemd was created, identify the specific problems it solves, and attempt to build superior alternatives rather than clinging to 1970s shell scripts.

[29:04](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1744s) Shifting Paradigms: The Next Generation and Modern Architectural Ideas

The perspective of incoming engineers is vastly different from that of veteran "Greybeards." New system administrators and developers do not conceptualize infrastructure through the lens of traditional UNIX files and scripts. Instead, they operate natively with cloud infrastructure and application containers:

> “The next generation of people who are coming into IT, coming into software engineering, coming into systems administration, they don't necessarily think about the systems they're running in the way that we do or that I do.”

To highlight this shift, Rice reflects that twenty years ago, the concept of provisioning a UNIX instance simply by hitting an HTTP API hosted by an online bookstore would have sounded astonishing. Modern developers naturally think in terms of web APIs and containerized workloads, making API-driven system supervision a baseline expectation.

Rice details several high-level architectural ideas embodied by systemd that operating system designers should study: 1. **Unified Messaging Transports and RPC Frameworks:** systemd relies heavily on D-Bus. Although Rice is not personally fond of D-Bus itself, he strongly endorses structured messaging over unstructured text. Apple solved this similarly using Mach messaging primitives. Rice envisions an alternative, kernel-resident message transport featuring robust authentication, security policies, and access-control endpoints. Such a mechanism acts as an equalizer, allowing higher-level userland software to issue uniform service requests (such as configuring a network address) without having to care whether the backing provider resides in kernel space or user space. 2. **Proper Service Lifecycles:** Unlike classic UNIX bootstrap scripts, systemd provides an integrated state machine for service lifecycles out of the box—capabilities that Windows NT had from its inception and that macOS achieved through `launchd`, sparing administrators from having to duct-tape disparate third-party process supervisors like OpenRC, runit, or supervisord onto their systems. 3. **Appliance Automation and Declarative Configuration:** Exposing system management through formal APIs rather than ad-hoc shell scripts radically simplifies the development of hardware appliances, embedded distributions like OpenWrt, and commercial enterprise storage products. 4. **Predictable Hardware Naming Schemes:** Despite having spent years advocating the FreeBSD tradition where every Ethernet device takes the name of its specific kernel driver (and despite disliking legacy Solaris disk identifiers like `c0t0`), Rice praises systemd's predictable network interface naming for deriving consistent, reliable device names from physical hardware attributes.

[33:51](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2031s) Systemd's Model: Logs, Containers, and Redefining the Application

Benno Rice continues wrapping up his talk by detailing features of systemd that he considers genuine improvements over legacy UNIX paradigms. Stable device naming is significantly better than having network interfaces or disks named arbitrarily after whatever random order the kernel happens to detect them in. He also strongly defends systemd's logging architecture, arguing that binary logs are inherently beneficial provided administrators have the proper tooling to inspect and dissect them. An append-only log file offers clear security and integrity benefits, particularly when it can be effortlessly streamed and shipped off-box to central log collectors.

```mermaid flowchart LR accTitle: Systemd Modern Application Model accDescr: Shift from traditional single-binary processes to encapsulated, unit-managed services. subgraph Legacy["Traditional UNIX Model"] direction TB B1["Single Binary"] -->|"spawns"| B2["Unmanaged Background Children"] end subgraph Modern["Systemd / Container Model"] direction TB C1["Encapsulated Unit"] -->|"manages & tracks"| C2["Grouped Processes"] C2 -->|"host feedback"| C1 end ```

Beyond logging, the rise of containers alongside systemd has enabled an entirely new conceptual model of an application. Rather than viewing software as a single isolated binary—or a master binary that blindly spawns detached child processes—an application can now be treated as an encapsulated collection of components managed uniformly as a single unit. Rice finds this approach exceptionally powerful. Looking forward, he expresses interest in seeing how Linux could adopt a macOS-style application model, where rich feedback loops between the host operating system and running services allow applications to dynamically react to host environment changes.

- Binary logs are defended on the basis of append-only durability and ease of remote transmission, assuming adequate extraction tools exist. - Applications evolve from solitary binaries into encapsulated, multi-process units managed holistically by the service manager.

[34:51](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2091s) The Catharsis of Tragedy and the Call to Action

Returning to the theme introduced at the start of his presentation, Rice revisits the formal Wikipedia definition of tragedy, which hinges on evoking *catharsis* in the audience. Catharsis—classically defined as the purification or cleansing of deep-seated emotions, specifically pity and fear, through art or sudden emotional transformation—is precisely what he hopes attendees take away from his breakdown of systemd. Rather than reacting with reflexive dread or condescension, users and administrators should let go of their fear and pity regarding systemd and those who adopt it.

Rice reflects on how software engineering mirrors broader realities of life: the world evolves constantly, forcing engineers either to adapt or to waste energy fruitlessly resisting progress. He cautions that not all changes demand blind, permanent commitment upfront—many Linux distributions experimented with or transitioned through multiple intermediate init systems before landing on systemd. Emphasizing thoughtful, logical evaluation over ideological dogma, he delivers a parting challenge before closing his slides:

> “What I would challenge everyone here is look at systemd and try and find at least one thing that you like and then go see if you can implement it.”

[36:17](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2177s) Q&A: Porting launchd to Linux, and Container "DLL Hell"

The audience bursts into applause, and Rice opens the floor for questions, asking attendees to keep their contributions strictly as questions rather than diatribes disguised with a question mark at the end. The first question asks whether porting Apple’s launchd over to Linux would have been a viable alternative, given that Apple had already solved many service-orchestration problems and released parts of their stack as open source. Rice explains that while systemd is aggressively Linux-specific, launchd is equally aggressively macOS-specific. It relies extensively on Mach ports and Apple-specific architectural primitives. Although Apple made exploratory gestures toward porting libdispatch and related plumbing to FreeBSD, the effort eventually petered out because Apple’s primary incentive was refining the framework for their own platform, just as the systemd project focuses entirely on Linux.

A subsequent questioner notes that while containers allow services to be bundled as clean units, isolating software this way seems to forfeit decades of progress made in dynamic library management, potentially landing developers right back into a modern variant of DLL hell. Rice pushes back on the comparison, clarifying his view of DLL hell:

> “Well I think in a... so DLL hell to me is more having five different versions of a library and always having your applications pick the wrong one.”

He points out that containers explicitly avoid that classic runtime ambiguity by encapsulating the exact required dependencies together, functioning much like the Go programming language does by statically linking binaries into self-contained operational artifacts.

- launchd depends deeply on Mach ports and Darwin internals, making cross-platform ports to Linux or FreeBSD impractical without heavy platform-level emulation. - Containers avoid traditional DLL hell by preventing mismatched system shared libraries from colliding at runtime.

[38:23](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2303s) Q&A: Community Backlash, Chilling Effects, and FreeBSD Init

Following an invitation from an audience member for Rice to organize a systemd microconference at the upcoming Linux Plumbers Conference in Lisbon, Portugal, another attendee asks whether the venomous community backlash directed at systemd has created a chilling effect that discourages developers from attempting ambitious system-level innovation. Rice concedes that the intense vitriol aimed at Lennart Poettering and other systemd developers likely has discouraged people. Writing low-level bootstrap code is vastly harder than most engineers realize, but managing the social dynamics of community acceptance is harder still. Rice quips that his own struggle with navigating social consensus when advocating for modern init systems on FreeBSD eventually led him to simply yell at the project in a keynote address.

When a Linux user interested in FreeBSD asks about the current state of a next-generation init system in the FreeBSD world, Rice points to the OpenRC project, which provides service management capabilities. However, he stresses that OpenRC does not represent a holistic operating system layer:

> “There are far too many people who immediately default to this notion that systemd is only about starting and managing services, when in my opinion if you're really going to do that kind of thing you need to look at the whole thing.”

Rice emphasizes that building a modern system layer does not require packing every feature into a single repository, but it absolutely requires designing with cohesive, system-wide intent so the entire stack behaves uniformly.

[41:11](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2471s) Q&A: Scope Creep, Embedded Devices, and the Broken Social Dynamic

A questioner brings up the sheer volume of previously distinct system services that systemd has gradually subsumed, asking whether consolidating all of them actually made sense. In response, Rice proposes a thought experiment: if the systemd developers had initially focused on formalizing clean, standardized management APIs for networking, time synchronization, and logging, external implementations could have remained interchangeable without needing to live in one monolithic codebase. However, he sympathizes with how project scope expands organically in practice—developers usually do not realize an abstraction boundary is needed until after they bring an external service in-house to solve an immediate integration roadblock.

Addressing a query about the merits of systemd in embedded Linux environments, Rice notes that systemd provides a robust hook for devices operating in dynamic hardware conditions, where peripherals are hotplugged and services must recover without human intervention. Standardized system APIs reduce the bespoke daemon-monitoring code embedded developers are forced to write from scratch.

Finally, a questioner asks how to bridge the toxic divide between a defensive systemd development team and an equally hostile user community. The attendee highlights that the developers often dismiss community input while users refuse to acknowledge systemd's broader architectural vision:

> “Given the interactions between the community and the systemd team in both directions have not always been the most positive to put it mildly... what needs to change both in the community and say this room and broadly and also in the systemd team in order to facilitate a better working relationship going forwards?”

Rice acknowledges that untangling this deep-seated friction is an extraordinarily difficult problem, suggesting as a first step that people watch Adam Harvey's talk on handling language version upgrades and technical transitions gracefully.

[45:14](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2714s) Balancing Community Demands and Developer Empathy

Responding to an audience question about managing upgrades and encouraging user adoption, Benno Rice highlights the importance of providing constructive incentives rather than purely negative reinforcement. He points out that getting users to transition requires showing them genuine reasons to change, rather than merely beating them over the head with reprimands not to do something. At the same time, Rice acknowledges the overwhelming pressure faced by the maintainers of systemd when dealing with the wider open-source ecosystem.

Addressing the friction between the maintainers and the community, Rice admits that while he speaks from outside the project, the sheer volume of conflicting requirements creates an untenable situation for any engineering team. Users and distributions frequently arrive with mutually exclusive feature requests and design expectations, creating an environment where friction is almost inevitable. While that environment explains the defensive posture often adopted by upstream developers, Rice argues that repairing this fraught dynamic requires mutual understanding rather than dismissiveness.

> “That’s a really hard set of constraints to try and work within, and so I can see that there would be a temptation to just tell them all to get nicked; that doesn't mean that that's the right thing to do.” — Benno Rice

> “I don't really know the right way for them to fix it, but it probably involves a lot more sympathy on both sides.” — Benno Rice

- **The challenge of conflicting demands**: Developers face simultaneous, irreconcilable requests from disparate community factions (e.g., wanting $X, Y, Z$ while others demand $A, B, C$), where numerous requests directly contradict one another. - **The cultural divide**: The friction between systemd’s core authors and the broader open-source user base has led to entrenched hostility, requiring conscious empathy from both sides to resolve.

---

[46:16](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2776s) Pervasive Messaging, RPC, and In-Kernel Transports

When asked by an audience member whether there are specific technical areas where systemd should push significantly further, Rice points directly toward system-wide inter-process communication (IPC) and Remote Procedure Calls (RPC). He notes that while systemd already leverages D-Bus extensively, he would like to see standardized messaging and RPC primitives become far more pervasive, deeply integrated, and thoroughly explored across the entire operating system stack.

Rice reflects on previous efforts within the Linux ecosystem to introduce a high-performance D-Bus-style transport mechanism directly into the Linux kernel (such as kdbus or BUS1). He argues that regardless of whether the implementation uses D-Bus semantics specifically or an alternative design, moving messaging primitives into the kernel layer offers major architectural advantages. By elevating IPC to a first-class kernel citizen, diverse system components are placed on an equal footing, unlocking more granular access controls, enhanced telemetry, and sophisticated security boundaries that user-space daemons cannot enforce alone.

> “I would very much like to see the messaging and RPC stuff become a lot more pervasive and a lot more thought about, if that makes sense.” — Benno Rice

> “I think that having that, even if it's not necessarily D-Bus, would be a really interesting thing to play with because it puts a lot of code on the same level and it also allows a lot more, yeah, control and interesting security features that you could do by having it in the kernel.” — Benno Rice

```mermaid flowchart TD accTitle: Potential Architecture for In-Kernel IPC accDescr: Diagram showing user-space system daemons and utilities communicating through an in-kernel messaging and RPC transport layer.

subgraph UserSpace["User Space"] SD["systemd Daemons"] App["System Services & Apps"] end

subgraph KernelSpace["Kernel Space"] IPC["In-Kernel Messaging / RPC Transport\n(D-Bus style / kdbus / BUS1)"] Sec["Security & Access Control Enforcement"] end

SD <-->|"Uniform RPC Interface"| IPC App <-->|"Uniform RPC Interface"| IPC IPC --- Sec ```

Following this response, the session chair announces that the presentation has run out of time, thanking Benno Rice as the audience concludes the session with loud applause.

## Notable quotes > [17:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1038s) There's an important distinction to be drawn between systemd the implementation and systemd as a set of ideas. — Benno Rice

> [25:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1512s) Nerds especially have a really complicated relationship with change: we love it to pieces, change is awesome when we're the ones doing it. — Benno Rice

> [10:49](https://www.youtube.com/watch?v=o_AIw9bGogo&t=649s) For a fast and efficient boot up, two things are critical: to start less and to start more in parallel. — Lennart Poettering

> [20:26](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1226s) The reality is that UNIX is dead. — Benno Rice

> [10:49](https://www.youtube.com/watch?v=o_AIw9bGogo&t=649s) An init system that is responsible for maintaining services needs to listen to hardware and software changes. — Lennart Poettering

> [22:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1338s) These days I think you've basically got Linux and some rounding errors. — Benno Rice

## Mentioned Benno Rice, Aurynn Shaw, Lennart Poettering, Matthew Garrett, Howard Chu, Adam Harvey, systemd, FreeBSD, Debian, Fedora, Arch Linux, Red Hat Enterprise Linux, Ubuntu, openSUSE, OpenWrt, UNIX, 4.3BSD, SunOS, AIX, Solaris, Windows NT, macOS, iOS, launchd, Upstart, OpenRC, runit, supervisord, Avahi, PulseAudio, udev, NetworkManager, journald, D-Bus, kdbus, BUS1, OpenLDAP, inetd, Living Computers Museum and Labs, Linux Plumbers Conference, linux.conf.au

## Video description Benno Rice

https://2019.linux.conf.au/schedule/presentation/156/

systemd is, to put it mildly, controversial. As a FreeBSD developer I decided I wanted to know why.

I delved into the history of bootstrap systems, and even the history of UNIX and other contemporary operating systems, to try and work out why something like systemd was seem as necessary, if not desirable. I also tried to work out why so many people found it so upsetting, annoying, or otherwise rage-inducing.

Join me on a journey through the bootstrap process, the history of init, the reasons why change can be scary, and the discovery of a part of your OS you may not even know existed.

linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see https://linux.conf.au/

#linux.conf.au #linux #foss #opensource

[Source](https://www.youtube.com/watch?v=o_AIw9bGogo)

中文简报

FreeBSD开发者Rice力挺systemd，直言传统UNIX已死 Rice认为，现代动态操作系统需要统一且事件驱动的服务监管机制，而非20世纪70年代的Shell脚本，并呼吁开源开发者采纳systemd的架构进阶成果，而非固守陈旧的UNIX教条。 Rice梳理了init系统从早期UNIX极简Shell脚本到Apple的launchd及Linux的systemd等现代服务管理器的历史演进。他指出，现代硬件的易变性、cgroups以及有状态服务催生了对居中“系统层”的需求，而非静态的顺序引导脚本。在回应有关臃肿、缺陷和POSIX可移植性的常见质疑时，他将具体实现缺陷与架构理念区分开来，同时着重指出了用户单元和可预测硬件命名等实质性突破。最终，他将持续不断的争议定性为鄙视文化和开发者与用户间同理心缺失所导致的有害副产品，力劝技术人员抛弃本能抗拒，积极拥抱现代设计理念。传统UNIX init将静态系统配置与持续的服务监管混为一谈，导致脆弱的Shell脚本虽能启动守护进程，却缺乏追踪或在崩溃后恢复它们的能力。 (4:57) Lennart Poettering很大程度上借鉴了Apple的launchd，为systemd引入套接字激活与事件驱动模型，以应对Linux环境中现代运行时的易变性。 (10:49) systemd并非仅仅充当一个简单的init守护进程，而是通过将udev、网络状态和日志记录吸纳进一个紧密结合的架构中，演变为连接用户空间与内核的完整“系统层”。 (13:45) 围绕systemd的激烈争议源于对外部颠覆的文化抗拒，以及在应对冲突需求的维护者与捍卫熟悉工作流的用户之间存在的同理心缺失。 (25:12)

Reading summary

Benno Rice argues that the fierce controversy over systemd is an emotional tragedy of computing culture: while critics cling to antiquated UNIX shell scripts, modern operating systems fundamentally require an integrated, event-driven system layer to manage complex, volatile runtimes. The Breakdown of Classic UNIX Init (1:48) Traditional UNIX init, originating in Seventh Edition UNIX (1979), was designed around brutal simplicity: PID 1 ran a shell script (/etc/rc) to handle basic housekeeping like mounting filesystems, spawned terminal listeners, and walked away. Network helpers like inetd handled ephemeral connections by forking temporary child processes. However, Rice explains that the emergence of the World Wide Web, persistent stateful services like relational databases, and multi-process worker pools broke this model. Traditional init systems stood daemons up without continuous operational supervision or fine-grained restart capabilities, failing to distinguish between one-time host configuration and active service lifecycle management. Service Models and the System Layer (7:57) Platforms outside classical UNIX embraced structured service managers much earlier, such as Windows NT's built-in service manager and Apple's launchd in Mac OS X Tiger, which unified init, cron, and inetd by holding communication channels open to start daemons on demand. Drawing directly from launchd's socket-activation model, Lennart Poettering created systemd to provide parallelized, event-driven supervision that responds dynamically to runtime hardware and software changes. Addressing Monolith and Portability Criticisms (17:18) Rice addresses standard technical criticisms against systemd, noting that it is not a monolithic binary but a modular suite developed within a single source repository. While acknowledging that bugs and memory corruption vulnerabilities occur across all C codebases, he argues that systemd's deliberate integration with Linux-specific primitives—such as cgroups, autofs, and dynamic process tracking—delivers essential functional capabilities that generic, lowest-common-denominator POSIX abstractions could not provide. With the computing industry having shifted from historical UNIX diversity to a Linux-dominated monoculture, Rice contends that strict multi-platform UNIX portability is effectively dead. Contempt Culture and Technical Disruption (25:12) The vitriol directed at systemd and its author stems heavily from what Rice identifies as contempt culture and an emotional resistance to disruptive change. Technologists embraced shell scripts like a familiar blanket, leading parts of the BSD and Linux communities to frame stagnation as a virtue while directing abusive backlash at maintainers. At the same time, upstream developers faced irreconcilable, conflicting demands across distributions, exacerbating defensive postures. Rice maintains that alternative operating systems should study systemd's engineering strengths—such as declarative unit files, user units, predictable device naming, and append-only binary logging—rather than dismissing them out of spite. Future Architectural Frontiers (29:04) Looking forward, incoming engineers view systems through web APIs and encapsulated containers rather than legacy shell scripts. To advance operating system architecture, Rice advocates building richer feedback loops between service supervisors and applications, alongside standardizing pervasive, in-kernel messaging and Remote Procedure Call (RPC) transports similar to kdbus or BUS1. Elevating messaging primitives to first-class kernel citizens would provide unified access control, robust security boundaries, and telemetry across both kernel and user-space components. Rice concludes that engineers must separate the implementation flaws of systemd from its underlying architectural innovations. Rather than fruitlessly resisting change or defaulting to tribal hostility, developers across both Linux and alternative operating systems are challenged to find at least one valuable architectural concept from systemd and build superior implementations.

精炼阅读摘要

Benno Rice在演讲中指出，围绕systemd的激烈争议不仅源于技术实现的优缺点，更反映了技术群体在面对颠覆性变革时的心理抗拒与“轻视文化”。他认为，传统的UNIX初期模型早已无法应对现代操作系统的动态需求，构建统一的系统管理层是必然趋势，各方应超越派系攻讦，理性审视其背后的架构价值。从极简初始化到现代服务模型 (1:48) 早期UNIX的初始化系统采取了极其简化的设计，1979年第七版UNIX中的init（PID 1）职责十分有限：在启动流程末期运行/etc/rc脚本执行挂载文件系统等管家任务，并为终端打字机派生进程。后续引入的inetd通过统一监听网络套接字并在连接到来时派生临时处理进程，有效管理了轻量网络任务。但随着互联网规模扩大与关系型数据库等有状态服务的普及，按连接派生进程的模式彻底失效，长时间持续运行的复杂服务成为主流。然而，SysV风格的init仅在启动时通过脚本拉起进程，缺乏服务运行时的健康监控与自动崩溃恢复机制，本质上混淆了单次系统配置与持续性服务监管这两类完全不同的任务。从launchd到systemd的演变 (7:57) 在UNIX体系之外，其他操作系统很早便建立了结构化服务管理框架。Windows NT自诞生起就原生支持服务生命周期控制与崩溃重启；苹果公司则在Mac OS X Tiger中推出launchd，统一替代了init、cron、at和inetd，通过监听UNIX套接字、TCP端口和Mach端口实现按需激活，大幅缩短了引导时间并强化了进程监督。Lennart Poettering借鉴launchd的套接字激活与事件驱动模型，于2010年提出了systemd的核心构想，旨在克服Ubuntu Upstart缺乏依赖排序的缺陷。systemd不仅追求并行启动效率，更关键的是构建一个能对硬件热插拔、动态DHCP与网络时间同步等运行时变化作出实时响应的“系统层”，终结以往依靠大量碎片化第三方工具与脆弱Shell脚本拼凑系统的局面。反思技术争议与Unix哲学的误区 (17:18) 针对社区对systemd违背Unix哲学（“做好一件事”）、代码庞大臃肿且Bug频发的批评，Rice提出了明确反驳。他指出systemd并非单一的巨型二进制程序，而是一个统一代码仓库下协同开发的模块化工具集，这与FreeBSD等系统长期采用单体源码树维护用户态工具的做法完全一致。此外，任何处于核心基础设施的复杂软件都无法完全避免安全漏洞，关键在于架构理念与具体实现应予区分，且systemd在发生致命错误时会转入无响应状态以防止直接触发全机崩溃。Rice同时坦言，systemd为追求极致功能选择与Linux特有内核机制（如cgroups）深度绑定、抛弃POSIX通用抽象的做法，虽然切断了跨平台可移植性并导致Debian技术委员会因分歧辞职等动荡，但在现代以Linux为主导的计算格局下，这是一种务实的工程权衡。变革心理学与下一代系统架构设想 (25:12) Rice认为社区对systemd的仇恨往往夹杂着“轻视文化”，人们对外部强加的变革怀有本能敌意，对使用了数十年的Shell脚本引导流程产生了类似“破旧毛毯”般的情感依赖。虽然Poettering等开发者在社区沟通中缺乏同理心，但部分BSD群体将停滞视作美德或向开发者发出人身威胁的行为同样不可取。随着云原生与容器化理念普及，新一代工程师习惯于通过API与结构化机制管理多进程单元。Rice呼吁系统设计者关注systemd展现出的优秀架构方向，包括利用cgroups实现精细资源隔离、提供无需root权限的用户级单元管理、统一可预测的硬件命名规范，以及采用防篡改的追加型二进制日志。对于未来演进，Rice建议进一步探索内核级RPC与结构化消息传输，将通信机制提升为操作系统的一等公民以提供更强大的访问控制与安全策略。 Rice呼吁开发者走出恐惧与敌意，承认现代操作系统对统一系统层的客观需求。与其盲目怀念古老的UNIX准则或对特定实现冷嘲热讽，技术社区更应探究systemd试图解决的核心架构难题，并在此基础上设计出更优良的解决方案。

Detailed notes — zh

## Background 该视频由频道 linux.conf.au 于 2019 年 1 月 24 日发布在 YouTube 平台上，记录了 Benno Rice 在该年度开源技术大会上的同名演讲。作为一名 FreeBSD 开发者，讲者通过系统自举与 UNIX 发展史的演进脉络，深入探究了 systemd 在 Linux 生态中引发巨大争议的技术与社会学诱因。 ## TL;DR Benno Rice 借用古典戏剧的“五幕剧”结构，复盘了从 1979 年传统 UNIX init、inetd 到苹果 launchd 的服务管理演进史，阐明现代操作系统向事件驱动与动态“系统层”整合的必然性。他客观反驳了关于 systemd 违背 Unix 哲学、单体化及代码缺陷的常见指责，并指出 cgroups 等 Linux 专有特性的采用标志着计算生态已由病态多样性走向病态单一文化。演讲最后深刻剖析了技术变革引发的心理抵触与社区中弥漫的“蔑视文化”，呼吁开发者摒弃盲目敌意，在反思系统消息总线与架构演进的同时重拾同理心。 ## Atmosphere & style 整场演讲呈现出幽默自嘲却又极其理性的反思基调，Benno Rice 以一名“局外”FreeBSD 开发者的超然视角，在尖锐揭示技术痛点与调侃老派极客心理之间游刃有余。现场氛围在轻松笑声与深层沉思中交替推进，既有解构争议时直言不讳的锋芒，也有触及人身攻击与社区撕裂时的严肃与诚挚。整场分享如同一场充满思辨意味的戏剧性“心理治疗”，带领听众在技术阵营的激烈对立中寻找认知的净化与释怀。 ## Bulletin - [13:45](https://www.youtube.com/watch?v=o_AIw9bGogo&t=825s) FreeBSD 开发者 Benno Rice 在 linux.conf.au 上剖析 systemd 争议，指出其并非简单的 init 替换，而是一个介于内核与应用层之间的统一“系统层”解决方案。 - [04:20](https://www.youtube.com/watch?v=o_AIw9bGogo&t=260s) 传统 UNIX 依赖 Shell 脚本和 inetd 的静态引导机制早已无法适应高并发常驻服务与动态硬件环境，现代服务编排必须转向事件驱动和按需拉起模型。 - [09:21](https://www.youtube.com/watch?v=o_AIw9bGogo&t=561s) systemd 的核心架构灵感主要源自苹果的 macOS launchd，并通过深度绑定 Linux 独有的 cgroups 等非 POSIX 特性实现了精准的资源控制与生命周期管理。 - [25:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1512s) 社区对 systemd 的激烈反对混合了极客对外部强加变革的本能抵触、开源“蔑视文化”以及主导者缺乏同理心的沟通方式，而非单纯的技术优劣之争。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=o_AIw9bGogo&t=0s) 演讲借鉴 Aurynn Shaw 的《蔑视文化》，指出技术社区常通过抱团嘲弄其他技术来维系身份认同，systemd 相关的舆论战正是这一现象的典型体现。 - [01:48](https://www.youtube.com/watch?v=o_AIw9bGogo&t=108s) 传统 Version 7 UNIX 的 init 职责极其粗暴极简，仅负责挂载文件系统、执行 /etc/rc 并拉起终端 getty，缺乏对长期运行服务的生命周期管理。 - [04:20](https://www.youtube.com/watch?v=o_AIw9bGogo&t=260s) Web 与数据库等有状态持久服务的兴起，使传统基于 inetd“一次连接 fork 一次”的瞬时模型彻底失效，催生了对持续服务监管机制的需求。 - [06:40](https://www.youtube.com/watch?v=o_AIw9bGogo&t=400s) 传统 UNIX 启动脚本长期混淆了“系统配置（一次性静态构型）”与“服务监管（长程动态守护）”，而 Windows NT 与 macOS 很早就厘清了这一边界。 - [09:21](https://www.youtube.com/watch?v=o_AIw9bGogo&t=561s) 苹果 Mac OS X Tiger 引入的 launchd 统一整合了 init、cron、at 与 inetd，首创了基于事件驱动和 Mach 端口/套接字按需唤醒的现代自举机制。 - [10:49](https://www.youtube.com/watch?v=o_AIw9bGogo&t=649s) systemd 在很大程度上借鉴了 launchd 的哲学，确立了“少启动、多并行启动”的设计原则，以动态事件响应取代传统的静态引导流程。 - [13:45](https://www.youtube.com/watch?v=o_AIw9bGogo&t=825s) 现代操作系统不仅由内核与用户态构成，还诞生了由 NetworkManager、udev 等构成的“系统层”，systemd 的扩张本质上是填补了 Linux 缺失的统一系统层。 - [16:08](https://www.youtube.com/watch?v=o_AIw9bGogo&t=968s) Debian 在经历漫长激烈争辩后采纳 systemd，导致多名技术委员会成员辞职，成为开源治理史上最具分裂性的事件之一。 - [17:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1038s) 针对 systemd 违背 Unix 哲学的指责，Benno Rice 指出其并非单体二进制文件，而是采用单代码仓库（monorepo）管理的多组件集合，且具备合理的假死容错机制。 - [22:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1338s) 操作系统生态已从昔日 POSIX 时代的“病态多样性”走向以 Linux 为绝对主导的“病态单一文化”，FreeBSD 等传统系统已失去接口定义的话语权。 - [23:48](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1428s) systemd 放弃向旧 UNIX 标准妥协，直接利用 Linux 内核的 cgroups 实现精细化进程树控制，并提供了极其便捷的用户级 Unit 机制。 - [25:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1512s) 极客群体对变革往往抱有双重标准：崇尚自己发起的变动，但对外界强加的改变充满防备，将过时的 Shell 启动脚本视作不愿舍弃的安全毯。 - [26:56](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1616s) 围绕 systemd 的死亡威胁和人身攻击彻底越界，盲目嘲弄与拒绝吸收其优秀理念只会阻碍其他开源操作系统的自我演进。 - [29:52](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1792s) 基于物理拓扑的可预测设备命名以及 journald 仅追加的二进制日志模型，为系统运维带来了宝贵的确定性与安全性。 - [36:17](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2177s) 将应用连同依赖打包为统一管理单元的容器机制，从根源上消除了“挑错动态链接库”的 DLL 地狱，并非倒退。 - [46:14](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2774s) 将类似 D-Bus 的消息传递机制下沉为内核级消息总线与 RPC，能够拉平系统通信层级并提供更强大的访问控制与安全特性。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=o_AIw9bGogo&t=0s) 引言、悲剧定义与“蔑视文化” 演讲在 linux.conf.au 上开场，Benno Rice 幽默地向观众打招呼，直言自己接下来要表达不少“主观观点”。他解释了讲座标题《The Tragedy of systemd》（systemd 的悲剧）的由来：在构思初期有了大致想法并定下标题后，整场演讲的脉络就自然浮现了。为了确立演讲的基调，他特意查阅了维基百科上关于“悲剧”（tragedy）的定义——“一种基于人类痛苦的戏剧形式，能够激发起观众相应的净化（catharsis）或快感”。他调侃道，围剿和争辩 systemd 的整个历程中，“痛苦”实在太多，绝对管饱，所以他希望能为台下的听众带来一些“快感”。 ```mermaid flowchart LR accTitle: Presentation Conceptual Influences accDescr: Three conceptual pillars forming the foundation of the talk about systemd. A["悲剧的戏剧定义 (痛苦与情感净化)"] --> D["演讲核心内核"] B["蔑视文化 (语言社区的社交符号)"] --> D C["对变革的抵触 (熟悉舒适 vs 时代适应性)"] --> D ``` 除了悲剧的定义，这场演讲还深受 Aurynn Shaw 的文章《蔑视文化》（Contempt Culture）的启发。Rice 强烈建议在场没读过的人都去拜读。该文的核心论点是：人们经常通过“蔑视他人”来构建身份认同和社交符号（social signifier）。虽然那篇文章主要聚焦于编程语言圈子里的鄙视链——例如 Python 社区冷嘲热讽 Perl 社区，Perl 社区反手嘲弄 PHP 社区，以此循环往复——但这种蔑视文化的内在逻辑在开源操作系统社区同样随处可见。最后，另一个贯穿演讲的核心概念是“变革”（change）。面对技术变革，人们本能会感到不安与抵触： > “Change is a tricky thing as change threatens what we find familiar, and familiar is nice, familiar is comfortable, but that doesn't always mean that it is good, and it certainly doesn't mean that it is still good now if it's been around for a long time.”（Benno Rice 谈技术演进与人们对旧习的迷恋） Rice 提到，有人曾告诉他经典的悲剧通常包含五个幕次，因此他的演讲也将分为五幕展开，首先从第一幕开始。 - **演讲背景**：Benno Rice 是 FreeBSD 开发者，他站在跨平台与操作系统演进史的视角来探讨 Linux 生态中 systemd 的纷争。 - **参考论著**：Aurynn Shaw 的《Contempt Culture》，揭示技术群体如何依靠“抱团蔑视”其他技术来维系群体认同。 - **演说结构**：全篇借用古典戏剧的“五幕剧”结构展开叙述。 --- ### [01:48](https://www.youtube.com/watch?v=o_AIw9bGogo&t=108s) 第一幕：UNIX 的诞生与极简的传统 init 第一幕开篇回顾了 UNIX 的起源。UNIX 并不是某个深谋远虑的产物，而是一个“快乐的意外”（happy accident）。如果它没有在那个特定的时代、特定的地点（贝尔实验室），以那种特定的偶然方式诞生，它绝不可能演变成今天的样子。当时的计算机系统臃肿且过度设计，UNIX 则是一种极端反弹——它选择“粗暴的极简”（brutally simple）。设计者抛弃了包揽一切的幻想，主张从小工具做起，积少成多，这种极度精简的理念也深刻影响了用户空间自举（bootstrapping userspace）的设计。 ```mermaid flowchart TD accTitle: Traditional UNIX Init Bootstrapping Flow accDescr: Execution sequence of traditional 7th Edition UNIX init handling bootstrapping and housekeeping. subgraph Boot ["内核自举末期"] K["Kernel Boot Procedure"] -->|"最后步骤唤起"| I["init (PID 1)"] end subgraph MultiUser ["进入多用户模式"] I -->|"执行脚本"| SH["/etc/rc Shell"] SH --> HK["管家职能 (Housekeeping) 挂载文件系统 + 启动 Daemon"] end subgraph Terminals ["终端监听"] I -->|"多次 fork"| TTY["控制台 / 电传打字机进程"] end ``` Rice 展示了 1979 年第七版 UNIX（Version 7 UNIX）中关于 `init` 的手册页（man page）。手册写道：`init` 在引导过程的最后一步被调用，其主要职责是为每个终端创建进程；当进入多用户状态时，它会唤起一个 shell，读取 `/etc/rc` 脚本执行“管家功能”（housekeeping functions），然后再为电传打字机（typewriter）等终端 fork 相应进程。Rice 特别圈出了手册里的“管家功能，如挂载文件系统和启动守护进程（daemons）”。随后，他展示了在运行第七版 UNIX 的 PDP-11/70 实机上的 `ps` 输出截图（特别感谢 Living Computers Museum and Labs 提供的真机环境）。在那个年代，系统运行的任务极为稀少：`init` 仅仅 fork 了几次用于管理终端，此外只有负责定时调度任务的 `cron`，以及定期将文件系统超级块刷入磁盘以防丢失的 `update` 守护进程。接着他又展示了一台运行 4.3BSD 的 VAX-11/730 的 `ps` 截图，二者几乎没有本质变化，唯一显著的演进是出现了用于处理串行控制台的成熟 `getty`（Rice 调侃年轻人应该回家问问祖父母 getty 是干什么的），以及用于网络连接的 `routed`、`inetd` 和若干 `telnetd` 进程。 - **Version 7 UNIX (1979)**：手册正式界定了 `init` 的职责边界——多用户脚本启动与终端创建。 - **极简进程快照**：PDP-11/70 的系统内只有寥寥数个基础程序（`init`、`cron`、`update`）。 - **历史硬件访问**：演示截图依托西雅图 Living Computers Museum and Labs 维护的历史真机。 --- ### [04:20](https://www.youtube.com/watch?v=o_AIw9bGogo&t=260s) 互联网浪潮、inetd 局限与“服务”概念的诞生 `inetd` 的出现曾经是一个天才设计，堪称“超级守护进程”（service super-daemon）。它的工作模式极度轻量：统一监听所有可能发生网络连接的端口与套接字，当有新连接进入时，才按需 `fork` 出来一个对应进程（如 `telnetd`、`ftpd`）与客户端通信。这套机制在互联网早期运转良好，因为当时 Telnet 和 FTP 的流量非常低，会话基本上是无状态的（ephemeral）；如果网络连接中断，用户重新建立连接并重新恢复状态即可，不需要系统常驻大量进程。然而，随着互联网和万维网（Web）的真正爆发，这种“一个连接 fork 一次”的模型彻底垮塌了。频繁创建进程的开销无法应对海量并发；更棘手的是数据库这类重量级有状态组件的普及——数据库维护着庞大的内存持久化状态，绝不能在连接断开后就随之退出。于是，“服务”（service）这一概念逐步取代了传统松散的“守护进程”（daemon）。服务往往是一组连续运行、协同工作的进程集合，而传统的 UNIX `init` 系统只管启动脚本，把进程拉起来后便撒手不管： > “Old-school init can start these things, but they don't really get involved with managing them after that, they just kind of stand them up and then walk off and if it falls over, they go [shrugs].”（Benno Rice 批评传统 init 缺乏持续生命周期管理）即便后来 System V 引入了 `inittab`，提供了一定的进程崩溃自动重启能力，但传统的重启机制原本只是给挂掉的终端 `getty` 设计的，它对现代复杂服务的监控粒度依旧极其粗糙，无法处理复杂的依赖关系和级联故障。 - **inetd 的设计初衷**：基于套接字按需动态 fork，节约宝贵内存，适应瞬时无状态连接。 - **Web 与数据库的冲击**：高并发连接使得 fork 成本无法承受；长生命周期与内存状态需要服务常驻。 - **“服务”（Service）的定义**：相比单个独立守护进程，服务往往指由多个子进程或进程集群组成的有机整体。 --- ### [06:40](https://www.youtube.com/watch?v=o_AIw9bGogo&t=400s) 配置与自举的混淆，以及 Windows 和 Apple 的服务体系启示 Rice 剖析了传统 UNIX 启动逻辑中长期存在的一个底层认知偏差：将“挂载文件系统”与“启动守护进程”混为一谈。他指出，这两者在本质上完全是两码事： | 职责类型 | 概念定义与类比 | 典型操作 | 传统处理问题 | |:--- |:--- |:--- |:--- | | **系统配置 (System Configuration)** | 类似飞行员降落前调整襟翼与缝翼，将飞机调整至“降落构型”；设定好后长期保持不变（set-and-forget）。 | 挂载文件系统、配置网络接口 IP、载入驱动。 | 传统 `/etc/rc` 脚本将这些一次性状态设定与长期运行的服务进程混杂在一起，阻碍了自动化服务编排。 | | **服务自举与监管 (Service Bootstrap & Management)** | 需要拉起常驻业务进程，并对其生命周期（健康监测、重启、崩溃处理）进行动态管理。 | 启动 Web 服务器、启动持久化数据库集群。 | 传统 init 把脚本逐行跑完后就失去控制，无法感知后续服务进程的生死状态。 | 在 UNIX 社区墨守成规时，其他非 UNIX 阵营的操作系统早早探索了更为先进的服务管理机制。Windows NT 从最初设计起就具备成熟健壮的服务模型（尽管 `svchost.exe` 的设计在后来引发过很多安全与权限缺陷），它从诞生起就原生支持服务的启停、健康检查与自动重启。这源于 Windows NT 继承自 VMS 等被早期 UNIX 视为“过度复杂”的系统血统。 ```mermaid flowchart TD accTitle: macOS launchd Unified Architecture accDescr: How launchd replaced legacy UNIX daemons into a unified event-driven system service framework. subgraph Legacy ["被 launchd 彻底取代的旧守护组件"] L1["init (PID 1)"] L2["cron / at (定时调度)"] L3["inetd (套接字监听)"] end subgraph Launchd ["launchd 统一事件中枢"] LD["launchd 核心监管引擎"] end subgraph Triggers ["按需触发唤醒源"] T1["TCP / UDP 端口请求"] T2["UNIX Domain Sockets"] T3["Mach Ports IPC"] end Legacy -.->|"统一并入"| LD T1 -->|"按需唤起"| LD T2 -->|"按需唤起"| LD T3 -->|"按需唤起"| LD LD -->|"延迟/按需生成"| Svc["具体系统服务守护进程"] ``` 另一条更为现代且优秀的路线来自于苹果的 macOS（以及后续的 iOS、watchOS、tvOS 等生态）。苹果的应用模型拥有极富弹性的宿主交互能力：应用程序通过 Application Delegate 监听来自宿主环境的系统生命周期事件（例如“系统正在低内存告警，请立即释放资源否则将被杀掉”）。更关键的是，苹果在 Mac OS X Tiger 中推出了 `launchd`，这直接开启了 Rice 讲座的“第二幕”。 - **启动语义混淆**：传统 UNIX 将静态的硬件/网络构型与动态的长程服务进程揉死在同一个平铺脚本流中。 - **Windows NT 服务**：自 1993 年发布伊始便具备完整生命周期监控与自动化重启体系。 - **macOS 与 iOS 委托模式**：宿主操作系统主动向下通知应用内存、电源与启停状态，形成双向协同管理。 --- ### [09:21](https://www.youtube.com/watch?v=o_AIw9bGogo&t=561s) 第二幕：launchd 的颠覆式创新与按需启动哲学第二幕正式开始探讨现代服务管理器的原型。Rice 提出反思：“深入到底层来看，systemd 究竟是什么？”为了说清 systemd，必须先理解苹果的 `launchd`。在 Mac OS X Tiger（10.4）中，苹果引入了 `launchd`，以前所未有的速度接管了操作系统内几乎所有处理事件的传统组件。它直接取代了老旧的 `init`、`cron`、`at` 以及 `inetd`。 `launchd` 吸收并大幅扩展了 `inetd` 的思想：现代操作系统里充满了为系统整体提供支撑的各种守护进程，但在系统刚开机时，绝大多数服务根本没有必要一直常驻在内存中占用资源，而只需要在真正产生交互需求时才被调用。`launchd` 不仅能够监听网络 TCP 端口和本地 UNIX 套接字，更直接深入到了微内核层级的 Mach ports。它接管了所有系统通信入口，将这些守护进程的启动完全变成“按需唤起”。这种设计带来两个颠覆性的结果：第一，系统引导时无需在串行阻塞的脚本里按序启动数十个守护进程，开机自举速度呈现出数量级的提升；第二，`launchd` 成为统管全局的超级进程监视器（supervisor），一旦某个服务在运行过程中异常崩溃，它能迅速捕获并进行可靠的原地拉起重启。苹果借由 `launchd` 证明了一点：一个现代操作系统的大部分底层系统服务，完全可以且应当解耦为由统一中心调度器所纳管的、响应事件按需启动的微型守护进程体系。这一思想为后来 Linux 社区 Upstart 和 systemd 的设计直接埋下了火种。 - **组件整合**：`launchd` 一举消除掉功能割裂的 `init`、`cron`、`at`、`inetd`，将事件调度收束归一。 - **多类型套接字唤醒**：全面支持 UNIX 套接字、网络端口及苹果特有的 Mach ports 拦截。 - **极速自举机制**：通过延迟按需唤醒（lazy-load daemons），彻底解决了启动期串行等待与资源抢占问题。 ### [10:49](https://www.youtube.com/watch?v=o_AIw9bGogo&t=649s) 借鉴 launchd：从服务按需启动到事件驱动模型在探讨现代操作系统启动机制时，Benno Rice 指出 macOS 的做法极具启发性。在 macOS 上，服务只有在真正被请求时才会被拉起，这不仅显著缩短了开机时间、降低了功耗，还通过细粒度的权限控制提升了系统安全性。苹果之所以能做到这一点，是因为其底层广泛使用了 Mach 端口（Mach ports）和高度统一的消息传递机制。作为一名 FreeBSD 开发者，Benno Rice 经常在 BSD 会议上遇到对 systemd 怨声载道的同行，而当这些人声称“为什么我们不用 launchd 呢”时，他总会直截了当地指出：systemd 本质上就是在很大程度上借鉴了 launchd。大约在 launchd 问世 5 年后，Lennart Poettering 开始审视 Canonical 为 Ubuntu 开发的早期启动机制 Upstart 等方案。虽然 Upstart 也像 launchd 和后来的 systemd 一样基于事件驱动，并能处理比传统 SysVinit 更多的系统事件，但它依然依赖 Shell 脚本，且在依赖关系排序（dependency ordering）方面存在明显不足。随后，Lennart 在其著名的博客文章中正式提出了 systemd 的设计构想与背后原理。正如 Benno Rice 引用 Lennart Poettering 的原文所言：“对于快速高效的引导，有两点至关重要：少启动，以及更多地并行启动。”（“For a fast and efficient boot up, two things are critical: to start less, and to start more in parallel.”）现代操作系统运行在一个远比过去更加动态的环境中，即使是运行在服务器或虚拟机上的系统也不例外。大量的硬件与软件变动都会化作事件涌入系统，需要被即时响应。因此，启动机制必须从“系统引导自检（bootstrap）”这一静态视角，转向“处理事件”的动态模型。Benno Rice 强调，Lennart 在博客中直接将 launchd 列为灵感来源；从 Lennart 此前的项目（如对标苹果 Bonjour 的 Avahi，以及直接与苹果 Core Audio 比较的 PulseAudio）也可以看出，他非常欣赏苹果的很多设计思路，即使他不一定完全赞同苹果的具体实现代码。 ```mermaid flowchart TD accTitle: 系统启动机制演进图 accDescr: 展示从静态引导到基于事件驱动并按需启动的演进路径 subgraph Legacy["传统机制"] SysV["SysVinit (静态脚本 / 串行执行)"] end subgraph EventDriven["事件驱动模型"] LaunchD["Apple launchd (Mach 端口 / 按需拉起)"] Upstart["Ubuntu Upstart (事件驱动 / 仍依赖 Shell)"] SystemD["systemd (并行启动 / 依赖拓扑 / 监听硬件软件事件)"] end SysV -->|"痛点：慢、静态"| Upstart LaunchD -.->|"架构灵感"| SystemD Upstart -->|"弥补依赖管理不足"| SystemD ``` --- ### [13:45](https://www.youtube.com/watch?v=o_AIw9bGogo&t=825s) “系统层”的诞生：从服务管理器到系统管理器随着 systemd 的迅速演进，它从最初单纯的 init 替代方案，迅速膨胀并接管了越来越多的系统职能。Benno Rice 认为这一扩展在逻辑上非常自然：当一个组件致力于响应所有系统级事件时，它必然会走向对全系统状态的统揽。许多人习惯于将操作系统简单划分为用户空间（userspace）和内核（kernel）两层，认为内核只负责底层硬件与 TCP 栈，用户空间只运行各种守护进程（daemons）。但在现代架构下，大量原本在内核中固定的静态配置都已经彻底动态化。 Benno Rice 回忆起早年自己编译 FreeBSD 内核的经历，当时甚至需要手动硬编码指定某块板卡插在哪个插槽、占用哪个 IRQ 中断号；而如今，硬件、网络（DHCP、IPv6 无状态自动配置）、系统时钟以及设备热插拔都处于高度动态的变化之中。如果管理员依然依靠拼凑 15 个来自不同上游、配置语法各异、行为模式完全不同的独立软件包来管理这些动态特性，系统维护将变得痛苦不堪。这催生了 Benno Rice 所定义的“系统层（system layer）”——它介于内核与上层应用程序之间，可能部分运行在用户态，部分依赖内核接口，专门负责打通并提供系统级的基础服务（如 NetworkManager、udev 等）。 systemd 项目正是通过向 Linux 内核补充这一整套用户态系统层，填补了现代 Linux 发行版的空白。虽然这种大一统的做法与习惯了旧模式的系统管理员格格不入，并引发了巨大争议，但它确实终结了各个发行版各自拼凑不兼容工具链的混乱局面。 - **内核静态向动态的变迁**：硬件中断与插槽分配从手动配置转变为全自动热插拔探测； - **网络状态的高度动态化**：从静态 IP 转向 DHCP 租约即时刷新与 IPv6 自动配置； - **系统层整合**：通过单一项目提供统一的配置格式与行为逻辑，避免多组件拼装带来的撕裂感。 --- ### [16:08](https://www.youtube.com/watch?v=o_AIw9bGogo&t=968s) 发行版的大规模采纳与 Debian 的痛苦抉择尽管面临争议，systemd 依然在极短的时间内席卷了各大主流 Linux 发行版，占据了 Linux 既有安装基数的绝大部分。在各个发行版的采纳时间线上，Fedora、Arch Linux、openSUSE、Red Hat Enterprise Linux、CentOS 以及 Ubuntu 纷纷转向 systemd。其中，Debian 对 systemd 的采纳过程尤为漫长且激烈。Debian 不仅支持 Linux 内核，还维护着基于 FreeBSD 内核的发行版本（Debian GNU/kFreeBSD），这使得切换到一个强绑定 Linux 内核特性的 init 系统面临巨大的技术与哲学障碍。Debian 技术委员会（Technical Committee）围绕这一议题展开了旷日持久的争论，各方各执一词，矛盾激化。正如 Benno Rice 所描述的那样：“极其糟糕的是，他们最终决定采纳它，但许多主导这场讨论的人最终都辞职了。”（“The really nasty bit is that they ended up going with it, but a lot of the people involved in steering that discussion ended up resigning.”）这一事件成为了开源治理史上最具分裂性的戏剧性节点之一。 --- ### [17:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1038s) 针对 systemd 的常见反驳：Unix 哲学、臃肿与代码缺陷针对社区中指责 systemd 的主流论调，Benno Rice 逐一进行了拆解与分析。首当其冲的指责是“systemd 违背了 Unix 哲学（即做好一件事）”。许多人想当然地认为 systemd 是一个巨大的单体可执行文件，但 Benno Rice 指出，如果真有人把 DHCP 客户端、NTP 客户端和 init 系统硬塞进一个二进制文件里，那确实愚蠢至极；然而 systemd 实际上是由许多个独立的二进制组件构成的集合。作为一个 BSD 开发者，他非常理解将分散的代码统一放在一个单体代码仓库（monorepo）中进行集中管理的设计选择。第二个常见指责是“臃肿与单体化（bloated and monolithic）”。对于它吸纳整合其他项目功能的做法，Benno Rice 表示理解反对者的不适，但从构建一致性系统层的角度来看，这种整合也是合理的。第三个指责则是关于“缺陷频出（buggy）”。任何软件都有 bug，而 systemd 身处核心地位，其缺陷必然会被无限放大。社区中甚至出现了一种苛刻的标准，即认为写 init 系统必须达到绝对零 bug 才能被接受，Benno Rice 认为这种要求极其不切实际，人为抬高了替换老旧代码的门槛。事实上，systemd 拥有相对合理的容错退化机制：在遇到未捕获异常时，它往往会进入假死（catatonic）状态而非直接崩溃导致内核崩溃（Kernel Panic），从而为管理员保留了选择在何种时机重启系统的余地。谈及安全性与软件缺陷时，Benno Rice 提到了 journald 曾爆出的一起由于在栈上分配内存而导致代码执行的严重安全漏洞。当时安全研究员 Matthew Garrett 发帖评论道：“在我看来，教训不是不要用 systemd，教训是也许在这些底层组件上不要再用 C 语言了。”随后有人反唇相讥坚称“教训就是不要用 systemd”。对此，Matthew Garrett 直接发出了 OpenLDAP 首席架构师 Howard Chu 维护项目的历史 CVE 漏洞列表作为回击。Benno Rice 借此强调，所有软件都会有 bug，有的甚至非常严重（例如在栈上分配动态内存），但在批判时必须将“systemd 的具体代码实现”与“systemd 代表的一整套架构理念”严格区分开来。 --- ### [20:26](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1226s) 个人意志与争议：Lennart Poettering 的强硬推进在反 systemd 的舆论中，对 Lennart Poettering 个人行事风格的抨击也是一个绕不开的焦点。Benno Rice 明确表示自己并不会为 Lennart 在社区交流沟通中的态度进行辩护，但他对 Lennart 所展现出的意志力表达了高度赞赏。试想这样一个场景：一个开发者在工作日突然萌生想法，决定自己写一套全新的 init 系统，随后意识到这不仅是 init，更是一套针对 Linux 的完整系统层。当他将这个激进的构想提交给管理层时，管理层直接回绝了；但他毫无退缩之意，依然硬生生地将其写了出来并成功运行，最终将其推向了几乎每一个主流 Linux 发行版。Benno Rice 直言，无论人们多么反感 Lennart 在 GitHub Issue 跟踪器上的言论和态度，这种凭一己之力撬动整个 Linux 生态的魄力与执行力，都是令人不得不佩服的。 --- ### [21:20](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1280s) 平台不可移植性与“Unix 已死”的技术现实最后一个让作为资深 FreeBSD 开发者的 Benno Rice 尤为在意的批评，是 systemd 的“不可移植性（not portable）”。systemd 采用了极其激进的 Linux 独占策略，深度依赖大量特定于 Linux 内核的机制与钩子接口（hooks），这些特性在 FreeBSD、NetBSD 或 Solaris 上完全不存在。这意味着一旦 systemd 成为事实上的通用服务管理标准，其他非 Linux 类 Unix 操作系统将面临被严重孤立、难以适配主流软件生态的巨大风险。然而，Benno Rice 也客观地指出，systemd 正是通过绑定这些特定于 Linux 的底层能力，才获得了诸多至关重要的现代系统功能，其中最具代表性的便是 Linux 的控制组机制（cgroups）。尽管批评者总在呼吁应该坚持使用更通用的经典 Unix 接口来实现这些能力，但 Benno Rice 抛出了一个极其残酷的技术现实：正如他所断言的那样，“但现实是，Unix 已经死了。”（“but the reality is that UNIX is dead so UNIX was”）经典 Unix 的技术形态早已无法满足现代计算环境对动态控制的需求。 ### [22:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1338s) 从病态多样性走向病态单一文化：Linux 与 UNIX 接口格局的剧变回顾 UNIX 的历史，POSIX 最初出现的核心动力，是为了在极端混乱且“病态多样化”（pathologically diverse）的硬件与操作系统平台上维持代码的可移植性。在那个时代，如果你在 VAX 架构的 4.3 BSD 上编写了一段代码，你同样希望它能无缝运行在 SunOS、AIX 以及当时被称为 Digital UNIX 的系统上。各大厂商与社区必须坐下来共同协商并达成标准。然而时过境迁，当今的操作系统版图发生了根本性的剧变。 Benno Rice 直言不讳地指出当前的市场现实：“我认为现在基本上只剩 Linux 和一些微不足道的误差了（I think you've basically got Linux and some rounding errors）。”虽然他对台下的 Solaris 铁粉表达了歉意，并坦言自己将大半职业生涯和心血都奉献给了 FreeBSD，但他承认 FreeBSD 已经彻底失去了接口定义的话语权。如今，如果 FreeBSD 跑去提议“等等，我们应该用这种接口形式”，整个 Linux 社区的反应只会是毫不在意地回一句“哦，我才不管”。相反，Linux 拥有绝对的统治力来宣称：“这就是 cgroups，要么用，要么滚蛋。”这种力量对比，标志着整个计算生态从当年的病态多样性转变成了一种“病态单一文化”（pathological monoculture），单一平台已经能够单方面主导行业规范与游戏规则。 - **POSIX 的初衷**：在 4.3 BSD、SunOS、AIX、Digital UNIX 等巨大陆续并存的 UNIX 衍生系统之间维持代码的可移植性。 - **话语权的倒错**：Linux 凭借压倒性的生态体量成为绝对事实标准，FreeBSD 等传统 UNIX 系统失去了制约或引导接口设计的能力。 - **跨平台约束的解绑**：Linux 与 systemd 不再受制于“传统 UNIX 会怎么看”这一历史包袱，能够直接利用非传统 UNIX 的底层特性大步向前。 ### [23:48](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1428s) 非 UNIX 特性的红利：cgroups 的粒度控制与用户级 Unit 的便捷性 systemd 之所以能够取得如此大的突破，正是因为它果断拥抱了许多根本不属于传统 UNIX 规范的技术。Benno Rice 在早期演讲中就曾指出，这种局面其实并非纯粹的坏事；它反过来也解放了 FreeBSD 等其他系统——既然 Linux 敢于大刀阔斧，其他项目同样可以放下对“传统 UNIX 标准”的瞻前顾后，自由去构建自己想要的底层机制。在这些非 UNIX 特性中，Linux 的 cgroups 是 Benno Rice 反复赞赏的利器。虽然 FreeBSD 早在多年前就率先发明了 jails，但在他看来，jails 在进程分组和资源控制的灵活性与细粒度层面上，完全无法与 cgroups 相媲美。此外，systemd 真正做对的另一大设计是“用户级 Unit”（user-level units）。以往在 FreeBSD 或传统系统上，如果你想以普通用户身份启动并维护一个后台守护进程，过程极其繁琐痛苦：用户通常必须编写一堆 Shell 脚本，然后通过 `sudo` 或 `su` 切换身份来执行，或者被迫使用古怪别扭的 `cron` 定时任务技巧。而在 systemd 下，用户只需在个人主目录的特定文件夹中放置一个简单的配置文件，守护进程就能干净利落地随登录自动运行。 ```mermaid flowchart TD accTitle: Traditional UNIX vs systemd Service Management accDescr: Comparison of traditional shell script execution against systemd declarative control and cgroups integration. subgraph TRAD["传统 UNIX 方式"] direction TB A["Shell 启动脚本 (/etc/rc.d)"] --> B["逐行调用 sh 解释器"] B --> C["sudo / su 切换用户身份"] C --> D["难以追踪的派生子进程 (PID 文件)"] end subgraph SYSD["systemd 机制"] direction TB E["声明式 Unit 文件 (~/.config/systemd/user)"] --> F["systemd 用户实例调度"] F --> G["cgroups 原生进程树隔离"] G --> H["精确的生命周期监控与资源限制"] end ``` ### [25:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1512s) 技术变革与极客的矛盾心理：丢不掉的“旧毛毯”与缺乏同理心的对抗技术架构的更替必然带来巨幅的颠覆，而这正是 systemd 悲剧的核心诱因——人与变革之间那错综复杂的情感纽带。Benno Rice 幽默地剖析了技术极客的心理防线：“极客尤其是这样，我们与变革的关系复杂极了；我们爱死它了——只要这场变革是由我们亲手主导的（nerds especially have a really complicated relationship with change. We love it to pieces: change is awesome when we're the ones doing it）。”然而，一旦这种变动是由外界力量强加而来的，它在极客眼中瞬间就会变得“面目可疑”，并深刻威胁到大家视作理所当然的熟悉感。对于很多老派 UNIX 用户而言，他们成长并习惯的世界是清晰单纯的：内核拉起 init，init 运行 rc 脚本，rc 脚本按顺序执行一堆 Shell 脚本，然后整套系统跑起来。这种模式深植于大家的舒适区内。但 Benno Rice 尖锐地指出，依赖 Shell 脚本及其隐晦的执行次序来引导操作系统，就像是一条早该在二十年前就扔掉的“破旧安抚毛毯”（tired old blankie）。不幸的是，推动 systemd 这场颠覆性变革的关键人物是 Lennart Poettering，而 Lennart 在与被要求做出改变的用户群体进行沟通时，所表现出的同情心和包容力显得非常欠缺。 - **极客的双重标准**：由自己发起的改动是创新的突破，由他人推行的改动则是对既有秩序的冒犯和不可信的威胁。 - **脚本引导的局限**：Shell 脚本构成的启动链虽然直观易懂，但在现代系统的依赖管理、状态反馈和并行控制面前早已过时。 - **人际沟通的脱节**：变革推进者的强硬姿态与缺乏同理心，直接加剧了社区内部的对抗与抵触情绪。 ### [26:56](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1616s) 越界的戾气与社区的反思：从无脑抵触到探寻技术本质在缺乏同理心的双向刺激下，反对阵营的抵触演变成了极端的下意识反弹。Benno Rice 严肃地指出，针对开源软件作者进行人身攻击是绝对不能容忍的底线：“没有人有理由因为一款软件就向 Lennart Poettering 发送死亡威胁（No one needed to send death threats to Lennart Poettering over a piece of software）。”同时，除了这种极端仇恨，社区中广泛弥漫的轻蔑与傲慢同样极不可取。他在 BSDCan 大会上就曾向 FreeBSD 社区严词直言：FreeBSD 绝不能把“我们没有 systemd”当成一种值得骄傲的功绩，这实际上恰恰暴露了系统在某些维度的缺失。如果社区只是把 Linux 用户和 systemd 当作段子来嘲笑，甚至将“绝不改变”当作吸引新用户的旗号，本质上就是在拒绝迈向未来。面对颠覆性的软件，开发者无论喜欢与否，都应该沉下心思考深层次的问题：systemd 为什么会出现？它到底在解决什么痛点？如果现有方案不好，我们能否设计出更好的解决方案？甚至对于不服气的开发者而言，去亲手造一个更好的替代轮子，至少也能亲自体会其中的工程挑战与乐趣。 - **抵制极端言行**：死亡威胁与网络暴力是开源社区生态的恶性毒瘤，必须坚决予以谴责。 - **反思傲慢偏见**：将 systemd 仅仅视作嘲讽的靶子，会使得其他开源操作系统失去从优秀理念中吸取养分的机会。 - **年轻一代的技术代沟**：新一代入行的工程师习惯了基于 HTTP API 调配云端机器和基于容器思考架构，对传统 UNIX 的底层执念与老一代“灰胡子”工程师截然不同。 ### [29:52](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1792s) 剖析 systemd 的技术启示：消息总线、服务生命周期与统一硬件命名抛开派系纷争，从更高的系统架构层面来看，systemd 提供了许多极其宝贵且值得学习借鉴的工程实践： 1. **消息传输机制（Messaging Transports）**： systemd 重度依赖 D-Bus。尽管 Benno Rice 本人不喜欢 D-Bus，但他高度推崇统一消息传递机制的思想（如同苹果 macOS 使用 Mach 端口消息机制）。他向 BSD 开发者建议开发一套驻留在内核中的原生消息总线，以便提供更强的安全隔离、身份验证与访问控制。这种消息传输机制的核心意义在于充当“平滑器”（leveling mechanism），使得上层系统在调用 API 时无需在乎背后的服务究竟位于内核空间还是用户空间——开发者只需发出一条 API 请求命令网卡配置 IP，系统便能自动调度执行，消除无谓的用户态与内核态认知割裂。 2. **严谨的系统级服务生命周期**：与 Windows 诞生伊始便具备服务控制管理器、macOS 逐步演化出 launchd 类似，systemd 为 Linux 提供了原生的第一方服务生命周期管理，摆脱了以往在 OpenRC、runit、supervisord 等形态迥异的第三方工具之间打补丁的混乱局面。 3. **API 式自动化配置与容器支持**：无需再通过复杂的 Shell 脚本拼装系统调用，直接通过标准 API 驱动系统初始配置，这为嵌入式与专业系统设备商（如 OpenWrt 或 Benno Rice 曾任职的大型存储设备厂商）扫清了工程障碍。与此同时，结合 cgroups 实现的轻量级隔离容器，进一步大幅降低了构建专业设备平台和环境封装的门槛。 4. **基于物理属性的持久化设备命名**：尽管 Benno Rice 过去曾坚持 FreeBSD“每个以太网驱动都应使用独立设备名”的传统，同时他也反感当年 Solaris 硬盘采用的 `c0t0` 晦涩代号，但他明确肯定了 systemd 依据硬件物理拓扑属性生成设备名称的做法，认为这在混乱的现代硬件环境中确立了宝贵的确定性。 ### [033:51] 日志系统革新与“悲剧”引发的宣泄反思 Benno Rice 进一步阐述了他非常欣赏 systemd 的两个关键设计：可预测的设备命名以及先进的日志模型。传统的设备命名往往取决于硬件被系统检测到的随机顺序，而根据物理路径或总线拓扑命名要可靠得多。在日志方面，他明确指出：“二进制日志只要有配套工具来解析提取，就绝不是一件坏事。”特别是 journald 提供的仅追加（append-only）机制，结合将日志流式传输到远端服务器的能力，为系统运维带来了极高价值。伴随着容器化与现代基础设施的发展，现代应用程序的定义已彻底改变——程序不再只是单个二进制文件或启动其他子进程的单一主程序，而是一组封装在一起、作为一个整体单元进行统一管理的组件集合。这种模式极其强大。Benno Rice 设想，如果能在 Linux 上实现类似 macOS 平台的那种应用模型，让底层宿主系统能够向应用暴露更多运行状态的丰富反馈，程序便可根据宿主变化灵活响应。 ```mermaid flowchart LR accTitle: systemd 现代架构的核心价值 accDescr: 展示了稳定命名、安全日志以及容器化应用单元三大核心优势 subgraph Core["systemd 核心优势"] Dev["可预测设备命名 (基于拓扑/路径)"] Log["Journal 二进制日志 (仅追加/易于外送/专用工具)"] App["应用即管理单元 (容器化封装/宿主交互反馈)"] end Dev --> Benefit["消除了传统 Linux 初始化中的不确定性"] Log --> Benefit App --> Benefit ``` 话题随后回到讲座开篇引用的维基百科关于“悲剧”（Tragedy）的定义。悲剧的一个核心作用是给观众带来“宣泄”（Catharsis），即通过艺术作品激发怜悯与恐惧，从而实现情感的净化与释放。Benno Rice 诚挚地表示：“我希望这场演讲能够帮大家消除恐惧，尤其是消除对 systemd 以及对使用它的人的那种怜悯与成见。”现实世界时刻在变，技术人员不可能永远抵抗变革，更不仅限于软件领域；每个人都应该理性评估每一次改变，判断自己是否站在了技术发展正确的一边。在致谢下台前，他向在场的所有听众提出了一个挑战：“我挑战在座的各位：去看看 systemd，试着在里面找出至少一个你喜欢的特性，然后动手看看能不能自己去实现它。” - 设备按照稳定拓扑命名，终结了过去因热插拔或枚举顺序不同导致设备名随机漂移的困扰。 - 许多发行版在采纳 systemd 之前都曾尝试过其他替代方案，技术演进通常是先尝试并验证其可行性，而非盲目承诺。 --- ### [036:17] 问答开始：移植 launchd 的现实阻碍与容器“DLL 地狱”争议讲座进入现场提问环节。Benno Rice 笑着提醒大家确保提问是真正的“问题”，因为他以往在发表相关演说时，常有人把充满怒气的个人长篇批判（diatribe）包装成问题来发难。第一位提问者询问：既然苹果早已将 launchd 开源，将 launchd 移植到 Linux 上在技术上是否可行？这样做有什么优劣势？Benno Rice 直言不讳地指出，launchd 和 systemd 处于两个极端：“如果说 systemd 激进地针对 Linux 定制，那么 launchd 也是激进地针对 Apple 平台定制的。”launchd 深层依赖 Mach 消息端口（Mach ports）等 macOS 专有体系。苹果曾尝试增强其可移植性，甚至提出为 FreeBSD 提供 libdispatch（Grand Central Dispatch）的移植支持，但最终这一努力逐渐搁置了。苹果核心关注的是让它在自身生态内表现完美，这与 systemd 专注于挖掘 Linux 内核特性的动机如出一辙。第二位提问者质疑：演讲提到容器让应用作为独立单元被管理，但整个开源生态过去数十年都在精细打磨动态链接库（dynamic library）的共享管理，如今每个容器打包一切依赖的做法，是否正在倒退回 Windows 曾经臭名昭著的“DLL 地狱”（DLL Hell）？Benno Rice 对此给出了明确的反驳： > “在我看来，‘DLL 地狱’指的是系统里有五个不同版本的库，而你的应用程序总是挑中错误的那一个。” 他认为容器技术通过隔离环境，恰恰从机制上根除了这种“挑错库”的 DLL 地狱，其思路非常类似于 Go 语言通过静态编译链接所有依赖来避免外部版本冲突。不过他也承认，容器可能会带来另一种维度的复杂度，比如同一系统上可能同时运行着不同版本的多个容器实例。 - 苹果对 launchd 可移植性的探索最终因平台重心转移而不了了之，没有形成通用跨平台方案。 - 会场期间有听众现场邀请 Benno Rice 参加当年在葡萄牙里斯本举办的 Linux Plumbers Conference（LPC），并主持 systemd 微型分会（Microconference），提到 Kay Sievers 和 Lennart Poettering 也可能会出席。 --- ### [038:50] 心理寒蝉效应、FreeBSD 的系统层现状与架构整合考量现场一位听众提出，开源黑客往往自诩是引领变革的人，但轮到自己习以为常的底层环境被改变时却最难接受；鉴于此前社区对 systemd 的攻击极具敌意，这是否会导致寒蝉效应，让其他有新想法的人不敢站出来以免“被乱枪打鸟”？Benno Rice 坦承，触及这种核心系统级代码必然会引发极大的焦虑和阻力，Lennart Poettering 所承受的人身攻击确实会造成不良的示范效应。更关键的是，编写这类基础系统软件本身就比想象中要难得多。推行此类变革最棘手的地方往往不在代码本身，而在于管理那些你试图说服其接受变化的人群，这需要极高的社交手腕。Benno 自嘲在这方面做得也不够好，这也是为什么他当初试图在 FreeBSD 推动类似变革无果后，选择直接在 Keynote 大会上公开向大家“喊话”。接着，一位对 FreeBSD 感兴趣的 Linux 用户提问：FreeBSD 目前在下一代 init 系统上的探索进展如何？Benno Rice 解释，FreeBSD 目前有 OpenRC 项目负责一部分服务管理逻辑，但距离形成一个“全局系统层”（System Layer）的概念还有相当遥远的距离。对此他感到非常沮丧： > “在围绕此事的任何讨论中，让我深感沮丧的一点是，有太多人总是下意识地认为 systemd 的全部意义就只是启动和管理服务而已。” Benno Rice 强调，要真正做好这一层，必须具备全局视角的系统性设计（holistic intent），以确保各子系统交互的统一性和可管理性。 ```mermaid flowchart TD accTitle: systemd 架构演进思考 accDescr: 对比现实中直接合并组件的做法与理想中基于抽象 API 解耦的架构 subgraph Reality["现实路径：快速集成扩展"] A1["服务管理需求"] --> A2["发现网络/时钟等依赖痛点"] A2 --> A3["直接吸纳 NetworkManager / Timesyncd 等入项目统一维护"] end subgraph Ideal["反思架构：标准化系统层 API"] B1["明确服务管理核心"] --> B2["定义标准的系统管理 API 规范"] B2 --> B3["第三方实现时钟同步 API"] B2 --> B4["第三方实现网络配置 API"] end ``` 针对后续听众提问“systemd 吞并了过多传统独立系统服务是否合理”，Benno Rice 进行了一次深入的思想实验：如果 systemd 当初没有直接把网络管理、时间同步等组件吸纳进同一个代码仓库，而是致力于定义一套供外部服务交互的管理 API，那么今天完全可以由不同的模块化项目来实现这些接口。但他十分理解开发团队为何最终走上聚合之路：当开发者实际推进时，往往是发现一个痛点就顺手抓过来解决一个，“只有在你把所有东西都拉进来之后，你才会恍然大悟：哎呀，如果我们当初把接口定义得更完善一点，或许就能避免把它们全都塞进同一个项目了。” - 在嵌入式场景中，systemd 的优势在于其应对环境动态性的能力。当外设频繁热插拔时，统一的事件与 API 响应机制能极大减少开发者为嵌入式系统编写的胶水代码量。 - Benno Rice 透露他曾在 FreeBSD 开发者群体中做过类似分享，遭遇的唯一真正阻力是大家普遍表态：“我们赞同需要类似的东西，只要它不是 systemd 就行。”会场听众打趣提议移植 launchd 时，Benno 透露 FreeBSD 社区此前真有人尝试过并移植了 Mach 端口兼容层，因此这并不是玩笑。 - 针对提问者指出的“社区与 systemd 维护团队长期互不倾听、关系剑拔弩张”的治理死结，Benno Rice 直言这极其棘手，并推荐大家参考 Adam Harvey 关于语言版本升级演进与社区沟通的演讲以寻求借鉴。 ### [45:14](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2714s) 推动变革的沟通困境与系统作者与社区的紧张关系 Benno Rice 谈到了推动软件升级与变革时的沟通艺术。他指出，单纯用强硬手段告诫人们“不要那样做”往往收效甚微，关键在于必须同时给用户提供充分的理由，让他们心甘情愿地去接受改变。两者结合才是理想的方式。然而，Benno Rice 坦承自己虽然“完全是站在一无所知的局外人角度来说这番话”，但他非常能够理解 systemd 作者们所面临的极端压力。如果换作是他处在系统作者的位置上，面对社区里不同群体的各执一词——有人强烈要求 X、Y、Z 功能，另一拨人坚持要 A、B、C，还有第三方提出完全不同的主张，而这些需求中往往至少有五项彼此之间是直接冲突的——在如此严苛且混乱的约束条件下工作极其艰难。正因如此，Benno Rice 认为在面对这些铺天盖地又相互矛盾的诉求时，开发者很容易产生一种将所有人都骂走、彻底不予理睬的冲动。虽然他也承认这绝非正确的处理手段，但双方之间的裂痕确实已经形成。他认同提问者的看法，即目前 systemd 核心作者群体与开源社区之间的关系显得极度紧绷和充满摩擦（fraught）。对于如何化解这一僵局，Benno Rice 直言自己并没有灵丹妙药，但确信其解决之道必然需要社区与作者双方付出多得多的同理心与体谅。 > “I think I don't really know the right way for them to fix it but it probably involves a lot more a lot more sympathy on both sides to some attain to that.” —— Benno Rice - 推动技术升级的要诀在于兼顾“解释为什么要改变”与“明确指出不要再做什么”。 - systemd 开发者面对的社区诉求繁杂且大量互斥，造成了巨大的协调与维护压力。 - 开发者与社区之间目前充斥着对立情绪，修复这种紧张关系亟需双方更多的相互理解与同理心。 ### [46:14](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2774s) 对未来架构的期许：内核级消息总线与 RPC 在问答环节的最后，有观众提问 systemd 应该在哪些具体领域走得更远。Benno Rice 回应称，他非常希望看到系统消息传递（messaging）与远程过程调用（RPC）机制在整个架构中变得更加普遍且经过更深思熟虑的设计。他补充说明，虽然确信 systemd 团队本身已经在持续思考这套机制的运作方式，且此前社区也曾多次尝试将类似 D-Bus 风格的传输通道直接合并进 Linux 内核，但他坚信这一技术方向依旧充满潜力。 Benno Rice 解释道，即便最终实现的不是狭义上的 D-Bus，拥有一种直接置于内核中的统一消息传输层也将是一件非常有价值的技术探索。一方面，它能将系统中的大量代码拉平到同一个通信基准层级上；另一方面，直接在内核层面实现消息传递机制，还能为系统赋予更强大的控制力以及更加有趣的现代安全特性。随着这番回答结束，主持人在全场热烈的掌声中宣布问答时间耗尽，正式为演讲画上句号。 > “I think that having that even if it's not necessarily D bus would be a really interesting thing to play with because it puts a lot of code on the same level and it also allows a lot more yet control and interesting security features that you could do by having it in the kernel.” —— Benno Rice ```mermaid flowchart TD accTitle: 内核级消息总线架构优势 accDescr: 展示将类似 D-Bus 的消息传递机制下沉至内核所带来的系统架构与安全优势 subgraph UserSpace["用户空间组件"] ServiceA["系统服务 A"] ServiceB["系统服务 B"] SystemdCore["systemd 核心"] end subgraph KernelSpace["内核空间传输层"] KernelBus["内核级消息/RPC 传输机制 (D-Bus 风格通道)"] end ServiceA <--> KernelBus ServiceB <--> KernelBus SystemdCore <--> KernelBus KernelBus --> Adv1["统一抽象：将大量服务代码置于同一通信层级"] KernelBus --> Adv2["增强控制：系统组件间高效解耦与状态协同"] KernelBus --> Adv3["安全特性：由内核统一保障的安全隔离与权限控制"] ``` - Benno Rice 期待消息传递与 RPC 在系统设计中获得更广泛、更深入的应用。 - 业界曾多次尝试把类似 D-Bus 的总线机制推入 Linux 内核。 - 将消息传输下沉至内核层能够统一通信抽象，并带来更强大的控制粒度与安全性。 ## Notable quotes > [10:49](https://www.youtube.com/watch?v=o_AIw9bGogo&t=649s) For a fast and efficient boot up, two things are critical: to start less, and to start more in parallel. — Lennart Poettering > [17:18](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1038s) 在我看来，教训不是不要用 systemd，教训是也许在这些底层组件上不要再用 C 语言了。 — Matthew Garrett > [33:51](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2031s) 二进制日志只要有配套工具来解析提取，就绝不是一件坏事。 — Benno Rice > [00:00](https://www.youtube.com/watch?v=o_AIw9bGogo&t=0s) Change is a tricky thing as change threatens what we find familiar, and familiar is nice, familiar is comfortable, but that doesn't always mean that it is good, and it certainly doesn't mean that it is still good now if it's been around for a long time. — Benno Rice > [25:12](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1512s) nerds especially have a really complicated relationship with change. We love it to pieces: change is awesome when we're the ones doing it — Benno Rice > [26:56](https://www.youtube.com/watch?v=o_AIw9bGogo&t=1616s) No one needed to send death threats to Lennart Poettering over a piece of software — Benno Rice > [36:17](https://www.youtube.com/watch?v=o_AIw9bGogo&t=2177s) 如果说 systemd 激进地针对 Linux 定制，那么 launchd 也是激进地针对 Apple 平台定制的。 — Benno Rice ## Mentioned Benno Rice, Lennart Poettering, Aurynn Shaw, Matthew Garrett, Howard Chu, Kay Sievers, Adam Harvey, systemd, launchd, Upstart, FreeBSD, Debian, Ubuntu, macOS, Windows NT, Linux, UNIX, cgroups, D-Bus, journald, inetd, SysVinit, OpenRC, PDP-11/70, VAX-11/730, Living Computers Museum and Labs, linux.conf.au ## Video description Benno Rice https://2019.linux.conf.au/schedule/presentation/156/ systemd is, to put it mildly, controversial. As a FreeBSD developer I decided I wanted to know why. I delved into the history of bootstrap systems, and even the history of UNIX and other contemporary operating systems, to try and work out why something like systemd was seem as necessary, if not desirable. I also tried to work out why so many people found it so upsetting, annoying, or otherwise rage-inducing. Join me on a journey through the bootstrap process, the history of init, the reasons why change can be scary, and the discovery of a part of your OS you may not even know existed. linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see https://linux.conf.au/ #linux.conf.au #linux #foss #opensource [Source](https://www.youtube.com/watch?v=o_AIw9bGogo)

Source quotes

[10:49] Lennart Poettering: For a fast and efficient boot up, two things are critical: to start less, and to start more in parallel. [17:18] Matthew Garrett: 在我看来，教训不是不要用 systemd，教训是也许在这些底层组件上不要再用 C 语言了。 [33:51] Benno Rice: 二进制日志只要有配套工具来解析提取，就绝不是一件坏事。 [0:00] Benno Rice: Change is a tricky thing as change threatens what we find familiar, and familiar is nice, familiar is comfortable, but that doesn't always mean that it is good, and it certainly doesn't mean that it is still good now if it's been around for a long time. [25:12] Benno Rice: nerds especially have a really complicated relationship with change. We love it to pieces: change is awesome when we're the ones doing it [26:56] Benno Rice: No one needed to send death threats to Lennart Poettering over a piece of software [36:17] Benno Rice: 如果说 systemd 激进地针对 Linux 定制，那么 launchd 也是激进地针对 Apple 平台定制的。

Source quotes

[17:18] Benno Rice: There's an important distinction to be drawn between systemd the implementation and systemd as a set of ideas. [25:12] Benno Rice: Nerds especially have a really complicated relationship with change: we love it to pieces, change is awesome when we're the ones doing it. [10:49] Lennart Poettering: For a fast and efficient boot up, two things are critical: to start less and to start more in parallel. [20:26] Benno Rice: The reality is that UNIX is dead. [10:49] Lennart Poettering: An init system that is responsible for maintaining services needs to listen to hardware and software changes. [22:18] Benno Rice: These days I think you've basically got Linux and some rounding errors.

Original transcript

[0:00] right thanks everybody for coming and [0:02] please welcome dinner rice so I know [0:12] this may come as a shock to some of you [0:14] but I have opinions so this is one of [0:22] those talks where I started you know I [0:23] had a kind of idea and I came up with [0:25] the title and suddenly it all started to [0:26] really come into place because you know [0:29] especially when I looked up what tragedy [0:31] what wikipedia said the tragedy meant [0:33] which is a form of drama based on human [0:35] suffering that invokes an accompanying [0:37] catharsis or pleasure in audiences and I [0:39] figured that was enough suffering in [0:40] this whole subject to go around and you [0:42] know hopefully I can deliver some [0:44] pleasure on to my audience [0:46] another big influence on this talk is a [0:49] piece that everyone should have read by [0:51] now and if they haven't please go read [0:52] it it's by Oren sure it is called [0:55] contempt culture the gist of that piece [0:58] is that people use contempt as a social [1:02] signifier it's and the piece itself is [1:04] largely based around language [1:06] communities so the Python community rags [1:08] on the purl community and the purl [1:09] community rag on the pH of he community [1:11] and so on and so forth but a lot of the [1:14] concepts in it are largely applicable [1:15] outside of that and the last concept [1:18] that really fed into this talk was [1:20] change change is a tricky thing has [1:24] changed threatens what we find familiar [1:25] and familiar is nice familiar is [1:28] comfortable but that doesn't always mean [1:31] that it is good and it certainly doesn't [1:35] mean that it is still good now if it's [1:37] been around for a long time so someone [1:40] also told me that tragedies come in five [1:42] five acts so let's start with Act one so [1:48] in the beginning there was eunuchs well [1:52] there was a lot more before that but for [1:54] the purposes of this we're gonna start [1:56] with eunuchs eunuchs was a happy [2:00] accident if it had not happened at the [2:03] place that it did in the time than it [2:05] did in the way that it did it just would [2:07] not have turned into the thing that it [2:10] did [2:11] it was a reaction to a bunch of previous [2:13] systems in that it was brutally simple [2:15] they looked at a whole lot of the other [2:18] systems that were on offer at the time [2:19] and went you know what this is just [2:20] trying to do too much we can be better [2:22] than this we just start with the small [2:23] stuff and work from there and it takes [2:27] this brutally simple approach to [2:28] bootstrapping itself and especially in [2:32] bootstrapping user space this is the [2:34] manual page for a net it says in it is a [2:36] voted and last step is the boot [2:37] procedure generally its role is to [2:39] create a process for each type Pro [2:43] moving on when it comes up multi-user it [2:46] invokes a shell with input taken from [2:48] the file at housekeeping functions for [2:51] several times the creative process for [2:52] each type right [2:54] sorry that's seventh edition UNIX from [2:57] 1979 it you know it the thing is though [3:02] it still sounds pretty much like what [3:04] the old-school in it does but one thing [3:07] that you know I really bumped on when I [3:09] was reading through this is the phrase [3:11] housekeeping functions like mounting [3:13] file systems and starting daemons there [3:17] were two things that one I mean it it [3:20] would the main the main thing that [3:21] really got me on that was that they'd [3:23] lumped those two together and I'll get [3:24] back to that in a sec though but given [3:26] the context of what demons meant at that [3:28] time this is the PS output on PDP 1170 [3:33] running seventh edition unix as you can [3:36] see there's not much going on there in [3:39] it has been forked several times to two [3:41] actors four terminals or typewriters [3:45] you've got cron there and updates job is [3:47] to write this file system super block [3:48] out every once in a while so that it [3:50] doesn't go away and the things you know [3:54] it didn't change all that much over time [3:56] like this is VAX eleven seven thirty [3:58] running four point three bsd and as you [4:01] can see things haven't changed all that [4:03] much we've actually got a proper getty [4:05] there and for those who don't know getty [4:06] is the thing that handles serial [4:07] consoles which something you should ask [4:09] grandfather about or grandmother sorry [4:13] and it's got a route d in a nine eight d [4:16] and a couple of telnet DS and that's [4:18] kind of where things started to get [4:20] interesting because [4:23] I net D is was the kind of a service [4:27] super demon if you like its job was to [4:30] listen on all of the sockets that [4:31] something could connect on and fork off [4:33] a process to talk to it when it came [4:35] along and that worked really well up [4:37] until the internet happened just before [4:43] I move on [4:44] big thanks to the living computers [4:45] Museum and labs who gave me access to [4:47] those machines to get the the [4:49] screenshots they will also give you [4:50] access to if you ask them nicely I'm for [4:53] whatever you want to do on a PDP 1170 so [4:57] the internet happened that I net D model [5:03] was great when what you were doing was [5:05] dealing with a small amount of stuff [5:06] going on like the amount of traffic that [5:08] goes over a telnet connection is not [5:10] actually all that much and there's not a [5:11] lot of state going on that isn't [5:13] ephemeral if the connection drops then [5:15] you just reconnect and you get your [5:17] state back some other way same with FTP [5:19] same with pretty much everything that [5:21] dinette D handled the web looked like it [5:25] would work that way and then it became [5:28] really really really popular and so you [5:31] end up with situations where forking off [5:33] a process to handle every single [5:35] connection doesn't really scale that [5:37] well then you also get these rather [5:39] annoying things like databases where you [5:42] have a ton of persistent state and you [5:44] don't really want them to go away in [5:45] between in vacations and so this leads [5:48] us to what we know these days as a [5:51] service it's kind of a superset of a [5:54] daemon there quite often encompasses [5:56] multiple demons or a whole bunch of [5:58] clones of a demon or various various [6:00] things like that a contiguous set of [6:01] processes and behaviors and in it [6:04] old-school in it can start these things [6:07] but they don't really get involved with [6:09] managing them after that they just kind [6:10] of stand them up and then walk off and [6:12] if it falls over they go and even with [6:18] system five features like init tab which [6:20] can restart things because the only [6:23] thing that is the gets restarted [6:25] properly on old-school UNIX systems is [6:27] get E Getti will get restarted as [6:29] terminals come and go with system v init [6:32] tab let you specify other process to do [6:33] that but again it's just if this process [6:35] crash has restarted it's not particular [6:37] the granular and that's not the only [6:40] thing that in it and etc RC had to do so [6:44] coming back to this quote it conflates [6:47] mounting file systems and starting [6:49] daemons these I think are two separate [6:51] but very kind of related things one of [6:54] them is system configuration and by [6:57] configuration I don't mean editing files [6:58] in etc I mean like you know when when a [7:01] pilot lands a plane they put the plane [7:03] into a landing configuration with the [7:05] slats and the flaps and various settings [7:07] system configuration is making sure that [7:09] your file system is mounted that your [7:11] interface is configured these things are [7:12] kind of set and largely forget but it [7:15] conflates these with service bootstrap [7:17] which is start that daemon and then walk [7:21] off and don't care anymore [7:23] and this gets commingled in a bunch of [7:27] ways that we don't often see because [7:29] we're really familiar with it and it [7:33] really gets in the way of things like [7:35] automated service management because [7:39] that's not there in this set up and [7:42] that's where things like upstart and [7:45] system D start to show up because they [7:48] deal with the services that services [7:52] that need a more active management [7:57] before we move on to other things let's [7:59] look at some other operating systems [8:03] Windows NT had a very strong will has a [8:07] very strong service model that came with [8:09] it from the very start a lot of it was [8:12] based around a particular process called [8:14] SVC host which led to a whole bunch of [8:16] things like security issues and stuff [8:18] like that but in general its service [8:20] model including starting stopping [8:21] restarting auto restarting and all that [8:24] was there from the beginning [8:25] and a lot of this comes from it's sort [8:28] of heritage as being coming from one of [8:29] these way too complicated operating [8:31] systems the UNIX was railing against [8:33] another operating system that has a very [8:35] good service model at least these days [8:37] is Mac Oz and its derivatives like I [8:40] asked watched us TV us and car us and [8:42] whatever else is coming down the pipe [8:43] when they release stuff so Mac haces [8:47] application model also gives you a bunch [8:49] of interesting [8:50] stuff in that it allows you to have a [8:52] much richer interaction with your host [8:55] Mac OS and iOS applications generally [8:58] take the form of an application delegate [9:00] that receives a whole bunch of calls in [9:02] from a surrounding environment that [9:05] tells that the things are happening like [9:06] you started you're going to quit now [9:09] the system's running low on memory and [9:11] if you don't do something about it I'm [9:12] going to kill you things like that the [9:16] other thing that came out of Apple was [9:18] launch D which is a good point to go to [9:21] act - so what even is system D when you [9:32] actually get down to it so starting off [9:36] launch D launched he showed up in macaws [9:39] Tiger it rapidly took over most of their [9:42] the sort of service handling stuff in [9:45] Mac OS and it replaced almost every [9:48] single what I would call event handling [9:50] daemon in the entire system so it took [9:52] over in it it took over cron and at it [9:55] took over I net D and it expanded from [9:58] this I net D like concept to go hang on [10:00] I've got all of these sort of service [10:03] providing daemons that form part of the [10:06] system that don't need to be running all [10:09] the time but they need to be brought up [10:10] when we need them and so it can listen [10:13] on not only TCP ports and UNIX sockets [10:15] but also mark ports and things like that [10:17] so that it can start these service [10:19] demons as they're needed and once you've [10:22] got that you don't need to start them at [10:24] boot time and that speeds the whole [10:25] thing up [10:27] it also can restart things if they need [10:30] it if they do need to be started then it [10:31] can watch the process if the process [10:33] exits it restarts it great so the idea [10:37] of launch D was to move as many system [10:40] services as possible into these demons [10:42] that could then be started as needed [10:44] because when you think about it the [10:46] actual underlying system when you're [10:48] talking about a system like Mac or [10:49] Windows or even like Linux if you're [10:51] running a desktop spin with gnome or KDE [10:53] or something on it is a lot bigger than [10:56] you think so on Mac OS the services get [11:00] started with something asked for them [11:01] which means you improve boot times you [11:03] improve Parkins [11:04] sumption you can improve security by [11:06] making the access to these things [11:07] granular and Apple can do a lot of this [11:10] because it's got this pervasive use of [11:11] mark ports and messaging systems [11:13] underneath it that it can use to do this [11:16] one of the things that I pointed out [11:17] because this talk started out as a as a [11:20] keynote for BSD conference one of the [11:24] things that I'd like to point out here [11:25] is a lot of the bsd people who like to [11:27] gripe about systemd if you actually say [11:29] oh you could you could you know why do [11:31] we do launch it yeah like launch D and [11:34] it's like you realize that system D is [11:37] basically a ripoff of launch D right [11:40] because five years after launch D this [11:45] guy that no one's heard I've called [11:46] Leonard puttering was looking at upstart [11:49] and a couple other things and didn't [11:51] quite like what he saw up start which [11:54] was a an older startup mechanisms [11:58] usually used on Ubuntu I think it was [12:00] event-driven like launch day and system [12:01] D it still used shell scripts it could [12:05] handle more event types than an int [12:06] which is not hard but lennart seemed to [12:10] feel that it didn't do enough with [12:11] dependency ordering and had a bunch of [12:13] other things missing and so you can find [12:17] this blog post this is basically where [12:20] he introduced the notion of system D it [12:23] goes into detail about the rationale [12:24] behind it and so a couple of interesting [12:26] quotes for a fast and efficient boot up [12:29] two things are critical to start less [12:30] and to start more in parallel it doesn't [12:33] really go into it's not overly concerned [12:36] with boot speed but that sort of gets a [12:38] gets in and as a side thing and in its [12:42] system that is responsible for [12:43] maintaining services needs to listen to [12:45] hardware and software changes this is [12:47] exactly a kind of thing that the Mac OS [12:49] and iOS do really really well when you [12:54] are a modern operating system you live [12:55] in a much more dynamic environment and [12:57] yes even if you are running on a server [12:59] or a virtual machine then you used to [13:01] and a lot of these things need to be [13:03] dealt with and a lot of these things [13:04] come in as events that need to get [13:06] handled and so if you move from the [13:07] notion of system bootstrap to I'm going [13:10] to handle events then system D does that [13:14] really well and he literally sites [13:18] launched D as an inspiration in this is [13:20] this kind of logic new it is not it is [13:23] basically launched D and I get the [13:26] impression sort of from this that [13:28] Leonard Leonard likes a lot of what [13:30] Apple does even if he doesn't like their [13:32] implementations of it because his [13:34] previous projects before this were an [13:36] implementation of apples Bonjour system [13:37] and an audio system that he directly [13:39] compares to apples core audio so we've [13:45] kind of evolved here from a service [13:49] manager to a system manager and again [13:52] there's parallels with Apple here [13:54] because system D like even though it [13:57] started as an init system sort of [13:58] rapidly spiraled out and started taking [14:01] on other things which you know in one [14:04] way as a fairly logical reaction to this [14:05] we're going to react to system level [14:07] events but I think what they rapidly [14:09] came across is an idea that it took me a [14:11] while to again on to to a lot of people [14:15] think of a system as having two parts [14:18] user space and kernel you know the [14:21] kernel looks after the hardware and [14:22] things like your TCP stack and user [14:24] space runs daemons and whatnot but a lot [14:27] of things that used to be static in the [14:30] kernel are now a lot more dynamic I [14:32] still remember building my own FreeBSD [14:35] kernels and basically having to say this [14:37] card is on this is in this slot with [14:40] this irq and this kind of stuff and now [14:42] that's all dynamic and it can change a [14:45] lot more networking is a lot more [14:47] dynamic DHCP my pv6 Auto config all [14:50] these kind of things are more dynamic [14:52] time is more dynamic some aspects of [14:56] device handling you know all of these [14:58] things are a lot more dynamic now and we [15:00] need a way of strapping these things [15:02] together so we can manage them that [15:04] doesn't involve installing 15 different [15:06] packages that all behave differently and [15:08] so what that ends up becoming is what I [15:11] term the system layer which is a bunch [15:14] of stuff which might be running in user [15:17] space or might be running in kernel [15:19] space but is providing systemic level [15:21] stuff as opposed to the stuff that [15:23] you're writing or using directly so this [15:25] could include things like network [15:27] manager and you dev and a whole bunch of [15:30] things [15:32] and systemd as a project ends up [15:35] complementing the linux kernel by [15:36] providing all of this user space system [15:40] layer it doesn't do it in a way though [15:42] that is familiar to everybody who's used [15:45] to the old way of doing it and but it [15:49] does mean that people can stop [15:51] reinventing this by strapping together [15:53] 15 different disparate packages that all [15:55] have different configuration file [15:56] formats and different behaviors that can [16:00] be a possible source of angst but it [16:03] does sort of explain a bit better the [16:05] reason why you would inhale that other [16:08] functionality so how does this work in [16:12] reality so system they actually got [16:21] fairly widely adopted not universally [16:25] these are all of the the dates of which [16:28] system D entered particular [16:30] distributions and between these [16:32] distributions here you're covering like [16:35] the bulk of the installed base of Linux [16:38] I would suggest I don't know that for [16:41] sure but you know some will probably [16:43] come up and tell me if I'm wrong Debian [16:45] is an interesting one on that one [16:47] because they had a very long debate [16:48] about whether to take it in which was [16:53] understandable given that they have [16:54] multiple kernels that they run on the [16:56] you can get Debian on the FreeBSD kernel [16:58] if you so desire and there's a you know [17:03] there are a bunch of arguments there and [17:05] the really nasty bit is that they ended [17:08] up going with it but a lot of the people [17:10] involved in steering that discussion [17:12] ended up resigning and yeah so the next [17:18] bit that I want to go through is some of [17:19] the more common arguments against system [17:21] D that people tend to advance it [17:25] violates the UNIX philosophy this this [17:28] this one I often find is predicated on [17:30] the notion that system D is one binary [17:34] because you know if you were good if you [17:38] were to have a DHCP client and NTP [17:39] client you know that all in one binary [17:42] yes I would agree with you that that [17:43] would be a bit silly but it's not [17:45] a bunch of separate binaries that are [17:47] all in the one project and being a BSB [17:50] person I do kind of understand the [17:51] notion that you want to bring a bunch of [17:53] disparate code into one repository to [17:54] manage it centrally and the next one is [18:02] that it's bloated and monolithic again [18:05] it's not really a monolith I can kind of [18:07] understand why people get bent out of [18:09] shape that it's inhaling a bunch of [18:10] other projects functionality but I do [18:12] understand why they're doing it to some [18:14] extent and so you know I'm not [18:16] particularly worried about that it's [18:20] buggy its software the thing that the [18:30] thing is though that this argument comes [18:33] in a bunch of forms I mean yes system D [18:35] has bugs and yes they're going to stand [18:36] out because it is such a core component [18:38] to that level but they all they're also [18:41] seem to be a sub variant of this we're [18:43] like oh well if you're gonna write an [18:45] init you have to be you know this bug [18:47] free in order to drive which makes it [18:51] really raises the bar to replacing that [18:53] particular bit of code and I don't think [18:55] that's the right way to do it and I mean [19:00] that it also has a reasonably good [19:01] failure mode where just instead of [19:03] actually crashing and taking the system [19:05] down it'll go catatonic so you can at [19:06] least choose the point at which you [19:08] reboot but in general I mean I do [19:13] sympathize with some of the bugs [19:14] although there was a recently a rather [19:18] fun an instance where there was a bug in [19:21] Journal D that I believe led to code [19:23] execution some little-known hacker named [19:27] Matthew Garrett pointed out that in his [19:30] opinion at least the moral is don't use [19:32] system D the moral is you know maybe [19:34] don't use C for these things to which [19:38] there was a responsive of you know [19:40] actually it means don't use system D and [19:42] so on so forth [19:43] - which Matthew replied with this which [19:46] needs a little bit of explanation in [19:48] that Howard Chu is the chief architect [19:52] of the open LDAP rotate [19:55] and that link was to a list of CVS in [19:59] open LDAP all software has bugs some [20:04] bugs are gonna be security issues [20:06] systemd does have some fairly impressive [20:09] bugs like that Journal debug that were [20:11] allocating memory on the stack don't do [20:13] that but that said I think that there's [20:16] an important distinction to be drawn [20:18] between system D the implementation and [20:20] system D as a set of ideas on top of [20:26] that another another one that people [20:28] like to come up with is this one I'm not [20:32] going to defend limits approach to [20:35] community interaction but what I will [20:40] say is you know you have to admire the [20:44] willpower and determination of someone [20:46] who at work one day goes I'm gonna write [20:49] my own in its system actually know it's [20:51] going to be a full on system layer for [20:53] Linux and takes it to his management and [20:56] goes hey I'm gonna do this and they go [20:57] no and he goes no way and then he comes [21:02] back with it and it works and then he [21:05] gets it put into pretty much every major [21:07] Linux distribution there is something to [21:10] be impressed by in that even if you're [21:13] not impressed by his attitude on the [21:16] github bug tracker or whatever else [21:20] another one that is particularly [21:22] interesting to me is it's not portable [21:24] now this interest to me because for [21:26] those who don't know I'm a longtime [21:29] FreeBSD developer systemd is [21:32] aggressively Linux specific it uses a [21:37] whole bunch of Linux specific process [21:41] maintenance hooks that just aren't [21:43] present on other systems and so if it [21:46] becomes the sort of established way to [21:49] manage services it runs the risk of [21:50] isolating the other platforms that don't [21:52] have those things but it gains a bunch [21:58] of really important functionality from [21:59] those things cgroups is a really [22:02] interesting thing you could argue that [22:04] it should stick to more UNIX II [22:06] interfaces doing these things but the [22:08] reality is that UNIX is dead so UNIX was [22:18] all about maintaining portability across [22:20] a pathologically diverse range of [22:22] platforms when when the UNIX notion came [22:25] out when POSIX first showed up what it [22:27] was there for was to make it so that if [22:30] you wrote code on 4.3 BSD on your VAX [22:34] I don't know if POSIX was around at that [22:36] point but it was not too far off [22:37] it would also run on sun offs and ax and [22:42] whatever digital UNIX was called at that [22:45] point and so on and so forth like there [22:49] was just these enormous lis disparate [22:51] range of of UNIX platforms of things [22:53] could run on and so everyone kind of [22:55] needed to agree on how to do that these [22:58] days I think you've basically got Linux [23:02] and some rounding errors I'm sorry to [23:07] all of the Solaris devotees out there [23:09] and I'm saying this as someone who has [23:13] spent a large amount of his time and [23:14] knows a significant amount of his career [23:16] to FreeBSD FreeBSD is no longer in a [23:20] position where it can go hang on we [23:21] should do this with an interface because [23:23] the entire Linux community would just go [23:25] oh I don't care [23:27] whereas Linux can go okay here's cgroups [23:31] take it or don't it's an interesting [23:35] position to be in the so we've got we've [23:40] gone from this pathological diversity or [23:41] a pathological monoculture where one [23:45] platform can effectively dictate what [23:48] the terms are system D gains a great [23:51] deal from unique using things that are [23:53] not Unix [23:55] and one of the things that I pointed out [23:57] when I first gave this talk is that this [24:01] doesn't have to be a net negative [24:02] because it means that FreeBSD and the [24:04] other projects could also feel similarly [24:06] liberated and try and create whatever [24:08] they wanted to without having to go hang [24:10] on [24:10] what does Unix think of this so and [24:14] cgroups is the thing I keep coming back [24:16] to it is cigarettes is a really powerful [24:18] mechanism for creating manageable groups [24:20] of processes I mean [24:22] previously came up with jails ages ago [24:24] but when I look at jails they're a lot [24:26] less flexible and a lot less granular [24:28] than what you can do with things like [24:29] cgroups [24:31] another thing that I think that systemd [24:34] gets really right is the notion of user [24:36] level units as if you want to do a user [24:39] space daemon as in a daemon that starts [24:41] up and runs as you without you having to [24:43] become root to install it on you know [24:48] FreeBSD that's really hard you basically [24:50] have to write in a shell script that's [24:51] then gonna sudo su as you and do all [24:53] that kind of stuff with system D I can [24:55] just drop something in a directory in my [24:58] home directory and if the things set up [24:59] right it just starts I mean the other [25:03] way you can do that is to play around [25:05] with cron but playing around with cron [25:07] is can be fun so it all comes back to [25:12] change system D represents a large [25:15] amount of disruptive change which brings [25:18] us to the actual tragedy of the piece so [25:23] yeah people have a complicated [25:26] relationship with change I like to say [25:30] that nerds especially have a really [25:32] complicated relationship with change we [25:34] love it to pieces changes awesome when [25:37] we're the ones doing it [25:39] [Music] [25:44] as soon as change is something that's [25:47] coming from outside of us it becomes [25:51] untrustworthy and it threatens what we [25:56] think of is the familiar people like me [25:59] grew up with a notion of you know in it [26:03] runs RC and RC runs a bunch of shell [26:06] scripts and then the system works and [26:08] that familiar might be you know it might [26:11] be good to us because it's under way [26:12] under stand it it's our comfort zone [26:15] it's what we're used to but I think at [26:18] this point like a system bootstrap that [26:21] relies on shell scripts and relies on [26:23] understanding how those shell scripts [26:24] work and interact and are ordered is [26:26] kind of like you know the old tired old [26:29] blankie that we maybe should have you [26:31] know handed off about 20 years ago and [26:34] you know persistently represents change [26:36] and it resent it represents a really [26:39] disruptive level of change and it [26:42] represents change that was pushed on us [26:44] by people like Leonard pottering whose [26:46] ability to have sympathy with the people [26:49] whose ease asking to change doesn't [26:50] appear to be the greatest but what this [26:56] leads to is a knee-jerk reaction because [27:00] the lack of sympathy isn't just on [27:01] Leonard's side the reaction the reaction [27:04] to system they've got a little bit over [27:06] the top in some places I think abuse is [27:10] not cool no one needed to send death [27:13] threats to leonard puttering over a [27:15] piece of software [27:18] [Music] [27:23] and it's not just abuse contempt is not [27:27] cool and this was one of the things that [27:29] I really wanted to ram home when I gave [27:32] this talk at bsd can freebsd should not [27:35] be proud of the fact that we don't have [27:37] a system d we should see that as we're [27:42] lacking something like we stop if we see [27:46] if we're mocking system mocking that the [27:48] fact that linux has system D and all [27:50] those poor Linux users with their [27:51] terrible software then it means that [27:54] we're treating it as a joke and not as a [27:56] source of ideas and that doesn't just [27:58] apply to FreeBSD it applies to pretty [28:00] much anyone who sits there going oh no [28:02] that system DS terrible it's like no [28:04] look at it a bit and one of the biggest [28:07] problems that I had with the FreeBSD [28:09] community on this one was things like [28:11] this because to me this says on behalf [28:15] of my community [28:16] come join FreeBSD we'll never change [28:21] we refuse to move forward into the [28:24] future yeah anyway and so really what I [28:28] want people to do and they look at [28:30] saying like system D whether they like [28:31] it or whether they don't and especially [28:33] if they don't is why why did system D [28:38] show up [28:38] why is system D important it's thinking [28:42] about that means that you suddenly go [28:44] hang on so is system D solving a problem [28:47] what problem is it solving could I solve [28:50] it better because one of the solutions [28:53] if you don't like system D is to go and [28:55] make your own at the very least you're [28:58] going to find out how much fun that is [28:59] and then another angle on this is that [29:04] it's not just about us Greybeards [29:06] the next generation of people who are [29:08] coming into IT coming into software [29:10] engineering coming into systems [29:12] administration they don't necessarily [29:14] think about the systems they're running [29:17] in the way that we do or that I do they [29:22] see a lot more api's in the sense of [29:24] like web api is like the you know 20 [29:27] years ago me going oh yeah I can spin up [29:29] a UNIX machine by punching a HTTP API on [29:33] it on a bookstore [29:35] that would blow me away back then and [29:40] also things like containers thinking in [29:43] containers ends up making you end up [29:46] thinking quite a lot differently than [29:47] thinking in not containers so and so [29:50] forth and so this brings us to the last [29:52] bit [29:57] what does systemd have that we could [30:00] learn from or what does it offer us so [30:04] this this is a section in the original [30:07] talk where I basically told a bunch of [30:11] BS D people what they could do if they [30:13] had something like that but I think [30:14] there's a bunch of interesting like if [30:16] you if you go up to the higher level of [30:18] what system D has there's a bunch of [30:20] really interesting stuff to think about [30:22] messaging transports this fret system D [30:27] makes heavy use of D bus I'm not a big [30:29] fan of D bus but I am a big fan of [30:31] messages Apple uses mark to do the same [30:35] kind of thing one of the things that I [30:37] told the BSD people was basically we [30:39] should write our own message transport [30:41] my version if I were to write one would [30:43] be kernel resident rather than user [30:45] space and it would allow a lot more sort [30:49] of security and authentication and [30:51] access control elements on the actual [30:53] bus endpoints but you people can write [30:57] your own because once you've got a [30:59] message transport it's a lot easier to [31:01] write an RPC framework and the question [31:05] is why would why do you need this and [31:07] the answer is because if you you need a [31:11] leveling mechanism to make the kernel [31:14] and user space operate at the same kind [31:16] of level as far as the code above them [31:18] is concerned you don't want to know [31:20] whether a particular service that you're [31:22] talking to is handled by the kernel or [31:24] by user space you just want it to happen [31:26] you want to be able to send out an API [31:28] request that says okay network interface [31:30] take this IP address and just have it [31:32] happen you don't want to have to worry [31:34] about you know am I talking to the [31:35] kernel or not the other thing that [31:38] systemd gives that a lot of previous [31:41] systems didn't give you as a proper [31:42] service life cycle you know as I said [31:45] Windows had this from inception [31:48] inception Matt [31:49] sort of organically grew it and then [31:50] once they did once they came up with [31:52] launched you sort of massively pushed [31:53] towards it and and does this without you [31:59] having to install a you know one of [32:02] several different systems that all work [32:03] differently like open RC or or run it or [32:07] supervisor D or any of these ones [32:10] automation via API sounds blithe but [32:12] once you can automate the setup and [32:14] configuration of a system through an API [32:17] that isn't sort of having to shell out [32:20] into system calls or anything like that [32:22] you've basically written most of what an [32:25] appliance vendor would need in order to [32:27] make a really good appliance so you can [32:29] think that things like open on wrt could [32:31] use it but then in my case I used to [32:34] work for a company that made large [32:36] storage appliances would have made our [32:37] job a ton easier to have that kind of [32:39] thing [32:39] and I think the last really important [32:41] thing that things like system D enable [32:43] through the use of things like C groups [32:45] and stuff like that is containers I [32:46] think containers are really interesting [32:49] not because I think that they are the [32:51] savior of security or anything like that [32:53] but just because they provide you with a [32:55] way to to encapsulate things in a way [32:58] that's quite cool and so system D [33:05] providing the system layer gives you a [33:07] more consistent platform for doing that [33:09] kind of stuff and the the barrier to [33:12] entry for building something on top is [33:14] like an appliance is massively reduced [33:18] but again system D doesn't have to be [33:20] the only implementation of this you [33:23] should go and explore but moving on I [33:28] think that the way system D names [33:30] devices is actually really good and I [33:35] say this is someone who used to spruik [33:37] the freebsd notion that every ethernet [33:38] driver should have its own name but and [33:42] while i also did not like the solaris [33:44] naming scheme of like c 0 t0 4 disks I [33:47] think that having consistent names that [33:49] are generated on physical attributes of [33:51] the device is a lot better than having [33:54] them named after what random order they [33:55] happen to show up in I also think that [33:59] system DS model of logging is really [34:01] good [34:02] binary logs are not a bad thing as long [34:06] as you have the tools to pull them apart [34:08] but having append-only logging in a [34:11] system like that especially append-only [34:12] logging that can be shipped off [34:13] somewhere else easily is I think very [34:16] handy but the other thing is that with [34:18] containers and a whole bunch of other [34:20] things you get a new model of an [34:21] application an application no longer has [34:24] to be a single binary or a single binary [34:27] that starts off other things it can be [34:28] an encapsulated series of things that [34:30] are managed as a unit I think that's [34:33] really powerful I think it would be [34:34] really interesting also to look further [34:37] on at how you would do a Mac off style [34:40] application on a platform like Linux [34:42] being able to provide a lot more [34:44] feedback from the host system about [34:47] what's going on so that it can react to [34:49] it so at the beginning of this talk I [34:53] showed the Wikipedia definition of [34:55] tragedy and it mentioned that it was [34:58] causing catharsis in people so [35:00] definition of catharsis meaning a [35:04] purification or cleansing would be [35:06] purification implication of emotions [35:08] particularly pity and fear through art [35:10] or any extreme change in emotion what I [35:14] hope that this talk has provided is a [35:17] removal of fear and particularly a [35:19] removal of pity of system D and the [35:22] people who actually use it the world is [35:25] changing around us and we can either get [35:27] with the change or we can try and resist [35:29] it and this applies in so many ways it's [35:33] not just software there are a whole [35:35] bunch of changes that go on that we [35:36] should we really need to logically [35:38] evaluate and work out whether we're on [35:40] the right side of we can try changes you [35:45] don't have to commit to them until you [35:46] know that they work I mean a lot of lot [35:48] of distributions had other systems that [35:52] they replace this and B with and worked [35:53] with it so yeah what I would challenge [35:58] everyone here is look at system D and [36:00] try and find at least one thing that you [36:02] like and then go see if you can [36:04] implement it thank you [36:07] [Applause] [36:17] yeah I'll do some questions okay we'll [36:21] put some time first of questions please [36:23] tried to make sure that they are [36:25] actually questions I've given this talk [36:28] before and as you can imagine I [36:29] occasionally get diatribes in the form [36:31] of questions not in the form of [36:34] questions they would have would it have [36:39] been feasible for launch D to have been [36:42] ported across to Linux and would there [36:45] have been any advantage or disadvantage [36:47] and and doing so given that Apple had [36:49] already done some of the work and [36:51] presumably that was open sourced as well [36:54] so the problem so if system D is [36:57] aggressively Linux specific launch DEA's [37:00] aggressively apple specific its it uses [37:05] it it deals in all with a lot of mark [37:07] ports and it also is I mean there's [37:10] Apple have done some work to try and [37:12] make it portable I know that they [37:14] offered to try and make all the Lib [37:18] dispatch bits and all everything that we [37:19] would need in order to do that on [37:20] freebsd but it did never quite it sort [37:24] of petered out because I think they're [37:25] focusing on making sure that it works [37:26] well for them which is fair enough in [37:29] the same way that system D tends to try [37:30] and work well for Linux I know you said [37:34] that containers enable a whole new way [37:38] of thinking about applications that can [37:39] now be managed as a unit we just spent [37:41] the last couple of decades getting [37:44] really good at dynamic library [37:45] management now this is starting to look [37:47] more like DLL hell what are your [37:49] thoughts on this well I think in a so [37:55] DLL hell to me is more having five [37:57] different versions of a library and [37:59] always having your applications pick the [38:01] wrong one [38:03] I think containers explicitly avoid that [38:07] particular version of it that said I [38:09] think there's a different version of it [38:11] where you might have different versions [38:12] of the container running and that kind [38:15] of stuff but I think that containers [38:16] explicitly avoid them the same way that [38:18] go tends to avoid that kind of problem [38:20] by statically linking everything would [38:23] you be willing to come to Linux plumbers [38:25] conference this year in Lisbon Portugal [38:26] and run a system D [38:28] micro conference library talk to Kay and [38:34] Leonard they said they might show up to [38:35] but hey I really enjoyed that and I [38:50] really appreciate your talk that many of [38:53] us really really love change we're we're [38:56] the ones saying hey you should change [38:58] and we don't like it when things change [39:02] on us do you feel there's been any kind [39:07] of chilling effect with the reaction to [39:10] systemd being so hostile that may be [39:13] causing other people who have good ideas [39:16] about how to do stuff saying well I'm [39:19] not gonna stick my head over the parapet [39:21] and I'm just gonna get shot it's [39:23] possible I mean whenever you're touching [39:25] code like that it's gonna it's going to [39:27] cause angst [39:29] I think the overreaction to system day [39:34] like you know the the stuff that Leonard [39:37] copped I think is good is gonna have [39:39] some effect on that kind of stuff I mean [39:40] the other thing though is it literally [39:42] writing that kind of stuff is a lot [39:43] harder than you think that doesn't mean [39:47] you shouldn't try but really I think one [39:51] of the the challenging prospects of [39:54] bringing something like that into the [39:55] world is managing the people that you're [39:58] trying to accept the trying to get to [40:00] accept the change and that requires a [40:03] certain level of social ability that is [40:06] beyond I mean he'll I don't think I'd do [40:08] a very good job of it [40:10] and it's one of the reasons why pushing [40:12] for that kind of change in FreeBSD was [40:14] something that I kind of wasn't sure how [40:16] to achieve and so I resorted to just [40:18] yelling at them in a keynote as a [40:22] FreeBSD curious Linux user [40:25] where's FreeBSD at with the [40:27] next-generation clone in it there's a [40:32] project called open RC that handles some [40:35] of the service management bits but in [40:39] terms of a holistic notion of a system [40:42] layer [40:42] they're a long way from that and that I [40:45] think is one of the things that I find [40:46] frustrating in this discussion in any [40:48] discussion around this is there are far [40:50] too many people who immediately default [40:52] to this notion that system D is only [40:53] about starting and managing services [40:56] when in my opinion if you're really [40:58] going to do that kind of thing you need [40:59] to look at the whole thing that doesn't [41:00] necessarily mean you have to do it all [41:01] in one project but you have to do it [41:03] with a level of holistic intent if that [41:07] makes sense because you want it to be [41:08] somewhat uniform and manageable [41:11] thank you for expressing better than I [41:14] could and much better than I can be [41:16] bothered a lot of thoughts that I've had [41:18] as well as you said systemd kind of [41:22] swallowed up a whole bunch of previously [41:25] separate system services do you have any [41:29] opinions on whether they all make sense [41:32] or some of them make sense and others [41:34] less so [41:37] okay so here's an interesting thought [41:39] experiment [41:40] if system D had not brought those things [41:44] in but had instead worked on defining an [41:47] API by which those services could be [41:50] managed [41:51] then they possibly would not need to be [41:55] in the same project because you wouldn't [41:56] be needing to keep the same level of [41:58] control you could have a bunch of [42:00] implementations of say the network [42:02] manager API or the time management API [42:04] or that kind of thing that would be [42:07] interchangeable to some extent I can [42:10] kind of see why they didn't go that [42:11] route in that it's not immediately [42:13] obvious until after you've done the [42:14] first thing like once once you've pulled [42:16] everything in gone oh crap we need to be [42:18] able to manage that too and we need to [42:19] be able to manage that and we need to be [42:20] able to manage that and so you brought [42:21] everything in together at that point you [42:22] kind of go oh hang on if we'd actually [42:24] just define the interfaces a bit better [42:26] than maybe we could have avoided that [42:27] that's the kind of thing that you see in [42:29] sort of as an afterthought but yeah it's [42:34] I think I can see the lot I can see [42:38] logic as to why they would have done [42:39] what the everything is there that's that [42:42] they're brought in but whether they need [42:44] to be there in the long terms and it's [42:46] an interesting question and if you were [42:47] to write your own implementation of that [42:49] kind of thing then there are ways that [42:50] you could avoid having to pull all those [42:52] things into one thing [42:56] I probably know or at least could [43:09] imagine what the will you think [43:12] advantage of using CMD on embedded [43:16] devices as opposed to desktop and [43:18] servers to start with I can think of [43:21] being able to restart your surfaces on [43:26] embedded devices that no one's gonna be [43:28] monitoring but what are you thoughts on [43:31] this if your embedded device has any [43:33] level of dynamism in its environment [43:35] like if things are getting plugged into [43:36] it then that gives you a hook to do that [43:39] if you have the the AP is for managing [43:42] things like that it means that the code [43:43] that you have to write in order to [43:45] implement your embedded device is [43:46] hopefully less it's that kind of thing [43:53] you mentioned that you're given a [43:55] similar talk to some FreeBSD developers [43:57] or FreeBSD users yeah it did you get a [44:01] lot of pushback on there and if so was [44:03] there a major category of pushback that [44:05] they specifically got are the only real [44:08] pushback that I got was ok we were on [44:11] board with the notion that we need [44:12] something like it but as long as it's [44:14] not system D which you know are oh well [44:21] no there was an attempt to do that and [44:23] including porting over a Marc ports [44:26] compatibility layer so don't joke thanks [44:30] for that given the interactions between [44:34] the community and the system D team in [44:36] both directions have not always been the [44:38] most positive to put up mildly you know [44:41] we're in a situation where the system D [44:43] team doesn't really listen to or take on [44:45] board community concerns but at the same [44:47] time the community is not really [44:48] listening to the system D team and their [44:50] vision what needs to change both in the [44:53] community and say this room and broadly [44:55] and also in the system D team in order [44:58] to facilitate a better working [45:00] relationship going forwards that's a [45:03] really tricky one that's what I'm asking [45:06] it so one thing [45:09] could do is watch Adam Harvey's talk [45:11] about version upgrades language version [45:14] upgrades because in it he discusses this [45:16] notion that you have to give people [45:17] reasons to change as well as just [45:19] beating them around the head to say [45:21] don't do that having a combination of [45:24] those things would be good I think the [45:25] problem that I mean I am I'm speaking [45:30] from a position of profound ignorance [45:31] here but where I in the system the [45:33] author's position having a whole bunch [45:35] of community people coming to me and [45:37] saying I want X Y and Zed and they want [45:39] a B and C and these people want [45:41] something else and at least five of [45:43] these things conflict with each other [45:45] that's a really hard set of constraints [45:48] to try and work within and so I can see [45:51] that there would be a temptation to just [45:52] tell them all to get nicked that doesn't [45:55] mean that that's the right thing to do I [45:58] do agree with you that the the [46:01] relationship between the author's and [46:03] the community seems fraught I think I [46:07] don't really know the right way for them [46:10] to fix it but it probably involves a lot [46:12] more a lot more sympathy on both sides [46:14] to some attain to that are there any [46:17] particular areas you think systemd [46:18] should go a lot further in I would very [46:23] much like to see the messaging and RPC [46:28] stuff become a lot more pervasive and a [46:31] lot more thought about if that makes [46:33] sense I mean I'm sure they are thinking [46:34] about how that works they've been [46:35] multiple attempts to get a a D bus style [46:38] transport into the kernel I think that [46:40] having that even if it's not necessarily [46:42] D bus would be a really interesting [46:43] thing to play with because it puts a lot [46:45] of code on the same level and it also [46:48] allows a lot more yet control and [46:52] interesting security features that you [46:54] could do by having it in the kernel all [46:57] right we're out of time so thank you Ben [46:59] [Applause] [47:05] [Music] [47:08] oh thank you very much