NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/acorn/8395

Internet Message Format | 1992-08-27 | 7.3 KB

Path: sparky!uunet!gossip.pyramid.com!decwrl!sdd.hp.com!hplabs!ucbvax!toy.usl.com!lithgow
From: [e-mail] (Malcolm Lithgow)
Newsgroups: comp.sys.acorn
Subject: Re: OS differences and improvements (Was Re: new PC's, what's happening acorn?)
Message-ID: <[e-mail]>
Date: 27 Aug 92 07:35:15 GMT
Sender: [e-mail]
Lines: 162

Last message on this subject. (I hear a lot of sighs of relief. ;->)

[In message "Re: OS differences and improvements (Was Re: new PC's, what's happening acorn?)", Andy Duplain writes:]
>    All you seem to be saying is that the user process should have
>    more control over what pages get swapped and what pages don't.
>    You say that the user process VM manager should be able to do
>    this, but you're wrong;  a user process would never be given
>    the CPU priviledge to do it, because of security reasons (a multi-
>    process operating system would never provide a way for a user
>    process to gain this priviledge -- you're just asking for
>    trouble).

No, I'm not saying that. I'm suggesting that, instead of the simplistic
limits of UNIX-style systems, where code runs as either system or user
code, that another type be added, and used.

In this case, I am talking about a 'library' of object managers that
user code uses to manipulate data-structures, etc. These object
managers are not part of the OS in the UNIX sense of the word, but
*are* in the (far more flexible and extensible) RISC OS sense of the
word. They are used by user processes (like libraries or system calls
or SWI's), and have a number of instantiations for each user process
(like shared libraries). The user process itself need never directly
call the OS memory management services. In fact, the user process need
never have code for most of the fundamental data structures.

The core OS regulates access to the memory mapping, but doesn't dictate
it. Regulation alone removes any security problems (as far as business
needs are concerned) -- we don't need to be dictated to.

>You also agree that the majority of the code would still
>    exist in the kernel, so all you're saying is that a new system call
>    should be added to allow the user process to control his virtual
>    memory... that is the _only_ way it could be done.

No, I think the code still in the kernel would be minimal -- a few
hundred lines of C or Assembler at the very most. Most of the code
would be in the 'libraries' or 'object servers'.

>But why do
>    you need it ?  One of the principle goals in any operating system
>    is to provide the user with a "virtual computer", one where the
>    disk, tape, memory etc devices are uniformly addressable.

The job of an operating system is to abstract the software environment
from the hardware environment (so that the OS will not change when the
hardware changes, and so that the burden on programs is reduced), which
my proposal does. I'm not sure what you mean by 'uniformly
addressable', and I don't remember seeing any such requirement in any
of the OS Architecture books I've read.

>By giving
>    the user so much control over the memory system, this "virtual
>    interface" is lost.

No it isn't. The user (actually the system libraries) simply has a more
powerful virtual interface. Now the library code can request memory,
remap it, or release it. What is so hardware-bound about this?

>No virtual memory system is perfect, as it
>    takes too much processing time to be so, but I, as a user, would
>    rather not have to worry about it; it's the operating systems job.

Exactly. And my proposal not only takes the worry off your mind, but it
also takes the the toil of writing code to handle b-trees, hash-tables,
frame-buffers, text-buffers, lists, tables, queues, stacks, etc. off
you.

[Lot's of stuff about UNIX and application portability deleted.]

>>In fact, if people had a standard data format, they could spend the time
>>to port their product to a different OS (such as RISC OS) instead of
>>writing millions of converters. ;-)
>
>    I can't think of a more boring subject than "standard data formats".

How about application portability? ;-)

>    Most of the arguments between you and I in this newsgroup come
>    about because you take every opportunity to slag off UNIX whenever
>    you can.

Well, surely I have a right to? I work for USL, after all. ;-)

>You keep trying to compare RISC OS to UNIX when they are
>    not in the same league, they are not for the same purpose, and are
>    therefore incomparable.

Well, RISC OS is a piece of software designed to abstract the hardware
from both software authors and computer users. UNIX is the same thing.
They are comparable on that level. (Just as are a Mac truck and a
Ferrari, both being self-propelled vehicles designed to transport
things. In fact, I would say that UNIX and RISC OS are more comparable
than that.)

>So what if UNIX is written in C and RISC OS
>    is written in Assembler ?  The main aspects of an operating system
>    should be what they offer by way of services to the user.  UNIX
>    offers a uniform interface to the computer hardware, RISC OS doesn't.

Pardon? In what way does RISC OS fail to offer a uniform interface to
the hardware? I can see no way that UNIX offers a more 'uniform'
interface. The ease with which programs migrated from the BBC Micro to
the Archimedes demonstrates how successful Acorn have been at designing
systems to offer a 'uniform interface' to the hardware.

>    UNIX is used by many computer researchers to implement new systems
>    (i.e. the VM system and fast filesystem that Berkeley introduced).

Neither of these are breakthroughs of any sort. DOS is used for the same
purposes.

>    This can't be done on RISC OS, because (a) the OS source code is
>    not distributable or even distributed, (b) it would take too long
>    as it is done in assembler.

What you are saying is that RISC OS is not a big lump of source code
for hackers/researchers to delight in. So what? Does that make it a
worse OS? Of course not!

Because RISC OS is properly designed, bits of it can be replaced at
your leisure, and have been over the years.

>UNIX is used at many commerical and
>    educational establishments to control computers because it offers
>    many capabilities.

Same with RISC OS.

>RISC OS is used by computer hobbyists to
>    control their home computers; these people don't need mail systems,
>    network    routers, network filesystems, office automation, project
>    development environments.

This is true, too. RISC OS can live in a lower-end environment than
UNIX. Does this mean it is worse? All the software you mention that
'these people don't need' is available for RISC OS, too.

>    To summarise:
>
>        o The two operating systems are different.

Too true.

>        o They are designed to perform different tasks.

Half true. (They are designed for the same task in different environments.)

>        o They are not comparable.

And completely false. Of course they are comparable!

Anyway, enough about UNIX. You know that I find UNIX full of holes, and
I know that you consider it perfection itself. Unless you have some
enlightening examples of why UNIX is so vastly superior, or I have some
(more ;->) examples of why RISC OS is superior, let's agree to differ.

BTW, if you took RISC OS away from me, I'd want to use UNIX (except for
graphical/DTP stuff, then I'd want to use the Mac). In other words,
UNIX comes second after RISC OS. Happy that I'm less biased now?

-Malcolm.  [e-mail]  These are merely my opinions.