Blame the Operating System
by Andrea W. Cordingly
If you are like me, you still include some Microsoft Windows use in your work or habits. Not that I am particularly keen to disclose this information about myself. But it's true and I needed to air it before I make my point.
As I finished watching a DVD movie on my Windows system, I decided to press the drive button and forgo the formalities of stopping the program, ejecting the disk, closing the program etc. With my Linux system I don't get nearly as much pressure to follow specific tasks. My mistake. I could not get my disk to eject, nor did the program continue to respond.
No big deal, I've had similar issues with Windows dozens of times. I just open the task manager, choose the silly DVD player application and end the task. WRONG! Instead, not even task manager worked. I kept telling it to end task. I was stuck. My DVD drive would not release the disk, the software would not listen to me and close. And Windows would not allow me to do anything anymore including rebooting!
Then all of a sudden, about three minutes into this fiasco, my DVD drive opens! I quickly grab the disk, close the drive, and flick the surge protector. I breathe a sigh of relief then start scratching my head in amazement.
"Wait," you say, what's all this got to do with blaming an OS? I have to take off my sweater and drink something cold to chill before writing further. You see I don't experience this with Linux for several reasons. I can get to them in a moment. But let's put this into perspective okay?
I have a Microprocessor in my system that can easily handle over 120 million instructions per second. If you like to get real geeky with me, consider this. The Intel processor I'm using is able to calculate the SuperPI number crunching benchmark to one million digits in about 100 seconds. It takes my Pentium 4 system less than two minutes to figure out this benchmark, and the Pentium 4 is notoriously bad at FPU calculations. On a bad day, this beautiful system can do some very serious powered thinking, and at speeds that even ten years ago NASA didn't have in their control rooms.
But, the very same system can not "think” through the decision to release the freakin' DVD drive without locking up for three minutes? How's that possible? The answer lies not with the hardware but the Operating System that drives the hardware.
Today, I think some very good, robust hardware is slave to OS issues that had 20 years to get refined and resolved. For example, failures and execution response errors should not need to take a full three minutes to process.
Even with the wait states, my system taking three minutes to figure out that "gee there really is no DVD disk in the drive any more and I should give control back" is unacceptable. It's unacceptable code driving my reasonably powerful computer.
With Linux, hardware components are not slaves to the application functions. Thankfully, these things are nicely divided and kept isolated. When I tell Linux to unmount and eject my DVD, that's what it does without issue -- and every time. The result is that a person actually runs the computer - rather than the other way around.
I am finding that it is not just big enterprise hardware that needs to be emancipated, but that regular users like myself, sitting at home trying to do work while sipping coffee also need our systems emancipated! Look, there's a good reason why 7 of the 10 fastest super computers in the world run Linux.
Well, it is most likey because based on FLOP/MIPS and FPU calculations it would take a lot more hardware to get the same results using the alternative. And more importantly, none of those true and awesome super computer geeks are going to allow an Operating System to embarrass them by taking longer to calculate the opening of a drive door than performing exponential number crunching.
So, tomorrow I plan to write over the Windows hard disk partitions with something that actually incorporates the processing power -- Linux.