RISC OS vs the rest - project leader speaks!
RWi...@acorn.co.uk
conclusion that he comes to about it (and happy about Jon Harley's
conclusions!). Here are some observations that he might like to consider.
(1) When we designed RISC OS, the all-powerful, overruling principle of the
design process was that THE USER COMES FIRST. We were not aiming to sell to
the designers of operating systems, and we realised that the internal structure
was unconventional (nay, weird) in some ways. This is not at all important,
compared to what the user sees at the end of the day.
(2) As well as the OS designer, the programmer too is ultimately subortinate
to the user. A system that allows the construction of wonderful and elegant
Unix-like toolkits is not at all important, compared to the support for
window'd programs that are easy to use. It is true that the application
virtual machine and process model is strange in places, but this really does
not matter to anyone except the implementors of language libraries. Come
to think of it, I haven't noticed the implementation of language libraries
for Unix being all that easy...
(3) The default target system for RISC OS is a 1MB machine with a floppy
disc, and with a standard colour monitor. This is what most of our users
have, a profile which is likely to remain the case for many years. Thus, the
opposition is XTs, ATs, Macs and Amigas rather than SparcStations. It was a
subject of much debate within Acorn that the developers had 4MB machines
with Winnies to work on, and that having such large machines might put us
out of touch with normal users.
(4) I have a RISC OS machine on my desk rather than a SparcStation, and I
like it that way. The reason for this is that RISC OS's desktop environment
is far better tuned to the needs of typical/casual users than anything I
have yet seen on Unix. I also find I get better window system performance
from a 4MB ARM3 machine than any Unix machine I have seen.
(5) For those who like novelty, I would suggest that the user model of the
desktop world in RISC OS is the most innovative one in the market in the
following major areas:
the direct manipulation model of data loading/saving/transfer by
icon dragging between tasks.
the Task display, in providing an easy-to-understand, direct manipulation
model of where your memory is being used.
the Font Manager, in using hinting and anti-aliasing to provide fonts
from a unified source for both screen and printer use (subject of a
recent paper at the USENIX graphics workshop in Monterey last November).
the Draw module, providing bezier filling graphics primitives as standard
in this price bracket for screen and printer use (the NeXT machine does
it - anything cheaper?)
the SprExtend module, providing bitmap-plotting with arbitrary scaling
and translation facilities, for use on both screen and printer.
the window system, in numerous minor innovations (e.g. instantly draggable
windows, menu/dbox structure, message system.
the printer driver system, in its unified approach to the user interface
for loadable graphics printer drivers.
None of these is novelty for its own sake - our aim was, and still is, to
help nonskilled users of personal computers find it easier than ever before.
--William Stoye
Richard Thombs
I have had a 1 megabyte A310 with a 20Mb hard disc from very early on. A friend
has an Amiga 1000 with 1 megabyte of RAM and two floppy drives. We are both
professional programmers. I want his machine, he wants mine...I'd gladly swap
if I could have a hard disc too. Anyway, here are a few observations:-
***
Before I start, does anybody (Acorn?) know of a BCPL compiler for the Arc?
***
1. Hardware wise, the Archimedes is extremely good. However, a basic
configuration as mentioned by William of a 1 megabyte machine and a single
floppy disc makes for painful operation with continual swapping of discs.
From a PROGRAMMER's point of view, this is next to hopeless because C takes
up most of one disc. If you hack it and make it a resident module you loose
too much memory. The Amiga suffers in much the same way, a basic setup of
a 1 megabyte machine and an 800k floppy can cause just as much grief.
2. Don't forget that an Archimedes with RISC OS is NOT a multitasking machine,
not like an Amiga. When some process decides to hog the machine it can do. As
soon as the program flow takes it into an OS routine the machine becomes single
tasking until the window manager is again called. This is fine for fast OS
routines, but for most disc I/O forget it - everything stops. The Amiga has its
own disc problems, on an Amiga 1000, I've heard two processes fighting over the
disc controller, stepping the disc 10 tracks out then 10 back again as they
each tried to get at seperate tracks on the disc.
3. Comparing the windowing systems of RISC OS and AmigaDOS is easy - RISC OS
wins. It is after all a state of the art system whereas the Amiga has been
around for years. RISC OS is fast and responsive (if nothing else is doing I/O!)
whereas the Amiga tends so be sluggish, but then it is running on slower
hardware.
4. To several points, Pete has said 'Buy an R140!' - you must be joking. An R140
is a bargain at 2999+VAT for the machine+monitor(+ethernet?), but with a disc
105% full its unusable as a standalone machine until you get a SCSI board and
another drive of a realistic size.
5. I don't like the paltry 10 character filenames on RISC OS. Nor do I like
the use of '.' as a directory seperator. From an upwardly compatible point of
view it makes perfect sence, but you try telling that to a DOS/AmigaDOS/UNIX
user.
To sum up, Acorn have produced an excellete OS for the USER. As a programmer
and hacker I hate it. The 1Mb floppy based system they see themselves aiming
at is unrealistic. At most a dual floppy or 4Mb system is needed. People with
small memory should be able to use a hard disc as virtual memory. The filing
system restrictions are too narrow minded. If I had the choice now, I'd buy
a large Amiga with lost of memory and a good sized harddisc. Or I'd wait, cos
there's always a better machine around the corner...
Richard Thombs.
--
Post: System Software Factors, Chiltern Chambers, Caversham, Reading, England.
Mail: {ric...@ssf.uucp,ssf!richard}
Phone: +44 734 476644
Ulf Dahlen
William Stoye states are the really good things about RISC OS, if find
myself thinking "this is really bad". So, I guess I just have to buy
an Archimedes and rewrite the whole thing.... :-)
I also realize that Acorn is aiming the Arcimedes to a market that
don't care about the things I care about. In schools (below the
University level) people don't care if multi-tasking is done by the
window manager with the (horrible) co-operation approach, or by the
nucleus with pre-emption. However, I'm absolutely convinced that RISC
OS would perform much better, even for a novice to notice, if it had
true multi-tasking.
(Actually, the Xerox Lisp machine has co-operative multi-tasking, but
there is a little program that adds preemption. This works fine *most*
of the time. So, I guess I could write a little preemption patch as a
module and be happy - for a while. The program simply blocks the
current process at regular intervals, trying to check that the process
isn't doing something that preemption would disturb.)
__________
Ulf Dahlen, u...@ida.liu.se, u...@liuida.UUCP
Dept of Computer & Info Science, University of Linkoping, Sweden
1981: The BBC Micro by Acorn: Standard hardware with excellent software.
1987: The Archimedes by Acorn: Excellent hardware with yesterday's software.
Sad, isn't it?
Gavin Wraith
I would like to put my oar in on behalf of RISCOS. It seems to me
that much of the detractors' arguments are at the wrong target, and
do not take into account the job it was designed to do. Of course,
they are entitled to quarrel with Acorn's design plan, but that is a
different matter.
It seems to me that very little thought has been given, until now,
to what an OS for a personal single user machine ought to be. There
are plenty of books and articles on the principles of OS design for
multi-user systems, perhaps because until now these were the only
systems which permitted serious software development. For micros the
only OS around were either cut down versions of things intended for
multi-user setups, or appalling quick-and-dirty affairs. Mr Dahlen's
assumption that task-scheduling ought to be along Unix lines should
be challenged. For a multiuser system I agree. For a single user
system, that might be used for real-time data capture tasks, it is
a different matter. Before we argue how good a piece of software is
we ought to be clear about what it is for and what criteria we are
using.
I agree that the discrepancies between unix and adfs filenaming
conventions are a nuisance, that make transferral of software that
much more difficult. I use unix and sunwindows on a Sun, gem on an
Atari, and RiscOS, and RiscOS to my mind is by far the more pleasant
to use: it is more consistent, better documented and more flexible.
What I find most attractive about Acorn's products is their openness
about what the software in their machines do, and the level of
abstraction in the design of it. The weak points are those that
always accompany idiosyncracy, and a tendency not to think big
enough (at least from the limited point of view of my armchair).
Computers arouse passionate partisan feelings, because we are always
dreaming how WE would like to arrange things in an ideal
micro-world, and because we are jealous of the intellectual
investment we have had to make ourselves. No doubt it all looks very
different if you are making and selling the things.
Gavin Wraith
Hugo Bignose Tyson
discs to your R140 - the ST412 controller and driver will handle
another quite happily, and Oak (ask Acorn Customer Services/read Acorn
User for address etc.) sell such a thing at about 1000 quid for 64
Megabytes. Of course, any ST412 drive will do, it just needs power
and cables, which any fool can make very easily with one trip to
Tandy's or equivalent/one letter to Maplin/RS.
Also, the disc arrives very full to save you having to load a pile of
floppies to get the networking, games, etc. etc. that most people
want; the choice of what goes on the disc and what is on floppies was
made to try to get a best-fit with most people's needs; we don't
expect anyone to want to load the whole lot ever....
- Huge
Peter Ruczynski
>Before I start, does anybody (Acorn?) know of a BCPL compiler for the Arc?
Sorry haven't heard of one.
>3. Comparing the windowing systems of RISC OS and AmigaDOS is easy - RISC OS
>wins. It is after all a state of the art system whereas the Amiga has been
>whereas the Amiga tends so be sluggish, but then it is running on slower
>hardware.
I wouldn't go quite so far as saying it's state of the art! But certainly one
hell of a lot better than the amiga.
>4.To several points, Pete has said 'Buy an R140!' - you must be joking. An R140
>is a bargain at 2999+VAT for the machine+monitor(+ethernet?), but with a disc
>105% full its unusable as a standalone machine until you get a SCSI board and
>another drive of a realistic size.
Yes the price does include an ethernet card, so with NFS you don't really need
a bigger drive unless you don't have access to a server, However,
I thought the argument was over the O/S, there's no pleasing some people!
>To sum up, Acorn have produced an excellent OS for the USER. As a programmer
>and hacker I hate it. The 1Mb floppy based system they see themselves aiming
>at is unrealistic. At most a dual floppy or 4Mb system is needed. People with
>small memory should be able to use a hard disc as virtual memory. The filing
>system restrictions are too narrow minded.
Here, here (as far as RISCOS is concerned)
>... Or I'd wait, cos
>there's always a better machine around the corner...
I've been waiting for years :-( !!
> Richard Thombs.
Pete.
--
-w--------- Pyramid Technology U.K. Peter Ruczynski
---www------- Pyramid House #include <std/disclaimer.h>
-----wwwww----- Farnborough p...@pyrltd.UUCP
-------wwwwwww--- Hants GU14 7PL England. Wot no funny comment :-)
Ulf Dahlen
genuinely interested in understanding the reasons for the design
desitions made when developing RISC OS. I realize that the people at
Acorn wasn't born yesterday, so I'm sure it's possible to motivate the
principles and the implementation of RISC OS.
In article <13...@acorn.co.uk> William Stoye writes:
>(1) When we designed RISC OS, the all-powerful, overruling principle of the
>design process was that THE USER COMES FIRST. We were not aiming to sell to
>the designers of operating systems, and we realised that the internal structure
>was unconventional (nay, weird) in some ways. This is not at all important,
>compared to what the user sees at the end of the day.
>
>(2) As well as the OS designer, the programmer too is ultimately subortinate
>to the user. A system that allows the construction of wonderful and elegant
>Unix-like toolkits is not at all important, compared to the support for
>window'd programs that are easy to use.
I'm not sure I understand what William Stoye is trying to say here. It
seems like he's implying that good OS design should somehow be
incompatible with user friendliness. Or maybe that the good intention
of always putting the user first would seriously limit the design
options.
In my view there is *no* conflict between e.g. pre-emtive scheduling
and user friendly-ness. I would in fact say that having disc I/O
(formating a disc or something) stopping everything else is an example
of user hostile behaviour!
The BBC Micro OS was incredibly sofisticated for it's time. Maybe
that's why I expected the same of the new generation of Acorn
computers. I was very disappointed when I read through the RISC OS
Programmer's Reference Manual (PRM). The first two volumes made me
quite happy. I was impressed with the documentation and all the
possibilies of intercepting system calls as a method of customization
and altering/extending the kernel.
Then I read volume III of the PRM. It's about the Filing System and
the Window Manager. Let's simply skip the Filing System for now; I
hate it and the way it's implemented, but I could live with it. What
about the Window Manager then? Well, first something about windows and
desktops.
The Archimedes Desktop, the Amiga Workbench and the Macintosh Finder
are all examples of wrong thinking. They all make a directory browser
the basis for a window environment. Why? Why? Shame on you Apple! You
stole the window notion from Xerox but introduced the icons-are-files
stupidity.
Introduction to window based user interfaces:
A window environment should form the foundation for tools for the user
to structure his/her computer work in a way that suits him/her. A
directory browser should be a separate program that the user invokes
when he/she wants to load or in any other way manipulate files. Icons
are small windows representing a program or any other entity in the
system. Menus provide the user with shortcuts to frequently used
commands and functions.
It's not user friendly to force the user to obey some rules of window
layout, window appearence, menu appearance, icon placement etc, that
some designer thought would be nice. Of course, a sensible default
behaviour should be well thought out and be useful for the casual
user.
An icon-bar was maybe a good idea for the Xerox Dorado in the late
70's but that doesn't make it the best solution now (or then for that
matter).
RISC OS has multi-tasking as a part of the window manager. I simply
don't understand why. Even if you insisted on a co-operative scheme,
it shouldn't reside in the Wimp module.
>(5) For those who like novelty, I would suggest that the user model of the
>desktop world in RISC OS is the most innovative one in the market in the
>following major areas:
> the direct manipulation model of data loading/saving/transfer by
> icon dragging between tasks.
This is good! I like it!
> the Task display, in providing an easy-to-understand, direct manipulation
> model of where your memory is being used.
This is horrible! I hate it! Yes, it would be nice to have the
possibility to adjust fuel flow, compression level and break fluid
pressure while driving my Ferrari, but it shouldn't be a necessity!
(Yes, I know it's not exactly like that in RISC OS, but many programs
require user interaction to tell it to run nicely.)
> the Font Manager, in using hinting and anti-aliasing to provide fonts
> from a unified source for both screen and printer use (subject of a
> recent paper at the USENIX graphics workshop in Monterey last November).
Also very nice, but not something revolutionary.
> the Draw module, providing bezier filling graphics primitives as standard
> in this price bracket for screen and printer use (the NeXT machine does
> it - anything cheaper?)
A good feature. No problem writing one yourself of course, but it's a plus
that it's included as standard.
> the SprExtend module, providing bitmap-plotting with arbitrary scaling
> and translation facilities, for use on both screen and printer.
Sounds fine to me.
> the window system, in numerous minor innovations (e.g. instantly draggable
> windows, menu/dbox structure, message system.
This is not very well designed, though I'm sure many users upgrading
from a PC are impressed. It's maybe even good money for Acorn, but so
are many PCs for other companies.
> the printer driver system, in its unified approach to the user interface
> for loadable graphics printer drivers.
Good, but nothing unique.
>None of these is novelty for its own sake - our aim was, and still is, to
>help nonskilled users of personal computers find it easier than ever before.
I can't see how these so called novelties would explain the
strange implementation of the things I've questioned about RISC OS.
__________
Ulf Dahlen
Work: Dept of Computer & Info Science, University of Linkoping, Sweden
Email: u...@ida.liu.se, u...@liuida.UUCP
Home: Troskaregatan 51:23, S-583 30 Linkoping, Sweden
"The beginning is a very delicate time."
H.A.Shaw
as I saw a flame-wars saga starting, but now with interest again. I would also
be interested in finding out about the design decisions taken by ACORN when
designing RISC OS. The multi-tasking especially. I see no particular problem
with writing a preemptive multi-tasking system. I have used an interrupt
routine called at regular intervals as the basis of a simple multitasking OS on
some 6809 single board computers (remember the ACORN System cards? of the
early 1980s) and I wouldn't consider myself an advanced programmer. I even
wrote some code for a BBC that trapped the screen refresh interrupt and swapped
up to four pure machine code routines in and out of disc (OK so I wasn't in a
hurry!!) just to see if it could be done.
So ACORN, suprise us all. What *WAS* the reason for multitasking in the WIMP
in the way RISC OS does it?
Email: h...@ukc.ac.uk | Howard Allan Shaw.
Phone: +44 227 764000 Extn: 3834 | Room 111A, Physics Laboratory,
| The University,
| Canterbury, England. CT2 7NZ
Brian J Syme IE88
I'm posting this on behalf of a friend that doesn't have net access (yet)...
--
I've been watching the Archimedes Flame-wars continuing for a few days and I'm
a little disappointed in the comments of Ulf Dahlen, he keeps saying nasty
things about the cooperative multitasking of RISC OS seemingly without much
in the way of logic to back them up. Mind you he's not the only offender in
this sense, here's my view on some of these issues.
The Archimedes is not a Sun SPARCStation(or a DEC Micro VAX, or an Apollo),
a simple statement but true, this is simple fact that seems to have slipped by
Ulf and some others. You cannot compare the Archimedes with this sort of
machine, even with the ARM3 upgrade. The Arc is not a workstation it is a
general purpose high performance single user desktop computer(some may say
that's a pretty good description of a workstation, but how many people run
interdictor-like flight sims and then C compilers in a single work session on
a workstation).
RISC OS uses 'cooperative multitasking' because it is well suited to the job,
it is a user oriented system, it is not aimed at programmers exclusively
unlike workstations with UNIX and its variants. Using a RISC OS machine
as a programmers workstation is not too hard at all, the only real restriction
is that it is more difficult to have several editting sessions open at once
and then to start a compilation - try this using the !EDIT task windows and
see what happens. Is this really a problem for most programmers, it would be
nice to be able to edit and compile simultaneously, but it's not impossible to
work this way. OK so we have to use a command line interface, that's not so
bad is it, I can remember the days when even UNIX had one of those. By the
way, the situation I've mentioned above doesn't work too well on a DEC VAX-
Station 2000 either, several text editting sessions and a compilation at once
tend to have a go at halting the system(under UNIX and X windows of course,
apparently VMS is a different story).
By using this system desktop tasks can be made to integrate more smoothly with
other desktop tasks, and if the programmer has done his job correctly all
tasks on the desktop will cooperate well and the user is happy. If an
application is written which has performace problems in the desktop then it
is simple to allow it to run in isolation as a true application outside the
desktop which suspends the desktop while it is running. This will keep the
performance of the application up as well as allowing user to use the machine
as if the desktop were still active(ie the desktop restores itself after the
application has finished running). Again the user is happy, the programmer has
done his job well and the system is happy.
>So, the "Multi-tasking" is absolutely NOT a cosmetic issue, but a real
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>design flaw.
I agree it's not a cosmetic issue it's a design decision based on the
targeted market for the machine, if you want a Arc with preemption go buy a
R140 if you want an Arc don't gripe about the lack of preemtion it's NOT a
problem. If you have to make comparisons with SPARC Stations(or other less
exotic machines) then do so fairly and if you like the Suns so much go buy one,
they're more expensive and less flexible, and they are not designed for the
casual user.
Why does the machine freeze when disc access takes place, this is a good
question, it doesn't need to, the filing system could have been written to
allow the desktop to continue while disc access takes place(particularly when
floppy drive access takes place). The other point to make here is directed at
Acorn why not build the Arc with an independent video system, having the
screen black out during disc access is most annoying, a separate video
system(possibly an ARM+VIDC combo with a tube-like interface to the Arc) would
help the problems with bus band width in higher screen modes.
The use of this in conjunction with the ARM3 would create one hell of a
machine.
Richard Thombs talks about the 10 character filenames being "paltry", I
couldn't agree more, why not longer file names, ADFS backward compatability is
not an answer, longer filenames could easily be accomodated.
Comments have been made regarding the PRM well here are a few more;
a) I find it ludicrous that there is no contents in the
index booklet, this would make life easier.
b) Who's idea was the page numbering scheme, why not use a system
of volume number followed by page in the volume, again this
would make life easier.
c) How about a more comprehensive index please.
d) Does anyone out there have any info on using the SWIs to claim
software vectors, the PRM appears only to consider the use of this
from assembly language, I use C and can't find any way of doing
this.
If Acorn do change the way the index is organised how about a reprint of the
index book free to owners of the PRM on return of the old index booklet.
Colm Buckley wants a MEMC which can handle 16MB, I agree but has he forgotten
that the present version of MEMC supports a master-slave configuration with
another MEMC providing another 4MB.
A new VIDC with 24 bit graphics yes, but how about this linked to an ARM as
a separate video subsystem with its' own video RAM, the software is easily done
using the software vectors in RISC OS, only things which write directly to the
screen would require re-writes(ie games).
Wouldn't it be nice also to have a FPU socket on the motherboard in any future
systems.
One last thing, a number of people are claiming that RISC OS is an upgrade of
the BBC micros OS, well sort of, it maintains compatability os some of the
system calls in name aand approximate funtion, this is for compatability of
BASIC programs. This is perhaps 5 % of RISC OS the rest is all new well
designed code.
I'm not actually on the news network as yet(our software seems to be non-existant) however any reply via the general eunet news system should get to me in the
end, any personal replies to the address below.
Gordon Turner If you can't do it in FORTRAN do
Dept. of Comp. Sci. it in assembler, if you can't do
Paisley College it inb assembler it isn't worth
Scotland doing! - annon.
Ulf Dahlen
But...
In article <15...@acorn.co.uk> Roger Wilson writes about how and why
RISC OS came to be the way it is. His article answered a lot of my
questions, and I'm quite satisfied. He said that the original OS (ARX)
turned out not to be workable on a A310 and that they had to abandon
it. Instead Acorn started the Arthur OS project, a BBC OS look-a-like.
According to Wilson, it was really meant to be a single-user/process
OS. The window and font stuff was added at a late stage to "[make it]
more interesting".
Since Arthur was BBC OS in new (and better) clothes, it wasn't made to
be a multi-tasking OS. However, a machine like the Archimedes deserved
multi-tasking and so a kind of co-operative process switching scheme
was added on top of it all. (That's what I call a "patch".)
All this means that RISC OS is *not* a good (multi-tasking) OS from a
computer scientist's view. I'm not saying that a PC is better, or that
the novice user can't use the machine; I'm simply stating the obvious
fact: the Archimedes could do a lot better with a better OS. But, as a
commercial company, Acorn has to worry about sales and such things.
Maybe it was a good decision not to start from scratch with a "real"
OS. Acorn made the existing one work.
Now to something completely different...
In article <16...@baird.cs.strath.ac.uk> Gordon Turner writes:
>I've been watching the Archimedes Flame-wars continuing for a few days and I'm
>a little disappointed in the comments of Ulf Dahlen, he keeps saying nasty
>things about the cooperative multitasking of RISC OS seemingly without much
>in the way of logic to back them up. Mind you he's not the only offender in
>this sense, here's my view on some of these issues.
Well, the "logic" behind my comments are computer science courses like
"Concurrent Programming", "Operating Systems Theory", "Object-Oriented
Programming", "Compiler Construction", "Logic Programming",
"Programming Theory", "Distributed Systems", "Computer Networks" and
"Advanced Computer Architecture" and books like "Principles of
Concurrent Programming" by M. Ben-Ari, "Fundamentals of Operating
Systems" by A.M. Lister and R.D. Eager, "Computer Architecture and
Parallel Processing" by Kai Hwang and Faye A. Briggs, "Computer
Networks" by A.S. Tanenbaum, "Distributed Systems - Concepts and
Design" by George F. Coulouris and Jean Dollimore and many others...
Of course, I'm not an expert on these questions (I didn't achieve the
highest grade on all these courses), but if co-operative scheduling
put on top of an operating system in the second release is regarded as
excellent OS design in Scotland, I would be *very* surprised.
My guess is that what Gordon Turner is trying to say is that I have
aimed my criticism at issues not so very important for a home or
school computer. Of course, I don't agree with this view either!
>The Archimedes is not a Sun SPARCStation(or a DEC Micro VAX, or an Apollo),
>a simple statement but true, this is simple fact that seems to have slipped by
>Ulf and some others. You cannot compare the Archimedes with this sort of
>machine, even with the ARM3 upgrade. The Arc is not a workstation it is a
>general purpose high performance single user desktop computer(some may say
>that's a pretty good description of a workstation, but how many people run
>interdictor-like flight sims and then C compilers in a single work session on
>a workstation).
I run games, compilers, text-editors - you name it - on workstations
in the same work session all the time.
>RISC OS uses 'cooperative multitasking' because it is well suited to the job,
>it is a user oriented system, it is not aimed at programmers exclusively
>unlike workstations with UNIX and its variants. Using a RISC OS machine
>as a programmers workstation is not too hard at all, the only real restriction
>is that it is more difficult to have several editting sessions open at once
>and then to start a compilation - try this using the !EDIT task windows and
>see what happens. Is this really a problem for most programmers, it would be
>nice to be able to edit and compile simultaneously, but it's not impossible to
>work this way. OK so we have to use a command line interface, that's not so
>bad is it, I can remember the days when even UNIX had one of those.
This line of argument is completely incomprehensible! Co-operative
multi-tasking is *not* needed to make a user oriented system. It has
in fact nothing what so ever to do with the user interface. Just
accept the fact (read Roger Wilsons article): co-operative
multi-tasking in RISC OS is not there for a purpose, it's there
because it was too hard to rewrite Arthur from scratch.
All programs and programmers and users benefit from having
multi-tasking just "happen". It should be transparent for the user.
>By using this system desktop tasks can be made to integrate more smoothly with
>other desktop tasks, and if the programmer has done his job correctly all
>tasks on the desktop will cooperate well and the user is happy.
This is the BIG drawback of co-operative multi-tasking! I simply do
not understand how people can come up with this as an argument FOR
co-operative multi-tasking. With pre-emptive multi-tasking (and a
genuine multi-process OS) this happens automatically!
>Why does the machine freeze when disc access takes place, this is a good
>question, it doesn't need to, the filing system could have been written to
>allow the desktop to continue while disc access takes place(particularly when
>floppy drive access takes place).
Again: if RISC OS had been made a multi-tasking OS from the start,
this would never have been a problem! The filing system could have
been written with a Donald Duck cartoon in mind; it wouldn't have
freezed because it would have been pre-emptied! :-)
To sum up:
The ARM related chip set is capable of forming the base for a much
more sofisticated OS than RISC OS. This doesn't mean that the
Archimedes isn't a machine worth buying; it simply means that the
machine is heavily under-utilized.
It is completely wrong to say that user-friendliness requires a
co-operative multi-tasking scheme. Also, this was in no way why Acorn
did what it did (again, according to Roger Wilson's article).
I'm satisfied with what Roger Wilson said. It explaines *why*. But of
course my criticism is still valid.
Kjetil Torgrim Homme
is able to edit a text and play a game at the same time! That is simply
not possible, and that is why multi-tasking is not called for in most
situations. A terminal wanting to share your resources is the only
reason I can see for a fully-fledged multi-tasking OS.
A few tasks should however be dealt with in the background, like
compiling, printer spooling etc. But it is not surmountable to make such
utilities to bee co-operative, or even driven on interrupts! Why can't
programmers put a time limit in their programs, even *I* could do that!
From my experience with workstations (Sun 3/50), the reason for a lot of
tasks being on screen at all times is the slow (compared to discs etc.)
transfer of data. So to avoid loading the program all over again, waiting
perhaps more than a minute if the server is busy, leave it alone in
memory. To a user, a switching system with a fast disc would be preferable.
On the subject of WIMPs, I don't think X-windows even can compare to
Desktop in terms of functionality or ease of use, and NEWS and Sunview
even less so. There is one thing I like - the ability to stretch windows
in all directions. I've yet to experience true interaction between tasks,
save for Emacs (have anyone ported this to the Archimedes?) and simple
text exporting.
But why shouldn't files be icons, Ulf Dahlen? I prefer dragging a file to
typing "cp /local/hacks/sun3/massacre .", and even more double-clicking
to run it!
We all seem to agree on that the ADFS is inflexible and generally a
nuisance. So why don't you make a new one before breakfast, Ulf Dahlen?
I'm sure a lot of people would be interested.
/////////////////////////////////////////////////////////////
// Kjetil T. Homme // "I keep reading between the lies" //
// Norway // Goodman Ace //
/////////////////////////////////////////////////////////////
Jon Hall
....
>
>A few tasks should however be dealt with in the background, like
>compiling, printer spooling etc. But it is not surmountable to make such
>utilities to bee co-operative, or even driven on interrupts! Why can't
>programmers put a time limit in their programs, even *I* could do that!
>
compiler check itself to see whether it has exceeded the time limit?
What does one do when it has exceeded this time limit. You say you could
program this - first write a compiler! (Or do you intend to write bolt
on code :-))
I think the point here is to have the OS control the switching of tasks
which otherwise have not been extensively modified to run in a
non-pre-emptive environment.
>From my experience with workstations (Sun 3/50), the reason for a lot of
>tasks being on screen at all times is the slow (compared to discs etc.)
>transfer of data. So to avoid loading the program all over again, waiting
>perhaps more than a minute if the server is busy, leave it alone in
>memory. To a user, a switching system with a fast disc would be preferable.
>
Or perhaps having the Workstation freeze when a 2 hour compilation is in
progress is *too* much?
--jon
ARPA : j.g....@newcastle.ac.uk JANET: j.g....@uk.ac.newcastle
UUCP : ...!ukc!newcastle.ac.uk!j.g.hall PHONE: +44 91 222 7957
SNAIL: Computing Laboratory, University of Newcastle upon Tyne, UK, NE1 7RU
Angus Duggan
>Now, what is Ulf Dahlen talking about? I'd like to see the person that
>is able to edit a text and play a game at the same time! That is simply
>not possible, and that is why multi-tasking is not called for in most
It simply is possible, even for some "real-time" games...I've read a book, had
a cup of tea, and played Elite simultaneously before now...
>situations. A terminal wanting to share your resources is the only
>reason I can see for a fully-fledged multi-tasking OS.
This is an over-simplification of the issue. Having to put explicit calls to
enable cooperative multi-tasking in *every* program which will operate in the
environment not only imposes an extra burden on the programmer, it is a recipe
for non-portability, and it also deprives the users of the chance of changing
their priorities. If I start a job which will take a long time, and I decide
to do something else, I just hit ^Z, type "bg", and carry on with what I want
to do. Co-routines and cooperative multi-tasking *are* useful in some
circumstances, especially for avoiding race conditions and for control
applications which must operate in real time.
>A few tasks should however be dealt with in the background, like
>compiling, printer spooling etc. But it is not surmountable to make such
>utilities to bee co-operative, or even driven on interrupts! Why can't
>programmers put a time limit in their programs, even *I* could do that!
Hmm, lets see... say I develop a program on a MIPS R2000 based system, I do
some performance measurement, and decide on a sensible (small) time-slice for
my program...I now port it to a Sun 3/50, which is heavily loaded, and it
starts thrashing...what's wrong? It is the Operating System's jobs to decide
what a sensible time slice for a program should be, based on the program's
priority, the current load on the machine, the phase of the moon, or anything
else which it needs to take into account. In RISCOS, the time slice is as long
as the program wants to take, with no other circumstances taken into account.
(Roger Wilson has stated the design goals for RISCOS already, this is not
meant to be a criticism *of RISCOS*; but I would prefer to have seen a
pre-emptive OS on the ARC. The MEMC limitations are the worst thing about the
R140; the small number of pages and the large page size do not make a very
nice VM system.)
>From my experience with workstations (Sun 3/50), the reason for a lot of
>tasks being on screen at all times is the slow (compared to discs etc.)
>transfer of data. So to avoid loading the program all over again, waiting
>perhaps more than a minute if the server is busy, leave it alone in
>memory. To a user, a switching system with a fast disc would be preferable.
Data transfer is not necessarily slow on workstations, you've probably got an
overloaded server. There is something else you have forgotten; the current
state of the program is preserved while it is in memory. Thus you do not have
to re-load files, templates, or modes, and find the place you were working on
again. Of course, a local disc is still preferable to a remote disc, but the
programs will still be used in a similar way with a local disc. If you have
virtual memory, then you don't have a restriction on the number or size of
programs which are loaded, and only the parts which are accessed frequently
will stay in the physical memory for a long time.
>On the subject of WIMPs, I don't think X-windows even can compare to
>Desktop in terms of functionality or ease of use, and NEWS and Sunview
>even less so.
This I must take issue with. X11 is NOT a window manager. The "ease of use"
you are talking about is a property of the window manager. There are
alternatives to the X11 distribution window managers which offer the things
which you probably are meaning when you talk about "ease of use" (files as
icons, dragging icons to move/copy files, double click to run programs).
NeWS has not been finished by Sun. The litewindows implementation which comes
with NeWS 1.0 and 1.1 is no more than a minimal set of capabilities to play
with. NeWS has the nicest, most customisable, easiest to program interface of
any window manager which I have seen. From the programmer's point of view,
NeWS is great. Unfortunately NeWS has never had a window manager/toolkit
worthy of it, and Sun does not seem to be putting much effort into NeWS
development.
You should also bear in mind that X11 and NeWS are Networked window systems;
it is possible (and easy) to run programs on remote machines which display
windows on your own machine. This has significantly affected their design.
(I won't try to defend SunView, any takers :-)
>... There is one thing I like - the ability to stretch windows
>in all directions. I've yet to experience true interaction between tasks,
>save for Emacs (have anyone ported this to the Archimedes?) and simple
>text exporting.
What load/mail/process/print queue monitors? I have these running most of the
time. What is "true" interaction between tasks? Do pipes count?
>But why shouldn't files be icons, Ulf Dahlen? I prefer dragging a file to
>typing "cp /local/hacks/sun3/massacre .", and even more double-clicking
>to run it!
See comment about X11 above. Have icons as files if you want, I prefer icons
to associate with processes or active objects.
> /////////////////////////////////////////////////////////////
> // Kjetil T. Homme // "I keep reading between the lies" //
> // Norway // Goodman Ace //
> /////////////////////////////////////////////////////////////
Angus.
==
Angus Duggan, Department of Computer Science, | #include <stddisclaimer.h>
University of Edinburgh, JCMB, | USENET: aj...@lfcs.ed.ac.uk
The King's Buildings, Mayfield Road, | JANET: aj...@uk.ac.ed.lfcs
Ulf Dahlen
since my arguments and explanations obviously haven't been accepted by
Mr Homme.
From mi...@slaka.sirius.se.
In article <25...@ifi.uio.no> Kjetil Torgrim Homme writes:
>Now, what is Ulf Dahlen talking about?
He's talking about the fundamentals of serious OS design.
>I'd like to see the person that is able to edit a text and
>play a game at the same time!
No problem. How about letting the chess game think while I edit a text?
>That is simply not possible, and that is why multi-tasking is not
>called for in most situations.
It is most certainly possible. There are other games than fast-paced
quick-reaction shoot'em up games.
>A terminal wanting to share your resources is the only reason I can
>see for a fully-fledged multi-tasking OS.
Isn't that what you've got already? Each window can be seen as a terminal
to the machine, sharing resources.
>A few tasks should however be dealt with in the background, like
>compiling, printer spooling etc.
And a clock and a disk formatter and a ray tracer and...
Why add a special background-mode when you can have it all for
free with true (pre-emptive) multitasking?
>But it is not surmountable to make such utilities to bee co-operative, or
>even driven on interrupts!
An interrupt-driven compiler? Gimme a break.
>Why can't programmers put a time limit in their programs, even *I*
>could do that!
A time limit for what? Max CPU time? You mean you want the task switch
to occur automatically after the specified time limit? Wonderful idea.
Automatic task switching. Hey, wait a minute. Doesn't this sound like
pre-emptive multi-tasking?
>From my experience with workstations (Sun 3/50), the reason for a lot of
>tasks being on screen at all times is the slow (compared to discs etc.)
>transfer of data. So to avoid loading the program all over again, waiting
>perhaps more than a minute if the server is busy, leave it alone in
>memory. To a user, a switching system with a fast disc would be preferable.
Have you any idea how much this says about your knowledge of OS design?
>On the subject of WIMPs, I don't think X-windows even can compare to
>Desktop in terms of functionality or ease of use, and NEWS and Sunview
>even less so.
I won't debate you there since it has nothing to do with the
multi-tasking. At least it shouldn't have.
>But why shouldn't files be icons, Ulf Dahlen? I prefer dragging a file to
>typing "cp /local/hacks/sun3/massacre .", and even more double-clicking
>to run it!
Ulf Dahlen was describing the original concept of icons as they were
researched and created by the computer scientists at Xerox Palo Alto
Research Center. (Name-dropper :-)
>We all seem to agree on that the ADFS is inflexible and generally a
>nuisance. So why don't you make a new one before breakfast, Ulf Dahlen?
>I'm sure a lot of people would be interested.
You say that you want print spoolers and compilers to run in the
background. Why don't you implement that before breakfast?
You complain about the performance of the Sun 3/50 and it's server.
Why don't you design and build new hardware and write new software
to solve that? Before breakfast.
You prefer dragging and double-clicking to typed commands. Why don't
you add a clickable and draggable unix to the before-breakfast list?
As you see, this kind of argument doesn't lead anywhere.
A final question:
What do you have against a "fully-fledged multitasking OS"?
Mikael Karlsson, Lovsattersvagen 10, S-585 98 LINKOPING, SWEDEN
mi...@slaka.UUCP, mi...@slaka.sirius.se
{mcvax,munnari,seismo}!sunic!liuida!slaka!micke
Steve Daffy Hunt
>A few tasks should however be dealt with in the background, like
>compiling, printer spooling etc.
Tell me who should decide which "few" tasks may run in the background?
What if I do a complex database query? Should I be forced to wait
just because it was not deemed to be one of these "few" tasks?
The only person who should be allowed to make this choice is the end
user. The best way for the user to be guaranteed the choice is to
have proper multitasking.
> But it is not surmountable to make such
>utilities to bee co-operative, or even driven on interrupts! Why can't
>programmers put a time limit in their programs, even *I* could do that!
And you could just use a Turing machine, but why put this extra
burden on the programmer? The idea of an operating system is to let
the programmer work inside a virtual machine that provides
abstractions of physical resources like CPU, disk and memory.
What sort of abstraction is "driven on interrupts". Have you ever
considered the merits of portable code?
>On the subject of WIMPs, I don't think X-windows even can compare to
>Desktop in terms of functionality or ease of use, and NEWS and Sunview
>even less so.
You are not comparing like with like. X and NeWS are not trying to do
the same job as Desktop. They are mechanisms which provide
abstractions of the screen and keyboard to facilitate writing portable
graphical programs. They intentionally do not provide a user
interface.
As such, provision of desktop facilities is not part of their
remit. Friendly desktop-like user interfaces can be provided by
programs running on top of X and NeWS (and indeed already are.)
> I've yet to experience true interaction between tasks,
>save for Emacs (have anyone ported this to the Archimedes?) and simple
>text exporting.
Yes, I have ported GNU Emacs to the Archimedes. I am using it to
compose this article. It runs under RISC-iX and took a few days to
port. You might find porting it to RISC OS a little harder --
something about running background processes :-) :-)
RISC OS has its good points, like being easy to use and blindingly
fast, but it has some obvious limitations.
--
Steve Hunt, UNIX Graphics, Acorn Computers Ltd.
(Above opinions are mine only.)