[Info-vax] Anyone interested in another public access system

[Bill Gunshannon]

In article <qMOZXUt3qWvj at eisner.encompasserve.org>,
	koehler at eisner.nospam.encompasserve.org (Bob Koehler) writes:
>  Bill Gunshannon wrote:
>> 
>> In article <BZhjsJkqzq4v at spock.koehler.athome.net>,
>>         koehler at eisner.nospam.encompasserve.org writes:
>> > In article <72pgbbFrckbiU1 at mid.individual.net>, billg999 at cs.uofs.edu (Bill Gunshannon) writes:
>> >>
>> >> U*mmmm....  No, not really.  Active development (well, at least as active as
>> >> VMS seems to be) for three of the PDP-11 OSes just ended last year.  So, if
>> >> you take when they first started and compare that to when VMS first started
>> >> VMS will need a few more real good years to match them.
>> >
>> >    Hm.  Although possibly not as important as the Berkley port to VAXen,
>> >    I seem to recall the development of UNIX including a port to PDP-11
>> >    early on.
>> >
>> >    Sadly, I think continued development of that '60s technology will
>> >    continue for a bit longer.
>> 
>> Unix is no more 60's technology than VMS (which traces it's roots back
>> to RSX on the PDP-11 as I recall) or zOS which can trace it's roots all
>> the way back to the IBM 360.
>> 
>> It never ceases to amaze me that Unix, which has seen constant development
>> and considerably more attention from Computer Scientists and Engineers
>> than VMS is seen as stagnant while VMS which, as frequently stated here,
>> has seen little in the way of anything beyond the minimal bug fixing, is
>> seen as the epitome of modern computing.
>  
>    UNIX is still a two-mode system which forks new processes every time
>    it turns around, and has no concept of files beyond stream of bytes.
>    That approach was typical of late 1960's OS design, and can be seen
>    in other OS, such as TOPS-10 and TOPS-20, which on the outside look
>    very different.
> 
>    Nothing that has happened to UNIX over all the years has changed that
>    basic late-1960's design.

And yet, it is by far the most successful OS to come along.  Maybe the
reason none of those features were put into Unix is because Unix does
the job of being an OS just fine and all of it's users (probably several
hundred times the number of VMS users) don't see any need for any of
that extra fluff.

So, tell me, what is wrong with forking a new process for each job?  What
does SPAWN do? The idea of using a separate process for each running task
is a part of the underlying paradigm that Unix is based on, why would they
do it any other way?  If you change the paradigm, then it isn't Unix any
more.  As for the file system being strictly a stream of bytes, why not?
Why impose a layer of overhead on all users when for many of the real uses
of computers every day the stream of bytes is sufficient.  If you want
more, then use it.  We had C-ISAM and if there really was a desire for it
ther eis no reason why RMS (or something compatable) could not be called
as a library interposing itself between that stream of bytes and an
application, thus limiting the overhead to people who need it and not
imposing it on people who neither need or want it.  the lack of all of
these features people keep bringiang up only goes to show that the majority
of people (based on the ratio of Unix Users to Users of other OSes) just
plain don't care and don't see any real value in such features.  Unix is
the most adaptable of any OS that I have ever worked with (and I have
worked with a lot of different OSes most of which have not survived the
advancement of the industry).  Any of these features that people bring
up could be added, most of them quite easily, but none of them have benn.
And the reason is so blatantly obvious.  The Unix user community just
doesn't see enough value in them to bother.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>