forrest@blia.BLI.COM (Jon Forrest) (11/13/86)
I recently received an Amiga on loan from a computer book publishing company in order to test programs from a new Amiga book I am doing a technical review of. I'm doing the review even though I told them that I don't know anything about Amiga's. Anyway, I started this project with an open mind. Now, after about 2 weeks of experience on the Amiga I thought I'd give an accessment of the Amiga from the point of view of an experienced computer programmer, although one without any Amiga experience or knowledge. My opinion is that, with the exception of being able to display many colors, the Amiga is pretty dismal. I deliberatly didn't look into the internal aspects of AmigaDos but base my opinion on user interface problems. I should also note that I mainly use the CLI interface. The first thing I noticed is that the Amiga doesn't use Control-S and Control-Q to stop and start output to the screen. Control-S does work but only carriage return seems to resume output. The XON/XOFF protocol is so common that I would hope that there is some good reason why Amiga doesn't use it. The next thing that bothered my is that the Amiga is SLOOOOOOW in performing tasks that a standard speed IBM PC can do much better. For example, running DIR is unacceptably slow. Yet, this is a very commonly run command. The CD command has the same problem. What follows is a short list of other annoying features of the Amiga: 1. The lack of wild card characters is a bother. 2. I couldn't find the command for removing a directory. 3. The file system is very similar to Unix and MS-DOS. Why couldn't they use the same pathname syntax of one of these? 4. The amount of time it takes to respond to Control-C seems unpredictable. This is true even though I was running a compile which does I/O like crazy, which on the IBM is when Control-C's can be detected. When I read other people's submissions complaining about systems I know something about I often think to myself that the person who wrote the article was obviously suffering from a severe case of cranial-anal inversion. But, being in the same situation is a very enlightening experience. Jon Forrest ucbvax!mtxinu!blia!forrest
vanam@pttesac.UUCP (Marnix van Ammers) (11/16/86)
In article <939@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >I recently received an Amiga on loan from a computer book >publishing company in order to test programs from a new >Amiga book I am doing a technical review of. I'm doing >the review even though I told them that I don't know anything >about Amiga's. > >Anyway, I started this project with an open mind. Now, after >about 2 weeks of experience on the Amiga I thought I'd give >an accessment of the Amiga from the point of view of an experienced >computer programmer, although one without any Amiga experience or >knowledge. > Boy, oh boy. I know you're going to get a lot of replies/followups from this one. Let me be among the first. I agree with a lot of your complaints. It would be nice if the Amiga worked like the older systems that we're used to. I'd like to see ^S/^Q, unix style wild cards, and unix style PATH names. I'm sure there are reasons why the Amiga chose to do things differently. Perhaps our idea of normal and standard is not normal or standard in the origins of AmigaDOS. In any case, I've gotten used to using [SPACE-BAR]/[BACK-SPACE] for stop/start control, and '#?' for '*' (AmigaDOS *does* have wild cards!). Lots of flames to you for using CLI without having read the manual! The workbench is for those who don't like reading manuals. The CLI is for those who like to get in a little deeper and don't mind reading manuals. Wait 'till you hear what the command is to delete directories! Marnix --- -- Marnix A. van\ Ammers Work: (415) 545-8334 Home: (707) 644-9781 CEO: MAVANAMMERS:UNIX {ihnp4|ptsfa}!pttesac!vanam CIS: 70027,70
daveh@cbmvax.cbm.UUCP (Dave Haynie) (11/17/86)
> > My opinion is that, with the exception of being able to display > many colors, the Amiga is pretty dismal. I deliberatly didn't look > into the internal aspects of AmigaDos but base my opinion on > user interface problems. I should also note that I mainly use > the CLI interface. > > The first thing I noticed is that the Amiga doesn't use Control-S > and Control-Q to stop and start output to the screen. Control-S > does work but only carriage return seems to resume output. The > XON/XOFF protocol is so common that I would hope that there is some > good reason why Amiga doesn't use it. The Amiga CLI output stops when you type nearly any character, and starts again when you delete that character or type <RETURN>. While you are correct in stating that it doesn't follow the more conventional XON/XOFF convention, I see no reason why it really should. That convention dates back to when you were typing on an attached TTY of some kind. This scheme is better, at least once you get used to it. Its part of the type-ahead mechanism; unlike type-ahead under UNIX, console output on the Amiga pauses until you complete a line. > The next thing that bothered my is that the Amiga is SLOOOOOOW in > performing tasks that a standard speed IBM PC can do much better. > For example, running DIR is unacceptably slow. Yet, this is a very > commonly run command. The CD command has the same problem. DIR and CD in MS-DOS is built-in, plus MS-DOS directories are organized more efficiently for directory searches. AmigaDOS directories are optimized to allow a named file to be found as quickly as possible, and in this respect they work very well. The Amiga CLI doesn't have any resident commands. Every command you type must be loaded from disk in a normal configuration. That's normally going to take a bit more time that the built-in CD command would, though with the command on a hard disk or in RAM: you wouldn't notice it. The advantage of a small CLI is that it allows more programs to co-exist in memory at once (no big deal if you've got a few megabytes on your machine, but important if you're limited to 256K or 512K in you current configuration). > What follows is a short list of other annoying features of the Amiga: > > 1. The lack of wild card characters is a bother. There's no CLI managed wildcard expansion, though most of the AmigaDOS commands (DELETE, COPY, etc.) support wildcards. These aren't like UNIX or MS-DOS, but are generally more powerful once you get used to them. > 2. I couldn't find the command for removing a directory. Did they supply you with an AmigaDos Manual? This could explain a number of the problems you've been having. The command for removing a directory is DELETE. If the directory contains files, you'd have to specify DELETE directoryname ALL similar to the UNIX rm -r directoryname operation. > 3. The file system is very similar to Unix and MS-DOS. Why couldn't > they use the same pathname syntax of one of these? Why couldn't MS-DOS use the already established UNIX pathname structure, instead of inventing one of its own? AmigaDOS is a direct descendent of TriPos, an operating system common in Europe. The directory structure and many of the other features are a direct result of this. > 4. The amount of time it takes to respond to Control-C seems unpredictable. > This is true even though I was running a compile which does I/O > like crazy, which on the IBM is when Control-C's can be detected. I've never noticed this, but AmigaDOS does allow ^C trapping within I/O routines. Actually, I believe that a ^C is noticed immediately by the I/O management Process, and during a program's I/O its occurance is polled. It depends alot on how the program is written; it can be dangerous to break out of a program at certain points, so its likely that the ^C checking is turned off in these cases. > When I read other people's submissions complaining about systems I know > something about I often think to myself that the person who wrote > the article was obviously suffering from a severe case of cranial-anal > inversion. But, being in the same situation is a very enlightening > experience. > > Jon Forrest > ucbvax!mtxinu!blia!forrest -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "Laws to supress tend to strengthen what they would prohibit. This is the fine point on which all the legal professions of history have based their job security." -Bene Gesserit Coda These opinions are my own, though for a small fee they may be yours too. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gary@mit-eddie.MIT.EDU (Gary Samad) (11/17/86)
In article <939@blia.BLI.COM>, forrest@blia.BLI.COM (Jon Forrest) writes: > I recently received an Amiga on loan from a computer book > publishing company in order to test programs from a new > Amiga book I am doing a technical review of. I'm doing > the review even though I told them that I don't know anything > about Amiga's. > ... > many colors, the Amiga is pretty dismal. I deliberatly didn't look > into the internal aspects of AmigaDos but base my opinion on > user interface problems. I should also note that I mainly use > the CLI interface. > If you're going to use the advanced user's interface, you better be an advanced user! > The first thing I noticed is that the Amiga doesn't use Control-S > and Control-Q to stop and start output to the screen. Control-S > does work but only carriage return seems to resume output. The > XON/XOFF protocol is so common that I would hope that there is some > good reason why Amiga doesn't use it. > If you had read the manual you would know that typing any character suspends window output and either deleting it or hitting <RETURN> allows output to resume. Yes, using ^S and ^Q would be nice, but there IS a normal way to do it! > The next thing that bothered my is that the Amiga is SLOOOOOOW in > performing tasks that a standard speed IBM PC can do much better. > For example, running DIR is unacceptably slow. Yet, this is a very > commonly run command. The CD command has the same problem. > Yes, tradeoffs have been made trading off directory access times for file access times, but doing a directory on the Amiga is no slower than doing a directory on an IBM PC's floppy disk. It appears to be slower because the entire directory is read in and SORTED before printing it. If you want immediate response (and an unsorted dir) use list. Also, last night I was doing some development on both my Amiga and IBM PC sitting next to it (with a hard disk) and learned how really fast the Amiga is. I compiled and linked a 5000 line program in C on the PC and it took 30 minutes; I compiled and linked a 25000 line C program on the Amiga and it took 25 minutes!! Don't tell me the Amiga is slow! > What follows is a short list of other annoying features of the Amiga: > > 1. The lack of wild card characters is a bother. Again, READ THE MANUAL. You just didn't start using your IBM without reading the manual did you? Most commands use a wildcard syntax that is both different (sometimes annoying) but much more powerful than the PC's. It uses a regular expression syntax allowing you to look for any of a set of characters, etc. Read the manual for an explanation. > 2. I couldn't find the command for removing a directory. Try delete. > 3. The file system is very similar to Unix and MS-DOS. Why couldn't > they use the same pathname syntax of one of these? Yes, the pathname differences are annoying, especially using / instead of .. to refer to the parent directory and having no way to refer to the current directory. > 4. The amount of time it takes to respond to Control-C seems unpredictable. > This is true even though I was running a compile which does I/O > like crazy, which on the IBM is when Control-C's can be detected. Some programs simply ignore ^C. Also, you should try ^D which is more effective when you are running a batch file. > When I read other people's submissions complaining about systems I know > something about I often think to myself that the person who wrote > the article was obviously suffering from a severe case of cranial-anal > inversion. But, being in the same situation is a very enlightening > experience. > > Jon Forrest > ucbvax!mtxinu!blia!forrest Look, the mouse/windowing Workbench is meant to be used by people who refuse to read the manuals. If you choose to use the Advanced User's interface, you better be an Advanced User! FLAME OFF! Gary
dillon@CORY.BERKELEY.EDU (Matt Dillon) (11/18/86)
Actually, my last posting on this subject had an error in it. I forgot to take into account the fact that the Amiga uses / at the head of a path to refer to the previous directory rather than '..' I never did get used to that so I allow you to use '..' in my CD command in my SHELL. >From: gary@mit-eddie.MIT.EDU (Gary Samad) > Yes, tradeoffs have been made trading off directory access times for file >access times, but doing a directory on the Amiga is no slower than doing >a directory on an IBM PC's floppy disk. It appears to be slower because the >entire directory is read in and SORTED before printing it. If you want >immediate response (and an unsorted dir) use list. Sorry Gary, Directories on a PC are quite a bit faster than on the Amiga whether you sort them or not. Let's at least get our facts staight when we argue. -Matt
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (11/18/86)
Let me add some heat to the fire... In article <939@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >Anyway, I started this project with an open mind. Now, after >about 2 weeks of experience on the Amiga I thought I'd give >an accessment of the Amiga from the point of view of an experienced >computer programmer, although one without any Amiga experience or knowledge. How experienced? I'm an "experienced programmer" (over 10 years) and systems manager (over six years), and after using the Amiga, there's not a chance in the world of me going back to CP/Moid (and MS/DOS is a bigger - and maybe better - CP/M) things again. >The first thing I noticed is that the Amiga doesn't use Control-S >and Control-Q to stop and start output to the screen. Control-S >does work but only carriage return seems to resume output. The >XON/XOFF protocol is so common that I would hope that there is some >good reason why Amiga doesn't use it. As others have said, RTFM. The Amiga supports a "clean line" discipline: if there's input waiting on the line, then no new output will appear. While not as nice as the VMS "echo-when-read" discipline, it's still a lot nicer than the typical "immediate echo" that leaves garbage on the screen. Once you've got this, C-s/C-q becomes redundant. I also find space/backspace a lot easer to hit than C-s/C-q. >The next thing that bothered my is that the Amiga is SLOOOOOOW in >performing tasks that a standard speed IBM PC can do much better. >For example, running DIR is unacceptably slow. Yet, this is a very >commonly run command. The CD command has the same problem. Dir is an unusual case - you're fighting the features in the Amiga file system that make normal cases (opening a file by name) fast, and add robustness. "List quick" will be faster than "dir" on the Amiga. Whether it's faster than dir on a PC floppy is unknown to me; the only obsolete hardware I deal with these days is our Cray. As for the cd command, it changes directory as fast as anything else I type at (i.e. - I can't see the delay between hitting return and the prompt) if you're not crossing disks. Verifying that the directory you're changing to actually exists is a nice feature, but it does take some time. >1. The lack of wild card characters is a bother. Uh, I don't know what YOU call them, but #? does what I need done 90%+ of the time. The extra power in alternation, etc. is also there if you want it. >2. I couldn't find the command for removing a directory. Delete works if it's empty. "Delete <directory> all" will trim the tree. >3. The file system is very similar to Unix and MS-DOS. Why couldn't > they use the same pathname syntax of one of these? I don't know about MS-DOS, but it's *NOT* similar to Unix. It's a forest, whereas Unix is a tree (Forests have several advantages over trees. They also have some disadvantages). Not copying the ms-dos backslash is a win; it should make programs more portable (not sure it does; I don't know if the MS-DOS compilers have hacks in them to understand '/'-seperated names). >4. The amount of time it takes to respond to Control-C seems unpredictable. > This is true even though I was running a compile which does I/O > like crazy, which on the IBM is when Control-C's can be detected. That's related to the worst problem in AmigaDOS as an OS, that programs have to exit themselves. It hurts in more (and worse) ways than the C-c problem. >When I read other people's submissions complaining about systems I know >something about I often think to myself that the person who wrote >the article was obviously suffering from a severe case of cranial-anal >inversion. But, being in the same situation is a very enlightening >experience. I won't say the obvious. I will say that you should at least have read the manual and worked with the system for a while before commenting on it. <mike
higgin@cbmvax.cbm.UUCP (Paul Higginbottom GUEST) (11/18/86)
In article <939@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: >I recently received an Amiga on loan from a computer book >publishing company in order to test programs from a new >Amiga book I am doing a technical review of. I'm doing >the review even though I told them that I don't know anything >about Amiga's. > >Anyway, I started this project with an open mind. Despite seemingly having a seeming bias toward UNIX/MSDOS (see below). >Now, after about 2 weeks of experience on the Amiga I thought I'd give >an accessment of the Amiga from the point of view of an experienced >computer programmer, although one without any Amiga experience or knowledge. > >My opinion is that, with the exception of being able to display >many colors, the Amiga is pretty dismal. I deliberatly didn't look >into the internal aspects of AmigaDos but base my opinion on >user interface problems. I should also note that I mainly use >the CLI interface. Despite the fact that most typical users will use WorkBench mainly? >The first thing I noticed is that the Amiga doesn't use Control-S >and Control-Q to stop and start output to the screen. Control-S >does work but only carriage return seems to resume output. The >XON/XOFF protocol is so common that I would hope that there is some >good reason why Amiga doesn't use it. Sure - not EVERYONE knows about CTRL-S/CTRL-Q being a defacto standard on terminals. Also, CLI blocks output of any program when the user types practically any characters (which for some reason I DON'T understand includes control characters) and resumes output when those typed characters are deleted, or the user hits RETURN. I would say this is a little simpler and more obvious than CTRL-S/CTRL-Q for the user who is NOT an 'experienced programmer'. >The next thing that bothered my is that the Amiga is SLOOOOOOW in >performing tasks that a standard speed IBM PC can do much better. This is too sweeping a statement! And you've judged the Amiga too quickly, and too narrowly. >For example, running DIR is unacceptably slow. AmigaDOS is optimized to accessing a file quickly (via hashing) rather than sequentially determining the contents of a directory, but I agree, it is intolerably slow. However, the roots of AmigaDOS were developed long before the Amiga existed, and seems to work well on a hard disk. >What follows is a short list of other annoying features of the Amiga: >1. The lack of wild card characters is a bother. Read the AmigaDOS User's Manual - there's tons of pattern matching; it's built into the disk resident commands, rather than the CLI itself. >2. I couldn't find the command for removing a directory. Try DELETE. If you want to delete a directory that isn't empty, use the ALL keyword at the end. >3. The file system is very similar to Unix and MS-DOS. Why couldn't > they use the same pathname syntax of one of these? BUT THEY HAVE - A: B: C: on MSDOS seems similar to device names under AmigaDOS - DF0: DF1:, RAM:, etc. Under UNIX, users rarely have to deal with "devices" directly, so I don't think the comparison is valid. Also, "/" is MORE compact than ".." under UNIX, and I really like it despite being a UNIX fan. >4. The amount of time it takes to respond to Control-C seems unpredictable. It's a multi-tasking machine remember, and it also depends on the program, the compiler, and what other programs are running. >When I read other people's submissions complaining about systems I know >something about I often think to myself that the person who wrote >the article was obviously suffering from a severe case of cranial-anal >inversion. But, being in the same situation is a very enlightening >experience. I trust you are now inverted the right way up. >Jon Forrest >ucbvax!mtxinu!blia!forrest Paul Higginbottom Disclaimer: I work for myself and my opinions are my own.
mikeb@tekfdi.UUCP (Mike Boyce) (11/18/86)
In article <939@blia.BLI.COM>, forrest@blia.BLI.COM (Jon Forrest) writes: BEGIN BOZO blah .. blah .. blah > The next thing that bothered my is that the Amiga is SLOOOOOOW in > performing tasks that a standard speed IBM PC can do much better. > For example, running DIR is unacceptably slow. Yet, this is a very > commonly run command. The CD command has the same problem. blah .. blah .. blah > Jon Forrest > ucbvax!mtxinu!blah!bozoland!cant_see_the_forrest_for_the_trees!!!! BOZO END Sheesh!! You know, you're right. The IBM PC gives faster directory listings than the Amiga. We all know (nudge, nudge, wink of the eye) that the IBM is the better of the two machines. I think that you DESERVE an IBM PC. And as for CLI, how could anyone (know what I mean) compare that to the infinately superior MS-DOS command interpreter. I mean, if it can't fit it 640K why even run the damn thing. Graphics? Who needs 'em. Multi-tasking? Thing of the past. Stereo sound? Say what? Multi-mate? Can't run it. 1-2-3? Can't live with out it! How could I have been so stupid as to buy an amiga. It should be written: "And on the 6th day IBM rested and as it was so shall it ever be so." THE EARTH IS FLAT!! (just put this in for effect.) Well enough parody. I guess its time to CD (cringe!). Maybe I'll post another news article on my Amiga's terminal emulator while my Amiga CDs (wait, wait, wait). If only I could afford a PC my prayers would be answered. Then I could CD all day long in the time the Amiga could be running a program. And just wait till the '386s hit the market with MS-DOS 5.0 (can you say kludge). In case you can't guess, the only line I didn't exagerate said, "I think you DESERVE an IBM PC." ------------------------------------------------------------------------------ I have a theory that Commidore posts these ludicrous letters just to see the response. If thats true, cut it out. It pisses me to no end! CUT IT OUT! Micky Mick Mick at your ... My employer disavows any knowledge of my existance.
cmcmanis@sun.uucp (Chuck McManis) (11/18/86)
In the previous article Matt Dillion wrote : (referring to Gary's comment)
)
) Sorry Gary, Directories on a PC are quite a bit faster than on the
) Amiga whether you sort them or not. Let's at least get our facts staight
) when we argue.
)
) -Matt
I agree with you in principle Matt, however I did verify something with
PC's that is not true with the Amiga. And that is that on hard disks
the PC's dir command gets slower and slower as the disk get bigger and
bigger up until it breaks at 32Megs. The Amiga's on the other hand
stays the same speed, and doesn't have a hard disk size limit. (Nor
does it waste a lot of space on "clusters" or "allocation blocks")
Personally, I consider that fact relevent now that Maxtor has a 675 Meg
5.25" winchester. (can you say 22 Ms-Dos partitions?) I am sure Microsoft
will continue to improve and upgrade their software as I am sure C/A
will too.
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.dillon@CORY.BERKELEY.EDU (Matt Dillon) (11/19/86)
>I agree with you in principle Matt, however I did verify something with >PC's that is not true with the Amiga. And that is that on hard disks >the PC's dir command gets slower and slower as the disk get bigger and >bigger up until it breaks at 32Megs. The Amiga's on the other hand >stays the same speed, and doesn't have a hard disk size limit. (Nor >does it waste a lot of space on "clusters" or "allocation blocks") >Personally, I consider that fact relevent now that Maxtor has a 675 Meg >5.25" winchester. (can you say 22 Ms-Dos partitions?) I am sure Microsoft >will continue to improve and upgrade their software as I am sure C/A >will too. >-- >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com >These opinions are my own and no one elses, but you knew that didn't you. The directory listing itself is extremely fast. The problem with the IBM is that to find the number of free blocks, the poor thing must seek about the entire partition. They made the limit 32Megs 'cause they were limited by the 8088 (I agree with you that they should have spent the extra time to make it 2Gig). IBM messed up in many other ways as well: The infamous 'floppy change' bug has not been completely fixed. You can't move directories or files into other directories, you can't rename directories, file path names use '\', file names are still limited to 8chars+extension, file paths are not integrated (letter: is not integrated with \name\name... try CD C:\somename, it doesn't work). CTL-S, CTL-Q, and CTL-C on the IBM ONLY work if you haven't typed anything else first. <BREAK> on the IBM will get you out of a program, but not as nicely (it's an actual interrupt). PC/MSDOS is still one up on the Amiga with a 'load&run' call which returns the return value from the function, and with enviroment variables. The Amiga doesn't really have enviroment variables, at least not in a system-standard way. IBM hard disks are still much faster than Amiga Hard Disks because, as yet, I have not seen a DMA Amiga HD on the market. (anybody know of one??? I admit my information is limited). And, as Chuck says above, the Amiga doesn't ponder when storage becomes extensive. With that many partitions, you start to run out of drive letters on an IBM. You CAN mount one drive designation on another, but it's a hack at best. -Matt Dillon
john13@garfield.UUCP (11/19/86)
In article <939@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes: [Intro deleted - about how he is reviewing an Amiga book without prior Amiga experience] >Anyway, I started this project with an open mind. Now, after >about 2 weeks of experience on the Amiga I thought I'd give >an accessment of the Amiga from the point of view of an experienced >computer programmer, although one without any Amiga experience or knowledge. "Assessment" implies both experience and knowledge of what you are assessing. You seem to have gotten hands-on experience without any kind of reference work, and with no one to answer your questions. 30 seconds or so of give-and- take with someone who knew about AmigaDos could have prevented the need for your posting. >My opinion is that, with the exception of being able to display >many colors, the Amiga is pretty dismal. I deliberatly didn't look >into the internal aspects of AmigaDos but base my opinion on >user interface problems. I should also note that I mainly use ^^^^^^^^^^^^^^ >the CLI interface. From the complaints you have later on, it seems like you haven't been a typical user. I found answers to all of your problems on my own, without any manuals, knowing only 1 or 2 commands initially. How did you get to see all of these colours using AmigaDos alone? >The first thing I noticed is that the Amiga doesn't use Control-S >and Control-Q to stop and start output to the screen. Control-S & Q are pretty arbitrary. Notice how both the S and Q keys are close by the control key, allowing you to do flow control with two fingers without stretching. The console handler on the Amiga stops output when you type a character, and resumes when you either delete or do a return. The rationale behind this is that you can interrupt output to type a complete command. For pausing streams of text the easiest keys to use are the \ and backspace, resting one finger on one and one on the other. >The next thing that bothered my is that the Amiga is SLOOOOOOW in >performing tasks that a standard speed IBM PC can do much better. >For example, running DIR is unacceptably slow. Yet, this is a very >commonly run command. The CD command has the same problem. "Dir" is kind of the odd command out. "List" (note similar to Unix ls) is the preferred method of getting directories from the CLI. It doesn't suffer from lack of speed, and when someone asks me how to get a directory I tell them to forget about "dir". Also remember commands must be loaded (as on Unix), which is time consuming. People who are up-to-date with Amigados keep frequently used commands like "cd" in ram, from which they execute instantly. >What follows is a short list of other annoying features of the Amiga: > >1. The lack of wild card characters is a bother. True, this is poorly documented. But #? functions the same as * for many commands, and ? I believe works the same way as you are used to. >3. The file system is very similar to Unix and MS-DOS. Why couldn't > they use the same pathname syntax of one of these? The / functions the same way (except for specifying parent directories). You obviously haven't had much experience on VMS, which uses similar device assignments to df0:, etc. Many AmigaDos commands are more reminiscent of VMS than Unix (ie delete, and using the "all" qualifier to delete the directories). >4. The amount of time it takes to respond to Control-C seems unpredictable. > This is true even though I was running a compile which does I/O > like crazy, which on the IBM is when Control-C's can be detected. > >Jon Forrest >ucbvax!mtxinu!blia!forrest Detecting control-c's is program specific - you can choose to let your program be aborted or not. The Lattice Compiler I believe does not let you break out in the middle with a control-c. But how can you base your opinion of an entire operating system on the quirks of one program? Methinks you are confusing AmigaDos with the programs that run under it (all of the commands, for example, are programs, and so some behave differently than others). Just because a system has the flexibility to allow you to break the rules is no reason to condemn it! Also I notice you make no mention of Intuition and using the icon/mouse based system. When you say "user interface problems" remember that casual users deal almost exclusively with this. Those who have graduated to the CLI *:^) have usually read the Dos manuals, at least. Disclaimer: These opinions are, of course, my own. John
gnu@hoptoad.uucp (John Gilmore) (11/20/86)
Jon Forrest brought up a lot of good nits about the Amiga.
Sure, if you are a raving wild lunatic hacker like many of us,
you can adjust to the idiot-syncracies of any system, and even
vehemently defend them against the infidels on inferior systems.
But among ourselves, couldn't we admit that Yet Another Way to name
files in a hierarchical file system is one more way too many? Couldn't
we (except RMS) admit that while ^S and ^Q flow control has its vices,
it does have many virtues and is universally known? Couldn't we, who
all think regular expresions are great, settle on ONE form of regular
expressions? (Admittedly, Unix has two, but AmigaDos could aspire
to be better than Unix, instead of just different.) Could we agree
that a file system design which makes file opens fast at the expense of
slow directory reads might benefit from a redesign? Can we recognize
that having no clean way to kill a task without crashing the system is
something that requires attention? And could we stop calling a command
language of typed commands which start up programs from a file system
an "advanced user interface"?
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa
"I can't think of a better way for the War Dept to spend money than to
subsidize the education of teenage system hackers by creating the Arpanet."dillon@CORY.BERKELEY.EDU (Matt Dillon) (11/20/86)
I don't like something, I change it. If somebody else doesn't like something and changes it, there is no guarentee that I won't like his modification. We could admit that it makes sense to keep with one way, but if we did that 20 years ago, where would we be now? If we do it now where would we be in another 20 years? I'll tell you where... in the stone age. Thus, things that were both well conceived and applicable to today's world are still around and being used (ASCII). Other things are going out (short filenames). Some new things will die (Crazy #? of AmigaDos, I hope). I actually agree with you in many of the examples you listed below. The only way your going to get what you want is if you bitch and moan, hack up 'fixes'... Effecting the change could be a simple matter of terminology. If you start CALLING something by the 'proper' name, the people who agree with your name will also start calling it by that name. If enough people start agreeing with you, you have a standard. Just apply a little Psychology (I don't want to give away too many of my secrets!)! -Matt Dillon P.S. I think I'll go back to signing my name 'Matt' your message: >John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa >Synopsis: Why be deliberately different? > >Jon Forrest brought up a lot of good nits about the Amiga. >Sure, if you are a raving wild lunatic hacker like many of us, >you can adjust to the idiot-syncracies of any system, and even >vehemently defend them against the infidels on inferior systems. > >But among ourselves, couldn't we admit that Yet Another Way to name >files in a hierarchical file system is one more way too many? Couldn't >we (except RMS) admit that while ^S and ^Q flow control has its vices, >it does have many virtues and is universally known? Couldn't we, who >all think regular expresions are great, settle on ONE form of regular >expressions? (Admittedly, Unix has two, but AmigaDos could aspire >to be better than Unix, instead of just different.) Could we agree >that a file system design which makes file opens fast at the expense of >slow directory reads might benefit from a redesign? Can we recognize >that having no clean way to kill a task without crashing the system is >something that requires attention? And could we stop calling a command >language of typed commands which start up programs from a file system >an "advanced user interface"? >--
mwm@eris.UUCP (11/21/86)
In article <1317@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >Jon Forrest brought up a lot of good nits about the Amiga. Well, a few, anyway. >Sure, if you are a raving wild lunatic hacker like many of us, >you can adjust to the idiot-syncracies of any system, and even >vehemently defend them against the infidels on inferior systems. I take it "idiot-syncracies" means "it ain't the way I'm used to it?" >But among ourselves, couldn't we admit that Yet Another Way to name >files in a hierarchical file system is one more way too many? Umm, well, yeah. But Tripos isn't a tree, it's a forest. This is an unqualified win (hack up the file system just to get a networked file system? Never!). You could follow OS/9 in making devices be the first component of absolute path names, but AmigaDOS has the VMS-oid symbolic device hook (and a very nice hook it is, too), which would mean you could create arbitrary names in the "root" directory. Maybe do-able, but not clear it's a good idea. Besides which, adding a third magic character (":") to file names gives you a nice way to refer to the root of the current device, which is handy. Now that paths starting with "/" aren't magicked (gee, just like Amoeba!), why don't we use it as a shorter-than-".." shorthand for the current directories parent directory? It all looks good to me. Not having a shorthand way to refer to the current directory is a loss, though. >Couldn't >we (except RMS) admit that while ^S and ^Q flow control has its vices, >it does have many virtues and is universally known? C-s and C-q are control character, for binding to commands. C-h is for overstriking, use "del" to delete characters :-). On a serious note, can you name any virtue for xon/xoff other than being used in lots of hardware, and so well know to rabid hackers? The AmigaDOS "clean display" code has the virtue of preventing the interleaving of input and output characters in a single line. I also find myself typing " " to try and stop output on Unix, but never C-s to stop it on AmigaDOS, so I must conclude that the AmigaDOS version is the more natural. Of course, putting in C-s/C-q flow control wouldn't have hurt anything but the aesthetics of the system. >Couldn't we, who >all think regular expresions are great, settle on ONE form of regular >expressions? (Admittedly, Unix has two, but AmigaDos could aspire >to be better than Unix, instead of just different.) Good idea, but which one? There's the two on Unix, the one (or is it two?) used by the Software Tools, the DEC (and followers) one for file names, and the ones used in various DECoid editors, the MVS version, etc. My favorite has always been the language theory version, which looks a lot like Unix ed. To bad Unix didn't use it for file names, too. But is "#?" really that much worse than ".*"? >Could we agree >that a file system design which makes file opens fast at the expense of >slow directory reads might benefit from a redesign? Maybe. I always figured that any file system that required two disk accesses per directory in walking a path had problems, too. A good buffering strategy and some intelligent caching seems to have made it useable without breaking the basic file system; I wouldn't be surprised to find that similar tweaks will work in this case. But I'd like to see a new file system with better performance. So, John, what can you give me that has (assuming the directory entries fit in a block) a one-block-read-per-element path walk, one block read to collect all the file names in a directory, and the ability to recover from any single-block hit without loosing anything but what's in the block that got scragged? Oh, yeah - no fair keeping hints in memory (caching, etc) as ANY file system can be made to give reasonable performance with enough hints. >Can we recognize >that having no clean way to kill a task without crashing the system is >something that requires attention? Yup. But for a single-user micro, there could easily be more important thing to worry about. After all, most micros (No, John, Hoptoad isn't a micro: If I can't throw it across the room, it isn't a micro.) on the market require a reboot (that's what C-c on CP/M is - a warm boot!) to kill runaway tasks anyway. I don't think that's true in this case. A way (even a dirty way!) to kill a non-cooperative task should be highest on the list of things to add to AmigaDOS. >And could we stop calling a command >language of typed commands which start up programs from a file system >an "advanced user interface"? No, I can't, as I don't call it that. I call it the CLI. Of course, you're probably parsing it as "advanced (user interface)", instead of the correct "(advanced user) interface." Considering the other interface on the Amiga, that's accurate. In summary: Lots of John's complaints boil down to "AmigaDOS doesn't look like Unix." Admittadly, a more legitimate complaint than "AmigaDOS doesn't look like MS-DOS." But not by much. In both cases, the correct response is "Good!" If you really don't like it, you can use the flexibility of AmigaDOS to fix it (gee, that sounds familiar!). Matt Dillon has already given us a cshell-like interface, complete with Unix-like file name expansion, and there are several other CLIs floating around. Given that, you can fix the filename convention by mapping "/dev/path" to "dev:path." If you put it in the library, you could even convince all your C programs to do the same thing. You'd still have to put up with "broken" translations on other programs, though. You could probably fix the C-s/C-q file system by adding a device driver, and tweaking Matt's shell to use it instaed of your own. Better yet, just have the shell open a window and do your own raw I/O (if/when I write a shell, I'm going to do just that (again) - I *WANT* C-w. But putting the shell in Emacs makes more sense to me). You could even get parts of stty back. Of course, porting Unix to the Amiga might be preferable. Or, if you can't stand the performance hit for 4BFD or V the System, you could wait for the OS/9 port. If you're really dedicated, you could just write your own OS, and get the best of all three worlds :-) <mike
rokicki@navajo.UUCP (11/21/86)
dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > PC/MSDOS is still one up on the Amiga with a 'load&run' call which > returns the return value from the function, and with enviroment variables. > The Amiga doesn't really have enviroment variables, at least not in a > system-standard way. One of my larger complaints is the lack of environment variables. On one of the fish disks (and posted to the net a while ago) is my environment variable `set' command which constructs a resident environment variable library; these are easily accessed from C. If anyone doesn't have a copy, let me know and I'll send it to you. I wish I had the power to set a standard . . . -tom
wagner@utcs.UUCP (11/22/86)
Well, we seem now to be graduating from dumping on Jon Forrest to asking ourselves why we dumped so hard on him. Since this isn't net.psych (whatever that's called after the re-org!), I'll keep it short. Most of what Jon Forrest said has been discussed here on this newsgroup before. We all found out about it, and in calmer, more rational discussion, we agreed that these were problems. We all heard each other, and it's even possible that Commodore heard us. Those failings of the Amiga took a long time to understand, and to some extent, learn to live with. As Matt says, some of us tried to solve those problems in our own ways. Then along comes Jon (wasn't there a song like that?). He leads with his chin. He says (effectively - I'm not quoting directly): I got this thing on loan. I have no vested interest in defending my purchase. I haven't bothered to read the manuals. I started in on the interface that looked like the one I'm used to, and it isn't at all like the one I'm used to once you get into it. I didn't like it. The amiga, viewed at this distance and in that manner, isn't all that hot. Well, you know what? He's right. Viewed in this curious way, the amiga isn't all that hot. Part of it is his fault for not being a little more thorough. Part of it is the amiga's fault, for not helping the user who comes in through that door a little (well, maybe I should say the fault of the amiga documentation). But why did we jump on him. We were mad because the insights that took us months (because we were motivated to find work-arounds) took him two weeks. But that is the nature of the difference between being an owner and not being an owner. That's why magazines get people to review things that aren't their own. You see more clearly. Pride of purchase doesn't get in the way. Don't jump. Think. Mostly, we agreed with him (except when he couldn't find the delete command...but he was sorry for that part afterwards). Why attack someone for saying things you want to say? Hmmm...guess this got long anyways. Oh, well. Michael (wagner@utcs or ..f.i.n.d..y.o.u.r..w.a.y..t.o..!utzoo!utcs!wagner) P.S. Maybe this means that Commodore should provide a tutorial for people coming in via previous experience in line-mode interfaces.
cc1@locus.ucla.edu (Michael Gersten) (12/06/86)
In article <1740@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: >paths starting with "/" aren't magicked (gee, just like Amoeba!), why >don't we use it as a shorter-than-".." shorthand for the current >directories parent directory? Because that is not what it means. The '/' is a-symetric: at the beginning of filenames it means "../", elsewhere it means "/". There is no way to refer to the parent of a directory; there is simply a kludge that allows access to a parent as a special case at the beginning of a filename. >The AmigaDOS "clean display" code has the virtue of preventing the >interleaving of input and output characters in a single line. I also But it also STOPS output, and stops any program that is trying to do output. This is what I dis-like; it effectively kills type-ahead. >John, what can you give me that has (assuming the directory entries >fit in a block) a one-block-read-per-element path walk, one block read >to collect all the file names in a directory, and the ability to >recover from any single-block hit without loosing anything but what's Very simple. First, the ability to recover from a block hit is not-- REPEAT, NOT--a function of the directory. Second, most micro's have DOS's with this feature. Trsdos (EVERY version) comes close (they miss only because they also keep a hash table which simply hashes the name, resulting in a quicker 'not found'; delete this and you get one read for filename, path walk, and everything. By putting links in data blocks, you get one hit doesn't kill. >on the market require a reboot (that's what C-c on CP/M is - a warm >boot!) to kill runaway tasks anyway. > THIS IS BAD! Even if it is true, that doesn't mean we have to stick wth it What about background jobs that are running? Better would be to say that any single-tasking micro requires rebooting. Michael Gersten Views expressed here may not be those of the Computer Club, UCLA, or anyone in their left OR right mind. And that's the name o' that tune.
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (12/12/86)
In article <3311@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes: >In article <1740@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: >>paths starting with "/" aren't magicked (gee, just like Amoeba!), why >>don't we use it as a shorter-than-".." shorthand for the current >>directories parent directory? > >Because that is not what it means. The '/' is a-symetric: at the beginning >of filenames it means "../", elsewhere it means "/". There is no way to >refer to the parent of a directory; there is simply a kludge that allows >access to a parent as a special case at the beginning of a filename. Gee, that's what I said - use "/" as a shorthand for "../". It actually WORKS like "../", as opposed to a kludge <etc>. If you go //filename, you get to the grandparent of the current directory. You might also note that, unlike the "." and ".." kludges in Unix (you want to count the number of programs that KNEW that the first two entries in a directory were "." and ".."? Of course, it might be worth pointing out that Unix has the same "a-symmetry." At the beginning of the file name, it means "use the root directory." Everywhere else it means "we've just finished a directory name." >>The AmigaDOS "clean display" code has the virtue of preventing the >>interleaving of input and output characters in a single line. I also > >But it also STOPS output, and stops any program that is trying to do >output. This is what I dis-like; it effectively kills type-ahead. Huh? I type ahead all the time. No problem, you just have to type a complete line. I also run "stty tostop" on Unix, which is even worse; you have to wait for commands to complete before finding out that there's output. But it's worth it; I LIKE not having garbage show up in the middle of a line I'm typing. >>John, what can you give me that has (assuming the directory entries >>fit in a block) a one-block-read-per-element path walk, one block read >>to collect all the file names in a directory, and the ability to >>recover from any single-block hit without loosing anything but what's > >Very simple. First, the ability to recover from a block hit is not-- >REPEAT, NOT--a function of the directory. Obviously. It's a function of the redundancy in the directory structure. Go look at the Xerox file systems for a good example of how to do this kind of thing right; of course, they use mucho caching to make it go fast. That doesn't change the problem of wanting a fast, robust file system without using mucho caching. >Second, most micro's have DOS's with this feature. Trsdos (EVERY version) >comes close (they miss only because they also keep a hash table which >simply hashes the name, resulting in a quicker 'not found'; delete this >and you get one read for filename, path walk, and everything. By putting >links in data blocks, you get one hit doesn't kill. Uh, EVERY version of TRaShDOS is STILL just one OS. CP/M (EVERY version :-), MS/DOS, os/9, os/1, Unix (EVERY version :-), Apple DOS, and MARC don't have robust file systems. Those with directory structures don't have one-read-per-element opens, because they (for the most part) stole the Unix design. I never worked with a TRSDOS system that had directories; how do they arrange for you to read the path with one read? Also, where do the put the information needed to recover from a hit on a directory block, and especially the block holding the root of the tree on that device? >>on the market require a reboot (that's what C-c on CP/M is - a warm >>boot!) to kill runaway tasks anyway. >> >THIS IS BAD! Even if it is true, that doesn't mean we have to stick wth it Yup, it's bad. It's what I said was the worst single problem with the Amiga. It's still MUCH better than most micro os's on the market, and THAT'S the market the Amiga is competing in. AmigaDOS is very useable as a single-user workstation OS. You'd have to be out of your mind to try running it in a multi-user environment. That's why it's not being sold to compete with Unix. Let's compare apples to apples, not oranges. Then again, maybe people comparing AmigaDOS to Unix should be taken as a good sign :-). >What about background jobs that are running? Better would be to say that >any single-tasking micro requires rebooting. In a market where people can get away with saying things like "DRI introduced multi-tasking to the micro market with Concurrent DOS", is there much difference? <mike
acs@amdahl.UUCP (Tony Sumrall) (12/12/86)
In article <3311@curly.ucla-cs.UCLA.EDU> ucla-cs!cepu!ucla-an!remsit!stb!michael@ihnp4.UUCP cc1@LOCUS.UCLA.EDU (Michael Gersten) writes: > In article <1740@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: > >The AmigaDOS "clean display" code has the virtue of preventing the > >interleaving of input and output characters in a single line. I also > > But it also STOPS output, and stops any program that is trying to do > output. This is what I dis-like; it effectively kills type-ahead. > It doesn't kill type-ahead for me...I just end my line with a CR and it gets queued up for the next read from the console. Not only that but, *because* of the "clean display" code, I don't have to try to figure out what it is that *I* typed in as opposed to what the *system* typed back at me. I'm like this feature a LOT. -- Tony Sumrall ...!{ihnp4,hplabs,seismo,sun}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
michael@stb.UUCP (Michael) (12/30/86)
In article <1910@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) writes: [discussion of '/' vs. '../'] My mistake; under 1.1 I had trouble using a '/' in the middle of a path specification to mean parent; under 1.2 there is no trouble. > might also note that, unlike the "." and ".." kludges in Unix (you > want to count the number of programs that KNEW that the first two > entries in a directory were "." and ".."? I know of none that knew the first two were that way, but a lot that knew that they were in there somewhere. I prefer it, but that may just be my background; it certainly is a nicer way of refering to the current directory > Of course, it might be worth pointing out that Unix has the same > "a-symmetry." At the beginning of the file name, it means "use the > root directory." Everywhere else it means "we've just finished a > directory name." Nonsense. In unix, all files have a complete specification relative to '/'; if you begin with '/', it uses that complete spec; otherwise, it prepends your current directory (which does begin with a '/') to make a complete path. [discussion of type-ahead, and console.device's clean-output type-ahead] > Huh? I type ahead all the time. No problem, you just have to type a > complete line. I also run "stty tostop" on Unix, which is even worse; > you have to wait for commands to complete before finding out that > there's output. But it's worth it; I LIKE not having garbage show up > in the middle of a line I'm typing. Matter of opinion; I don't like having programs block just because I'm typing a the same time. [discussion of directories, recovering from hits] > Obviously. It's a function of the redundancy in the directory > structure. Go look at the Xerox file systems for a good example of how > to do this kind of thing right; of course, they use mucho caching No, its redundancy in the FILE-system, not the directory-structure. > >Second, most micro's have DOS's with this feature. Trsdos (EVERY version) > >comes close (they miss only because they also keep a hash table which > > Uh, EVERY version of TRaShDOS is STILL just one OS. CP/M (EVERY > version :-), MS/DOS, os/9, os/1, Unix (EVERY version :-), Apple DOS, > and MARC don't have robust file systems. Those with directory > > I never worked with a TRSDOS system that had directories; how do they > arrange for you to read the path with one read? Also, where do the put > the information needed to recover from a hit on a directory block, and > especially the block holding the root of the tree on that device? Allow me to restate this. Every version of trs-dos, (thats actually 5 different O/S's or more--Model 1, model 1 version 2.7, model 3, model 2/12, vtos, Ldos, Newdos, probably others. The only thing they agree on is the address to call for file opens, close, reads, and writes. They don't agree on arguments or disk formats.) comes close. They don't have nested directories, but there are several unused bits that can be used for 'this is a directory'. All the information of where a file is located is stored in the 32 or 48 bytes of the directory (if thats not enough most of those will use another entry for extension entries). So, with one read you get 8 file names Whether or not it is a directory Where on the disk the data is stored Now, to be recoverable from a hit, just put next-block links into each sector, just like filesystem-handler. Add a pointer back to the directory entry that is for this file (again, like filesystem-handler.) Presto! Oh yea--the root of a directory is stored in the boot sector. If that goes, then you recognize the directories by their having a different DAM (data-address-mark) on the disk. If thats not enough, the default is track 17 for trs-dos, sector 170 for NeWDOS, clyinder 20 (?) for Ldos, etc, etc. NeWDOS and Ldos allow the user to change that. Trs-dos can be patched. Don't know about Vtos, DblDos, Dos-plus, etc. Michael -- Michael Gersten ihnp4!ucla-cs!cepu!ucla-an!remsit!stb!michael "But you can't go to war for not liking the same jokes" "Why not? It's as good a reason as any other"