Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

la la land



Seth writes:
| On Windows NT, if you try to delete or rename a file that's already
| open, you get a "sharing violation" error ...
...
| (Was there some intelligent technical trade-off behind the choice to
| run NT like this, or is it one of those legacies of DOS that can't be
| worked around, or what?  They guy they hired to run the NT project in
| the beginning, if memory serves, was one of the big developers of VMS,
| so I would expect a certain level of clue from him....)

The most straightforward explanation, as with other OSs, is that it's
simply  a  case  of  an  independent development line whose designers
couldn't be bothered to study other  systems  or  learn  any  of  the
history of software engineering. The "Not Invented Here" syndrome has
been clearly active in the history of the Microsoft OSs. They weren't
about  to  learn  why those unix nerds did things in the strange ways
they did.

The fact that NT's designers came out of  VMS,  which  has  the  same
Multics ancestry as unix, is true but probably irrelevant. The recent
description of unix's file-linking scheme as "strange" is an  example
of  how  even  experienced  unix  users  and programmers don't always
understand the reasons behind the design.  The unix fork+exec  scheme
is another.  It usually takes quite a lot of experience to understand
why these are Good Ideas, and designers without that  experience  are
likely  to  design things in a more obvious way.  Unix's file linking
scheme, and the fork/exec scheme, actually came out of  Multics,  and
it  took  quite  a lot of experimenting to come up with these elegant
solutions to problems.  The ejection of things like file formats  and
command languages from the OS kernel are other examples of subtle but
correct designs  that  are  counterintuitive  to  all  but  the  most
experienced software engineers.

The gang at Bell Labs understood the design of Multics, and picked  a
lot  of  the best-known (at the time) solutions to problems for their
little stripped-down system.  It is sorta disappointing that 30 years
later,  we still have OSs that implement inferior or non-solutions to
the same problems.

It's probably overly paranoid to think that the DOS/Windows/NT  chain
were  intentionally  designed to violate what was known about good OS
design at the time.  They were just in their own world, and not about
to  learn  from  "legacy" systems, because they were brilliant people
with their own brilliant ideas of how to do it right.  So  they  made
the same mistakes, and haven't yet stumbled across the solutions that
the Multics people discovered back in the 1960's.

Who was it that first said "Never attribute to malice that which  may
be adequately explained by ignorance (or stupidity)"?  I've seen this
attributed to any number of people (all of whom probably did say it).

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org