Project Proposal: gnome-container-session

Technical Proposal: The gnome-container-session Project

This document presents a formal proposal to the maintainers and developers of non-systemd Linux distributions and the BSDs. In light of the GNOME desktop environment's increasing integration with systemd[^1], this proposal introduces a viable, fourth option for retaining GNOME. It outlines a pragmatic engineering solution—the gnome-container-session project—designed to resolve the technical incompatibilities without compromising the core philosophical principles of modularity and "init freedom" that define these operating systems.

[^1]: For clarity, project names in this document are pronounced as follows: GNOME ("Nome," as in garden gnome) and systemd ("system d").

--------------------------------------------------------------------------------

1.0 Problem Statement: The GNOME 49 Inflection Point

Understanding the recent architectural shifts within the GNOME desktop environment is of strategic importance. These changes represent more than an isolated technical decision; they constitute a fundamental challenge to the design philosophy of non-systemd distributions, creating a new and pressing inflection point with the release of GNOME 49.

1.1 The End of the Fallback Mechanism

With GNOME 49, a critical fallback mechanism within gnome-session has been removed. This built-in service manager, a 17-year-old codebase from GNOME 2.24, previously allowed GNOME to function in environments where the systemd user instance was unavailable.

The direct catalyst for this removal was the cleanup of legacy hacks in the GNOME Display Manager (GDM). These hacks, which were required to support multi-seat and remote login scenarios, were incompatible with modern components like dbus-broker. With these hacks eliminated, GDM now correctly uses systemd to manage the login screen's session. This architectural improvement rendered the non-systemd fallback code "completely unused and untested" by upstream developers. Citing its age and interference with a planned session save/restore feature, this fallback has been excised from the codebase.

1.2 New Hard Dependencies

Beyond the removal of the session fallback, GNOME is introducing new, hard dependencies on systemd components that extend beyond the existing elogind compatibility layer.

* GDM and systemd-userdb: To properly manage multi-seat and remote login sessions, GDM now depends on systemd-userdb to dynamically allocate user accounts. This replaces the aforementioned legacy hacks.

* Future AccountsService Replacement: There is a stated plan to eventually replace the AccountsService daemon entirely with functionality provided by systemd-userdb, further solidifying this dependency.

These changes create a new reality where non-systemd distributions must "implement replacements for more systemd components," a significant increase in maintenance burden. While temporary workarounds are available for GNOME 49, the long-term direction is clear: distributions must implement the userdb Varlink API to remain compatible.

1.3 The Philosophical Impasse

The core conflict is philosophical. systemd is designed to run as Process ID 1 (PID 1) and systematically replaces previously modular components of a Linux system with its own tightly integrated versions. This architecture is fundamentally at odds with the "init freedom" philosophy championed by distributions like Devuan, Artix, and Void, which prioritize modularity and user choice.

GNOME's new direction of deep integration effectively makes it, as observers have noted, "less of a Linux desktop environment and more of a systemd desktop." This transformation forces non-systemd distributions into a set of difficult and suboptimal choices for their users.

--------------------------------------------------------------------------------

2.0 An Evaluation of Existing Alternatives

Before presenting a new solution, it is critical to perform a rigorous analysis of the currently available options. This evaluation demonstrates why a novel approach is not only preferable but necessary to navigate the current landscape.

1. Adopt systemd

This option is a non-starter for the target distributions. It represents a capitulation on the core principle of "init freedom" and the modular design philosophy that are the very reasons for their existence. To adopt systemd would be to abandon their foundational identity.

2. Stick with an Older GNOME Version

This is an unsustainable, short-term strategy. While it buys time—for instance, distributions have the option of holding back on GNOME 48, which will receive security fixes until GNOME 50 is released—it inevitably leads to a divergence from upstream. Users are cut off from new features, and more critically, the distribution's maintainers are saddled with the increasingly difficult task of backporting security patches to an aging codebase.

3. Drop GNOME Entirely

This is a valid choice, particularly as a political statement to GNOME developers that their project has become hostile to a significant portion of the Linux ecosystem. However, it comes at a high cost. It removes a popular and well-regarded desktop environment as an option, reducing user choice and potentially alienating users who prefer the GNOME experience.

4. Create a Hard Fork

This represents the most resource-intensive and challenging path. A hard fork of a project as complex as GNOME requires "effectively taking full ownership of the fork." This entails a massive and perpetual maintenance effort that is often beyond the capacity of volunteer-driven distribution development teams.

The significant drawbacks associated with each of these options highlight the urgent need for a more pragmatic and innovative solution.

--------------------------------------------------------------------------------

3.0 Proposed Solution: The gnome-container-session Architecture

We propose a novel "fourth choice": the gnome-container-session. This is a pragmatic engineering solution that resolves the technical incompatibility between modern GNOME and non-systemd hosts without compromising the philosophical principles of the host system.

3.1 High-Level Concept

The gnome-container-session is a specialized container engine tailored to run a stripped-down systemd instance. This containerized systemd is used for one purpose: to launch and manage the GNOME desktop environment as required by upstream. From the user's perspective, the experience is seamless. Upon selecting their session and logging in, the desktop environment starts as expected, with the underlying complexity abstracted away.

3.2 Architectural Principles

The solution operates on a set of clear architectural principles designed for security, integration, and philosophical alignment.

* Session Initiation: When a user logs in, the host system's display manager launches the gnome-container-session program instead of the traditional gnome-session binary.

* Host Resource Access: For seamless integration, the container is granted read-only access to necessary host resources. This includes the user database, device files, and other components required for the desktop to function correctly.

* Write Request Mediation: Any request from the containerized environment to write to the host system is intercepted by the gnome-container-session layer. This layer acts as a policy engine, determining whether the request should be:

  * Allowed to proceed.

  * Ignored or gracefully blocked.

  * Redirected to an ephemeral part of the container, ensuring no permanent change to the host.

* Quarantine by Design: This architecture creates a functional quarantine. It allows systemd and its dependencies to operate within the container exactly as GNOME requires, without altering, replacing, or otherwise compromising the host system's native init process.

This architecture effectively decouples the desktop environment's dependencies from the host's core architecture, providing a clean and maintainable path forward.

--------------------------------------------------------------------------------

4.0 Strategic Justification and Benefits

The architectural merits of gnome-container-session are not merely tactical; they provide compelling strategic advantages that directly address maintenance scalability, community resilience, and future development pathways.

* Preservation of Init Freedom

This is the primary and most crucial benefit. It allows distributions to offer a modern, fully-featured GNOME desktop to their users without being forced to replace their chosen init system, thereby preserving their core identity.

* Reduced Maintenance Burden

The effort required to maintain a single, targeted container solution is vastly lower than the immense work of re-implementing an expanding suite of systemd-specific APIs. This approach obviates the need to create custom implementations of the userdb Varlink API, build bridges for NSS, replace gnome-session-ctl, or translate systemd unit files into native service definitions.

* A Pathway for a Future Fork

Should the community decide that a hard fork is eventually necessary, the container provides a stable, working foundation. A systemd-free fork of GNOME can be developed and tested more strategically from within this controlled environment, rather than starting from scratch.

* Decoupling from Upstream Dependencies

This solution frees non-systemd distributions from the "whims" of upstream GNOME's architectural choices. GNOME developers can integrate systemd as deeply as they wish, and it will no longer break non-systemd environments, which can simply update the container image.

* Enabling User and Developer Participation

It provides a safe and practical avenue for users and developers on non-systemd systems to participate in GNOME development. They can build, test, and contribute to upstream GNOME without having to compromise their own systems.

* Cross-Platform Potential for BSD

The container concept is not limited to Linux. BSD users and developers can adapt the architecture to their own login mechanisms, leveraging the same container image. This re-opens the door to having a modern, supported GNOME desktop on BSD platforms.

This approach transforms a point of conflict and exclusion into an opportunity for robust, cross-platform engineering.

--------------------------------------------------------------------------------

5.0 Phased Implementation Roadmap

The gnome-container-session is not a monolithic undertaking. It can be developed and delivered through a series of well-defined, incremental stages. This approach ensures manageable progress, allows for continuous testing, and delivers value at each step of the process.

1. Stage 0: Running a minimal base container image based on the host system's distribution (e.g., a Devuan container running runit).

2. Stage 1: The base image runs a stock systemd as PID 1 within the container.

3. Stage 2: The container image runs a bare graphical environment (enough to run an xterm or Wayland equivalent).

4. Stage 3: The container image can seamlessly handle graphical events, notifications, and media servers.

5. Stage 4: The container image runs a bare minimal version of GNOME.

6. Stage 5: The container image seamlessly runs a full GNOME environment. This milestone marks the first stable release of the project.

7. Stage 6: The stock systemd in the container image is stripped of components not needed to run GNOME.

8. Stage 7 (Optional): Use the stable container image as a base to start developing a hard fork of GNOME that runs on other init systems.

This roadmap provides a clear and achievable path from a proof-of-concept to a fully-realized, stable solution.

--------------------------------------------------------------------------------

6.0 Addressing Technical Considerations and Objections

Any innovative proposal will face scrutiny and valid questions. This section proactively addresses the most likely objections and technical considerations to demonstrate the robustness of the gnome-container-session concept.

* Objection: "What about the performance overhead of running a desktop in a container?"

* It is true that containerization introduces a performance hit compared to a bare-metal installation. However, with modern hardware and lightweight container technology, this impact is expected to be negligible for all but the most mission-critical scenarios. For the vast majority of desktop users, the experience should be indistinguishable from a native session.

* Objection: "Why not just use an existing container engine like Podman?"

* While Podman is a powerful engine designed for running systemd in a container, its primary design target is a host system that is also running systemd; certain features are known to break on other init systems. Rather than a general-purpose engine, gnome-container-session is proposed as a specialized session initiator. This project can and should adapt key technologies from best-in-class tools like Podman—specifically its fork-and-exec style of container management and rootless containers—while remaining tailored for non-systemd hosts.

* Objection: "Why not just run our preferred service manager as a systemd service?"

* This suggestion is a classic "bait-and-switch." While it is technically possible to run a service manager like runit under a systemd supervisor, doing so cedes control of the service supervision chain to systemd. This tactical compromise opens the door for proponents to then pressure developers to migrate all services to native systemd units, ultimately defeating the entire purpose of preserving init freedom.

* Objection: "You should just use systemd. No one uses other inits."

* This objection has two responses. The first is diplomatic: with the gnome-container-session approach, we can state, "We are using systemd, but in a slightly different way"—namely, as a quarantined application dependency rather than a host system controller.

* The second response refutes the premise. The users and developers of distributions such as Devuan, Artix, antiX, Alpine, Void, Slackware, and numerous embedded Linux systems are certainly not "nobody." They represent a significant and principled segment of the community for whom this solution is designed.

The gnome-container-session concept is resilient to these common criticisms and represents a well-reasoned engineering compromise.

--------------------------------------------------------------------------------

7.0 Conclusion and Call for Collaboration

The gnome-container-session proposal offers a clear path forward through the impasse created by GNOME's tightening integration with systemd. This solution is technically sound, providing a robust method for running modern GNOME on any host. It is philosophically aligned, preserving the core principle of init freedom by quarantining dependencies. Finally, it is strategically pragmatic, drastically reducing the maintenance burden compared to all other viable alternatives.

We urge the developers and maintainers of non-systemd Linux distributions and the BSDs to consider this proposal as the foundation for a collaborative, cross-distribution effort. By working together, we can build and maintain this critical piece of infrastructure, ensuring continued and unfettered access to the GNOME desktop for all users, regardless of their choice of init system.

The Weird and Wonderful World of Proot and Inits

If you want to run Linux on your unrooted Android phone via Termux, there's at least two main methods of doing so: full virtualization using Qemu, or using containers with proot-distro.

What's Proot-distro?

Proot-distro is a wrapper script around the proot utility, which is a user space implementation of chroot(or in other words, a non-root container engine).

Proot's implementation of chroot relies on using ptrace to hijack system calls and fake being root within the proot session. However, while proot can isolate the host file system from the guest, it cannot isolate the process view like other container engines like Docker and podman can.

Limitations of Proot

This means that while you can get away with merely running a shell within the proot session, you can't run any traditional init system that relies on being PID-1 and manages processes on its own. I've tried, and everything from kitchen sink systemd to sysvinit to even Rich Felker's minimal init won't properly run without modification.

Making a !PID-1

So, with these limitations of proot in mind, I decided to try to either modify an existing init or write one from scratch. My first attempt was commenting out the PID check in Felker's init and compiling the result. It worked, but job control got disabled and the proot session hung on exit. Progress, but still not usable. So I instead attempted to write a proof of concept in shell script, since proot simply launches a shell by default. It completely worked. Next I tried further modifying Felker's init by disabling all functionality except passing off execution to /etc/rc. The result was literally a one-line main() function. It worked! So now I have two working starting points to build up an init system with a "proot mode" of operation. And since it seems that there's literally no other projects with this specific aim(podman doesn't count because that's a container engine explicitly designed to run systemd, rather than an init designed to run in proot) that I could find, it's likely I'm a pioneer in this specific area.

...But why?

It's a fair question. What's the value of running an init in a prooted distribution? Isn't it enough that proot handles job control and by default automatically launches a shell?

This Red Hat Developer article advocating for podman actually explains the rationale for running an init inside a container better than I could. But as my attempts to use traditional init systems demonstrate, it's currently not as simple as "apt install systemd", and then restart with "proot-distro login debian --isolated -- systemd". Proot is a different beast than Docker, podman, or systemd-nspawn, and it requires init systems designed to adjust to it or written from the ground up for it.

So right now, I'm going to attempt to rewrite Felker's init where instead of refusing to run if it's not PID-1, operate in "proot mode" and put it up on my GitHub if it works.

Update: Here it is. I stripped Felker's init down to a one-line main function, as a minimal working starting point, and I plan to add a "hybrid" version that runs as a normal init if it's PID-1, else it runs in proot mode. And after that, I'll implement support for running groot as a user service manager.