Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!paperboy!think.com!samsung!rex!uflorida!gatech!udel!ee.udel.edu From: new@ee.udel.edu (Darren New) Newsgroups: comp.os.misc Subject: Re: What constitutes a good OS? Message-ID: <42488@nigel.ee.udel.edu> Date: 22 Jan 91 21:12:01 GMT References: <5392@auspex.auspex.com> <42346@nigel.ee.udel.edu> <5427@auspex.auspex.com> Sender: usenet@ee.udel.edu Organization: University of Delaware Lines: 133 Nntp-Posting-Host: estelle.ee.udel.edu In article <5427@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Oh, that's *real* swell. Is there no way I can say "dammit, I NEED to >have a line inserted between these two lines, no arguments from you, Mr. >Editor?" Do I have to renumber the file (and invalidate all those >line-numbered listings that CP-V/CP6 people seem to be finding so >useful"? You could just renumber the lines in the immediate area. You're changing that area anyway. In practice, I never needed it, as I never inserted 1000 lines of changes in the same place before making a new listing. >I like editors where inserting >text is simply a matter of pointing and typing; I don't like to have to >think about what I have to do to insert text. But with my proposed file system, we could *both* have our way. For the same reason you probably would not want to do without regular expression searches, I don't want to do without line numbers. "I don't like to think about what I have to do to" find text. >Uh, if I can't insert something between two lines in the fashion you >describe, that would seem to make life harder, not easier.... (And >support for keeping line-numbered listings might make your life easier, >but not mine.) Why would it make your life harder? If it doesn't, why would you deny it of me? It is less a restriction than saying "you can't have file names longer that 255 characters." It comes up so rarely in practice that you just never think about how to get around it in advance. You *can* insert something between those two lines. You just have to renumber some of them. It is less a restriction than under UNIX saying "I can't insert a newline in the middle of a text line without getting two lines." It is about the same level of problem as saying "dammit, why do I need to run ctags every time I insert a new function into a file?" >Arbitrary keys - in which case, how do you tell it where to get the >keys? - or line numbers? It just uses the defaults. Why is this a problem? You are saying "mixing keyed files with unkeyed files is no good, because adding keys to files that don't need keys does not add any information." >In other words, keyed files don't solve the "/etc/passwd" problem >magically, in the sense that either: > > 1) "/etc/passwd" would be editable as a text file, but wouldn't > have keys; > > 2) "/etc/passwd" would have keys, but wouldn't be editable as a > text file; > > 3) "/etc/passwd" would be editable as a text file, would have > keys in some sense, but you'd have to do something special to > generate the keys (the 4.3BSD solution). > >(Note to those who would say that 2), say, is a solution: I didn't say >it wasn't, I just said it wasn't a "magical" solution. I.e., if UNIX >had native keyed files, and allowed you to read them as text files, it >would still have to have chosen some implementation technique for the >password database other than implementing it as a plain text file in >order to give it keys.) Sure. But I contend that that program to do either 2) or 3) with keyed files is easier than the program to do either 2) or 3) without keyed files. I'm not insisting that you give up bytestream files, you know. (If you really want to know, the passwd file was edited by a special editor, so it falls under category 2. However, that editor did quite a few integrity checks that you don't get with the UNIX passwd editor :0) >I'd rather have the error messages show up in another file, or in >another window, perhaps with a way to jump to the point at which the >error occurred (e.g., the compile mode some EMACSes support. And you could do that. It takes a special command to merge in the error messages from a separate file. I do it my way, and you do it your way. What's the problem? >With what file is, say, the resource that specifies menus associated? The menus specific to the application are in the application's code. On the Mac, other menus are required to be read out of other files and manually inserted, due to the way the menus selections are indicated to the application (ordinally rather than by keyword). A better example (because of the way menus are handled on the Mac) is "what file are the font resources associated with?" Fonts that are available to every program are in the "system" file (vmunix equivalent). Fonts that are available only within the specific application are in the application's executable file. Fonts that are available only within a particular document (say, that has been sent from somebody else (who knows you don't have that font) to you) are in the resource fork of that document. The "resource editor" can move resources from applications to system files and so on. When the application looks for a font, the system looks through a stack of files that normally contains document<-application<-system for the first resource matching the request. Other files (for example, a specific font file) can be inserted into this chain. Another example: the window border is drawn by a WIND resource (or something like that). If you want a particular application to have a different-looking window, simply replace the WIND resource in that application file and it will override the one found in the system file. >I suspect that in most cases you wouldn't *want* to access them >randomly; tapes aren't known for their speed of random access.... True. But again, you are making a pointless restriction. Usually, I don't want to access the passwd file sequentially. However, that was the only way to do it for quite some time. By making tapes randomly accessible, you make it possible for programs to work on tapes just like they work on disks. For example, the archiver (ar, tar, whatever) stored files by adding keys or prefixing keys (depending on the original file). Hence, just as tar can read from either a disk file or a tape, the CP-V archiver could read from either a disk or a tape. Primarily this capability was there so that system utilities (dump, quotas, etc) did not have to bypass the filesystem to do their work. Most of your objections seem to be of the form "Well, I don't work that way, and here is how to get around the problem of which you speak." I'm not trying to make you work my way. I'm just pointing out that there are other possibilities. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=