Opinions please! I am only a messanger.

["keky_uswest.net" <keky@xxxxxxxxxx>]

Hey ya all:

I am ancient! This is not an attempt to knock LINUX; 8 of my lab systems run LINUX of many castes. (RedHat, Debian, Susie, Mandrake..).I came across some provacative comments from people I respect for their knowhow.  

Here is what they have to say

Mr.Rob Pike of Bell Labs ..Co-author of 'The Practice of Programming' with Brian Kernighan
in one of his recent presentation.. SYSTEM SOFTWARE RESEARCH is IRRELEVANT !
All of it at http://cm.bell-labs.com/who/rob/utah2000.pdf

7 Linux

Innovation? New? No, it's just another copy of the same old

stuff.

OLD stuff. Compare program development on Linux with

Microsoft Visual Studio or one of the IBM Java/web toolkits.

Linux's success may indeed be the single strongest argument

for my thesis: The excitement generated by a clone of a

decades-old operating system demonstrates the void that the

systems software research community has failed to fill.

Besides, Linux's cleverness is not in the software, but in the

development model, hardly a triumph of academic CS

(especially software engineering) by any measure.

17 Linux the Academic Microsoft Windows
The holy trinity: Linux, gcc, and Netscape.

Of course, it's just another orthodoxy.

These have become icons not because of what they are, but

because of what they are not: Microsoft.

But technically, they're not that hot. And Microsoft has been

working hard, and I claim that on many (not all) dimensions,

their corresponding products are superior technically. And

they continue to improve.

Linux may fall into the Macintosh trap: smug isolation leading

to (near) obsolescence.

Besides, systems research is doing little to advance the trinity.

>>>>>>>>>>>>>>>>>>end Pike's Spike <<<<<<<<<<<<<<<<<<<<<<<<<<

And now, here is what MULTICIAN have to say about UNIX.

Excerpt from alt.multics.os..

Actually, Unix is anything but elegant.  It prided itself on providing a
set of oversimplified, inadequate, and arcane tools that could, with
great difficulty, be assembled by a do-it-yourself-er into something
that almost, but not quite, worked - but not reliably.  It was an
unsecure single-user system; all the security and multi-user features
have been added on since, which goes a long way toward explaining why
Unix is so unsecure.

Here's my top ten Multics-only features:

Multics had, and Unix did NOT:

1. Standard Command Arguments.  An arg of -a meant -all for every
command; same for -l (long), -b (brief), etc.  How wonderful that was! 
You could just start using commands without having to use help, and it
was always easy to come back to Multics without having to re-learn. 
Unix commands are all over the map, and very hard to remember.

2. Actual Error Messages - lots of 'em.  Not only did Multics have more
than 32,000 possible error codes, you could make your own error_segment_
and add 32,000 more for your own program without conflicting with the OS
error codes.  Unix has only 256 error codes (a holdover from the 8-bit
days) and gives errors like "enomem", which could mean a problem in
shmem, semaphore, stack, virtual memory, output buffer, heap, etc.,
forcing users to use guessing as a debug method.  Jim Falksen referred
to these as "content-free messages"; one wondered why Unix bothered to
print anything at all.  On some Unix systems (notably the DTC-II SunOS
boxes) the "panic" message (just the word panic, nothing else) was
output on the printer port - if you didn't have a printer, you saw no
error message at all...

3. Real Virtual Memory - automated!  While porting applications to Unix,
I discovered how much Multics was actually doing underneath.  In Unix,
you have to manually map/unmap memory areas (and unmap/re-map if the
size changes).  It's like the difference between a self-propelled mower
and a push-mower:  they both cut grass, but one gives you a lot more
exercise. The Unix error for accessing beyond the end of mapped memory? 
Bus Error! Very helpful.

4. Real Access Control.  The access control in Unix file systems is so
inadequate, it's really pathetic.  ACLs, Ring Brackets, & AIM made
things so secure.  Half the attacks on our servers couldn't have even
started under Multics...

5. Support for SMP (actually Asynchronous MP - the CPUs didn't all have
to be the same) long, long before Unix.  This was, as Tom pointed out,
part of the reliability aspect of Multics - but it impacted performance
as well.

6. Dynamic Linking.  Oh, my, how I miss this!  Recompile one program out
of 300, and then just re-run the test.  Or, tmsr inside the debugger,
edit & recompile the defective program, then jump down one stack frame
and re-execute the call.  It was possible to replace parts of a large
running program without restarting it...  ENWGS was routinely patched
(e-fixed) in this way.

7. Long Date Storage.  72-bits.  No Y2K bug.  No 2028 bug.  Dates in
Multics won't run out for thousands of years yet...

8. Re-startable Condition Handling.  OK, some conditions can't be
re-started; but some can.   Record Quota Overflow, for example.  Use a
cleanup routine in an RQO handler to delete temp files, and you can keep
your program running.  The same occurrence in Unix is a Core Dump. 
Which reminds me...

9. Easy Debugging.  No Core Dumps.  Every program halt causes a wall in
the stack, allowing the debugger to be invoked to analyze, repair, and
restart the frozen program.  I hate Core Dumps...

10. Terminal Control.  The ctls in Multics were far superior to any of
the termcap & terminfo controls available in Unix.

Anyway, that's my list for now.  I'll probably think of more later...

        -RAM

For those who are not ancient MULTICS is the Brahma of all OS.  It was
developed in MIT in the 60's.  UNIX development by Ken Thompson and
Dennis Ritchie was inspired by MULTICS.  One of them was a MULTICS
developer.


Cheers,

Keky Robertson


---
Visit our home page at: www.chennailug.org
Send e-mail to 'ilugc-request@xxxxxxxxxxxxxxxxxx' with 'unsubscribe' 
in either the subject or the body to unsubscribe from this list.