undefined | Better HN

0 pointsbarrkel14y ago0 comments

That's true to the degree that the implementation of those libraries does not require other things from the rest of the system. If they are just libraries of code, attached to nothing, sure.

But when they need integration with things beyond that? That's when it breaks down. That's when you need interfacing libraries that adapt one version of a library's interface to the next version, and very careful API and ABI design. I see that there's very little reason to take that approach for open source everywhere, but that kind of environment is essential for the stability commercial development needs.

Static libraries aren't the answer. A careful API and ABI interface to the core system, with managed compatibility from release to release, is needed. This is hard work; incredible amounts of effort went into making Windows 95 work as smoothly as it does, and some of the best war stories from Raymond Chen's blog date from this effort.

Things like preserving bugs in the moral equivalent of malloc to accommodate software that used memory after freeing it. This very concept - bug compatibility - is something that I see OSS community in general as being fairly hostile to, thinking that the software with the bug should be fixed, rather than making things work for the user. Of course the buggy software should be fixed; but making things work for the user is more important still.

0 comments

bryanlarsen14y ago

Actually, your post is making me optimistic.

On Linux, the 4 most common API layers encountered by an application are:

1) system calls 2) standard (and not-so-standard) libraries 3) X11 4) d-bus

#1 is notoriously stable. Linus often posts quite a vehement response to anybody who proposes breaking #1.

#3 was for a long time, TOO stable, it wasn't taking advantage of new developments in hardware and design. The breakup of XFree86 freed that up.

#4 is relatively stable because it's a cross-distribution partnership. They're designed to be the same across multiple distributions which by necessity makes them stable.

The problem are for Linux is #2. Most standard libraries are actually very stable on the micro level. The problem is the vast area they expose: if a single backwards-incompatible change can break your app, it's a problem if there are a million things that can potentially change.

Windows & OS X applications "solve" this problem by shipping their libraries with their applications.

I think Linux has a potentially even better solution: simply allow multiple versions of applications and libraries to be installed simultaneously, a la rubygems & bundler. You'll get all the disk space savings of shared libraries at the point of initial install, which will slowly erode as users install new apps, upgrade some apps but not others. But who cares? Disk space is cheap, but more importantly, if the user cares he can do something about it, only upgrading applications when the whole application upgrades.

j / k navigate · click thread line to collapse