Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) Newsgroups: comp.sys.amiga Subject: Re: Initial Opinion of Amiga Message-ID: <1910@jade.BERKELEY.EDU> Date: Thu, 11-Dec-86 23:02:28 EST Article-I.D.: jade.1910 Posted: Thu Dec 11 23:02:28 1986 Date-Received: Sun, 14-Dec-86 19:24:40 EST References: <939@blia.BLI.COM> <3917@mit-eddie.MIT.EDU> <1317@hoptoad.uucp> <1740@jade.BERKELEY.EDU> <3311@curly.ucla-cs.UCLA.EDU> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) Organization: Missionaria Phonibalonica Lines: 88 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. 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?