Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <5427@auspex.auspex.com>
Date: 22 Jan 91 19:09:10 GMT
References: <42128@nigel.ee.udel.edu> <5392@auspex.auspex.com> <42346@nigel.ee.udel.edu>
Organization: Auspex Systems, Santa Clara
Lines: 107

>Edit (under CP-V) would simply bop you out of insert mode if you
>tried to insert something between 1736.165 and 1736.166.

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"?

Even if it's rare that a file has to be renumbered, because the editor
works hard at trying to keep the space of line numbers sparse, I'd
rather not have to do that *at all* - 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.

>>I've never seen a system that uses records, by that definition, as
>>lines, nor any that use line numbers as keys.  I presume you have.
>
>Yes, CP-V and CP6 both have such file types.  Makes life much easier,
>believe me.

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.)

>It wasn't a problem because the editor could read unkeyed files and put
>keys on if you wanted.

Arbitrary keys - in which case, how do you tell it where to get the
keys? - or line numbers?

>More important, you rarely actually edited files that were generated in
>such a way as to require keys; that is, the files that were generated
>consecutively were not often modified randomly, and when they were you
>just had to put on the keys.  Since the keys had no significance to the
>contents, the lack of good initial keys was not a problem in practice.

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.)

>I can see where putting the "correct" keys on might be useful. For example,
>the Pascal compiler could put error messages in a specially-flagged comment:
>    {%%% Error 104: Undefined variable}
>and key it in such a way that the error message could be merged into
>the source at the correct place. The special tag could make the errors
>easy to delete. The compiler could check to see if the error message is
>already there in the source and not generate it again if it is.

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.

>The reason I claim that the question is unfair is that there is no need
>for the UNIX-like programs to put stuff in the resource fork. What goes
>in the resource fork is Mac-specific, and UNIX ports don't use
>Mac-specific stuff.  The tools that make the Mac useful either put the
>correct stuff into the resource fork because that is their job (like a
>font installer) or they don't need to change the resource fork at all
>(like a text editor).  What makes the resource fork useful is that
>things there can be changed after the application is compiled, new
>items can be added that are never looked at by the originating
>application, and so on.

Sounds similar to the OS/2 HPFS notion of a bag of name/attribute pairs
hung from a file; some people are looking at adding this to some UNIX
file systems (I think the UNIX International file system group is).

>>Again, this sounds like a case where providing a "stream of lines"
>>read interface to a structured file is easy, but providing a "stream of
>>lines" write interface to a structured file isn't so easy.
>
>Correct. Specifically, the Mac stores text like UNIX does, so the
>"stream of lines" is the same on both. However, if I'm not speaking
>English, I can modify all the Mac menus to be written in (say) German.
>This is because I can change the menus in the resource fork, making
>them different sizes and in different places, and not screw up anything
>else.

With what file is, say, the resource that specifies menus associated? 

>Again, CP-V and (I understand) CP6 would allow you to even write
>keyed files to a tape, allowing you to access them exactly as if
>they were on a disk, random access and all, except that you
>could not write them.

I suspect that in most cases you wouldn't *want* to access them
randomly; tapes aren't known for their speed of random access....
(In the UNIX world, and I suspect in lots of other OSes, tapes are
generally used as archival, backup, and file transfer media.)