re: Windows NT woes, switching to Linux

[turnbull@example.com (Stephen J. Turnbull)]

>>>>> Ted writes: 

   If you have to call MS tech. support about clone disk drive controllers, 
   regardless of admission of guilt, multiple responses from different techs., 
   misc. other excuses, then you very likely don't know what you're doing, or 
   buying.

I have no idea where you're coming from.  I didn't have to call anyone
until after my disk was trashed.  Then I report a bug and the fix, and
you say "[I] very likely don't know what [I'm] doing or buying"?  How
much do I need to know?  And in a previous thread you gave me a hard
time for writing about "MS compatible hardware," arguing that
practically everything is.  Now you're offering advice on "good Intel
CPU based equipment and Windows NT resources".  Should I not infer
that some compatible equipment is more compatible than other
compatible equipment?

I'm serious.  Professionally, I am interested in economic aspects of
information and communication systems.  Obviously, computer systems
are not atomic commodities like, say, "red wheat #2" or "east Texas
light crude" or "4 Mbit DRAM".  However, theoretically "plug'n'play"
should work; as far as I know the jury is still out on whether the
MS/Intel implementation works to specification.  I'm sure most bugs
will be ironed out pretty quickly though.

Or maybe not.  That's the issue here, right?  When a spec is
published, people may choose to disregard it, work around it, use
undocumented interfaces and internal subroutines, etc, etc, either for
efficiency reasons or because the spec itself is buggy or just because
they don't feel like going the long way around.

My philosophy is that I don't trust much of anybody to do it right.  I
especially don't trust Microsoft (why is the DPMI spec in use *still*
an incomplete version, 0.9?  1.0 *has* been published and offers
serious system integrity improvements---UAEs are nearly impossible,
I'm told, it almost has to be a kernel or DPMI host bug).  Microsoft
has spent a lot of effort the last few years to make sure that they
are the standard everyone else conforms to; I'm not so sure about
their willingness to conform to others' standards when it's
inconvenient (does anybody know what improvement TrueType is over
Adobe Type 1, aside from the fact that MS doesn't have to pay Adobe
royalties on it, which is the only motivation I've ever heard of?)  On 
the other hand, if you have to publish your source and every tech
weenie in the world is going to pore over it to find some way to blame 
you when something goes wrong, you'll be a bit more careful about
dotting t's and crossing i's.

Of course, I can't trust the hardware makers either.  But hardware is
hard, and software is soft.  Even if I have the "source" for the
hardware, I can't change it.  By definition.  Whether it's right
("specification compliant") or wrong.  The software is another matter.
As long as the hardware does the same thing every time, I can program
around its flaws.  *If* I have the source.  (Granted, some hardware is
so buggy that replacing it at 5 times the cost is the cost-effective
solution.  This is simply not true of my SCSI host adapter, even if
it's not a big-name-for-SCSI brand.  Replacing the OS at 0% of the cost
was the cost-effective solution.)

Now, my experience with system problems, on a wide variety of systems
ranging from automobiles to PCs to accounting, has been that when
multiple vendors are involved, they all point fingers at the others.
"Our stuff works---talk to the other guy."  MS tech support is known
to do this, just like everybody else.  But it's hard to get away with
that if the customer has the source code and can read it!

It seems to me that if the OS's source code is public, there is a
point of reference for making judgements about where the failure is.
Conversely, with a proprietary system like Windows NT, I can't ever
know enough.  That means I must ask Microsoft what hardware I'm
allowed to use---you seem to have discounted the fact that my SCSI
host's docs said "use a Buslogic driver when available."  In
combination with the rest of your argument, I assume I must infer that 
I shouldn't trust the hardware vendor; I must ask MS's permission!

This is great for Microsoft.  It may be an efficient way to organize a 
computer industry; I don't know.  That's a topic of current research,
although I'm not pushing it very hard at this moment.  As a consumer
and hobbyist, it gives me gas, as Archie Bunker used to say.

Obviously, you don't believe I should need to ask MS's permission to
use a given hardware vendor.  I know some of the things you can say
("use a reputable vendor who's been in the business for a long time
with lots of successful products," etc).  But do you have a coherent
philosophy of how these things should work, or is your argument based
more on many years of experience as a user and an employee of a
well-respected hardware vendor, and not necessarily integrated into a
"philosophy"?

   Now if you knock of the name calling,

What?  You mean "old man"?  Wasn't it you that called me a
"whippersnapper" a few weeks ago?  If not, I apologize.

   and want some good resources
   for using good Intel CPU based equipment and Windows NT resources,

No, thank you.  I was dead serious.  I see no reason whatsoever to use
Windows NT in my shop at this time.  It just doesn't offer *my lab*
anything that Linux doesn't.  And it would require me to learn a whole
new set of system administration techniques, and so on.  If I change
my mind, I'll let you know.

Remember, I personally was simply trying Windows NT because it's
supposed to be the best thing on the block, and because I happened to
inherit responsibility for a host running Windows NT Advanced Server.
In maybe 25 hours of casual experimentation (playing games, watching
the event queue, using the file manager, etc) with the initial public
release and now v3.5J, I've experienced a catastrophic data loss, a
very annoying system bug, and several configuration problems.

Your experience says "use reputable hardware."  My experience says
"use the OS that does the job and works with your clone hardware."

When I find a task for which NT is better suited than Linux, or when
I've got time to experiment with a new system, I'm imagine I'll try it
again.

   I'm happy to oblige, just ask, and chill.

Hey, who needs to chill here?  I enjoy a little flame-war as much as
the next guy; you were probably right about the 64-bit processor
thing, but hell, my brother works for DEC---gotta help him sell a few
Multias, right?  But on this one, as far as I can see, you have some
interest in blaming real problems with Windows NT on me.  I mean, I
just can't win for losing: you open with "did you contact knowledgable
Win NT resources, or bitch and moan on Linux MLs?" and when I reply
that I contacted Microsoft, you tell me that the fact that I had to
contact Microsoft (to report a bug and the fix, yet) means I didn't
know what I was doing!  As the author who "developed one of the first
apps for NT," did you *never* contact MS about the project?  Dollars
to donuts, you did.  If the app was good enough to show, I'm sure you
knew what you were doing.  Why can't you give me the same credit?

Sure, this is a Linux mailing list.  A little Linux advocacy, even if
it means knocking another OS, isn't completely out of place, is it?
We're all grownups, right?  I don't hide the fact that I have an
emotional bias against Microsoft.  That doesn't mean it's entirely
groundless, as you seem to infer.  Just that people should be a little 
cautious about taking my words as gospel.  But in this case, I think
that the facts are on my side.  Windows NT has decided to "get" me :-)

And remember, Linux *is* an open OS.  It's a playground for people who
like to open up the hood.  I think discussion of the design and flaws
of other OSes *is* germane to this list if it's not too one-sided.

The fact that Microsoft doesn't follow published specifications for
writing drivers is of interest to Linux programmers when it provides
an example of how dangerous that is.  The fact that "God's Own OS"
apparently has some deadlock problems in its IO handling subsystem
demonstrates how difficult those systems must be to program.  So what
if these are old versions?  They were publically released.  You tell
me my excuses are weak.  Well, I think the difference between release
3.5 and release 3.51 is a pretty weak excuse for a deadlock in a major
subsystem of a multi-tasking OS!  And we don't even know for sure that
the problem is fixed in 3.51---you just thought I should try it before
complaining.

Well-I'll-be-damned Department:

I didn't believe anyone would pay attention to my bogus attachment,
but here's what Ted's mailer said in quoting my post:

   Use Voluptous Font: true
   Previous From: slaveholder-tlug@example.com
   Previous To: t-slug@example.com
   Attachment Count: infinite
   --$----Linux--Attachment----$

   X-LNX-Content-Type: kernel binary
   X-LNX-Content-Typename: mail-bomb
   X-LNX-Content-Charset: X-Sanscrit
   X-LNX-Content-Filename: vmlinux
   X-LNX-Content-Transfer-Encoding: X-UUENCODE

      <NGM : auto-uudecoded attachment /don't-boot-my-ass/v...>

Yowsa!  I thought I was just being paranoid when I made sure that the
file name referred to a non-existent directory....  Shoulda known, I
guess, Ted's mailer wouldn't put that garbage in if it didn't use it.

-- 
                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tennodai 1-1-1, Tsukuba, 305 JAPAN                 turnbull@example.com