Linked by Thom Holwerda on Mon 15th Jan 2007 11:25 UTC
Ian Murdock blogs about the importance of backward compatibility. "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. Why is backward compatibility important?"
Thread beginning with comment 202081
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-09-21
As Cloudy and trembovetski mentioned, maintaining binary backwards compatibility for other OS's like Solaris which is OSS, doesn't hamper their ability to innovate. But it does require some serious engineering effort to do so. Just look at the amount of discussion in including ksh93 in opensolaris/solaris 11 because ksh93 isn't completely (though mostly) compatible with AT&T's original ksh88.
All the effort is basically shifting the burden from the user to the developers, which some people seem to take for granted, while I know some others appreciate.
In fact, I had a harsh reminder recently of the kind of breakage that can go on in Linux when trying to install Cisco VPN client software, which is distributed purely in source form where you need to compile the module on your system. .. God, sooo many small things have changed since the 2.6.x kernel interfaces that Cisco were using.. function arguments, structure member names, etc. All of which I certainly do not know how to fix. And even if it compiled, who knows if the semantics have changed for other things..
Just because the source is available doesn't mean anything in an unstable API world if you don't have someone who has full time responsibility of maintaining your needed code.
For example:
http://www.hipac.org/
nf-HiPAC v0.9.1 does not compile with linux kernel versions greater or equal to 2.6.14 because in 2.6.14 the number of parameters of the netlink_kernel_create() function was changed. Please apply this patch if you want to use nf-HiPAC v0.9.1 with kernel versions greater or equal to 2.6.14.
What if it was left like that for a while? What if it just stagnated? It's still OSS -- who would've picked up the slack if so? And such kinds of stagnation usually leads to a death spiral: the more broken it is, the less likely someone else wants to pick it up.
.. and the nf-Hipac update was a year ago.. who knows if things will break again with 2.6.20..