- David L Norris
- Indianapolis, Indiana, United States
Semi-topical babble about Radio, Computers, Linux, Life, the Universe, and Everything.
Previous Posts
Archived Posts
Netflix - Movies At Home
Netflix - Next In Queue
2005-03-07
Myths and Realities
Linux Reality Outstrips Linux Myth is well worth a read. It's much shorter and surely more interesting than what I've written here.
Myths
The article highlights a popular Linux "myth" as a sign that we've reached a tipping point in the public awareness of computer technology. There's this fascinating myth circulating among people who are unfamiliar with Linux. The myth is making the public aware that Microsoft and Windows are not their only choice in a grass-roots way. I've heard this myth first-hand numerous times from all sorts of people. The myth pits Linux against Microsoft in an epic battle that started long ago in a land far away. It goes on to explain how Linux aims to defeat big old Microsoft and save the world from buggy computer software. Those may be nice side effects but they have nothing to do with any motivations behind Linux. It does make an interesting story. A consequence of this myth is that people are able to consider alternatives. Once people consider that there are alternatives they may also consider that Windows is not even a good alternative.
Incidentally, you can buy a DVD copy of the great documentary Revolution OS detailing the real story behind Linux, GNU, Open Source, and Free Software. The extras and cut-scenes on the DVD are well worth watching.
Realities
The reality is that stagnation for much of the last 15 years defeats Microsoft. Sure, you can point to hundreds of little things that may be better now. But mostly we are talking about changing window decorations and replacing confusing option dialogs with wizards and cartoons. Among the most anticipated new features are workarounds like anti-spyware, anti-virus, and such for problems that shouldn't exist in the first place. That's especially sad since Microsoft has such a great research division. Meanwhile, UNIX and Linux have progressed forward in technical capability at a steady clip.
History Repeating History Repeating Itself
Since long before Linux became popular, Microsoft core desktop offerings have consisted of the same basic set of programs with the same basic features. Those programs are Windows, Word, Excel, Access, Visual C++, Visual Basic, and a few others. Their server offerings haven't changed much either. The most notable change between versions of each program is that the newer version almost always creates documents in a format older programs can't read or write. And for your convenience the newer program will happily translate all of your old documents into a format only the newer program can read. After nearly 2 decades of constant development one would think that the stability and compatibility of these programs would be drastically improved. Yet they are still chasing after the same old ghosts and providing the same basic features.
Why is Microsoft frozen in place? That is really quite obvious from the perspective of an outsider. They have found something people will pay insane sums of money to use and they don't want to screw up the cashflow. The only thing preventing them from improving Windows is their belief that the existing body of proprietary Windows software must be supported at all cost. There are large subsystems in Windows which deal with nothing but cataloguing and emulating the bugs found in previous versions of Windows. You might think that sounds insane and I think you'd be correct. However, Microsoft really can't force broken Windows programs to be fixed because Microsoft fiercely promotes the idea of proprietary software; that is, software which cannot be modified or repaired by anyone but the program's original developer. Windows provides what Microsoft calls "Shim Technology" to make a specific proprietary program work as if it was running on the outdated or broken version of Windows used to develop it. Windows needs to know about each specific program that a user might want to run and then provide a set of "shims" to make that program more or less work. A huge set of shims comes with each new version of Windows allowing old programs to remain more or less functional.
Contrast and Compare
A deeply concerning problem for Microsoft should be that the Windows environments and interfaces encourage programs to be deeply tied into the Intel x86 architecture. It isn't feasible to rebuild most native Windows programs for use on another architecture or OS. Microsoft has more recently created the .Net and C# programming environment to encourage developers to write proprietary programs that are not dependent on the x86 processor. However, by my count there are more Linux and UNIX systems running .Net software than Windows. .Net is still so uncommon that most developers of retail software simply don't use it.
A typical presumption when writing a UNIX or Linux program is that you have no clue which computer architectures might run your program. Indeed, you don't even know which operating systems might run your program. Consequently, UNIX and Linux programmers tend to write very portable programs that require only a trivial rebuild to support a new CPU or OS. UNIX and Linux development tools have always encouraged programmers to write portable programs. To further promote writing portable software services like SourceForge and even computer manufactures themselves provide free remote access to development systems. SourceForge has many different computer architectures and operating systems available for Free and Open Source Software developers to use as a test bed.
Another issue with writing Linux and UNIX programs is that most computer architectures don't allow programmers to make serious mistakes. For various reasons and excuses, Intel x86 processors allow a whole host of serious programming mistakes to occur without detection. Worms, memory errors, data corruption, and entire classes of problems Windows-x86 users experience every day simply aren't allowed to occur on other architectures. If a program makes a mistake most computer architectures will instantly abort that program. Then why doesn't Windows support these other architectures? Well, Windows NT did support several of them until around 1999 when Microsoft finally conceded that almost no one wanted Windows on those architectures. Almost no Windows programs existed for those architectures. And porting a mildly buggy Windows-x86 program to a bug-hostile architecture is often more trouble than writing a new, portable program from scratch.
Alternate Realities
Let's consider Mozilla Firefox, a popular Free and Open Source Software web browser, running on the Debian "universal" operating system. Debian can run Mozilla Firefox on Alpha, ARM, HP PA, Intel x86, Intel Itanium, Motorola 68000, MIPS, MIPSEL, Power (Apple & IBM), IBM s/390, and Sun Sparc computer architectures. Debian can run the same program on at least 10 completely incompatible computer architectures without modification. About half of those architectures are strictly 64-bit.
The standard Debian system includes 10,000 programs like Firefox. There are hundreds of thousands of programs like this available from SourceForge. There are over 1 million people helping develop Free and Open Source Software at SourceForge. And I'm barely scratching the surface. There are many other services similar to SourceForge. Many and probably most developers use none of these services and work by themselves or with a close group of friends.
Now consider that Debian provides a choice of 4 different kernels: Linux, FreeBSD, NetBSD, and GNU HURD. This isn't an install-time choice, either. You can quickly switch between the different kernels on an already installed system. Linux supports a huge variety of peripheral hardware and architectures, NetBSD runs equally well on many architectures, FreeBSD provides robust server technologies on popular architectures, and HURD is...well I'm not sure what HURD is good for.
Some Perspective
Natively running the same program without modification on dozens of incompatible architectures under dozens of competing operating systems must seem like complete fantasy to some software developers. And if that's fantasy then easily replacing the system kernel with a different, incompatible kernel must seem completely inconceivable. Believing that one kernel is the best for every purpose seems a bit shortsighted. Not entirely unlike tying your software to a single computer architecture that you don't manufacture...
Myths
The article highlights a popular Linux "myth" as a sign that we've reached a tipping point in the public awareness of computer technology. There's this fascinating myth circulating among people who are unfamiliar with Linux. The myth is making the public aware that Microsoft and Windows are not their only choice in a grass-roots way. I've heard this myth first-hand numerous times from all sorts of people. The myth pits Linux against Microsoft in an epic battle that started long ago in a land far away. It goes on to explain how Linux aims to defeat big old Microsoft and save the world from buggy computer software. Those may be nice side effects but they have nothing to do with any motivations behind Linux. It does make an interesting story. A consequence of this myth is that people are able to consider alternatives. Once people consider that there are alternatives they may also consider that Windows is not even a good alternative.
Incidentally, you can buy a DVD copy of the great documentary Revolution OS detailing the real story behind Linux, GNU, Open Source, and Free Software. The extras and cut-scenes on the DVD are well worth watching.
Realities
The reality is that stagnation for much of the last 15 years defeats Microsoft. Sure, you can point to hundreds of little things that may be better now. But mostly we are talking about changing window decorations and replacing confusing option dialogs with wizards and cartoons. Among the most anticipated new features are workarounds like anti-spyware, anti-virus, and such for problems that shouldn't exist in the first place. That's especially sad since Microsoft has such a great research division. Meanwhile, UNIX and Linux have progressed forward in technical capability at a steady clip.
History Repeating History Repeating Itself
Since long before Linux became popular, Microsoft core desktop offerings have consisted of the same basic set of programs with the same basic features. Those programs are Windows, Word, Excel, Access, Visual C++, Visual Basic, and a few others. Their server offerings haven't changed much either. The most notable change between versions of each program is that the newer version almost always creates documents in a format older programs can't read or write. And for your convenience the newer program will happily translate all of your old documents into a format only the newer program can read. After nearly 2 decades of constant development one would think that the stability and compatibility of these programs would be drastically improved. Yet they are still chasing after the same old ghosts and providing the same basic features.
Why is Microsoft frozen in place? That is really quite obvious from the perspective of an outsider. They have found something people will pay insane sums of money to use and they don't want to screw up the cashflow. The only thing preventing them from improving Windows is their belief that the existing body of proprietary Windows software must be supported at all cost. There are large subsystems in Windows which deal with nothing but cataloguing and emulating the bugs found in previous versions of Windows. You might think that sounds insane and I think you'd be correct. However, Microsoft really can't force broken Windows programs to be fixed because Microsoft fiercely promotes the idea of proprietary software; that is, software which cannot be modified or repaired by anyone but the program's original developer. Windows provides what Microsoft calls "Shim Technology" to make a specific proprietary program work as if it was running on the outdated or broken version of Windows used to develop it. Windows needs to know about each specific program that a user might want to run and then provide a set of "shims" to make that program more or less work. A huge set of shims comes with each new version of Windows allowing old programs to remain more or less functional.
Contrast and Compare
A deeply concerning problem for Microsoft should be that the Windows environments and interfaces encourage programs to be deeply tied into the Intel x86 architecture. It isn't feasible to rebuild most native Windows programs for use on another architecture or OS. Microsoft has more recently created the .Net and C# programming environment to encourage developers to write proprietary programs that are not dependent on the x86 processor. However, by my count there are more Linux and UNIX systems running .Net software than Windows. .Net is still so uncommon that most developers of retail software simply don't use it.
A typical presumption when writing a UNIX or Linux program is that you have no clue which computer architectures might run your program. Indeed, you don't even know which operating systems might run your program. Consequently, UNIX and Linux programmers tend to write very portable programs that require only a trivial rebuild to support a new CPU or OS. UNIX and Linux development tools have always encouraged programmers to write portable programs. To further promote writing portable software services like SourceForge and even computer manufactures themselves provide free remote access to development systems. SourceForge has many different computer architectures and operating systems available for Free and Open Source Software developers to use as a test bed.
Another issue with writing Linux and UNIX programs is that most computer architectures don't allow programmers to make serious mistakes. For various reasons and excuses, Intel x86 processors allow a whole host of serious programming mistakes to occur without detection. Worms, memory errors, data corruption, and entire classes of problems Windows-x86 users experience every day simply aren't allowed to occur on other architectures. If a program makes a mistake most computer architectures will instantly abort that program. Then why doesn't Windows support these other architectures? Well, Windows NT did support several of them until around 1999 when Microsoft finally conceded that almost no one wanted Windows on those architectures. Almost no Windows programs existed for those architectures. And porting a mildly buggy Windows-x86 program to a bug-hostile architecture is often more trouble than writing a new, portable program from scratch.
Alternate Realities
Let's consider Mozilla Firefox, a popular Free and Open Source Software web browser, running on the Debian "universal" operating system. Debian can run Mozilla Firefox on Alpha, ARM, HP PA, Intel x86, Intel Itanium, Motorola 68000, MIPS, MIPSEL, Power (Apple & IBM), IBM s/390, and Sun Sparc computer architectures. Debian can run the same program on at least 10 completely incompatible computer architectures without modification. About half of those architectures are strictly 64-bit.
The standard Debian system includes 10,000 programs like Firefox. There are hundreds of thousands of programs like this available from SourceForge. There are over 1 million people helping develop Free and Open Source Software at SourceForge. And I'm barely scratching the surface. There are many other services similar to SourceForge. Many and probably most developers use none of these services and work by themselves or with a close group of friends.
Now consider that Debian provides a choice of 4 different kernels: Linux, FreeBSD, NetBSD, and GNU HURD. This isn't an install-time choice, either. You can quickly switch between the different kernels on an already installed system. Linux supports a huge variety of peripheral hardware and architectures, NetBSD runs equally well on many architectures, FreeBSD provides robust server technologies on popular architectures, and HURD is...well I'm not sure what HURD is good for.
Some Perspective
Natively running the same program without modification on dozens of incompatible architectures under dozens of competing operating systems must seem like complete fantasy to some software developers. And if that's fantasy then easily replacing the system kernel with a different, incompatible kernel must seem completely inconceivable. Believing that one kernel is the best for every purpose seems a bit shortsighted. Not entirely unlike tying your software to a single computer architecture that you don't manufacture...