[barrkel]

State is the big evil in software. Minimize shared state, and many, many problems go away.

Centralized package management with a web of specific versioned dependencies is a huge hairball of state as it is. And when installed applications poke around inside your system, it only takes one or two oversights here and there to mess up this state.

Sandboxing, where feasible, minimizes shared state; usually at the cost of other things, but with modern software and modern resource constraints, our ability to deal with complexity is usually the tightest constraint. Sandboxing reduces the probability that things will break horribly (e.g. installing one app, and finding you need to install a new version of a library, which in turn means you need to reinstall 100+ more apps, which may bring in a new desktop or some other abomination).

[icebraining]

That has nothing to do with sandboxing: it's a matter of distributing the libraries with the package itself, either as .so files or as a big statically compiled binary, and using those instead. Nothing forces the developer to use the distro provided libraries.

And frankly, I think this is one of the things where you can't please everyone; personally, I rather have dependencies and know that a security fix in a library will fix all applications that use it than having to hope each developer releases an updated version, like on Windows.

[barrkel]

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.

[bryanlarsen]

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.

[eli_gottlieb]

Yes, but then we all have to use Plan 9.