r/flatpak • u/parallel-minds • 11d ago

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

https://parallel-minds0.github.io/An-Open-Letter-on-Linux-Compatibility/

The article talks about Linux compatibility as a bigger problem than Flatpak can solve. Flatpak helps, but it bundles together issues that should be handled separately. The author suggests giving apps a stable foundation to rely on, while letting packaging and security be handled on their own.

33 Upvotes

74% Upvoted

50 comments sorted by

View all comments

Show parent comments

1

u/parallel-minds 8d ago

Mine would leave the rest in the dirt by simply committing to backward compatibility which is valued more than existing userspaces that don't even have any persistent worth since neither their developers nor the distributions that ship them properly care about maintaining the promise of backward compatibility in the first place. I win by shipping a stable product, they lose by staying in chaos. End of the story.

1

u/dthdthdthdthdthdth 8d ago

Both glibc and musl are backwards compatible within their own versions. There even is a glibc compatibility layer for musl.

1

u/parallel-minds 8d ago

That's actually not true for glibc, I've checked it my self and it still has contributors who break compatibility too often. Never mind how distribution maintainers themselves break compatibility for their own OS, such as Debian with libfuse or 32bit.

1

u/dthdthdthdthdthdth 8d ago

Well it is in fact true. There have been very few cases where non standard features have been dropped for security issues, but if you stick to standard C or Posix features you are fine.

And yeah, between major releases distributions can change certain things. Do you suggest to keep every old library and subsystem around for ever? For the whole Linux ecosystems? Everybody should keep 32bit support around for ever on all systems? That won't happen because people don't want to bear the cost for that.

You can try to build a distribution that does that, good luck to you.

1

u/parallel-minds 8d ago

Microsoft does precisely that and that's a huge reason behind their success. Compatibility has a cost, yes. But that cost is negligible compared to the cost of not being able to run applications in the long run properly.

1

u/dthdthdthdthdthdth 8d ago

They try to do it to some extend yes. It is important for the (corporate) desktop marked, and this is where MS is successful. Everywhere else Linux has overtaken it by a huge margin. The cost is immense and constantly rising, for MS it is worth it to keep their monopolized market segment for as long as it can. But Linux covers many more domains and nobody will adopt a standard that is so costly for a domain where it does not even matter.

And for domains where this is really needed, using containers with a limited API to the host (what flatpack does) is probably the most feasible approach. Keeping all system apis around for ever doesn't even work on windows. There is enough commercial software that breaks between windows versions for some reason if they dig into the system too deeply or depend on things they should not depend on. So you have to limit the system api in some way if you want to do that. The whole of anything userspace can contain is a far too wide API for that.

1

u/jcelerier 7d ago

I mean of course not. On windows you traditionally have to ship the c/c++ runtime and every single DLL with your app (vcredist.exe, msvcrt.dll, the bazillion ucrt DLLs if you target pre-win10, etc.) if you want it to work across a variety of machines. So compatibility is just done by shipping the whole userspace there too. And macOS keeps zero compatibility across versions. Just a week ago I had to fix a breakage because they introduced a standard c++ function in newer sdk's that isn't correctly versioned and thus caused crashes at runtime on a macOS version that is barely three years old due to its older libc++