shadow@pawl.rpi.edu (Deven T. Corzine) (08/02/89)
*sigh* Here I go again. On 1 Aug 89 12:54:54 GMT, lofaso@titan.tsd.arlut.utexas.edu (Bernie Lofaso) said: In article <195@VAX1.CC.UAKRON.EDU>, benton@VAX1.CC.UAKRON.EDU (Kevin Benton) writes: Kevin> I'll agree with you that AmigaDOS is half way decent for the Kevin> user interface, although from a programmer's standpoint, the Kevin> operating system itself is about the buggiest thing I have ever Kevin> seen. When my Amiga crashes CLI's for no apparent reason, I Kevin> would tend to think there must be something better out there, Kevin> especially since Minix comes with SOURCE CODE!!!! 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. From a programmer's standpoint, AmigaDOS itself isn't notably buggy. Many of the PD/Shareware/Freeware utilities and programs you need to make the damn UI halfway decent ARE, but that's another issue. What IS poor is the BCPL shit showing up in the programming interface. Also arbitrary limitation of functionality. I can understand time pressure forcing C-A to give in and use outside help and BCPL to implement the file system. HOWEVER, the "official" languages for the Amiga were (and are) primarily Assembly and C. Both share stack, pointer and string conventions. BCPL does not. To use BPTRs and BSTRs in the programming *interface* is simply unforgivable. All the dos.library functions should have internally converted the passed arguments to BCPL crap. This way, everyone could have been saved *much* irritation, bugginess and hassle, and the BCPL code could be later cleanly replaced with C or Assembly code. Furthermore, using a nonstandard jump table for dos.library was equally stupid. Being unable to SetFunction() calls in dos.library is simply a ridiculous and unnecessary restriction. Doubly unforgivable is crippling the *Exec* OpenLibrary() and OpenDevice() functions. How are they crippled, you ask? An Exec Task can not safely run them. Why not? If the library or device isn't found, *AmigaDOS* butts in and tries to load them out of LIBS: or DEVS:. Now, this isn't unreasonable, until you consider that it will *fail* unless the Task is also an AmigaDOS Process. You'd think the damn thing could just create temporary data structures it needs, but NOOOO. Some things, like needing to be a Process to call dos.library's Delay() function are annoying and silly, but understandable and acceptable. [besides, it belongs in timer.device as Sleep()] Then there's the stupid 20 CLI limit... CATS-folx: Sorry to be so caustic, but things like this just strike me as SO inconceivably *stupid* that I have real difficulty understanding why anyone would do it. *sigh* Well, on with the show. Bernie> I have a very difficult time with the part about "the buggiest Bernie> thing I have ever seen". This is simply hog wash. AmigaDOS Bernie> is no more buggy than most other operating systems. I'll buy that. Bernie> My guess is that Mr. Benton may be running much PD software Bernie> which, as one might expect, does not live up to more rigorous Bernie> programming standards that some of us might expect. There are Bernie> several issues, which Mr. Benson's message alludes to, as have Bernie> others posted on the net, which nobody seems to have Bernie> addressed. 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] Bernie> How many people who have OS source (to Minix or anything else) Bernie> would actually do anything with it? Arguably few would attempt to *change* things in the operating system, but many programmers would be interested in seeing how things work, and it allows programmers to analyze how they need to write a program to have it mesh properly with the OS. [I've found the Exec disassembly to be of great usefulness...] (program to generate it is on a Fish disk.) Bernie> While there are plenty of good programmers who might could do Bernie> something with it, would they have the time or care? The Bernie> number of those who would are statistically insignificant Bernie> compared to the number of those who wouldn't know what to do Bernie> with the code. Typically systems of this magnitude are either Bernie> incomprehesible or trivial. Minix is designed to be reasonably comprehensible, though it is quite large, of course. As for whether it would be used... even if the source *isn't* used [which I doubt] it hardly hurts to have it available. I don't see Commodore distributing commented source for all THEIR code. [not that I'm saying they SHOULD, but it would be nice.] Bernie> Why do you want Minix (Unix, etc.) on your Amiga? I suspect Bernie> many people voice a desire because it's extremely popular and Bernie> they are used to it. Excellent reasons, but are you also used Bernie> to the system administration headaches that can come along Bernie> with it? 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. Yes, Unix is multiuser, but that doesn't need to complicate things much. Managing an AmigaDOS system well can be a lot of work as well. [unless you LIKE using only the stock configuration...] Bernie> (Since only a C= Unix would ever become popular, when you add Bernie> devices to Minix, etc. guess who gets to write the device Bernie> drivers. :-) I don't see how that necessarily follows. True, C-A Unix [Amix] gives instant name-recognition, and some expectation of support and service. However, I consider it to be a stretch to claim ONLY a C-A environment could thrive. Consider ARexx. 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. (So much easier on the Amiga, it just crashes.) Real-time Unix systems DO exist. Most are not. The Amiga Exec OS achieves excellent response by not supporting VM, message-passing by reference, strict task prioritizing and other such little tricks. They can work nicely and attain impressive speed and response time, but there ARE clear drawbacks. Bernie> Well, some are decent, but the response of AmigaDos is in my Bernie> opinion superior. The responsiveness of Exec is excellent. AmigaDOS isn't always so hot. Consider directory scans, a VERY common operation, which is slow as all hell. [and don't bother to mention FFS -- it's backpatching to make the file system what it should've been to begin with.] Bernie> There is also a more elegance of design to the AmigaDos Bernie> system. AmigaDOS? More elegant than Unix? Don't make me laugh. Bernie> (That might be good for a few flames.) Big surprise. Bernie> I wouldn't want to do without the ASSIGN command and logical Bernie> volumes in general. I could go on. Logical volumes are among the few _good_ things about AmigaDOS. Take a gander at dos.library sometime, however. Elegant? Ha. Kevin> I don't know if you have ever used Unix before, but there's a Kevin> lot more for Unix than just Multiple Users... (not to mention Kevin> 2000 times more pd software, interprocess communication, etc.) Bernie> Now you've hit the nail on the head... it's not that you're in Bernie> love with Unix's process communications (which incidently Bernie> aren't as good as AmigaDos except on newer systems like Bernie> SunOS), Oh? So you're saying the brilliant PIPE: AmigaDOS device is better (and more elegant!) than Unix's pipe() system call? How about fork() and exec()? [execve() for purists.] Or are you thinking of Exec's message-passing? It has advantages and disadvantages, but is decent overall, and none to AmigaDOS's credit. Maybe you're thinking of the AmigaDOS packets for asynchronous I/O? [granted, elegant in concept, but ugly in implementation.] Bernie> but it's the utilities! Damn right. Unix tends to be a far more constructive environment. I'd much rather spend my time wrestling with a problem I'm trying to solve than wrestling with the poor tools I have available to use. Bernie> Life is not worth living if I can come in early in the morning Bernie> and grep a few files to start my day. With make, diff, awk, Bernie> etc. etc. etc. life is so much easier. Yes. Bernie> But, since most of these have been ported to the Amiga, Bernie> including some impressive user shells to replace the CLI Bernie> (don't like CLI... only dirty three letter word I know), Bernie> what's the advantage? Well, now. Here you are bringing up the same PD (/Free/Shareware) software you were condemning before as the bugginess culprit. You can't have it both ways. These ports (which are usually not as good as the real thing) are NOT part of AmigaDOS. Many excellent utilities ARE part of Unix. (generally speaking.) The advantage? They usually WORK, as documented, without crashing the entire machine if somethign goes wrong. Bernie> I think that if people consider arguments like these, there Bernie> would be much less desire to run Unix on the Amiga. If people believe faulty arguments, then maybe so. I, for one, don't agree. Bernie> (Did I also mention disk and memory requirements for Unix. Bernie> Hardware vendors love it I'm sure.) 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. All current versions of Unix are derived from it. It has most of the major concepts that make Unix so successful. Minix is a complete reimplementation (a much cleaner one) of Unix V7, distributed with source code. [As Unix itself was, long ago.] {My Amigix project will also use Unix V7 as a base. But that's a subject for other articles.} 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.
richard@gryphon.COM (Richard Sexton) (08/03/89)
In article <SHADOW.89Aug2040433@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes:
An article whose sheer length alone will prevent it from ever being read.
--
*(jfh@rpp386.signature)
richard@gryphon.COM decwrl!gryphon!richard gryphon!richard@elroy.jpl.NASA.GOVshadow@pawl.rpi.edu (Deven T. Corzine) (08/03/89)
On 3 Aug 89 02:45:47 GMT,
richard@gryphon.COM (Richard Sexton) said:
Richard> In article <SHADOW.89Aug2040433@pawl.rpi.edu>
Richard> shadow@pawl.rpi.edu (Deven T. Corzine) writes:
Richard> An article whose sheer length alone will prevent it from ever
Richard> being read.
Ironic, isn't it? And I get a challenging reply because I didn't go
into *enough* detail. Some people assume because you don't conduct a
guided tour of every sidestreet that you're clearly no more than
noddingly familiar with the main roads...
Deven
[yes, I realize this is tame for alt.flame, but this time it's small.]
--
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.