Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!ucbvax!jade!eris!mwm From: mwm@eris.UUCP Newsgroups: comp.sys.amiga Subject: Re: Initial Opinion of Amiga Message-ID: <1740@jade.BERKELEY.EDU> Date: Fri, 21-Nov-86 07:50:53 EST Article-I.D.: jade.1740 Posted: Fri Nov 21 07:50:53 1986 Date-Received: Sun, 23-Nov-86 03:25:10 EST References: <939@blia.BLI.COM> <3917@mit-eddie.MIT.EDU> <1317@hoptoad.uucp> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) Organization: Missionaria Phonibalonica Lines: 131 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 :-)