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? Rally cars built to WRC standards are much much closer to what you can buy off the shop floor and permitted modifications to the base production model are also off-the-shelf. Driver and support crew skills are somewhat more difficult to come by. So, not so much as mobile laboratories as proving existing technologies.
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.
To be honest, I agree. I routinely learn new languages, but won't use Python because it's too much like another I know. --SimonMould
OS design sucks because programming is really really hard.
OS design sucks because those with the best resources to advance it are also the most reluctant to risk their market share by doing something that breaks with the old way of doing things.
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?
Perhaps that should be 'when compatibility is more important than performance'...
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.
("Troublesheet" - that's a new word for me. I think it deserves to mean something, but what?)
On Windows, (and probably most other OperatingSystems, but I know it IS on Windows), it splits SYSTEM PROCESSES into services in Task Manager. On Win7, it lets you 2ndary click on a service to view the process. The service also shares a name with its part of the registry, so if you want to replace one which is playing up with, say, the one from Win98SE (although for that you would have to set up specific compatibility, maybe a light version of Win98SE, to run the service), just copy onto a (compatible) stick, paste to the Win7, and edit the REG files. But that IS a lot of hassle, and would be made easier by splitting OS's. I agree. (But there should still be default groups of services being OS's!) --SimonMould
Would a UniversalCatalog
that made all software equally accessibly to users negate the mindshare and inertia of MicroSoft