[OT] NT, software reliability, and the lack thereof.

From: Dean Billing <drbilling_at_ucdavis.edu>
Date: Mon Mar 15 17:13:03 1999

At 08:21 PM 3/15/99 -0000, you wrote:
>Dean Billing <drbilling_at_ucdavis.edu> wrote:
>> After M-Squish designed NT, they hired one of the VMS gurus from DEC
>
>No, they weren't *that* stupid. They hired him at let him design it.
>The actual operating system deep in the bowels of Windows NT isn't so
>bad.

This doesn't sound right to me. I guess there are so many legends about the
NT design team that we would have to name each person and understand their
contribution. Very early on, when NT betas were being distributed free, and
I got one of them, the lore going around that NT core was canabalized from
the new Mach kernel. Later, I heard that one of the VMS gurus was hired by
MS. I find it very difficult to believe that they would hire a DEC VMS guru
before NT was cast in iron and then "...let him design it." If NT was
based, even loosely, on the Mach kernel, why would they hire a VMS guru?
Why not a Mach kernel guru?

>But they have lventy-seven layers of crap on top of it to keep
>you from seing anything that might be simple and elegant.

Every operating system today has "...lventy-seven layers of crap on top of
it..." including UNIX with an X client and then applications or AIX with
SMIT on top of an X client or even VMS.

>> ...
>No, it isn't. The underlying operating system is nothing like Unix, and
>only vaguely like Mach (which are themselves two entirely different things).

OK, but isn't the general end result of using the Mach kernel, a UNIX system?

>However, as a "normal" Windows programmer (for the Win32 subsystem), you
>can't even get to the operating system. You can only call the Win32
>layer.

VMS protects itself in the same way. If you are writing well behaved
applications, you can only make VMS system calls, even if you are writing
drivers.

>> Therefore, they have not been able to implement a true clustering system
>> and IMHO because the DEC software engineers came late to the game, they
>> were unable to design the basic reliability into the operating system
>> software interfaces.
>
>Again, that's not the fault of the kernel. The kernel is pretty good. The
>problem is the leventy-seven layers of crap above it.

I believe it is the fault of the kernel, for without a kernel with a built
in distributed lock manager, you can't implement true clustering. You get
something like IBM AIX with HACMP which is a "...lventy-seven layers of crap
on top of it." to simulate a "cluster" in a UNIX environment, except you
have a system disk on each CPU which must be synchronized with every other
system disk.

>And the I/O architecture is even OK, but unfortunately you end up with
>hundreds of device drivers written by bozos running at ring zero, so
>naturally the system isn't as robust as it should be. DEC was in complete
>control of the VAX, so most VMS sites didn't run any drivers that were
>written by clueless morons.

This is surely not the case of sites that used VAXen for process control,
which was a primary feature of VMS in the early days; VMS being an extension
of RSX-11. DEC also has documentation to write drivers properly, as I would
assume MicroSoft does for NT. I doubt whether all of the problems with NT
are bad drivers written by our local " ... clueless morons." ... since we
don't do that, and our NT systems still crash frequently.

> ...
>Um, what do you mean by "doing development work on them"?

I mean doing any kind of application software development work
simultaneously with using it for a server, which is what we do every day on
our VAXcluster and IBM RS/6000 UNIX servers.

>If you want a file server to be as robust as possible, it should be used for
>nothing but serving files. That was true even in the old days.

That would be news to any large VMS or IBM mainframe shop.

>Nowdays people load all kinds of crap on their NT file server. It's no
>wonder the things fall over every few days.

We have loaded all kinds of applications and third party software on our
VAXcluster, from Interleaf, Sapiens, Oracle, MEC, and others and it has
never crashed except during hardware failures which have ocurred every few
years.

>Of course, if NT didn't have the problems discussed above, it should have
>been able to go weeks or months without falling over.
>
>> Another drawback to NT is that many software
>> upgrades and application installation/deinstallations require rebooting,
>> something unheard of with VMS.
>
>This problem is definitely a matter of poor design. I'm pretty sure this
>one is also not the fault of the kernel, but of the leventy-seven layers
>of crap above it. The programmers were too lazy and/or in too much of a
>hurry to bother to figure out how to make changes without rebooting.

Agreed.

-- Dean
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dean Billing Phone: 530-752-5956
UC Davis FAX: 530-752-6363
IT-CR EMAIL: drbilling_at_ucdavis.edu
One Shields Way
Davis, CA 95616
Received on Mon Mar 15 1999 - 17:13:03 GMT