🚀 go-pugleaf

In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes:
<*sigh*  Here I go again.

Yup, there you went again. With all the accuracy of the person usually
associated with that statement. If I had more sense, I'd ignore it,
but you've hogwashed out my horsesense.

<First, I think AmigaDOS's UI sucks.  But that depends to a degree on
<what you're used to.  I'm used to Unix, and I find AmigaDOS annoying
<and clumsy, and often frustratingly limiting.

This, of course, is a matter of taste. Graphical interfaces pretty much
all suck. On the other hand, if I could find a command line interface
for Unix as nice as the one I've got on my Amiga, I'd be using it in
an instant.

<Then there's the stupid 20 CLI limit...

Right. However, that can be fixed without having PD software running
on your machine. You only have to run it once...

<Ah, but the PD software is virtually _necessary_ to maintain a
<reasonable environment.  (the stock configuration is virtually
<unusable, in my opinion.)  [particularly the CLI]

That's odd - I run PD software to make the grahical interface more
useable. I use commercial software to make the CLI useable. Of course,
if you want a CLI that looks like Unix, you have to use PD software.
On the other hand, if you want a system that looks like Unix, you
should have bought one that ran Unix, not an OS that's superior to
Unix (see below).

<I don't see that Minix/Unix on an Amiga need be any more of a headache
<for system maintenance and administration than AmigaDOS itself is.

You obviously haven't tried adminstering a Unix machine. The entire
system is much more fragile than AmigaDOS. That getting a usable
system on a single floppy (or even two) is nearly impossible doesn't
help much.

Minix may be a vast improvement on Unix (i.e. - almost tolerable),
though. I haven't tried to run such a system.

<Bernie> There are also other disadvantages to Unix-like systems.  I've
<Bernie> not seen one yet that had decent real-time response.
<
<And how often do you run across Unix systems without MMUs?  Virtual
<memory can slow a system way down.

Key word: "can". It doesn't have to. Last time I looked, the hardware
people were still debating whether you could build a faster system
without virtual memory than with.

BTW, the big conventional boys (Cray, CDC) all have virtual memory (in
the sense of address mapped, not in the sense of demand paged).

Question: can anyone demonstrate that AmigaDOS is really a real-time
system? If so, what's the lower limit on response time to external
events (remember: that response has to hold no matter _what_ else is
running) if I set up a task for real-time work.

<(So much easier on the Amiga, it just crashes.)

You want a Unix box, you should buy a Unix box. Remember, the Amiga
doesn't compete (in price, anyway) with Unix, It competes with things
like the 8086 based IBMs and the Mac I. That it gets compared to Unix
boxes (even unfavorably) is a major complement all by itself.

<Real-time Unix systems DO exist.  Most are not.

Quite correct. This is because designing a real-time system is not
easy, and has only a small market. Most people just don't need the
ability to responed to external events in a fixed amount of time.

<The Amiga Exec OS achieves excellent response by not supporting VM,
<message-passing by reference, strict task prioritizing and other such
<little tricks.

This is bullshit. Those are things the AmigaOS _does_. There are other
OSs that are fast that don't do those things (v6 Unix comes to mind).
There are OS's that do any of those things that are slow.

The Amiga OS is fast because some sharp people worked hard to make it
fast. That's about the only way an OS gets to be fast. And that may
not be enough.

<Bernie> There is also a more elegance of design to the AmigaDos
<Bernie> system.
<
<AmigaDOS?  More elegant than Unix?  Don't make me laugh.

Why should you laugh? Are you really that unschooled in OS design?

Unix follows the monolithic monitor model for OS design. The only good
reason for that is that it was written 20 years ago, when nobody knew
any better.

Unix also chose the wrong basic object for IO operations, the file.
AmigaDOS (among other OSs) got it right, and chose tasks for basic IO
objects. If you don't think this is right, I'll write a task that uses
a disk and acts like a file. You write a file that acts like a task
(using whatever hardware you need).

BTW, the same logic applies: when Unix was written, nobody knew which
was right.

Most Unices still don't have a mechanism to allow seperate control
threads to share an address space. As a result, things that need such
a facility either have to share data (making them bigger & slower), or
to implement the control sharing themselves (ditto). AmigaDOS doesn't
have a way to force processes into seperate address spaces, but that's
not something you have to code around.

Unix _was_ very simple and elegant when it was first introduced,
having a very large number of good ideas in it. However, that was 20
years ago, and now everybody and their brother has those things. Plus
being able to profit from the last 20 years of OS theory.

Of course, one thing all those people haven't picked up is how this
translates into commands the user types. Most software that was
written by people who don't understand this doesn't produce output
that could usefully be fed back to itself. Most commercial AmigaDOS
software (but not all of it) suffers from this, and takes some
processing before it can be fed to the next command down the line.

However, that's not a flaw in the OS or the Exec; that's a flaw in the
commands. That can be fixed by replacing the commands.

<Logical volumes are among the few _good_ things about AmigaDOS.  Take
<a gander at dos.library sometime, however.  Elegant?  Ha.

Comapred to what Unix does to do DOS calls? Yes, it is. Compared to
the rest of AmigaDOS? No, it isn't.

<Oh?  So you're saying the brilliant PIPE: AmigaDOS device is better
<(and more elegant!) than Unix's pipe() system call? 

You haven't looked inside of a modern pipe() system call, have you?
Elegant is hardly the word. Of course, if you just want a "here's a
pair of fd's" type interface, that's not hard to build on top of
PIPE:. You wanna try and do the opposite? I'd like to know how you're
going to escape pipe()'s need for communicating processes to have a
cooperating common ancester.

<How about fork() and exec()?

What about them? The versions in my Amiga library are slightly
different than the ones on Unix, but not enough to cause any problems.

<Or are you thinking of Exec's message-passing? It has advantages and
<disadvantages, but is decent overall, and none to AmigaDOS's credit.

Sorry, but that's not quite true. That AmigaDOS could be quickly
integrated into the Exec message-passing is to it's credit. You just
flat couldn't do that with Unix.

<Bernie> (don't like CLI... only dirty three letter word I know),

What about IBM? DEC? Sun? (aka the greater devil and the two lesser
devils). I think those are all dirty words. On the other hand, I also
support or used to support software from them.

<Many excellent utilities ARE part of Unix.  (generally speaking.)

No, many excellent utilities are generally shipped with Unix. They
aren't part of Unix. Those vendors that tried to unbundle the
utilities got pretty quickly trashed by their customers. That's about
the only reason the utililities generally are bundled in with the OS.

Note that the Amiga doesn't come with a C compiler, or very many other
real applications. Like most OS's meant to be used by people (as
opposed to programmers), it's a platform to put applications on, not a
platform for an application. Unix is generally viewed as a platform
for programming on. If you want to program on an Amiga, you need to
get the tools to do that, just like anything else. If you want to do
things other than program on Unix, you have to get the tools to do it.
Of course, that Unix is a programing platform means there are lots of
tools for doing things other than programming, built as programmers
needed to do them. These tools are invariably inadequate.

<For standard System V Unix, the system requirements are a bit much.
<Same for BSD.  Not so for Unix Version 7.  It's small and elegant.

So, where do you buy a v7 system? Oh, BTW, did you know that the v7
kernel is much larger & slower than v6, and only added one new kernel
facility?

<All current versions of Unix are derived from it.

Not so. System V is derived from PWB 1.0 (-> PWB 2.0 -> Unix 3 (aka
System III) -> Unix 4 -> System V). PWB 1.0 is dervied from a pre-v7
Unix that was never released outside of AT&T.

<It has most of the major concepts that make Unix so successful.

Actaully, the only thing that's missing is networking. Unlike
AmigaDOS, which was designed from the start with networking in mind
(see "TRIPOS--A portable Operating System for Mini-computers", 
in Software P&E vol 9, pgs 513-526).

<Minix is a complete reimplementation (a much cleaner one) of Unix V7,
<distributed with source code. 

It's not complete (even I know that much). It's missing mpx files and
ptrace. The former was mostly useful for crashing systems. The latter
was a bad idea poorly implemented, and nobody will miss it.

	<mike
--
Tell me how d'you get to be				Mike Meyer
As beautiful as that?					mwm@berkeley.edu
How did you get your mind				ucbvax!mwm
To tilt like your hat?					mwm@ucbjade.BITNET