first off, the fact that an IBMer was involved in the discussion does a lot to discredit the whole article. they have really bad UIs! they, IBM, also fall into the traps he is talking about: designers are frequently not listened to, UIs are designed by the core engineers and influenced by marketing, they need to rush out the next release, the engineer needs some checkbox in place so that he can claim an accomplishment to justify his paycheck.

to be honest, my employer only issues Mac or Windows laptops. i started with a Mac and really tried hard a whole summer to use it, but in the end i dumped it for a Windows laptop over which i installed kubuntu. the help system in Mac OS is super crappy. the package management system is non existent. (the assertion that you just add and remove stuff from applications directory is naive. there is other stuff happening that leaves things broken if you ever update or remove packages.) as a developer it's just too hard to get a good development evironment setup (not just the IDE, but all the tools as well). getting network printers and storage setup on Mac OSX is a crap shoot: sometimes it is easy, but other times it is impossible!

to be honest KDE 4.0 was pretty lame, but i'm loving 4.2!

A few year ago I wrote and maintained the Aironet driver. The years of maintaining the driver and supporting users (I still support them) has illustrated to me the importance of an ABI. I didn't really notice it at first, but it hit me in stages.

1) Experimental driver stage. I distributed the source and had online instructions, but you would be surprised at the large number of people that I had to walk through compiling their kernel with the correct .config. It was hell. It was something that neither I nor they wanted to go through. I figured the problem would go away once I was integrated with kernel source.

2) Late experimental stage. I had all the problems of the previous stage, but now the kernel API was changing under me so I had to put #ifdefs in to deal with it. I figured the problem would go away once I was integrated with kernel source.

3) In the kernel. Yeah I made it into the kernel. Okay first it was the pcmcia package and then the kernel. But now I had to strip out all the #ifdefs because we don't want that cruft in the kernel, but I still had to maintain the #ifdefs for other kernels. So now I had all the previous problems, but now I had to make patches with and without the #ifdefs. I figured the problem would go aways once everyone moved to the new kernel.

4) Firmware changes. Oh no! Cisco changed the firmware which changed a bit the I/O interface. Oh and look they are still changing the API in the kernel. So I can patch the new kernel code to support the new firmware, but I can't expect everyone to upgrade kernel just for my driver. (I wouldn't even do that because the XXXX driver doesn't work so well in the latest kernel.) Now I have even more problems to deal with including everything from before.

5) Throwing in the towel. It became just too much of a time sink. Both sides of my driver was changing like mad (the hardware and the kernel API) and the poor users that were trying to make it all work with kernels that they wanted to use. All my time was being sucked up in maintaining the status quo and I couldn't work on anything new, so I turn the driver over to good hands and moved on.

Now imagine how nice would be if in the experimental phase I could release the source and a binary for everyone to use. I wouldn't have to tweak and recompile for every new kernel. Anyone would be able to just grab the binary and use it if they wanted to. (Kinda like Windows... Ironically I use ndiswrapper for my new laptop with a broadcom driver and it rocks! I've used the same windows driver in linux for the past year across many versions of the kernel. It sucks that the windows network driver ABI is the only driver ABI that linux has.) If the firmware changed, I or anyone else could fix it and everyone could use it.

Whether or not we Linux allows closed source drivers is orthogonal to an ABI. Technically you can write closed source drivers now and if you want to, you can prohibit closed source drivers with your new ABI.