Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!rpi!pawl!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Minix, Unix on the Amiga, and flames on AmigaDOS braindamage... Message-ID: Date: 6 Aug 89 04:01:25 GMT References: <1610@uw-entropy.ms.washington.edu> <195@VAX1.CC.UAKRON.EDU> <513@titan.tsd.arlut.utexas.edu> <26900@agate.BERKELEY.EDU> Sender: usenet@rpi.edu Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 322 In-reply-to: mwm@eris.berkeley.edu's message of 3 Aug 89 00:38:07 GMT In article 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.