Downwards compatibility during long time development

Tux
Microsoft’s Larry Osterman described in a recent blog entry that there will be no totally reworked Windows kernel after Vista due to the need of downwards compatibility. The argument however raises the question if Linux could be faced by a similar problem.

Larry Osterman’s post explains that there will be no new kernel since it would break downwards compatibility. He mentions an example where Microsoft dropped support for NT 4 audio drivers in Vista and immediately was called by customers who complained about not-anymore working audio software – although the support officially was dropped 1998 anyway:

People reported that some call center applications had stopped working. We started digging and discovered that these call centers were using software that depended on the NT4 style audio drivers. These call centers didn’t have the ability to upgrade their software (the vendor had gone out of business, and the application worked just fine for their needs). So we put the support for NT4 drivers back, because that was what our customers needed to have happen.

First of all this example shows pretty well why it makes sense to use Free Software for your core applications: in the worst case (the vendor goes out of business) you can still pay someone else to make changes you really need. In this case the call center could just pay a developer to alter the audio core of the application to use the new ones.

Nevertheless the question remains if something similar could happen with Linux.

In case the software just uses a specific sound architecture Linux already showed that it can handle such things: Linux’ sound architecture ALSA replaced the older Open Sound System some years ago but still provides a compatibility layer. So even if you have an application which only works with OSS it still works on a new kernel. Since the above described problem seems to be such a case the question is why Microsoft didn’t add a compatibility layer.

However, if the sound application came along with it’s own drivers and needed NT 4’s driver API Linux wouldn’t be faced by such a problem anyway: in Linux the drivers have to be Open Source. As a result, if the driver API changes, the drivers are ported to the new API. This shows how important it is to open up all drivers and not introduce a general stable API: the API would have to change sometime in the future which would in return drop support for all old drivers.

Still, there is one thought which I can’t get rid off: Windows has a stable base of customers and well established ways of speaking to them (the important ones at least). This is worth money since these customers – equipped with Beta software – are a large computer test lab. I doubt that Linux has something similar. There are hardly any Linux hardware/software test labs I would now off and I never heard of anyone running mass regression tests on standard hardware pieces on a daily base for the newest Linux kernel. Not even from one of the big vendors. But that should be the usual way!
But running regression tests against for example one hundred different network cards costs a lot of money, and maybe the community is just not there yet.

6 thoughts on “Downwards compatibility during long time development”

  1. The community is there, the question is how to best utilize the community? There are most definitely hundreds of thousands of people out there that have a reasonable amount of free time on their hands that wouldn’t mind running a few simple scripts on their computer to help the community out. I am by no means a code expert, but if there were a tool easy enough to use, and the tool was promoted well, people would use it. I for one would be one of those people. I believe that the ideal of FOSS can be attained only if we have full community participation, and that means even from those who know hardly anything about how their email is sent over the internet. Instead of chastising people for not knowing or even desiring to ever use their terminal, we should promote that everyone should have a roll in the community, no matter how minute.

  2. Will, I like the script idea. Unfortunately, testing devices and hardware most often requires restarting of the system and booting into new kernels – if then anything goes wring the user is left with a huge problem if not done right:/

  3. What about small live-cd with the kernel and the test script that tests drivers for available hardware and sends logs to developers ?

  4. Hmm… I’m glad to hear that Linux drivers don’t sit and rot…

    But I do think it would be a good idea to put the drivers under the BSD. Now, I like the GNUv2, but if those drivers got BSD’d, or dual licensed or something, then BSD and opensolaris would be able to compete on technical merit instead of hardware support, and contribute in kind. They shouldn’t be /Linux/ drivers, they should be Free Drivers.

    As I said, I like the GNU, but sometimes you need to put things aside for the sake of unity.

  5. To be fair, that’s not exactly what I said (or maybe what I meant to say). What I meant to say is that all the discussions about somehow replacing Windows with ignore the restrictions imposed by backwards compatibility.

    And yes, *nix may very well have the same issues eventually. I personally believe that many of the reasons for OSX Leopard’s delay was because of appcompat issues.

    As soon as you accept that you need to have a stable ABI, you will eventually discover that the requirements for application compatibility start to become more and more important.

Comments are closed.