An Open Letter on Linux Compatibility (and Why Flatpak Isn't the Fix)

As a lot of you already know, backward compatibility has never really been the strong suit of Linux or the BSDs. Part of this is cultural: there's a mismatch in expectations around dependency and package management, and userspace developers don't always appreciate that “old” code is often still doing real work. People break it without realizing how much depends on it, and compatibility suffers as a result.

So here's the problem, stated plainly:

Dependency management and compatibility haven't been solved elegantly yet. There have been interesting attempts: Canonical's Snaps, Red Hat's Flatpaks, and Simon Peter's AppImage all come to mind, but it feels like app distribution and compatibility are actually two separate problems that keep getting bundled together. The attempts above end up overreaching outside their actual problem domain. App distribution shouldn't be on the hook for handling userspace components or compatibility with userspace, and it shouldn't be on the hook for security either. Those are genuinely separate concerns and should be treated as such.

To be clear, I'm not trying to single out Flatpak as the villain here. What it's doing is a natural response to trying to solve a fragmented ecosystem all at once. It's a holistic fix for a problem that's anything but holistic.

The plan, then, is to rethink this from the ground up. Instead of meeting the fragmentation halfway, which is essentially what Flatpak does, the focus should be on building a stable, backwards-compatible userspace first, as the actual foundation everything else builds on. Package management or app distribution and security would be split off as two separate concerns, each handled by its own subsystem, rather than crammed into the same tool. Naturally, this raises immediate concerns, particularly regarding the risk of centralization. These concerns are addressed in the Implementation Detail section of this page.

Basically: bring the Windows NT compatibility promise to Linux.

Implementation Detail

The compatibility layer is deliberately abstracted from the userspace beneath it. The userspace is intended to remain stable in its own right, even when software interfaces with it directly; the abstract API exists to reduce applications’ dependence on particular userspace components and implementation details. It is concerned with the operating-system facilities that applications should be able to rely upon initialization, service management, application lifecycle, permissions, desktop integration, and similar functionality not with replacing every library commonly found on a Linux system. It does not attempt to impose project-specific versions of OpenGL, Vulkan, traditional C-style sockets, or every other established interface. Those technologies may remain available where they are appropriate, while applications that want a more portable and durable target can use the higher-level API. The purpose of this layer is therefore not to make the userspace irrelevant, but to make dependence upon any one part of it less necessary.

Applications will primarily be distributed as application packages, but these packages are not required to be completely self-contained in the manner of an AppImage. Because the operating system provides a stable userspace and a stable application-facing API, an application does not need to bundle everything merely to protect itself from arbitrary changes in the host environment. The package may contain libraries and dependencies that are not part of the operating-system contract, including application-specific runtimes or, where necessary, its own C library (The project’s own C library is intended to be small, simple, and backward-compatible, but applications are not required to use it if another implementation better suits their needs). Publishers may bundle a more complete userspace when there is a specific reason to do so, just as with an AppImage, but this is an option rather than the normal distribution model. The aim is to avoid both extremes: applications should not depend blindly on an unstable host system, but neither should every application need to duplicate the entire operating system.

These packages may contain more than a single executable. Applications can be nested within one another, allowing a package to include supporting applications, tools, or components without requiring each part to be distributed independently. A Lisp-based definition and configuration layer will describe the package’s contents, relationships, metadata, dependencies, configuration, and required behavior. The same language will also serve as the principal configuration and systems language for the wider operating system, allowing the entire system including installed applications, services, permissions, system settings, and other state to be described as a reproducible configuration. Rather than applying a sequence of manual changes, the system can evaluate that configuration to produce a complete declared state, allowing environments to be recreated, compared, versioned, and rolled back. In this way, application packages and system configuration can share a common, inspectable means of describing composition and behavior, while still remaining separate from the stable operating-system API itself. The language is not intended to make every implementation detail part of the compatibility promise; rather, it provides a flexible mechanism through which applications, packages, and system components can be composed and entire system environments can be reproduced.

These packages will be distributed through a dual system. They may be installed directly from downloadable or offline sources, or they may be installed from repositories selected by the user. A synchronization system is also intended to allow packages installed from non-repository sources to be synchronized with a repository, and packages obtained from a repository to be detached, cloned, and used independently. In either case, the package may later be synchronized with its original or selected repository when necessary. The precise verification method used to establish legitimacy is outside the scope of this article; the important point is that repository-based and standalone distribution are not mutually exclusive states.

This gives the system flexibility without sacrificing compatibility. Applications can be obtained through repositories when convenient, deployed independently when required, and moved between those forms without being permanently tied to a single distribution channel. Combined with the stable userspace and application-facing API, this provides a distribution model that is both highly compatible and adaptable to online, offline, centralized, and independent use cases.

The project is not intended to become a centralized source for Linux or a mandatory standard imposed upon existing distributions. It is an independent system and reference implementation whose interfaces and design can be adopted voluntarily. If the approach proves useful, other projects should be able to implement compatible systems or create direct derivatives without relying upon one central organization or vendor-controlled source. A successful implementation would earn its place by providing a useful stable userspace, a durable abstract API, reliable application distribution, and a coherent security model. Other implementations could then preserve the same application-facing contracts while differing internally. Compatibility would emerge from usefulness and adoption, rather than being forced upon the wider Linux ecosystem.

Core Design and Organization

The sections above describe the problem and the idea. This part covers how the platform would be built, and who would build and maintain it. It follows two rules for the userspace: do not break old code, and keep it small and simple. The first rule is the product. The second makes the first one affordable, because a small interface is cheap to test and cheap to keep stable for years. Every choice below is measured against both.

The common API and the core

The core has two parts: a common API that gives system components one standard way to talk to each other, and a small set of userspace services behind it. You can think of the API as a bus connecting the pieces, and as a set of guidelines for how they fit together.

The reason is to keep components from getting tangled up. When one component grows more complex or adds features, the rest of the system should not have to take on that complexity. Init is the clearest example. A system could use a feature-heavy init such as systemd, as long as it connects through the API. The desktop and other components talk to the API instead of talking to systemd directly. If the OS later wants a different init, nothing above it has to change.

What the core knows

The core only knows a short list of long-lived kinds of things, and never a specific vendor’s device:

  • Storage: files and directories as objects a program has been handed. There is no global filesystem to browse.
  • Network: sockets stay as they are, since they are already stable. On top of that the core adds a small connectivity-status interface (online or offline, metered or not, which link is active) and thin Wi-Fi and Bluetooth management interfaces for the shell and settings: scan, join, pair, connect and forget. Ordinary apps do not use the management interfaces. They see Bluetooth devices through the audio and input interfaces they already use.
  • Display and windows: create a window, draw into a buffer, receive input. This has to stay fixed so apps look right under every shell.
  • Input: keyboards, pointers, touch and controllers as event sources.
  • Audio: a stream in and a stream out.
  • Time, notifications, clipboard and dialogs: the basics every app needs.
  • Permissions: ask the user for access to something, and get a reference back if they agree.

The test for what belongs is lifespan. The core can know about long-lived kinds of things, such as files, windows, Wi-Fi and Bluetooth, which are decades old and are not going anywhere. It never knows about fast-moving or vendor-specific ones. GPU vendors, Wine, Waydroid, and Windows versus Android all stay outside. Only these stable abstractions have to hold still, so everything beneath them can change as often as it likes.

A native program does everything through a few calls: get a reference to something, send it a message, read or write one of its slots, release it. Everything else is an object reached through those calls. These ideas (objects, references, messages) are decades old, and that is deliberate. Nothing goes into the core unless something like it has already survived for a long time somewhere else.

Why C, and how the interface stays stable

C is a good fit for a stable binary interface. It has a long history, it is used everywhere, and it lacks the metaprogramming features that open a gap between what the source promises and what the compiled code does. It is not perfect. Inline functions and macros in public headers end up baked into other people’s binaries. The fix is to export symbols through map files, so the linker and loader enforce exactly what is public.

  • The abstractions describe relationships, like “something you can read from” or “something you can send a message to,” and say nothing about what the thing is. New hardware and new ideas can attach later without changing the core.
  • Interfaces are versioned. Nothing is ever removed. A mistake gets a v2 next to the v1.
  • The written documentation is the contract, and the compatibility tests come straight from it. A guarantee that is painful to document is probably too complicated to keep.
  • Graphics and audio pass shared buffers by reference, so nothing gets copied and there is no message for every frame.

The services behind the API

  • Init and service manager. Starts, stops and supervises services behind a stable interface. Nothing else goes around it. What runs underneath is up to whoever ships the system.
  • App lifecycle. Launch, suspend, resume and quit. Suspend and resume is hard to get right, and users notice immediately when it is wrong, so it belongs in the core.
  • Permission broker and sandbox. Hands out references and confines foreign code through a wrapper for each subsystem. More on this under Security below.
  • Subsystem registry. A table that maps each kind of binary to the subsystem that runs it.
  • Package format and install rules. What installing, removing and updating mean, defined once and kept stable.
  • The C library. A stripped-down fork of musl that talks to the core instead of making raw system calls. A libc is a promise that lasts a decade, and the risk is getting it wrong, not failing to be original. musl is small, permissively licensed and already well tested, and the target is a fraction of glibc’s size.
  • Facades over existing parts. For display, audio and networking, wrap what already exists (Wayland, PipeWire, iwd or wpa_supplicant for Wi-Fi, BlueZ for Bluetooth) behind the core’s API first, and replace a layer only when the wrapper cannot hide the problem. New display or audio stacks take years and sink projects.

Left out of the core: GPU drivers, newer or vendor-specific radios such as cellular, Thread and UWB, Wine and Waydroid, the shell, theming, default apps, branding and onboarding. Drivers ship in the kernel bundle, compatibility layers and newer radios are subsystems, and the look and feel belongs to whoever ships the system. A company can restyle everything above the API without breaking a single app, because the window, input and dialog API underneath does not move.

Getting other projects to use it

Building a common API is the easy part. Getting other projects to use it is hard. The seatd project is a useful lesson. It gives desktops a clean interface for something they currently get from systemd’s logind, and GNOME and KDE still have not made an effort to adopt it. So this platform does not wait for upstream to cooperate. Its own shell and native stack are built against the API, and foreign software gets wrapped. The cost is that the platform has to own more of the system itself.

Subsystems

Anything that brings its own world with it is a subsystem. Wine and Proton bring Windows. Waydroid brings Android. They sit next to the core as recognized parts of the OS and run the way they run on Linux today, with no porting. The core keeps a registry that maps each kind of binary to its subsystem, so launching a Windows program starts Wine automatically. This is close to how Linux’s binfmt_misc hands programs to Wine today, and how Windows NT handled its own subsystems.

They are not rebuilt inside the core because they are large, fast-moving projects with their own developers, and a translation layer like that is never finished. Microsoft tried it with the first version of WSL and later replaced it with a design built on a real Linux kernel. Pieces of a subsystem can move into the core later when it is cheap, for example when a piece is small, performance-critical, or removes a dependency. Nothing promises the move will ever be complete. Ordinary programs do not need any of this. They are native, and only foreign worlds get to be subsystems.

The kernel bundle

The kernel, graphics drivers (Mesa) and firmware ship together as one tested bundle for each hardware family. That gives one test matrix and a clear line of support: the bundle and the core belong to the platform, and everything above belongs to the customer. The core only asks the kernel for raw mechanisms like memory, scheduling and device access, so the kernel could be replaced in principle. In practice it is Linux, because Wine and Mesa expect Linux interfaces.

Why the package model works here

The closest existing model for the package format is the macOS app bundle: a folder that gets copied into place, leaves the system’s libraries out, and can hold several executables. AppImage tried the same idea on Linux and never took off, largely because Linux has no common set of libraries an app can assume. This platform supplies that set. A game might bundle SDL2 and nothing else, which keeps packages small and avoids a heavy runtime. Developers manage dependencies inside their own app, and OS maintainers keep the userspace sane.

Security

The core idea is that to touch something, a program has to hold a reference to it. A program that starts with nothing can reach nothing. Native programs work this way directly.

Foreign binaries are handled differently. The subsystem registry already knows which subsystem each binary belongs to, so every subsystem gets a special-built wrapper: code that understands that subsystem and knows how to protect against its binaries. A Windows program and an Android app are different kinds of risk, and each wrapper is written with that in mind. A small sandbox, targeted at about 5,000 lines of C, does the enforcing with Linux’s own tools (namespaces, Landlock and seccomp), and access is handed over through the core.

Security is hard to keep modular because it sits at the center of how a system works, and Linux’s security primitives are weak. OpenBSD is a good reminder of how much a small, integrated system can do. Giving each subsystem its own wrapper is how this design stays modular without treating every foreign binary the same way.

The organization behind it

The technology will not carry this alone. It needs people who are paid to maintain it for years, and those people need an employer that makes money from the result. Volunteers have had about thirty years. In the Linux world a problem usually gets fixed only when a corporation steps in and has a reason to fix it. The parts that work best are the ones where that is true: the kernel has paid engineers, Mesa is funded largely by Valve, Intel and AMD, and Android has Google.

The proposal is to do what Google and Microsoft do and pay professionals to maintain the unglamorous parts of the OS, but split the work across many small companies instead of one big one. It would be a decentralized network, not a monolith.

  • About a dozen independent companies. They all share one tiny core, so a company can be as small as five people.
  • Each one sells a stable OS platform that its customers brand as their own. The customers are hardware and device makers who need an OS but do not want to run an OS business.
  • The core is the only thing the companies share. They agree to stay compatible with it.
  • Everything else belongs to each company: name, trademark, products, hardware focus, support and pricing.
  • The customer keeps their own product, brand and interface. The company maintains the platform and promises compatibility for ten years.

The whole structure depends on the core staying small. If the core needs more than about five people to maintain, the model stops working. That is why so many of the choices above favor taking a part from upstream, wrapping what exists, or pushing something out to a subsystem.

Companies already pay for Linux maintenance. Red Hat and Canonical sell it for servers, and for specialized desktops and devices such as studios and embedded systems. The method is the same everywhere: freeze a narrow stack and keep patching it. That works when the workload stays fixed. It does not work for a general desktop user whose hardware and apps keep changing, and nobody has a model for that case. This plan sells a stable interface that holds while the parts underneath keep changing.

The funding problem is real. The companies have to be profitable, and each one has to work out how to get there. Customers pay once they believe something works, and it only works once somebody has built it, so the early months have to be paid for before revenue arrives. Likely buyers are companies like Valve and System76 that want an OS but do not want to spend the time and money to build and maintain one. How a company covers the early period is its own decision. It could be an anchor customer, contracts, hardware sales or something else.

Limits of this design

  • Linux is still the kernel in practice, because Wine and Mesa expect its interfaces.
  • Each subsystem needs its own security wrapper, so adding a subsystem also means writing and maintaining one.
  • The size targets (about 5,000 lines for the sandbox, a C library at a fraction of glibc) are estimates, not measurements.
  • Which Lisp dialect to use is still undecided.

Q&A

The project is intended to address three related problems:

1. The Linux userspace does not provide sufficiently strong, long-term compatibility guarantees for applications.

2. Application packaging, system compatibility, and security are often combined into large and complicated systems.

3. Linux distributions offer a fragmented target for developers, making it difficult to build software that remains usable across different systems for many years.

The goal is not merely to create another package format. It is to create an open platform with a stable userspace, a durable application-facing API, a simpler application distribution model, and clearly separated responsibilities between the operating system, application publishers, repositories, and security infrastructure.

In the article I describe the project as an attempt to bring a Windows-NT-like compatibility promise to an open platform: applications should be able to depend on a stable foundation for (ideally) decades rather than merely on the compatibility practices of individual libraries or distributions.

No. The criticism is not primarily directed at the Linux kernel. The kernel has maintained strong userspace compatibility for a long time.

The concern is the broader userspace environment: system services, libraries, initialization, application lifecycle, permissions, desktop integration, and other interfaces that applications depend upon. A stable kernel alone does not guarantee that applications will continue working across changes to the rest of the operating system.

The proposed compatibility layer is therefore intended to sit above the kernel and provide a durable application-facing contract.

Linux has important compatibility guarantees, but they are not sufficient for the broader goal being proposed.

The kernel provides strong compatibility for its system-call interface. Many individual libraries also maintain compatibility, and applications can sometimes preserve old dependencies indefinitely. However, this does not automatically create a coherent, stable application platform across distributions.

The problem is not that every Linux component breaks compatibility constantly. The problem is that Linux does not offer a single, sufficiently strong contract covering the complete environment an application relies upon. Compatibility often depends on:

  • Which distribution is being used
  • Which versions of libraries are available
  • How system services are implemented
  • Which assumptions an application makes about the host system
  • Whether a library considers an old interface officially supported
  • Whether a distribution continues shipping a required component

The proposed system would establish a more deliberate and long-lasting contract instead of relying on compatibility emerging inconsistently from many independent projects.

The concern includes cases where changes to userspace components break older software, including changes associated with system infrastructure and libraries such as glibc.

Exhibit A https://x.com/Plagman2/status/1559683905904463873

And if you examine the contributors at the userspace level, you’ll see for yourself how many are breaking clearly significant structure.

The important point is not that every such case represents a conventional public API break. Software can break when it relies on behavior, symbols, internals, or compatibility details that maintainers no longer consider worth preserving. From the perspective of the affected user, however, the result is the same: software that previously worked no longer works.

A ten-year-old line of code may still be performing essential work. The proposed platform would adopt a stronger standard: if an interface has been made available to applications, it should be preserved for as long as reasonably possible, even if maintainers consider the old use case unusual, deprecated, or inconvenient.

This does not eliminate human error. It reduces the number of situations in which ordinary maintenance decisions can unexpectedly invalidate older applications.

It includes a compatibility layer, but that description is incomplete.

The proposed layer is not intended to replace every Linux library or emulate an entire foreign operating system. It would define stable operating-system facilities that applications can rely upon, including areas such as:

  • Initialization
  • Service management
  • Application lifecycle
  • Permissions
  • Desktop integration
  • Other core operating-system behavior

Applications would still be able to use established interfaces such as OpenGL, Vulkan, and traditional sockets where appropriate. The purpose is to reduce dependence on unstable or distribution-specific implementation details, not to make the rest of the userspace irrelevant.

Flatpak is useful, and the argument is not that Flatpak has no value. It provides a practical application distribution mechanism, sandboxing, runtimes, and a common target for developers.

The concern is that Flatpak addresses too many different problems at once. A Flatpak-based application generally depends on an ecosystem containing:

  • The Flatpak subsystem
  • Runtimes
  • Sandboxing and permission mechanisms
  • Repository metadata
  • Update infrastructure
  • Security maintenance
  • Tooling and integration with the host operating system

This makes the application portable within the Flatpak ecosystem, but the problem it introduces is dependency on an overly-complex, online subsytem.

The proposed approach separates these responsibilities. And it reduces complexity, no need for an over-engineered subsystem running on your stack. The operating system maintains a stable userspace and application-facing API. The application package carries dependencies that are not part of that contract. Security is treated as a separate subsystem, and application distribution can work either through repositories or independently, reducing online dependence.

Organizational backing is a real strength of Flatpak and Snap. A project with substantial resources can maintain tooling, infrastructure, repositories, runtimes, and security updates.

However, that strength also reflects the amount of infrastructure the system requires. The question is not whether maintenance is necessary; everything requires maintenance. The question is how much must be maintained and where the responsibility belongs.

The proposed platform would try to keep the package format and compatibility infrastructure smaller. A relatively small independent organization, perhaps a handful of committed maintainers, could maintain the format, tooling, compatibility tests, and reference implementation. The operating-system maintainers would maintain the stable userspace, while application publishers would maintain their applications and bundled dependencies.

This is not a guarantee that the project will succeed. It is a claim that the maintenance burden can be made more limited and clearly divided.

The operating system or distribution implementing the platform would maintain it.

That maintenance cost cannot be eliminated. The difference is that the stable userspace would be the central responsibility of the operating system rather than something reconstructed indirectly through every application runtime and packaging framework.

The platform would also need:

  • A compatibility specification
  • Automated compatibility testing
  • A policy for deprecation
  • Long-term support procedures
  • Documentation for application developers
  • A reference implementation
  • A process for reviewing changes that could break applications

The project is not claiming that stability happens automatically. It is proposing that stability should be an explicit design objective and institutional responsibility.

Then it can fail, just like any other project.

The proposal does not provide a magical guarantee against abandonment. Its intended advantage is that the system should be easier for a small group to understand, maintain, fork, and replace than a large stack combining packaging, runtimes, sandboxing, repositories, permissions, and updates.

The platform should also avoid making applications permanently dependent on one central organization. Packages should be usable offline, transferable, archivable, and capable of being detached from one repository and synchronized with another. Compatible implementations should be able to preserve the application-facing contracts even if the original organization disappears.

Adoption is not guaranteed.

The project is not intended to force existing Linux distributions to change. It would begin as an independent system and reference implementation. Other projects could adopt its interfaces, create compatible implementations, or build derivatives voluntarily.

The expectation is that adoption would come from demonstrated usefulness: a stable userspace, durable application compatibility, a convenient distribution model, and a more coherent user experience. That is a bet, not a certainty.

The project would introduce another platform, so the criticism is valid as far as it goes.

The distinction is that this is not intended to be merely another optional package format competing for attention inside ordinary Linux distributions. It is a new open platform with its own architecture and userspace contract.

The goal is not to make every existing distribution support the platform immediately. The goal is to create a system whose internal design is coherent enough that users and developers choose it because it offers something existing systems do not.

That still creates a network-effect risk. The project must attract users, developers, maintainers, and applications. The proposal does not remove that risk; it accepts it in exchange for pursuing a cleaner foundation.

Using Debian would make sense if the project only needed a stable distribution base and conventional Linux compatibility.

That is not the plan. The proposed architecture depends on a custom userspace foundation and a different separation between the operating system, application packages, and security infrastructure. Building on an existing distribution would inherit many of the assumptions the project is trying to change.

Debian is a valuable and comparatively stable project, but it is still part of the wider GNU/Linux ecosystem whose userspace contracts are not strong enough for the proposed long-term compatibility goal. The project is therefore not simply trying to create a better Debian derivative.

Yes, at the conventional Linux userspace level, but not arbitrarily.

The platform is not intended to promise compatibility with every existing Linux distribution. It is intended to provide a new, more stable application target.

That means there would be a transition cost. Existing Linux applications might need to be ported, repackaged, or adapted. The justification is that compatibility with an unstable or inconsistent foundation is not enough. A new platform may be worthwhile if it offers a stronger long-term contract and a simpler development model.

The proposal aims for compatibility within its own stable platform (of which, many derivatives can be made of), not universal binary compatibility with every existing generic Linux system or stack.

Technically, Android is a Linux distribution because it uses the Linux kernel. However, it is commonly treated as a distinct operating-system platform because it has its own userspace, APIs, application model, and hardware assumptions.

That distinction matters here. The project is not intended to be another conventional distribution built from the standard GNU/Linux stack. It is intended to be an independent open platform that uses Linux where useful but defines its own application-facing foundation. Where Android uses a virtual machine to define its foundation, this project will instead use a typical self-sourced userspace stack with a C-style API interface.

Compatibility has two meanings.

For users, it means that the applications they want are available and continue to run on the platform.

For developers, it means that supporting the platform should not require repeatedly changing how applications are built, compiled, packaged, or maintained.

The proposed platform therefore needs to provide both:

  • A stable environment in which applications continue to run
  • A predictable development and packaging target that developers can support without maintaining a separate solution for every distribution

Simply having a stable API is not enough if no applications are available. Conversely, having many packages is not enough if they depend on a constantly changing environment.

The proposed package format is AppImage-like, but it is not necessarily the AppImage format itself.

It is inspired by some of AppImage’s strengths, particularly its ability to distribute applications independently of a central repository. However, the package format would be designed as part of a broader platform with a stable userspace and application-facing API.

A conventional AppImage may need to bundle a large number of libraries and may still depend on assumptions about the host system. The proposed platform would provide a stable userspace and application-facing API so that applications would not need to bundle the entire operating system merely to survive ordinary host changes.

Applications could include libraries, application-specific runtimes, or even their own C library when necessary. Complete self-containment would be optional rather than mandatory.

Yes. An AppImage-like package does not magically eliminate dependencies.

That is why the proposal is not simply “use AppImage and stop there.” The package format would be combined with a platform whose userspace and application-facing APIs are stable by design.

System-level dependencies would be handled by the platform’s userspace contract. Dependencies outside that contract could be included in the application package. This is intended to avoid both extremes:

  • Blind dependence on an unstable host system
  • Requiring every application to duplicate the entire operating system

Packages could be obtained in several ways:

  • Downloaded directly
  • Installed from an offline source
  • Installed from a repository selected by the user
  • Copied or archived for later use
  • Synchronized with a repository after initially being installed independently
  • Detached from a repository and used independently

The repository would therefore be a convenience rather than an unavoidable dependency. Repository-based and standalone distribution would be compatible states rather than mutually exclusive models.

No.

Repositories could exist, but the platform would not require one central repository or one vendor-controlled source. Users and organizations could select repositories, deploy packages directly, or maintain private distribution channels.

The design goal is to support centralized and decentralized distribution simultaneously:

  • Centralized repositories for convenience
  • Independent downloads for flexibility
  • Offline installation for reliability
  • Private repositories for organizations
  • Portable packages for archiving and migration

Security would be treated as a separate concern from application distribution.

That does not mean packages would be trusted automatically or that security would be ignored. It means that application packaging should not be responsible for solving every security problem at the same time.

The eventual platform would need a clear verification and trust model for package authenticity, updates, permissions, sandboxing, and repository integrity. The article intentionally does not finalize the precise verification mechanism. Its main claim is that security should be designed as an independent subsystem rather than being inseparably coupled to the application package format.

Nix is not being rejected as a technical model. In fact, the project already plans to use a unified language with several properties that make Nix powerful.

The system will use a Lisp-derived language throughout the platform, including:

  • Package configurations
  • System configurations
  • Application definitions
  • Service descriptions
  • Build and deployment declarations
  • The interactive terminal shell

This language is intended to behave consistently across those contexts, in much the same way that Nix provides a unified declarative model for package and system configuration. The difference is that the project will use a flavor of Lisp rather than the Nix expression language.

The objective is to preserve the benefits of a unified configuration and package language while integrating it more deeply into the operating system and user environment. The same language should not only describe packages but also function as a practical interactive shell.

Therefore, the project is not proposing a simpler model by abandoning the expressive and unified aspects associated with Nix. It is proposing to use those ideas within a different platform architecture, with a stable userspace and an AppImage-like application distribution model.

It is both.

The technology must provide a stable userspace, a durable API, workable packaging, compatibility testing, and a practical distribution system. But none of those will matter without maintainers, developers, users, documentation, funding, and adoption.

The project is therefore not claiming that a technically elegant design automatically wins. Politics, marketing, resources, and network effects matter in open source as well.

The article is an attempt to find people interested in taking that risk and helping establish the platform. It is not an assertion that adoption will happen solely because the design is theoretically better.

Yes. Merit alone is not enough.

Politics, marketing, developer incentives, existing user bases, funding, and institutional support all influence adoption. AppImage shows that a technically simple format can gain adoption when developers can use it independently, but a stable userspace is a much deeper commitment and cannot be adopted as effortlessly.

The project would therefore need more than a good design. It would need:

  • A working reference implementation
  • Developer tooling
  • Documentation
  • Compatibility tests
  • Early applications
  • A compelling user experience
  • A community of maintainers
  • A sustainable funding model
  • A strategy for attracting users and developers at the same time

The claim is not that merit guarantees success. The claim is that a useful implementation can provide a foundation around which those other factors can develop.

Yes. This is one of the project’s central risks.

The project would need to break that cycle through some combination of:

  • A focused initial use case
  • Early support from developers who share the compatibility goal
  • Compatibility tooling that makes porting straightforward
  • High-quality development tools
  • A small number of compelling applications
  • Support from hardware vendors or platform projects
  • A clear advantage for a particular audience, such as gaming or specialized workstations

The proposal does not make the network effect disappear. It argues that the current Linux ecosystem’s fragmentation is already imposing costs, and that a new platform may be worth pursuing if it offers a sufficiently better foundation.

That would be one possible route, but it may be difficult because distributions have different goals, design philosophies, release models, init systems, package systems, and institutional interests.

The proposed platform instead starts with a coherent implementation. Other projects could later adopt compatible interfaces or borrow parts of the design if the approach proves useful.

This does not require every distribution to move in lockstep. It requires one platform to demonstrate that a stable userspace and clearer application contract are practical.

No.

The project is not asking Debian, Fedora, Arch, Ubuntu, or other distributions to immediately abandon their current systems. It is proposing an independent platform that people could voluntarily adopt, implement, fork, or extend.

Existing distributions could remain exactly as they are. The project’s success would depend on whether users and developers found the alternative valuable enough to support.

No. It is an advocacy paper and an invitation to collaborate, not a finished implementation specification.

The purpose of the article is to describe the problem, outline the intended architecture, and attract people interested in developing the project. It does not yet specify every ABI rule, compatibility policy, package-verification mechanism, security boundary, toolchain detail, or migration path.

Those details would need to be developed through technical design documents, prototypes, testing, and implementation work.

The userspace would provide the stable foundation that applications are allowed to rely upon. This would include operating-system facilities such as:

  • System initialization
  • Service management
  • Application lifecycle management
  • Permissions
  • Desktop integration
  • Stable application-facing APIs
  • Other platform-level behavior

It would not necessarily replace every existing Linux interface or dictate one implementation of every graphics, networking, or multimedia library. The aim is to stabilize the parts of the system that applications need while allowing implementation freedom underneath.

No.

The project may provide a small, simple, backward-compatible C library, but applications would not be required to use it if another implementation better suits their needs.

Applications could bundle libraries and dependencies that fall outside the operating-system compatibility contract. They could also bundle a more complete userspace when there is a specific reason to do so. The intended model is flexibility within a stable platform, not mandatory use of one implementation.

Yes.

Packages would not necessarily be limited to one executable. They could contain supporting applications, tools, or components and express relationships between them.

The Lisp-based definition and configuration layer is intended to describe package contents, dependencies, metadata, configuration, and required behavior. The same general mechanism could describe reproducible system configurations, installed services, permissions, and system state.

No.

The project would initially benefit from a reference implementation and a small organization capable of maintaining the format, tooling, and compatibility work. But the interfaces should be open enough for other organizations or individuals to create compatible implementations.

The intended model is closer to an open platform specification than a permanently centralized service. Compatibility should ultimately come from shared contracts and implementations, not from dependence on one vendor-controlled repository.

No. It is a deliberate risk.

The argument is that the existing ecosystem has structural weaknesses that are not adequately addressed by adding more layers to the current stack. A new platform could fail because of insufficient adoption, inadequate funding, technical mistakes, or competition from established projects.

The project is being pursued because the potential benefit of a stable, open, long-term application platform appears worthwhile despite those risks.

No.

The criticism is directed at the structure and incentives of the current ecosystem, not at the competence or intentions of individual developers. Existing projects solve real problems under difficult constraints.

The claim is that the ecosystem has not produced the level of stable, long-term userspace compatibility being proposed. Respecting the work of existing projects does not require accepting their design trade-offs as sufficient for every future use case.

The purpose is not merely to obtain compatibility at any cost. The goal is to create an open platform with strong compatibility guarantees.

Windows demonstrates that long-term application compatibility is possible, but it does not provide the openness, inspectability, independence, and user control that this project seeks. The project is intended for people who want those properties without accepting the weaker compatibility contract common in the Linux ecosystem.

Application compatibility should be built on a deliberately stable operating-system foundation, while application packaging, distribution, and security should remain separate concerns.

Success would mean that an application developer could target the platform once and reasonably expect the application to continue working for many years, across compatible implementations, without rebuilding the entire application for every distribution.

For users, success would mean that applications could be:

  • Installed from repositories
  • Downloaded independently
  • Used offline
  • Copied between systems
  • Archived for long-term use
  • Updated without being permanently tied to one distribution channel

For the wider ecosystem, success would mean that compatibility comes from a clear, durable contract rather than from every application independently defending itself against userspace fragmentation.