[ChiefOBrien]

Hot take: A great tragedy of the GNU/Linux ecosystem is the fact that ABI+API is still not figured out, and the most common interface between programs is the C ABI, which is embarassingly primitive even by 80's/90's standards. Some people in the FOSS community just want to leave things as-is to hinder propiertary software, and it's the same story with device drivers. You can debate the merits rightfully so, but then there's still companies pushing out binary blobs which break every few kernel updates. As a FOSS developer it's an eternal fight between good and evil with no winner in sight, as a propiertary developer it's pain in the ass to maintain old and new software between all the permutation of Linux distros, and as a user I get to cry because of the lack of popular software and backwards compatibility. Snaps and flatpaks are an ugly hack, literal ductape around this very fundamental problem, and clearly not the solution. GNU/Linux should have adopted COM and/or an adequete proglang with stable ABI a long time ago, and should have tried to control wasted effort put into duplicate software ecosystems (KDE and Gnome).

[qppo]

That's a searing hot take, to be sure.

There is no alternative to the C ABI. If you look at stable ABIs in other programming languages, they're either identical to or thin shims around the C ABI! Even COM, with the caveat of calling convention on MSVC.

Regardless of ABI stability you also need software to have API stability for stable distribution. The two solutions to this problem are to statically link everything or package your shared objects with your software. Then to launch the software you need a shell script that overrides the loader search path and move on with your life.

The ultimate solution is the .app/.bundle paradigm of MacOS. Everything should copy that.

The other issues of packaging software like entitlements/capability based security and code signing are similarly orthogonal. If you're shipping big software today, it needs to have everything it needs and to ignore whatever is on the user's system unless they explicitly request an override.

The real tragedy of GNU is that the interchangeability of software was always possible, package managers just managed to make it accidental and explicit. Too many foot guns there.

[wahern]

> Then to launch the software you need a shell script that overrides the loader search path and move on with your life.

> The ultimate solution is the .app/.bundle paradigm of MacOS. Everything should copy that.

All ELF systems support the $ORIGIN RPATH macro. It lets you build and package an application exactly like, if not better than, you would a macOS bundle. Specifically, it let's you specify at compile time a library load path relative to the invoked binary. You'd specify it as $ORIGIN/../lib for the canonical bin/, lib/, etc layout.

[qppo]

Awesome tip, thanks! I didn't know this existed.

[brundolf]

I haven't done native development professionally, but it seems to me like dynamic linking is a leftover from a time when memory and even disk space were precious, isn't it? Are the savings really still worth all the breakage? What is Docker but a way to force static linking on programs that were built for dynamic linking?

[fomine3]

Example: GCC had been known that GNU worried to add plugin API.

https://lwn.net/Articles/301135/

[SubjectToChange]

Stable ABIs don't seem like a good solution though. It is preferable that the system running the code should make the decisions on how best execute it. Especially as hardware becomes more specialized and diverse. Additionally, guarantees of stability necessarily increase maintenance burdens, so they should be avoided whenever possible.

IMO, the best solution would be something like SPIR-V. That is, programs are shipped in an intermediate representation which a platform-specific compiler would reduce to the final program. That way no stable ABI is needed, there is less maintenance for distros and toolchains, and end users still get high quality binaries.

Of course there are issues with protecting the intermediate representations of programs from reverse engineering. But the combination of strong DRM with obfuscation should satisfy most software vendors. After all, most companies are comfortable shipping Java based programs.

[tn1]

I believe Apple sort of does this for iOS: developers submit LLVM IR to them and they compile it to send to end users

[Spivak]

As a primarily Linux developer I'm super jealous of COM. It reminds me a lot of dbus with more legacy cruft but also a lot better designed.

[mailslot]

As a former Windows developer, I am thankful that I never have to touch COM ever again.

[Spivak]

Damn, guess the grass isn’t greener.

[johnisgood]

We should aim to not use Snap, please! :/