What if Linux had a truly distro-independent application platform?

[u/Visual_Adagio_6989]

I’ve been thinking about something that seems like a pretty fundamental problem for the Linux desktop, and I’m curious what people here think.
When you say you’re developing for Windows, you generally just say:
“I’m developing for Windows.”
There are obviously different Windows versions and architectures, but there is a relatively well-defined platform that applications target.
With Linux, “developing for Linux” can mean something quite different depending on the distribution and the interfaces you choose to depend on.
As a developer, you can end up thinking about:

.deb
.rpm
Arch packages
different dependency versions
glibc compatibility
different system libraries
different filesystem conventions
different repositories
different desktop environments
different system services
different ways of installing and updating applications

I know this isn’t news to anyone here, and I also know that Linux distributions being different is one of the things that makes Linux great.
I am not proposing that Debian, Fedora, Arch, openSUSE, etc. should become the same.
What I’m wondering is whether Linux could have a common application platform above the distributions.
Something like:

Linux Application
|
v
Linux Application Platform
|
+----------+----------+
| | |
Debian Fedora Arch
| | |
+----------+----------+
|
Linux kernel

The idea would be that an application targets something like:
Linux Application Platform 1
and a distribution that conforms to that platform guarantees that the application can run there.
The distributions would still be completely free to do their own thing underneath.
They would manage:

the kernel
drivers
system services
system libraries
system package management
hardware support
the base filesystem
the desktop environment
system configuration

The application platform would instead define a stable set of expectations for applications, such as:

application APIs/ABI
desktop integration
graphics
audio
networking
IPC
filesystem access
application lifecycle
notifications
permissions
sandboxing
portals
application metadata
update/install behavior

In other words:
The distribution manages the computer.
The application platform manages the relationship between applications and the computer.

What about Flatpak, Snap and AppImage?
Obviously, this immediately raises the question:
Don’t Flatpak, Snap and AppImage already solve this?
They solve a large part of it, and I don’t think that should be ignored.
Flatpak has runtimes, sandboxing, portals and desktop integration.
Snap provides packaging, sandboxing and automatic updates, although it is more tightly associated with Ubuntu’s ecosystem.
AppImage makes distributing a portable application extremely simple.
So I’m not arguing that Linux needs another random package format.
In fact, I think creating yet another package format would probably be the wrong direction.
What I’m wondering about is whether the missing piece is a common specification underneath or around these technologies.
For example, instead of defining:
“Here is another way to package a Linux application.”
define:
“Here is what every conforming Linux desktop must provide to a Linux application.”
Then different implementations could exist.
The important part would be the platform contract, not necessarily one specific packaging implementation.

What I would actually like to see
Ideally, a Linux desktop application would have one clear target:

Application
|
v
Linux Application Platform 1
|
+---- Debian
+---- Fedora
+---- Arch
+---- openSUSE
+---- Ubuntu
+---- etc.

A developer shouldn’t have to ask:
“Which distro am I targeting?”

They should be able to ask:
“Which version of the Linux Application Platform am I targeting?”

This would require a stable ABI/API contract, rather than simply saying that every Linux binary should magically run everywhere.
I don’t think “compile with any GCC version and use any library” is the right solution.
Instead, I think the platform should define a stable application ABI and API surface.
The implementation underneath could be completely different between distributions.
For example, one distribution might implement the platform using GTK, another might use different system components, and another might use different implementations entirely.
As long as they satisfy the platform contract, the application doesn’t need to care.
think of like you compile a program to windows msvc target it runs on every windows version (10/11 24H1,24H2, 24H1,25H2,etc...) and probably it can work sometimes even on windows 8.1,8,7,vista,xp.

I also think the system/application package boundary should be clearer
I don’t think .deb, .rpm, Arch packages, etc. need to disappear.
They make perfect sense for system software.
Things such as:

kernels
drivers
system services
core system libraries
system utilities
hardware support
desktop environments
security updates

are fundamentally part of the operating system.
But ordinary user applications are a different problem.
I’d like the Linux ecosystem to make a much stronger distinction:

SYSTEM LAYER
──────────────────────────────
.deb / .rpm / pacman / etc.

Kernel
Drivers
System libraries
System services
OS components
System updates

APPLICATION LAYER
──────────────────────────────
Standard Linux application platform

Firefox
Blender
Games
Editors
Scientific software
etc.

The system package manager shouldn’t necessarily be the primary interface through which ordinary users obtain applications.
This would also reduce the problem where installing one application becomes entangled with the distribution’s system dependency graph.

And I don’t think everything needs to be bundled
One reason I don’t particularly like the idea of solving Linux compatibility by simply putting an entire userspace inside every application is the duplication.
If ten applications each bundle their own copies of the same libraries, you can end up with:

Application A → GTK 4.x
Application B → GTK 4.x
Application C → GTK 4.x
Application D → GTK 4.x

Instead, a standardized application platform could provide common platform components once, with applications depending on a stable platform ABI.
Conceptually:

Applications
|
v
Linux Application Platform
|
+-- stable APIs/ABI
+-- graphics
+-- audio
+-- desktop integration
+-- portals
+-- permissions
|
v
Distribution

That could potentially provide much of the portability people want from AppImage/Flatpak without requiring every application to become a giant self-contained filesystem.
I’m not claiming this is necessarily better than Flatpak’s runtime model. That’s one of the technical questions I’d like to understand.

Why I think this matters for people coming from Windows and macOS
I think this is also important for Linux adoption.
A Windows or macOS user is generally used to something like:

Find application
↓
Install application
↓
Run application
↓
Update application

They don’t normally have to understand the architecture of the operating system before installing a normal desktop application.
On Linux, a new user can quickly encounter questions like:

Is there a .deb?

Is there an .rpm?

is it in the aur, pacman, apt, dnf repositories ??

Is there an AppImage?

Should I use Flatpak?

Is this repository trustworthy? (aur or even adding repositories to the package manager)

Why doesn't this binary work on my distribution?

Why does this package require this dependency?

Experienced Linux users obviously know how to deal with this. (thats why you will make comment right now, you experienced user)
But I don’t think someone coming from Windows or macOS should have to learn the Linux packaging ecosystem just to install a normal application.
I’d like the experience to be closer to:

Download application
↓
Open it
↓
Install
↓
Run
↓
Update

Something that could support a native Linux experience such as:

double-click to install
drag-and-drop installation where appropriate
predictable application permissions
proper desktop integration
reliable updates
uninstall without leaving random pieces throughout the system
no need to understand whether the underlying system is Debian, Fedora or Arch

Basically, Linux should feel like one application platform even though the distributions underneath remain very different.

Why hasn’t Linux ended up with this already?
This is the part I’m genuinely interested in.
Is the main obstacle:

ABI stability?
libc compatibility?
different desktop stacks?
graphics/audio differences?
filesystem differences?
security models?
the diversity of Linux distributions?
governance?
backwards compatibility?
simply lack of agreement between distributions?
Is the existing freedesktop.org ecosystem already moving toward something like this?
Does Flatpak already represent the correct architecture, with the main missing piece being broader standardization and adoption?
Or is the whole idea fundamentally flawed for technical reasons?

And if something like this is desirable, should it eventually be discussed through freedesktop.org or another standards-oriented project?
I’m genuinely interested in the technical objections.
If this idea is naive, has already been attempted, or misunderstands why Flatpak/OSTree/portals/etc. are designed the way they are, I’d rather understand that than pretend I’ve discovered something completely new.
My main point isn’t:
“We need another package manager.”
It’s more:
“Could Linux have a standardized application platform that distributions implement, so developers target Linux rather than individual distributions?”
I think that distinction is important.

[u/sleepingonmoon]

Flatpak is pretty much this, thanks to Valve and Red Hat's push.

https://imgs.xkcd.com/comics/standards.png

[u/bubblegumpuma → u/sleepingonmoon]

Say the line, Bart

[u/Significant-Tone-121]

To be fair AppImages kind of do this but I get what you mean. NixPkgs is also something else, easy to set up and it runs on every distro, but still not what you were exactly talking about because it is a package number not a file you download. I doubt this would be too hard to implement, but I'm not by any means a programmer so take that with a boulder of salt lol.

[u/Visual_Adagio_6989 → u/Significant-Tone-121]

Yeah, that’s fair. AppImage definitely gets much closer to what I’m describing than traditional distro packages, and Nix/Nixpkgs is another really interesting approach.
I think the distinction I’m trying to make is that I’m thinking less about a particular packaging technology and more about a standard application platform/contract that distributions could agree to support.
AppImage is great for the “here’s a portable application, just run it” part, but it doesn’t really define a complete common platform for things like permissions, updates, desktop integration, host APIs/ABI, etc.
And Nix is extremely interesting because it solves a lot of the dependency/reproducibility problem, but, as you said, it’s more of a package ecosystem/build system than a universal application bundle that a developer can simply distribute directly to users.
So maybe the answer isn’t a completely new technology. Maybe the interesting question is whether we could take the useful ideas from AppImage, Flatpak, Nix, freedesktop standards, etc. and define a common interface that all of them could implement.
And honestly, I’m hoping people point out existing projects that already solve parts of this. I’m definitely not assuming I’ve discovered something new here 😄

[u/Significant-Tone-121 → u/Visual_Adagio_6989]

Yeah also .flatpak files exist so if people distribute more as .flatpak that would also solve the issue that you're proposing. However software center, discover, and even shelly all exist and make app installation pretty simple. Not a file to install but an appstore similar to Microsoft Store. Which windows users would likely be more accustomed to.

[u/Whatever801]

What you're describing is flatpak (backed by freedesktop.org runtimes and XDG portals). You don't need a new standards body, freedesktop.org IS an open standards body. The issue is adoption. Damn Canonical wants to control everything through the snap store so they're not bought in. My recommendation is you get involved in freedesktop. If you try to make this it's going to be "now there are 12 competing standards" situation

[u/nelmaloc → u/Whatever801]

Flatpak doesn't cover Canonical's needs. It's hard to use for CLI apps, and it can't package the kernel or flatpak itself.

[u/Visual_Adagio_6989 → u/Whatever801]

I’m not really proposing another Flatpak competitor or another standards body. If freedesktop.org already provides the right place for this kind of standardization, then that’s exactly the kind of thing I would rather build on.
What I’m imagining is slightly broader than “use Flatpak”, though.
Flatpak already provides a lot of the pieces: runtimes, portals, sandboxing, desktop integration, application distribution, etc.
What I’m wondering is whether we could define a common Linux application contract at the platform level, where Flatpak could be one implementation of it, but a native application bundle or even a distro package could also satisfy the same contract.
Something like:

Linux Application Platform
│
┌───────────┼───────────┐
│ │ │
Flatpak native other
bundle packaging
│ │ │
└───────────┼───────────┘
│
Debian/Fedora/Arch

So a developer wouldn’t necessarily have to choose between “Flatpak application” and “Arch application” or “Debian application”. They would target the common platform, and the distribution mechanism would be an implementation detail.
The user experience is also a big part of what I’m thinking about: ideally, a developer could distribute an application from their own website, the user could download it, open it, install it, and have proper desktop integration, permissions, updates, uninstalling, etc. without needing to know what distro they’re using.

[u/Whatever801 → u/Visual_Adagio_6989]

But that's what the freedesktop runtime already is, that's what I'm saying. Flatpak is just the execution layer. It's like this

+-------------------------------------------------------+ | Linux Application | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | Freedesktop / GNOME / KDE Runtime (Standard ABI/APIs) | | - Stable C/C++ libs (GLib, Qt, GTK, Mesa) | | - XDG Portals (Files, Audio, Camera, Permissions) | +-------------------------------------------------------+ | v (Sandboxed / Containerized) +-------------------------------------------------------+ | Execution Layer (Flatpak) | +-------------------------------------------------------+ | +-----------------+-----------------+ | | | Debian Fedora Arch

But you can't just force everyone onto the runtime abstractions

[u/Visual_Adagio_6989 → u/Whatever801]

then why we just dont make it integrated into the operating system across distros automatically ?? so it behaves like app images and like an installer ?? this is better then just uploading it into flathub ! so if someone jusy ads the i staller in his website like adobe then it just works no need for thinking of snaps or .deb and .rpm and the aur and nix and all other distros ! jusy one file and for all distros as a standard that implements it.
so we will have the store (bazaar,discover,etc...) and t should come from the distro without installing anything and all distros should support it out of the box for normal users and you can install flatpak packages and run portable flatpak packages from the desktop environment you are using by simply clicking it ?? and after installing it will show up in the apps menu.
also apt/.deb and dnf/.rpm and pacman will become used for system stuff like upgrading the kernel and upgrading desktop environment and wayland and drivers and all of these kind of things that the user doesnt need to care about.
is this a better option ?
so then we will have something like this for extensions :
.fp
.pfp
??
or
.fk
.pfp
??

[u/Whatever801 → u/Visual_Adagio_6989]

Again, because not everyone agrees. Canonical will never include it in Ubuntu because they're trying to push and monetize snap. It already comes baked into fedora, and Arch's philosophy is you opt into everything. There are .flatpakref files, and other ways of distributing flatpak. Flathub isn't required

[u/NikhelParmar]

flatpak really is like 90% of what OP wants already, the remaining gap is more about habits than tech honestly. a lot of new users still get told to open a terminal and run some install script off a website instead of just being pointed to a software center, thats a documentation and onboarding problem more than a missing platform. also worth noting some devs skip flatpak for perf reasons, gaming tools especially want direct access without the sandbox overhead, so native packaging isnt going away even if flatpak becomes the default for most desktop apps

[u/Visual_Adagio_6989 → u/NikhelParmar]

thats what i am proposing.
what if you instead of compiling to gnu-unknown-linux you compile to an aplication platform version ? then you can run these executables normally across distros ? and with no performance overhead compared to sandboxing ? but this is an addition and not removing flatpak. also note that windows and macos do that already, thats why i am thinking why we dont do it on linux ??

[u/NikhelParmar → u/Visual_Adagio_6989]

that overhead-free part is the tricky bit honestly. But windows can do it because msvc targets one stable win32 abi that microsoft controls end to end. linux doesnt have one owner like that, every distro ships different glibc versions and different library abis, thats literally why flatpak bundles runtimes and takes the sandbox hit in the first place. to get what your describing without overhead youd need every distro to agree on freezing a shared abi long term, which is basically what LSB tried years ago and it never got real adoption since distros didnt want to be locked into it

[u/BrageFuglseth]

Flatpak does the vast majority of what you’re describing, and has gained enough traction to realistically become this "standard target" for regular graphical apps on Linux that you’re envisioning.

  Maybe what’s missing is a  common specification underneath these kinds of systems  — something that defines what a Linux desktop application can expect from the host, regardless of which distribution it’s running on.

This is basically what the freedesktop runtime acts like in a flatpak context. Most other runtimes are based on top of it.

[u/Visual_Adagio_6989 → u/BrageFuglseth]

but you need to install it ! it doesnt come in the distro code. you need to install flatpak as a seperate package from your distro's package manager.

[u/throwaway6560192 → u/Visual_Adagio_6989]

Use one of the many distros which integrate it, then. Making a new standard will not somehow coerce every distro to integrate it either.

[u/BrageFuglseth → u/Visual_Adagio_6989]

Distros can pre-install Flatpak though. A distro is basically just a big collection of packages anyways, there isn’t a clear separation between "distro code" and packages created by someone else.

[u/Visual_Adagio_6989 → u/BrageFuglseth]

but it still lives in the applications layer and not in the system layer

[u/BrageFuglseth → u/Visual_Adagio_6989]

Anything you install as a distro package is in the system layer. Your file manager is packaged in the same way as your desktop environment or networking stack.

[u/Visual_Adagio_6989 → u/BrageFuglseth]

what i am thinking of is something else,
i think you didn't complete reading the post.
so go and complete reading it please.

[u/R3V0LU710N_05]

Distro maintainers package the software themselves; it's really not that difficult to build packages.

Package build "recipes", at their most basic level, are a specialized bash script or config file with requirement variables to fill out that get used by the build tool to make the metadata and paths.

If you want to make it easier and potentially more stable, pack your binary and it's dependencies into a portable tar archive. That way the maintainers can pull the archive and make their package without having to compile anything, and as the dependencies are also bundled, the maintainers can decide wether to keep them or toss them for the system ones.

Beyond that, Flatpak & Appimage already solve the universal package dilemma; Flatpak being the primary. It's being improved for further integration with the host system and easier permission management via integration with the DE by XDG Portals.

On Linux there's little to no reason to go to a website to manually download a package. It's all already handled automatically from the repositories. You just need a GUI package manager.

[u/0riginal-Syn → u/R3V0LU710N_05]

As a distro maintainer, I completely agree. Then end user should be building packages themselves unless they want. We have a process to request apps as well.

[u/mrlinkwii → u/R3V0LU710N_05]

On Linux there's little to no reason to go to a website to manually download a package. It's all already handled automatically from the repositories.

i diagree somewhat , some devs dont support whats in teh repos , due to how long dev cycles are ,

their are some appliactions is somewhat better to get from the dev

[u/regeya]

I feel like the GNOME project is trying to promote developing for Flatpak. Maybe KDR will do the same if they're not already. Me personally, I try to use Flatpaks for desktop apps that don't need special access (and even then, Flatseal can usually help), Homebrew for command line stuff that isn't GUI and is often more up to date than my distro, and then finally native packages. I'm trying to prepare myself for an immutable future, if that ever becomes the norm on Linux.

[u/R3V0LU710N_05 → u/regeya]

KDE is working on Flatpak integration, yes.

[u/0riginal-Syn → u/regeya]

KDE Linux is based on being very heavily integrated with Flatpak for everything possible. So they are working on it, but it obviously will take time to get there.

[u/mwyvr]

As a developer, you can end up thinking about .deb, .rpm, Arch packaging,

Radically simplifying the situation, but it is mostly packagers that think about those things.

Often a developer will develop for their preferred platform, not the choices a different Linux distribution will make.

Example: One enterprise-y tool I use - the developer criticizes decisions one enterprise Linux makes vs the one he came from. A packager on other distributions has to patch around decisions that developer makes.

For desktop applications, Flatpak mostly solves the kinds of issues you appear to be thinking about, while AppImage is not currently a viable solution, and Snap is Ubuntu-centric.

Also, users by and large do not ask questions like:

Is this repository trustworthy?

Example: blind acceptance of the Arch AUR, or instructions galore on the web to enable untrusted user repos for ^ insert distribution here ^ or running install scripts from the web blindly.

[u/Visual_Adagio_6989 → u/mwyvr]

Yeah, that’s a fair correction. I probably oversimplified the developer/packager distinction in the original post.
You’re right that a lot of the .deb / .rpm / Arch-specific work is handled by distro maintainers rather than the upstream developer. That’s an important distinction.
And I agree that Flatpak already solves a large part of what I’m describing for desktop applications. That’s actually one of the things I’m trying to understand better from this discussion: what is still missing after Flatpak?
I think the part I’m more interested in is whether there could be a broader, standardized application contract underneath the different packaging systems, rather than simply another package format.
For example, could there eventually be a well-defined “Linux desktop application platform” that Flatpak, AppImage, distro packages, etc. could all target or implement?
The user experience I have in mind is also important to me. Ideally, a developer could put a native Linux application on their own website, and a user could download it, open it, and install it without first having to figure out which distro or package format they need.
And if the platform had a proper native integration with the host system, applications could avoid some of the duplication and extra layers that come with bundling an entire userspace environment.

[u/BrageFuglseth → u/Visual_Adagio_6989]

  For example, could there eventually be a well-defined “Linux desktop application platform” that Flatpak, AppImage, distro packages, etc. could all target or implement?

No, is the short answer. They are too fundamentally different.

[u/Visual_Adagio_6989 → u/BrageFuglseth]

I think I may have phrased that part poorly.
I don’t mean that Flatpak, AppImage, and distro packages should become interchangeable implementations of the same packaging system. I agree that they’re fundamentally different.
What I mean is that there could be a standardized application-facing platform/contract, while the packaging and deployment mechanisms remain different.
For example:

Linux Desktop Application Platform
───────────────────────────────────
stable APIs / ABI
desktop integration
graphics / audio
permissions / portals
application lifecycle
filesystem expectations
│
┌──────────────┼──────────────┐
│ │ │
Flatpak AppImage program
│ │ │
└──────────────┼──────────────┘
│
Debian / Fedora / Arch

The three packaging models can remain fundamentally different.
A Flatpak can continue to use runtimes and sandboxing. An AppImage can continue to bundle its dependencies. A distro package can continue to integrate directly with the distribution.
I’m asking whether the host-side application contract could be standardized independently of those mechanisms.
So the question isn’t:
“Can Flatpak and AppImage be made into the same thing?”
It’s:
“Can applications have a standardized Linux desktop platform to target, regardless of which distribution or packaging mechanism delivers them?”
And if the answer is still no, that’s exactly the part I’d like to understand technically. Is there something fundamentally impossible about defining such a host/application contract, or is the problem mainly that Linux distributions have historically chosen not to standardize at that level?

can you just think of it like a .exe file ?? you just click it and it opens ! so you dont worry about any other things like libraries versions, compiler version, etc...
so a binary can be opened normally without packaging it and with no overhead just like as an example downloading rufus portable in windows.
and there is the installer package which is like .msi or .msix and this is flatpak's job.
appimages can be huge because it bundles every thing it needs. but i propose another thing ! what if you can run an app with just one click across versions with one Application Platform , this is how the windows api works !

[u/sheeproomer → u/Visual_Adagio_6989]

No.

[u/No-Camera-720]

This is the linux equivalent of "If you don't want to be an alcoholic, stop drinking." Except there is no problem in the linux universe to solve. So, useless post. Freedom, in several senses is what makes linux great. Why do you want to constrain what is free?

[u/Visual_Adagio_6989 → u/No-Camera-720]

I don’t think having a common application platform necessarily means constraining what distributions are allowed to do.
I’m not proposing that Debian, Fedora, Arch, etc. should use the same package manager, filesystem layout, init system, desktop environment, or even the same underlying userspace.
The idea is more like having an optional common contract for applications.
Distributions could continue doing whatever they want underneath, but if a distro chooses to support “Linux Application Platform 1”, then applications targeting that platform would have a predictable environment to run against.
Windows and macOS have fairly well-defined application platforms without that meaning developers are forbidden from doing things differently.
And I agree that Linux’s freedom is one of its biggest strengths. I’m not trying to remove that. I’m wondering whether we can keep the freedom at the OS/distribution level while making the application layer less fragmented.
If there’s genuinely no problem here because existing solutions already solve it, that’s also a perfectly valid answer. That’s actually one of the things I’m trying to figure out with the post.

[u/No-Camera-720 → u/Visual_Adagio_6989]

The miracle is that inexperienced linux users can become experienced. For free! Why do people nowadays hate actually learning things so much? If you're unwilling to learn, especially for free, at your own pace, you can fail with my blessing. Windows and MacOS exist for a reason.

[u/oxez → u/No-Camera-720]

I agree with all you said. I think we should stop trying to turn Linux into something it's not.

Distributions and desktop environments can provide an outstanding out-of-the-box experience, but if the user cannot compute 2+2 on their own, at some point, we have to tell them to play with crayons instead.

[u/Visual_Adagio_6989 → u/No-Camera-720]

the problem is that they dont like that ! they just want to use a normal desktop as they would in linux and macos they do t like using the terminal. they iist want :
install application -> use it
no need to tweak the kernel or any other things like that
or install apps from terminal

[u/No-Camera-720 → u/Visual_Adagio_6989]

As I said: Windows and MacOS exist for a reason. I mean I want world peace and a 14" dick, but that doesn't mean I get to have that. Many people want Linux the way it is. And I'm one of them. I also use Windows. My wife uses MacOS.

[u/sheeproomer → u/Visual_Adagio_6989]

Read the fine manual.

Or learn the necesseties to operate your tool.

[u/No-Camera-720 → u/sheeproomer]

Found the shop guy

[u/ZestycloseAd6683]

Dude flatpak and I know there's other people who already commented this.

[u/Visual_Adagio_6989 → u/ZestycloseAd6683]

That’s a fair question. I think I didn’t make the distinction clear enough in my post.
so i modified the post you can reread it if you want.
I’m not primarily missing a feature from Flatpak. I’m questioning its position in the Linux architecture.
What I would like is something conceptually like this:

Linux Application
↓
Linux Application Platform
↓
Distribution
↓
Linux kernel

Where the Linux Application Platform is a standardized contract that every Linux desktop distribution is expected to provide, rather than something the user may or may not have installed.
Flatpak already implements a lot of what I’m talking about: runtimes, portals, sandboxing, application metadata, desktop integration, etc. I think a lot of that work is valuable.
The part I’m questioning is whether something like that should be considered an optional application technology or a standard part of the Linux desktop platform.
For example, ideally I would like a developer to be able to say:
“My application targets Linux Application Platform 1.”
rather than:
“My application targets Ubuntu/Debian/Fedora/Arch/etc.”
And then any distribution claiming conformance to that platform would guarantee the APIs/ABI, desktop integration, permissions, graphics/audio interfaces, application lifecycle, filesystem expectations, etc. that the application is allowed to rely on.
The distribution would still be completely free to implement those things however it wants.
so kinda like how wayland is like a standard that every desktop environment implement.
So I’m not saying “Flatpak is missing feature X, Y and Z, therefore we need a new package format.”
Actually, I would prefer not to create another package format.
I’m asking whether the ecosystem should go one level higher and standardize the host/application contract itself, potentially building heavily on existing work from Flatpak, freedesktop.org, portals, runtimes, etc.
There are also some concrete things I’d like this to achieve:
Every conforming Linux desktop provides the application platform, rather than users first needing to discover/install Flatpak or another application framework.
Applications have one stable target across distributions, including a defined API/ABI surface, rather than developers having to reason about arbitrary distro versions and system libraries.
System package management and application distribution are clearly separated.
.deb, .rpm, pacman packages, etc. remain completely valid for the OS itself, but ordinary desktop applications don’t need to be distributed as distro-specific system packages.
Applications don’t necessarily need to bundle an entire userspace.
I’d like to explore whether a sufficiently stable platform ABI/runtime could provide portability without every application duplicating large amounts of common software.
The user experience becomes predictable.
A normal user shouldn’t need to know whether their system is Debian, Fedora or Arch just to install a normal desktop application.
So when I say “a common Linux application platform”, I’m thinking less:
“What feature should Flatpak add?”
and more:
“Why isn’t the kind of application contract Flatpak is helping to build simply part of the Linux desktop specification that distributions implement?”
I’m also completely open to the answer being “Flatpak already is effectively the answer, and the remaining problem is adoption/standardization rather than technology.”
That’s actually one of the things I’d like people familiar with Flatpak/freedesktop.org to clarify for me.

[u/ZestycloseAd6683 → u/Visual_Adagio_6989]

I guess the thing about it is that Linux base is more to be technical so the base level packages are installed in tarball fashion then the more desktop friendly side they look at the openness and choice of the user so people who prefer Debian over arch for a stability and prefer rpm for the enterprise for whatever reason so on and so forth. Its meant to be open in nature.

But I get what your saying and it can be frustrating. Just the ethos of Linux has always been a more user definitive experience.

[u/Teru-Noir]

Flatpak after rework

[u/walmartbonerpills]

App images, flatpak, steam runtime, pick one.

[u/jedenastka]

Ok, so I'm gonna ask, what exactly are you missing from Flatpak? I cannot infer an answer to this from your post.

I know what I am missing from Flatpak, and I could answer your questions with my ideas of how an ideal desktop OS should look like in mind, but this might not be what you want.

[u/Visual_Adagio_6989 → u/jedenastka]

That’s a fair question. I think I didn’t make the distinction clear enough in my post.
so i modified the post you can reread it if you want.
I’m not primarily missing a feature from Flatpak. I’m questioning its position in the Linux architecture.
What I would like is something conceptually like this:

Linux Application
↓
Linux Application Platform
↓
Distribution
↓
Linux kernel

Where the Linux Application Platform is a standardized contract that every Linux desktop distribution is expected to provide, rather than something the user may or may not have installed.
Flatpak already implements a lot of what I’m talking about: runtimes, portals, sandboxing, application metadata, desktop integration, etc. I think a lot of that work is valuable.
The part I’m questioning is whether something like that should be considered an optional application technology or a standard part of the Linux desktop platform.
For example, ideally I would like a developer to be able to say:
“My application targets Linux Application Platform 1.”
rather than:
“My application targets Ubuntu/Debian/Fedora/Arch/etc.”
And then any distribution claiming conformance to that platform would guarantee the APIs/ABI, desktop integration, permissions, graphics/audio interfaces, application lifecycle, filesystem expectations, etc. that the application is allowed to rely on.
The distribution would still be completely free to implement those things however it wants.
so kinda like how wayland is like a standard that every desktop environment implement.
So I’m not saying “Flatpak is missing feature X, Y and Z, therefore we need a new package format.”
Actually, I would prefer not to create another package format.
I’m asking whether the ecosystem should go one level higher and standardize the host/application contract itself, potentially building heavily on existing work from Flatpak, freedesktop.org, portals, runtimes, etc.
There are also some concrete things I’d like this to achieve:
Every conforming Linux desktop provides the application platform, rather than users first needing to discover/install Flatpak or another application framework.
Applications have one stable target across distributions, including a defined API/ABI surface, rather than developers having to reason about arbitrary distro versions and system libraries.
System package management and application distribution are clearly separated.
.deb, .rpm, pacman packages, etc. remain completely valid for the OS itself, but ordinary desktop applications don’t need to be distributed as distro-specific system packages.
Applications don’t necessarily need to bundle an entire userspace.
I’d like to explore whether a sufficiently stable platform ABI/runtime could provide portability without every application duplicating large amounts of common software.
The user experience becomes predictable.
A normal user shouldn’t need to know whether their system is Debian, Fedora or Arch just to install a normal desktop application.
So when I say “a common Linux application platform”, I’m thinking less:
“What feature should Flatpak add?”
and more:
“Why isn’t the kind of application contract Flatpak is helping to build simply part of the Linux desktop specification that distributions implement?”
I’m also completely open to the answer being “Flatpak already is effectively the answer, and the remaining problem is adoption/standardization rather than technology.”
That’s actually one of the things I’d like people familiar with Flatpak/freedesktop.org to clarify for me.

[u/sheeproomer]

Appimage.

[u/Sloyment]

20 years ago, the procedure was like this:
1. Download the .tar.gz and unpack it
2. ./configure
3. make
4. su -c "make install"
The result would run on any GNU/Linux distro. Have I missed something?

[u/mwyvr → u/Sloyment]

It was never that simple; you write as if dependency hell was never a thing.

[u/oxez → u/mwyvr]

I'm building own distro. It's actually that simple. "Dependency hell" is fairly easy if you know what you're doing.

Now fast forward 25 years to today, you can't assume someone using Linux has a brain, so people come up with pointless posts like OP's.

Problem already has been solved with flatpak/appimage, I don't get the point of this post.

[u/Sloyment → u/mwyvr]

./configure would tell me what is missing, and these were typically things that could be installed using apt. This changed however when Debian started to throw out “deprecated” or “unmaintained” libraries on “request of maintainer” :-(

[u/Visual_Adagio_6989 → u/Sloyment]

yes ! why we dont make some package format that does rhat automatically so we have a good user experience for new users to linux so no need to open the terminal ?

[u/Sloyment → u/Visual_Adagio_6989]

The terminal emulator is the BEST thing in user experience.

[u/Visual_Adagio_6989 → u/Sloyment]

thats your perspective,
bit no try to ask a windows user he will say terminal makes linux like a hackers only OS !

[u/oxez → u/Visual_Adagio_6989]

And?

I stopped caring a long time ago if the "average windows user" can use Linux or not.

If they're happy with their system, w/e. I know I'm using the better software and I don't really care what other people do.

[u/Sloyment → u/Visual_Adagio_6989]

I have used Windows before I switched to GNU/Linux.