Project Proposal: gnome-container-session

 

Project Proposal: gnome-container-session - A Strategic Path Forward for GNOME on Non-systemd Systems

1.0 The Challenge: GNOME's Divergence from Init-Agnosticism

For years, a core principle within the Linux ecosystem has been the modularity and independence of its components. Desktop environments, in particular, have traditionally remained agnostic to the underlying init system, allowing distributions the freedom to choose the foundational software that best suits their philosophy and technical goals. However, the recent release of GNOME 49 marks a significant break from this principle. By creating a hard dependency on systemd, this move unilaterally dismantles a long-standing architectural assumption, forcing a significant portion of the Linux ecosystem to re-evaluate its relationship with a foundational desktop project.

1.1 The Breaking Change in GNOME 49

The specific technical change that precipitated this crisis was the removal of the fallback code within GNOME that previously allowed it to function on systems not running systemd. Until this release, non-systemd distributions were able to bridge the gap using compatibility layers like systemd-shim and elogind. The removal of this support effectively mandates systemd as a non-negotiable prerequisite. The consequences of this change are not theoretical; they are immediate and tangible. The recent release of Devuan Linux 6.0 "Excalibur" on November 3, 2025, serves as a stark example: for the first time, this major non-systemd distribution has been forced to ship without offering GNOME as a desktop environment option.

1.2 The Dilemma for Non-systemd Distributions

This development presents distributions dedicated to "init freedom"—such as Devuan, Artix, and Void—with three difficult and unappealing choices:

• Drop GNOME: The simplest route, this involves completely removing GNOME as an official desktop environment, alienating users who prefer it and reducing the distribution's appeal.
• Maintain an old version: This path involves sticking with an outdated version of GNOME and attempting to backport critical security patches and features. This is painstaking work that becomes increasingly unsustainable over time as the upstream GNOME codebase diverges.
• Create a hard fork: The most resource-intensive option involves forking the entire GNOME project to remove the systemd dependency. This requires taking on the immense effort and full ownership of maintaining a complex, multi-million-line codebase, a task beyond the capacity of most development teams.

Faced with these untenable options, a new approach is necessary—one that sidesteps this dilemma entirely.

2.0 A Fourth Path: The gnome-container-session Concept

This proposal outlines a fourth, more pragmatic choice that circumvents the dilemma described above. The gnome-container-session project is an innovative approach that isolates the systemd dependency within a specialized container, allowing the latest GNOME desktop to run on any host system, regardless of its native init software. This strategy preserves user choice without forcing a fundamental change to the host operating system's architecture.

2.1 Core Architectural Concept

gnome-container-session is not a generic container engine like Docker or Podman. It is a highly specialized tool designed for a single purpose: to run a stripped-down systemd instance that, in turn, automatically launches the GNOME desktop environment within an isolated container. The entire system is engineered to provide a seamless user experience while containing the systemd dependency, treating it as an application-level requirement rather than a host-level mandate.

2.2 User Experience and Session Flow

From the end-user's perspective, the experience is designed to be nearly indistinguishable from a native installation. A user approaches a graphical login screen, selects their desired desktop environment (GNOME), and enters their credentials. However, the underlying process differs significantly from a traditional session startup:

• Instead of the host's login manager directly launching gnome-session, it will instead execute the gnome-container-session program.
• This program then transparently initiates and manages the containerized systemd and GNOME environment, presenting the full desktop to the user.

The goal is a completely seamless login process that requires no special configuration or knowledge from the user. This high-level simplicity is made possible by a carefully designed technical architecture that manages the complex interactions between the host and the container.

3.0 Technical Architecture and Host Integration

Our architectural philosophy is centered on a mediated trust model. The project's success hinges on achieving seamless integration between the non-systemd host operating system and the containerized GNOME session. This requires providing a native-like user experience—with full access to user files, hardware, and system services—while maintaining strong security and isolation boundaries.

3.1 Host-Container Interaction Model

We propose a brokered architecture where gnome-container-session acts as the sole policy enforcement point for host-container interactions. This ensures stability and prevents the containerized environment from making undesirable changes to the host system.

• Resource Access: By default, the container will be granted read-only access to essential host resources. This includes critical files like the user database for authentication and device files for hardware interaction.
• Write Request Mediation: The gnome-container-session process will act as an intelligent broker for any write requests originating from within the container. It will inspect each request and determine the appropriate action based on predefined security policies:
  • Ignore: The request is silently dropped.
  • Gracefully Block: The request is blocked, and an appropriate error is returned to the containerized application.
  • Redirect: The write operation is redirected to an ephemeral location within the container, preserving the integrity of the host filesystem.

3.2 Learning from Existing Container Technologies

While a specialized solution is necessary, the project does not need to reinvent the wheel. Existing container technologies offer valuable concepts that can be adapted. A common question is why a tool like podman is not sufficient for this task. The primary limitation is that podman is designed for host systems that are already running systemd. While other container solutions like Docker, Kubernetes, lxc/incus, and cri-o were considered, podman provides the most relevant concepts to adapt for this specialized purpose. Developers of gnome-container-session can and should adapt valuable features pioneered by these modern tools, including:

• The "fork-and-exec style of container management," which is lightweight and efficient.
• The use of "rootless containers," a critical security feature that enhances isolation by running the container without elevated privileges.

This hybrid approach—a specialized engine built upon proven concepts—provides a clear technical path forward, translating directly into the strategic benefits of the project.

4.0 Strategic Advantages and Value Proposition

The gnome-container-session project offers more than just a technical workaround; it provides a suite of strategic advantages that strengthen the entire non-systemd Linux ecosystem, ensuring its long-term viability and preserving its core principles.

4.1 Preserving User Choice and "Init Freedom"

The primary value proposition is simple yet profound: users can run the latest, fully-featured versions of the GNOME desktop without being forced to replace their host system's chosen init software. The container acts as a "proper quarantine," allowing systemd and its dependent software to function where required by GNOME, but preventing them from compromising the "init freedom" of the host.

4.2 Reducing Maintainer Burden

This container-based approach dramatically lowers the workload for distribution maintainers. Instead of the "painstaking work" of backporting features or the monumental effort of maintaining a hard fork, developers can focus on a cleaner, more manageable process. By containerizing the entire GNOME stack, distributions can treat it as a single, atomic dependency, simplifying their build systems and continuous integration pipelines. Packaging, testing, and deploying new GNOME releases via a standardized container is a far more efficient and sustainable model.

4.3 A Pathway to Future GNOME Development

Beyond solving the immediate problem, this project creates immediate and long-term strategic value. It instantly establishes a stable, isolated environment for developing and testing GNOME on non-systemd systems. This foundation can then serve as a strategic stepping stone for a future community effort. Once a fully integrated containerized environment is achieved (Stage 5), it could be used to develop a hard fork of GNOME that is truly init-agnostic, as envisioned in the optional Stage 7.

4.4 Performance Considerations

The most predictable technical trade-off of a containerized solution is performance. It is important to acknowledge that running GNOME inside a container will introduce some overhead compared to a bare-metal installation. However, the practical impact of this must be put into perspective: "on modern hardware, the performance hit would be negligible for all but the most mission-critical scenarios." For the vast majority of desktop users, the benefits of access to modern GNOME will far outweigh any minor performance degradation.

This balance of benefits and manageable trade-offs is reflected in the project's concrete, step-by-step plan for execution.

5.0 Phased Development Roadmap

To ensure success, this project will follow a phased, iterative development plan. This approach is designed to mitigate technical risk by tackling the most significant dependencies first (i.e., container setup, then systemd integration) and to deliver incremental value for community feedback at each stage. Each phase builds upon the last, incrementally adding functionality until a fully stable and integrated solution is achieved.

• Stage 0: Foundational Container Validation. The initial stage focuses on establishing a minimal base container image derived from the host's own distribution (e.g., a Devuan container running runit), validating the core containerization runtime on the target systems.
• Stage 1: systemd Integration. With the base container validated, this stage focuses on successfully running a stock systemd as PID 1 within the container, tackling the core dependency head-on.
• Stage 2: Basic Graphical Environment. This stage establishes a bare graphical environment inside the container capable of running a terminal (such as xterm or a Wayland equivalent), proving the viability of basic graphics pass-through.
• Stage 3: Full I/O Integration. Building on the previous stage, this phase implements seamless handling of all graphical events, notifications, and media servers between the host and the container, which is critical for a native-like experience.
• Stage 4: Minimal GNOME Implementation. The first major integration milestone, this stage aims to run a bare, minimal version of the GNOME desktop environment within the container.
• Stage 5: Full GNOME Environment (v1.0 Stable Release). This milestone marks the first production-ready release, delivering a seamlessly running, full GNOME environment to end-users.
• Stage 6: Post-Release Optimization. Following the stable release, work will focus on stripping the container's stock systemd of all components not essential for running GNOME, reducing the container's footprint and overhead.
• Stage 7 (Optional Future Scope): Fork Development Base. With a stable and optimized container in place, the project could serve as a reliable foundation for a community effort to begin development on a hard fork of GNOME that runs natively on other init systems.

6.0 Anticipated Questions and Project Positioning

A project of this nature will inevitably attract questions and criticism, particularly from proponents of a systemd-centric ecosystem. Proactively addressing these points is crucial to clarifying the project's goals and positioning within the wider community.

"Why not simply use a minimal version of systemd, but use your favorite service manager as a systemd service?"

This approach, while technically possible, is a "classic bait-and-switch." It cedes control of the boot process to systemd and undermines the core principle of init independence. The next logical "suggestion" from proponents of this method is to convert the remaining services to native systemd services, defeating the entire purpose of preserving init freedom.

"Why not use podman or another existing container engine to run systemd and GNOME?"

This suggestion overlooks a key technical limitation: podman is explicitly designed for host systems that are already running systemd. It is not a viable solution for the target distributions. However, as noted in the technical architecture, gnome-container-session can and should adapt some of podman's excellent features, such as its fork-and-exec management style and its implementation of rootless containers.

"Just use systemd. Nobody uses those other inits anymore."

This assertion is factually incorrect. A vibrant and dedicated community continues to build, maintain, and use distributions that provide an alternative to systemd. These include:

• Devuan
• Artix
• antiX
• Alpine
• Void
• Slackware
• and numerous embedded Linux distributions

These communities deserve the freedom to choose their foundational software without being locked out of major desktop environments.

7.0 Conclusion and Call for Collaboration

The gnome-container-session project represents a technically sound, strategically vital, and forward-looking solution to a critical challenge facing the non-systemd community. By isolating the systemd dependency within a specialized container, this initiative allows users to access the latest GNOME desktop environment while upholding the core principle of "init freedom." It reduces the unsustainable burden on distribution maintainers and provides a clear, incremental path toward a stable, long-term solution. We confidently invite developers, maintainers, and enthusiasts from all affected distributions to collaborate on this important project to preserve choice and diversity within the broader Linux ecosystem.