Path: utzoo!mnetor!uunet!nuchat!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.os.misc
Subject: Re: OS features
Message-ID: <1276@sugar.UUCP>
Date: 17 Dec 87 02:35:25 GMT
References: <1971@cup.portal.com>
Organization: Sugar Land UNIX - Houston, TX
Lines: 98
Summary: More explanations and a mild flame.

In article <1971@cup.portal.com>, Mark_G_Woodruff@cup.portal.com writes:
> From: uunet!nuchat!sugar!peter
>   >  Berkeley symbolic links.
>      [Please explain.]

You create a symbolic link from "/usr/joe/blah" to "/work/acct/fred/baz". The
link is actually the string "/work/acct/fred/baz".

>   >  VMS/AmigaDOS symbolic names.
>      [Please explain.]

In AmigaDOS:

1> LIST SYS:C
Directory "sys:c" on Wednesday 16-Dec-87
Run                         2324 rwed Today     05:57:30
Fault                       2728 rwed Today     05:57:30
Install                     1800 rwed Today     05:57:31
...
1> ASSIGN C: SYS:C
1> LIST C:
Directory "c:" on Wednesday 16-Dec-87
Run                         2324 rwed Today     05:57:30
Fault                       2728 rwed Today     05:57:30
Install                     1800 rwed Today     05:57:31
...
1> ; You can do the same sort of thing under VMS.

This does the same sort of job as links: creates an alias for a file. It has
strong points and weak points.

>   >  RMD in RSX.
>      [Please explain.]

Realtime Memory Display. Shows processes and where they are in memory. The
best memory display type setup I've ever seen.

>   >  Being small and tight is good. Taking features out if it helps is good.
>   >  Version 7 is a better designed O/S than either System V or Berkeley.

This last cannot be too strongly emphasised.

> From:  Mark.G.Woodruff@Cup.Portal.Com
> 
>   o  Virtual Machines.  They allow you to code as close (or far) from the
>      hardware as you like without sacrificing security.  They also aid
>      tremendously when writing operating systems or hardware-dependent
>      software.

They also give you a performance hit. See above.

>   o  A common command language for both the editor and the shell.  With
>      Rexx and Xedit under VM, you can use the same command language to
>      write your editor macros and you shell scripts.  This also makes the
>      editor a much more powerful tool for software building than any
>      equivalent under Unix.

What about Emacs?

>   o  An easy-to-learn command language.  Rexx is far easier to learn and use
>      than any other interpreted language I've seen (including Basic, the
>      shell and cshell languages, Logo, and Smalltalk).

None of which are really terribly easy to learn.

>   o  An object-oriented file system.  The designers of Unix made a serious
>      mistake in forcing all objects in their file system to have the same
>      format.  A much better approach would be to define a common protocol,
>      then let each object decide how best to implement it.

I'd have to see this in action. My experience with IBM file systems has been
that they're like trying to read a menu in a dark restaurant wearing
sunglasses.

>   o  Long command and option names that can be abbreviated easily.  Unix
>      is impossible for a novice to use without a manual in large part due
>      to its poor user interface in this regard.

CMS is better???

>   o  A real-time kernal.  Essential for a great many tasks.

For a real-time machine, yes. For a time-shared machine, no. Personal
computers should be real-time. Mainframes shouldn't be.

>   o  Contiguous file allocation on large devices.  The additional overhead
>      of discontiguous file allocation is unwarranted on modern hardware.

How do you implement this without throwing away most of your file space to
fragmentation and/or having the overhead of frequent garbage collection?

> Mark

In closing, I'd like to ask why you made this survey only to completely
ignore most of it?
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.