(I spoke to someone else who was utterly amazed that NT allowed driver development without requiring that the whole kernel be relinked from object files.)
(I spoke to someone else who was utterly amazed that NT allowed driver development without requiring that the whole kernel be relinked from object files.)
The one thing you will find almost as a theme with Linux design is that there is minimum of "future" it. That applies to most of the Linux user space as well. This is a good thing and a bad thing.
For example multi-gpu systems with multiple outputs were not taken into consideration when both the Kernel and Xorg parts were designed. They took the most common usecase of single GPU, probably made some assumptions around it and coded something that works for that usecase.
Microsoft, on the other hand (almost out of necessity) had to actually design the NT Kernel while making no assumptions - multi GPUs may not have existed when XP was released but none the less MS had to design for the eventual reality when some OEM will stuff 2 GPUs and will have to write drivers for it without Microsoft being able to change the XP kernel design or even implementation in any way. I am sure the same can be said about scalability - when massively multicore CPUs weren't around NT kernel was mostly up for task of supporting them, whereas Linux adopted with lot of scalability related work that followed after the fact. (Remember the early NT vs Linux benchmarks?)
Designing for future is bad because it comes with certain baggage and to an extent added upfront costs. It is good for future compatibility, code maturity and obviously saves rewrite efforts - you don't have to rip off all the code and start over and take care not to break existing software etc. There is less code churn in Windows world I am sure than there is in the Linux world where people are constantly adopting to new realities. This creates an environment ripe for new bugs, instability and only with the amount of volunteer effort the cost factor can be lesser than prohibitively expensive.
Maybe because it is mostly about the "past", bringing enterprise UNIX and mainframe designs into Linux?
It's depressing in a way but that's the best we got when it comes to a hackable Open Source OS that you can somehow run on your hardware and even patch things you don't like.
What new ideas in operating system design has Linux brought, other than being a UNIX clone at zero cost?
You could put 2 or 3 NeXTdimension cards in a NeXT Turbo Cube, for example - each with its own i860 running Display PostScript and something like 32MB of RAM - and use a display attached to each.
And the other workstation vendors had even fancier graphics subsystems and options. You could get real time stereo (LCD shutter) 3D with full Z-buffer and overlay planes for UI use (requiring a few dozen MB of VRAM) for the cost of a sports car. And with some systems use several at once.
Find some old copies of UNIX World or Personal Workstation or BYTE from the era...
Filesystems, TCP/IP stack, Multi core scalability etc are the areas that most benefited from old UNIX design. (Questionable in case of TCP/IP - Alan Cox rewrote it and I am not sure if he was influenced by any older UNIX implementation or not.)
mjg59, I could not disagree more. Without working drivers what good are working apps? I can run my Radeon x1900 under Windows 7/8 with Windows Vista drivers. Runs StarCraft2 and newer FPS games just fine.
The Linux kernel devs are so determined to break binary compatibility, I haven't been able to run with ATI's proprietary binary drivers for years. While AMD was a good open source citizen and released the specs, the open source drivers for my card are useless for anything other than 2D. That's about as disruptive as it gets.
Well, of course. As long as no one else can use their drivers, they won't get a serious competitor in open source land. Pity about the rot in official drivers, though (e.g. for me, the latest is USB 1.x sound dongles in debian lenny -> squeeze).
Which suggests to me that if I wanted to write a OS that could become really popular I should use Windows device drivers in a microkernel approach where each lives in its own address space and process. Hmmm.
For example, Solaris has had a stable driver DDI (Device Driver Interface) for years. This is what allowed ISVs to write drivers for ancient versions of Solaris that still work today (assuming the base hardware platform is still supported).
That's also what allows the latest versions of the nVidia driver to generally just work on different releases of Solaris.
Frankly, I'm still more impressed by a monolithic kernel that did it better, before: Plan 9 (released in 1991). What use is for NT to be object-oriented, if it can't share its objects through a network like Plan?
VMS.
> Frankly, I'm still more impressed by a monolithic kernel that did it better, before: Plan 9 (released in 1991). What use is for NT to be object-oriented, if it can't share its objects through a network like Plan?
Sadly the UNIX crowd decided it was not worth it adopting it.