🚀 go-pugleaf

In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu
(Deven T. Corzine) writes:

Deven> *sigh*  Here I go again.

On 3 Aug 89 00:38:07 GMT,
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) said:

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

Accuracy?  I find no lack of accuracy.

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

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

Of course it's a matter of taste.  I acknowledged that, in case you
didn't notice.

Deven> Then there's the stupid 20 CLI limit...

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

That there is a workaround does not change the fact that it is a flaw
in the design.

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

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

I don't consider "you should've gotten a Unix box then" to be a valid
argument.  I want an Amiga, but with the major functionality of Unix.
They are NOT necessarily mutually exclusive.

[and I didn't even buy an Amiga; I'm poor these days.  When I can
afford it I will.  Until then, I can only use friends' Amigas.]

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

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

Strike one.  I have, and I am a capable sysadmin.  And I still don't
see that a small Unix system can't coexist with Exec and AmigaDOS.
[and getting a usable AmigaDOS system on a single floppy is no small
task, either.]  I'm not suggesting running SysV.  I propose a variant
of Unix V7, as Minix is.

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

Then don't attack it out of hand.  You appear to be biased against
Unix.  So be it.

Bernie> There are also other disadvantages to Unix-like systems.  I've
Bernie> not seen one yet that had decent real-time response.

Deven> And how often do you run across Unix systems without MMUs?
Deven> Virtual memory can slow a system way down.

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

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

Fine.  So I should have stipulated demand paged VM.  Address mapping
is easy to do in real time; it's just a lookup table in hardware.
It's paging that can kill system performance.

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

The Amiga is a fine machine.  And cheaper than an equivalent Unix box.
And more useful.  Actually, placing the Amiga in a class with PClones
and Macs sounds more like an insult to the Amiga to me.

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

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

Yes, but these are optimizations which ARE significant.  The whole
design of Exec is centered around efficiency and flexibility.
[excellent goals]

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

AmigaDOS's implementation is somewhat of a crippling effect.

Bernie> There is also a more elegance of design to the AmigaDos
Bernie> system.

Deven> AmigaDOS?  More elegant than Unix?  Don't make me laugh.

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

Hardly.

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

I understand the traditional internal structure of Unix, and I tell
you it's not as important.  AmigaDOS forces C programmers to deal with
(explicitly) BCPL conventions.  Unix does not force awareness of its
monolithic design.  And Minix is structured entirely different
internally, with user process devices, message passing, etc.  The
interface remains consistent and clean.  The same can not be said for
AmigaDOS.

Mike> Unix also chose the wrong basic object for IO operations, the
Mike> file.

           _             ^
You say tomato, I say tomato.

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

Unix /dev/* devices.  They are "special files" with associated code.
No specific task; they're part of that monolithic kernal.  (in the
traditional Unix implementation)  But they act with the same effect as
AmigaDOS's tasks.  Strike two.

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

Ah, it's the old "the poor idiots don't know what's good for them"
routine.

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

No, you just have to pray every program running is well-written, so it
doesn't bring down the entire system.

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

AmigaDOS ignores many of the good examples Unix sets forth.  Pipes are
a prime example.

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

That's because the design philosophy differs from that of Unix.  Under
Unix, in most circumstances, the preferred approach is to act on the
assumption that the output from your program will be the input to
another program.

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

The commands are an integral part of the environment, and help shape
and define that environment.

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

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

AmigaDOS ignores many design goals of Exec.  And what's wrong with the
way Unix handles FS syscalls?

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

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

PIPE: is a poor excuse for a generalized networking solution.  TCP/IP,
Unix-domain sockets and SysV named pipes all escape the need for a
common ancestor.  As for the internals of the pipe() call, it's
irrelevant.  The internals are INTERNAL, and can be left that way.
AmigaDOS prefers for force you to deal with it.

Deven> How about fork() and exec()?

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

Strike three.  "Slightly different?"  You can't get the same
functionality.  You can't open files for the child process, you can't
dup() a filehandle, you can't do any process environment setup after
forking but BEFORE execing.  About all you can do is spawn a new
process.  Far less flexible.

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

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

The reason AmigaDOS adapted easily to Amiga message-passing was that
TRIPOS was already based on message passing.  Couldn't do what with
Unix?  Message passing?  Try UDP.  Implement AmigaDOS?  Who would WANT
to?  [actually, you could emulate an Amiga in a single Unix process.]

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

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

Pay attention.  The "generally speaking" was because technically the
utilities are not integral to Unix itself, but they ARE integral to
the environment, and normally found together.

Mike> These tools are invariably inadequate.

Sounds like another biased opinion.

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

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

Oh, yes.  The pipes.  Oh, no.  Pipes aren't an important part of Unix.
Wake up.

Deven> All current versions of Unix are derived from it.

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

I don't know about internal to AT&T, but System V was derived from
System III which was derived from Unix V7.  [as far as releases go.]
On the other side, it went V7 -> V32 [Vax] -> BSD 4.0 -> 4.1 -> 4.2 ->
4.3, and now SysVr3 & BSD 4.3 will merge into SysVr4 and OSF will help
make sure we still have two major versions.

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

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

No.  Ported from TRIPOS, a networking OS, into AmigaDOS, with no
native networking support.  (true, hacking the message-passing
facility would not be difficult, but AmigaDOS has no networking.)  So,
why not an Amiga with Unix V7 and networking added?

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

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

Ever try using SunOS 4.0 trace(1)?

Deven
--
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2214 12th Street, Troy, NY 12180       Phone:  (518) 271-0750
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.