Moved from OperatingSystemsDesign
When talking about design
of some product, it is important to compare with past and current research, as opposed to other commercial products.
For instance, when talking about the design of a popular automobile, it would be inane to compare it with other popular automobiles. Rather, one would compare an automobile design with, say, the original EV-1 produced by Aerovironment, or the 3-wheeled teardrop-shaped auto produced by BuckminsterFuller
. In fact, one would also compare automobiles with very different products like airplanes (for aerodynamics), trucks, trains, bicycles, et cetera.
Similarly, one must compare an OS design with designs of research OSes in past and present, rather than comparing Unix against Unix and Unix and Unix to come to the inane conclusion that "Unix is good". One should also compare an OS design against other software products (commercial and research) such as databases, languages, et cetera.
The WindowsNT design is decades obsolete. 3 or 4 decades. Unix is similarly obsolete, it only has the advantage of being almost as old as it is obsolete.
The field of commercial OSes is obsolete. This may be the case with all software. It seems to be the case with all commercial products suffering from NetworkEffects
. Consider standard computer keyboards and mice against the KinesisKeyboard
I can buy a standard keyboard for $5 at Frys. How much does the KinesisKeyboard cost? Since mice and keyboards (and all sorts of other input devices, such as trackballs, joysticks, steering wheels, lightpens, and things more exotic than that) have well-standardized interfaces to computers (at several different layers--physical, protocol, and software), I doubt NetworkEffects are the issue in this case.
For OS's, certainly.
You're right, it's not quite the NetworkEffects
. It's the fact that exotic hardware doesn't sell because it's expensive but it's expensive because it doesn't sell. What do you call that particular catch-22? In addition, the KinesisKeyboard
suffers from the evil of being patented.
So, why is it production systems are obsolete? (By the metrics described here; they certainly are - though obsolescence doesn't make something "crap", in my opinion.
- Simple inertia. People prefer what they know. Affects far more than software.
- Compatibility with existing software/hardware. An important concern for end-users.
- The belief (borne out by experience) that old = mature. VersionOnePointOhIsCrap.
And one final reason:
Many things such as ExoKernel
, and numerous other new OS technologies are still subjects of active research. Is a hierarchical filesystem ancient technology? You bet. Is it something that OS developers know how to implement well - a relatively stable body of knowledge? Yes.
Consider automobiles, and the difference between features available on racecars (heavily-financed professional circuits such as NASCAR, CART, F1; not the local dragstrip where teenagers drive around souped up Hondas trying to be like Vin Diesel in the movie) and consumer models available down at the local dealership. Racecars have (and have had) lots of features fresh from the research labs of automakers, things which you won't find in any auto dealer showroom today. However, the racing technology of today will become the consumer standard of tomorrow; just like the racing technology of yesterday is the standard technology of today. In other words, racecars are mobile laboratories. I remember when fuel-injection was a high-performance add-on, and most cars where equipped with carburetors. Nowadays, can you even buy
a new car which still has a carburetor?
Such is it with operating systems. Some years ago, JournalingFileSystem
s were only found in research kernels. Eventaully they made their way into high-end production operating systems, the sort that run in so-called "data centers" and cost more money than most of us make. Nowadays; they are ubiquitious. (Of course, not every new idea gets into production. But that's OK--learning what doesn't work is just as important for advancing the state of the art as learning what does work).
This sort of TechnologyFoodChain?
applies to many different products and disciplines. Why should operating systems be any different? (Actually, there are several reasons why - research in OS's, at least if you exclude high-end scalability as a concern, can be done in anyone's office or den. Research on technology for physical products tends to require expensive laboratories.)
We aren't talking here about "features". We are talking here about principles and fundamental concepts. Is uniformity a "feature" that has appeared in any production OS? No, it has not. The same all the way down the line. PlanNine satisfies only 3 1/2 of the 16 principles of OS design.
Implementation techniques and other such features migrate down the TechnologyFoodChain?, but architectural and other high-level principles never do. Despite decades worth of research in them. IOW, the TechnologyFoodChain? simply
Many people claim "compatibility" is the primary reason programmers write old-fashioned-style software. They are wrong for 2 reasons:
So since compatibility explains jack, what does explain software suckdom? Inertia is almost right. Because it's not simple inertia that people feel. Rather, it's an irrational, primal fear of change. And it's not users who primarily feel that fear, because they have the least to lose and the most to gain. Rather, it's programmers who have the most invested in existing OSes and languages. It's programmers who resist OO in languages. It's programmers who won't write in high level languages. It's programmers who resist new techniques, new methologies, new findings.
OS design sucks because programmers are crazy morons.
- Compatibility is routinely broken, so it must not actually be that important.
- When compatibility is important, you can always use emulators.
Compatibility is routinely broken, so it must not actually be that important.
False; what is important is that it is compatible enough
to get the job done. WorseIsBetter
When compatibility is important, you can always use emulators.
False; not all computers are fast enough to effortlessly emulate another platform. I can run my Commodore 64 software fast enough to even multitask
the emulators. But I openly challenge anyone to get a (near) real-time emulation of a PowerPC Mac on a modern PC. It's not going to happen. Yet. --SamuelFalvo?
They suck because they try to do too much. It's time to SplitOperatingSystemIntoServices
, and have an agreed-up protocol between these services so that we can X-ray the pipes when things get funky. A big locked-up black-box OS is nearly impossible to troublesheet, except by trial-and-error knob twiddling, turning us into Sherlocks with scant clues instead of engineers. If we SplitOperatingSystemIntoServices
and say my internet connectivity component was acting up, I could swap it out for a different one, or at least moniter the communications between the connectivity component and the other items.
Would a UniversalCatalog
that made all software equally accessibly to users negate the mindshare and inertia of MicroSoft