Backwards compatibility: not backward at all
Ian Murdock had a few words to say on the subject. I want to complement his words in this article.
Let me quote from his article:
I’m often asked why I’m so obsessed with backward compatibility and, as a result, why I’ve made the issue such a central part of the LSB over the past year. Yes, it’s hard, particularly in the Linux world, because there are thousands of developers building the components that make up the platform, and it just takes one to break compatibility and make our lives difficult. Even worse, the idea of keeping extraneous stuff around for the long term “just” for the sake of compatibility is anathema to most engineers. Elegance of design is a much higher calling than the pedestrian task of making sure things don’t break.
Ian’s concern is simple: he wants backwards compatibility. In the vernacular, this means old applications must not malfunction in new systems
. He recognizes, at the same time, that backwards compatibility is perceived as a rather laborious and unrewarding task, especially impeded due to the nature of our distributed development efforts.
He’s right about that, and I’m thankful that he’s pushing for more backwards compatibility. Let’s understand why.
A worthwhile goal it is
There are people out there who entertain this notion (or some variant thereof): Why shouldn’t an old application malfunction in a newer system? After all, “it’s just a matter of recompiling the old app on the new system”, right?
They couldn’t possibly be more mistaken.
Three fronts of compatibility
There are several main compatibility concerns:
- ABI compatibility: Programs that use external (dynamic linking) libraries should have guarantees that updated (minor versions of) libraries won’t stop working in the future. Otherwise, a single library can yield an entire system unusable.
- API compatibility: Applications written against a particular library (and version) should always compile against the latest (minor) version of that library.
- Formats and protocols: Newer (foundational) developments shouldn’t break other, older applications that depend on them.
Sometimes, it’s impossible to “just recompile”
There are dozens of thousands of applications for Linux out there. Do you honestly think their users have access to the source code, or the required skills, to update them and make them work with newer Linux systems?
I didn’t think so, either. Gentooers comprise a minuscule share of Linux users. The rest of us want to install a package in seconds, and have it not break when another package is upgraded.
The huge hidden costs of not maintaining compatibility
Face it: eschewing compatibility in favor of the “new fashionable thing” saves a little time for the developer. But it makes everyone else incur in exploding hidden costs, which only increase with time.
Software isn’t like a car. Stable software applications tend to break only when the underlying set of assumptions (in general, “operating system and system-level apps”) change. Therefore, it’s vital that the underlying system stays as stable as possible.
Stability isn’t just “no blue screens”, you know?
Pages: 1 2