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.
I switch to dvorak about 10 years ago when I was having problems with my hands cramping. The first few weeks were almost impossible, but soon it became natural and I've stuck with it since then. After I became comfortable, I found that I can switch between the two without even thinking about it. When I first sit down to type, if the first character is an error, my brain automatically switches.
My experience has been:
1) No more hand problems at all.
2) I still type slower in dvorak than I did with qwerty, but I was a really fast typist. (I worked as a secretary for a few months before I got my first full time programming job.) I really haven't worked on typing faster because I attribute 1) to my slow down in typing not a better layout.
3) I can still type qwerty, but I am quite a bit slower.
4) Having dvorak as your keyboard prevents people from pushing you off the keyboard when you are working on a problem.
As a past maintainer of a Linux wireless driver, I whole heartedly second the notion that there is a driver crisis. It became almost impossible to keep up with changes in firmware on one side and changes to the kernel API on the other.
It was tragic to fix a problem and then have to walk a whole community of users through setting up a compile environment! It would have been so nice to have been able to plunk a binary on a web page for such users. Even I fall into that community! Two cases at home illustrate this. I bought a laptop that required me to use ndiswrapper (that project rocks!) so the Broadcom wifi would work, and I had on old a USB Linksys wifi adapter that worked with a driver on a guy's web page. In both cases I just wanted something that works. In both cases I had just installed Ubuntu and it would have been nice to just download the binary. Imagine if you had to recompile all your apps every time the kernel changed!
Now if I do a kernel update and I forget to grab the headers, I have to revert to a kernel with working drivers, grab the headers and recompile. Even at work I have a problem. We use 802.1x and I need a patched driver. Again, every kernel update I have to grab headers and recompile!
I'm not advocating that the drivers should be closed source, but you should be able to just grab driver binaries when you need them.
Slashdot Mirror
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.
.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.
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
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.
I switch to dvorak about 10 years ago when I was having problems with my hands cramping. The first few weeks were almost impossible, but soon it became natural and I've stuck with it since then. After I became comfortable, I found that I can switch between the two without even thinking about it. When I first sit down to type, if the first character is an error, my brain automatically switches.
My experience has been:
1) No more hand problems at all.
2) I still type slower in dvorak than I did with qwerty, but I was a really fast typist. (I worked as a secretary for a few months before I got my first full time programming job.) I really haven't worked on typing faster because I attribute 1) to my slow down in typing not a better layout.
3) I can still type qwerty, but I am quite a bit slower.
4) Having dvorak as your keyboard prevents people from pushing you off the keyboard when you are working on a problem.
It was tragic to fix a problem and then have to walk a whole community of users through setting up a compile environment! It would have been so nice to have been able to plunk a binary on a web page for such users. Even I fall into that community! Two cases at home illustrate this. I bought a laptop that required me to use ndiswrapper (that project rocks!) so the Broadcom wifi would work, and I had on old a USB Linksys wifi adapter that worked with a driver on a guy's web page. In both cases I just wanted something that works. In both cases I had just installed Ubuntu and it would have been nice to just download the binary. Imagine if you had to recompile all your apps every time the kernel changed!
Now if I do a kernel update and I forget to grab the headers, I have to revert to a kernel with working drivers, grab the headers and recompile. Even at work I have a problem. We use 802.1x and I need a patched driver. Again, every kernel update I have to grab headers and recompile!
I'm not advocating that the drivers should be closed source, but you should be able to just grab driver binaries when you need them.