Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 11:20 UTC (Tue) by nim-nim (subscriber, #34454)
In reply to: Shared libraries by DemiMarie
Parent article: APT Rust requirement raises questions

> If distros want ecosystems to be more friendly to them, they need to put in the (large) amount of work to make that happen.

Why should they ? The same developer-friendly argument was made for Java software, the same refusal to invest in a mechanism to share components and stabilise ABIs was advanced by Java developers, the same hostility to distribution best practices was trumpeted right and left.

Fast forward twenty years the technical debt come due and no one can leave the Java boat fast enough. Turns out, refactoring vast piles of vendored, forked and obsolescent code, with no clear lines of demarcation because no one enforced ABI separation for a long time, is completely unappealing. You can ignore problems a long time they come back with a vengeance.

to post comments

Shared libraries

Posted Nov 25, 2025 13:46 UTC (Tue) by khim (subscriber, #9252) [Link] (12 responses)

> Fast forward twenty years the technical debt come due and no one can leave the Java boat fast enough.

You live in some imaginary universe. On our universe Java is number three language, behind JavaScript and Python, but ahead of PHP, it's used by the most popular OS and no one thinks about abandoning it… sure, people like to grumble about Java problems… they use Java, nonetheless.

> You can ignore problems a long time they come back with a vengeance.

Isn't that what you are doing here?

Shared libraries

Posted Nov 25, 2025 17:45 UTC (Tue) by ssokolow (guest, #94568) [Link] (11 responses)

I think it's just that, because Java originally shaped its APIs toward "write once, run everywhere" and away from tight platform integration, and originally had a restrictive license, it's not very visible on desktop Linux.

...in the same way that C# is the language people are most likely to reach for on Windows because it's very well-suited to interfacing with Windows-specific APIs, people are likely to reach for C, Perl, Python, etc. on Linux because it's well suited for interfacing with POSIX APIs and Linux-specific APIs.

Web servers, specialty applications, Android apps... none of these grab your attention on a Linux desktop. The only Java apps I can think of having encountered on Linux are Minecraft, JDownloader, Azureus, Trang, FreeMind, and the control software for my KryoFlux.

Shared libraries

Posted Nov 25, 2025 18:22 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (10 responses)

> I think it's just that, because Java originally shaped its APIs toward "write once, run everywhere" and away from tight platform integration, and originally had a restrictive license, it's not very visible on desktop Linux.

It’s not “just that”. The restrictive licensing has been lifted a long time ago. There are loads of available FOSS Java components. There are lots of people who know how to code in Java.

What kills Java as a general purpose language that could be used to build generic components that could end up in generic software deployed in generic distributions is lack of ABI enforcement resulting in lack of version convergence. Life is just too short to delve in the pile of specific component versions each and every Java project uses. Each project is effectively a walled garden, its own component universe, hostile to other component universes.

Shared libraries

Posted Nov 25, 2025 18:29 UTC (Tue) by khim (subscriber, #9252) [Link] (9 responses)

> What kills Java as a general purpose language that could be used to build generic components that could end up in generic software deployed in generic distributions is lack of ABI enforcement resulting in lack of version convergence.

Except it doesn't “kill Java”. It kills “generic distributions”. I'm not really even sure how they are relevant, in the grand scheme of things: the only reason they survived till now was the fact that people needed them to develop server software. But with Docker on macOS and WSL they no longer needed even for that.

> Each project is effectively a walled garden, its own component universe, hostile to other component universes.

You mean: exactly and precisely like a Linux distro? Pot, meet kettle, I would say.

Shared libraries

Posted Nov 28, 2025 11:24 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (8 responses)

Yes precisely like a Linux distro;

And you can say “well I don’t need your stinking distros” then just show how you can assemble a full system. Distros proved they could do it from the bare metal to the apps above. Distro opponents have not managed to do it. (And when they attempt to do it it looks like a distro reinvention).

Shared libraries

Posted Nov 28, 2025 11:38 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

> Distro opponents have not managed to do it.

Seriously? Can you find another, more believable, delusion? The most popular OS on the planet shows us how that can be done.

You may claim that there are bazillion Linux distros and only one successful alternative, but that's not entirely true: there were others (Tizen, Maemo), they just have proven not to be very interesting… ironically enough one of the worst problems they had was precisely the fact that they have broken compatibility too much.

> And when they attempt to do it it looks like a distro reinvention

Not really. It's like saying that car and the plane are the same thing if they both use Rolls-Royce engine.

The critical difference between distro's “steaming pile of packages” and proper OS is an SDK: something that you can use to build your binary and, most importantly, target different versions of OS simultaneously. Here are downloads for Anroid. These are for Windows. MacOS are the shittiest ones, yes, they exist.

Where can I find something like that for any popular distro? If the answer is “you should just install bazillion versions on CI in docker”… then here's your answer for why things work as badly as they do with Linux on desktop.

Shared libraries

Posted Nov 29, 2025 16:32 UTC (Sat) by anselm (subscriber, #2796) [Link] (3 responses)

The critical difference between distro's “steaming pile of packages” and proper OS is an SDK: something that you can use to build your binary and, most importantly, target different versions of OS simultaneously.

Chances are, if you're developing software for Linux you probably want to target more than one Linux distribution, anyway. At that point, relying on an “SDK” provided by any one distribution likely wouldn't be enough – it would be weird to expect the “Debian SDK” to spit out RPM packages for RHEL or openSUSE, after all, and vice-versa –, and using CI to build more than one flavour of your code doesn't look all that unreasonable anymore. Been there, done that; it's not exactly rocket science.

Shared libraries

Posted Nov 29, 2025 16:48 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

> Chances are, if you're developing software for Linux you probably want to target more than one Linux distribution, anyway.

Why is that a problem? Go back quarter century… Windows 9x and Windows NT were significantly more different than different Linux distros… yet creating one binary that worked on both was the norm. Supporting Windows 3.x (with Win32s) was harder, but still possible.

These days that support is often done with help of Docker and, now, Flatpacks. Not sure how well it works with Flatpacks, but Docker for server packages works reasonably well.

> it would be weird to expect the “Debian SDK” to spit out RPM packages for RHEL or openSUSE, after all, and vice-versa

Yes, that's why people invented something that works for both. Many things, in fact. If GNU/Linux couldn't give them usable SDK then they would pick someone who would… Valve, e.g.

But then distros spent decades punishing them for that.

The only thing that achieved is the development of open source ecosystems that consider distros their enemy, or, at best, “the necessary evil”.

Rust just have turned into reveal show because distros have come to the Rust developers with demands then need to fulfill… and got back the question they haven't expected at all: “why should we care?”.

They have gotten certain answers, ultimately, via the Rust-in-Linux route: certain developers want to use distro-provided version of Rust and that means certain features needs to be included in Rust at certain time… that got acknowledgement, even if not full acceptance. Everything else? Distros have created the problem for themselves by introducing some strange arbitrary rules, distros may decide how to resolve them… developers of most Rust packages are just too busy doing useful work with people who don't invent random crazy hoops, they don't have time for the distro-invented circus.

Shared libraries

Posted Nov 29, 2025 17:39 UTC (Sat) by pizza (subscriber, #46) [Link]

> The only thing that achieved is the development of open source ecosystems that consider distros their enemy, or, at best, “the necessary evil”.

Those ecosystems decided that support for non-Linux environments was required, so they had to take a different approach.

If you have to reinvent the wheel completely anyway, why not just use that new wheel for Linux systems?

The smarter ones incorporated the lessons learned from Distros, but the not so smart ones (Python comes to mind) are still paying the price.

But as the saying goes, with sufficient thrust even a pig will fly. And thanks to the AI craze Python has a *lot* of well-funded thrust.

Shared libraries

Posted Dec 1, 2025 18:54 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Eh, we make tarballs that extract to a standard installation prefix. The binaries are relocatable, so we just need to make sure we build on a suitably old distro (currently CentOS8) and document libraries we assume exist (X11, some libxcb libraries, etc.). Works well enough. But yes, if you don't want to ship everything above the "bare bones", you'll need a per-distro package.

Shared libraries

Posted Dec 1, 2025 8:58 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

The other solutions work when you have a rich monopolistic sugar daddy to pay for the base OS. Because the other solutions are totally ineffective to build this base OS and require the injection of loads of capital and management directives to achieve the same result.
A lot of us are not interested in hanging FLOSS decorations on a monopolistic closed system.

Shared libraries

Posted Dec 5, 2025 3:42 UTC (Fri) by dvdeug (subscriber, #10998) [Link] (1 responses)

> The critical difference between distro's “steaming pile of packages” and proper OS is an SDK: something that you can use to build your binary and, most importantly, target different versions of OS simultaneously.

It's relatively easy to do that on Windows, as Microsoft controls all the systems. It's not so easy to do that with Linux or *BSD, as there's multiple different forks you have to deal with. Flatpaks ultimately do what Windows does; ship all dynamic libraries with the program. I don't see any reason you don't accept that you can do that with a flatpak.

(Note that most people don't distribute native binaries for Android; the system compiles the APK into a native format. There are a bunch of "binary" formats that may or may not take an installation step, that you can run on different versions of Linux, ranging from well-designed compiled code to any number of interpreters to APKs and JARs. RenPY programmers distribute one binary package for Windows and Linux all the time.)

None of those are proper OSes; a proper OS has no users so there are no problems. Real systems have problems and make compromises. Distributing the same binary to versions of Linux from many times, from many vendors was not one of the driving goals behind Linux, so the compromises it demands weren't made. Note that Windows binaries, include ones built from post-2010 .NET, don't generally run across architectures; ARM Windows will emulate x86 binaries, but the x86-64 emulator is a lot more fragile and experimental, and x86-64 Windows won't run ARM Windows binaries.

So, yes, Linux can do it, using flatpaks or other options, no, Windows can't do it if you want to use a modern Windows SDK and target both ARM Windows and x86 Windows at the same time.

Shared libraries

Posted Dec 5, 2025 9:28 UTC (Fri) by taladar (subscriber, #68407) [Link]

If you really want to you can emulate Linux binaries from other architectures relatively transparently using qemu-user and binfmt_misc. Of course you still need a full set of libraries for them just as you would if you ran the code on that platform. Mostly it is useful for things like chroots with mounted SD-Cards for low power embedded devices where the emulation on your PC is still much faster and has more RAM available to compile stuff.

Shared libraries

Posted Nov 25, 2025 18:47 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Why should they ? The same developer-friendly argument was made for Java software, the same refusal to invest in a mechanism to share components and stabilise ABIs was advanced by Java developers

Whut?!? Java is one of the _best_ examples of stable API/ABI. I can launch software written for JVM 1.3 in 2001 on the most modern JVM, as long as it doesn't use stuff like "Unsafe". Even SWING and AWT are still available!

This absolutely helped with Java's popularity. Banks and enterprises _love_ not having to update the code every year.

Shared libraries

Posted Dec 1, 2025 9:08 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

Correction : the integrators that work for banks *love* a system where they are paid to reinvent the wheel for every deployment, and love the maze of custom component versions that prevent their customers from auditing deliverables and noticing when they have been sold a leaky obsolescent mess.

Of course the same lack of ABI convergence that make those languages perfect to resell a mess at inflated prices to banks, makes them totally inadequate for cooperative OS building, where inefficiencies are not an occasion to invoice more but a direct cost in volunteer efforts.