Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.os.misc Subject: Re: What constitutes a good OS? Message-ID: <5293@auspex.auspex.com> Date: 16 Jan 91 18:52:58 GMT References: <41679@nigel.ee.udel.edu> <5258@auspex.auspex.com> <41772@nigel.ee.udel.edu> Organization: Auspex Systems, Santa Clara Lines: 173 >Mainly that the programs that UNIX uses the most cannot depend on having >an ISAM package available. I.e., that the editors can't store line >numbers because the compilers won't use them. I.e., you're complaining that 1) UNIX doesn't come standard with an ISAM package and 2) that UNIX doesn't support stuff like "variable with fixed-length control" files with the "fixed-length control" used for line numbers. I have no great problem with the former complaint (I haven't needed an ISAM package for what I've done, but others do use it). I'm not sure what having line numbers built into the lines buys you, though. >And lines are records, are they not? They're also sequences of bytes terminated with some character or characters, on many systems. >I think it is incorrect to state that compilers want byte streams. I think it's incorrect to state that they want records, too; they want lines, and generally don't care whether the lines are defined as "a bunch of bytes with a (LF/CR-LF/CR) at the end" or "a byte count followed by the bytes of the line". >I think that compilers for languages which are not line-bound (C, >Pascal) want byte streams. I think that the shell, awk, make, SCCS, >assemblers, FORTRAN, BASIC all want lines. Lines, not records. >Even C knows that things are records, because it gives error numbers in >terms of lines. Lines, not records - and since: 1) UNIX text files don't have embedded line numbers and 2) nevertheless, UNIX C compilers give error numbers in terms of lines why do you want embedded line numbers? >But that isn't how it works, is it? If I write many small records to a >tape and then read back one big one, it won't work the same as if I do >it to a file on disk. No, it doesn't; indeed, programs that don't understand record boundaries can't always deal properly with tapes. However, programs that *do* understand tape blocks *can* deal with disk files as well as tapes; e.g., "tar" and "cpio" can maintain their archives directly on tape or on a disk file, which is quite useful (consider the number of FTP-able or UUCP-able packages archived as possibly-compress "tar" files). >The terminal, the mouse, and the windows are not >files. Sure, you can make an interface to them that looks like a file, >but that is the same thing as making records on top of keyed files, I don't think you meant that, unless "making records on top of keyed files" means something quite non-obvious. >and has all the same problems. The terminal is record oriented (unless you >switch it to raw). Yes, but I don't see why that's a problem. Programs that read and write text files can generally read and write the terminal as well. >The mouse is clearly record oriented, in that reading >half a `record' tells you nothing. Yes, but I'm not sure why this renders the fact that you access the mouse by opening "/dev/mouse" and doing "read()" calls from it at all bad. >The paper I read indicated that IOCTLs are used to do bitblts to the >window (if I remember right), Either you read a different paper, or don't remember right; the paper *I* read indicated that "...when a client process in a window *writes a message* (to the 'bitblt' file) to clear the screen, the window system clears only that window." >and that isn't like a file either. No, it isn't identical to a disk file in its behavior (one generally doesn't write messages to a disk file and expect it to do something), but: 1) it might make it possible to trace the window system actions being performed by your program by interposing something like "tee" between it and "/dev/bitblt"; 2) even if it doesn't look exactly like a disk file, the fact that it (or other kinds of objects) exists in the same *namespace* as files, and supports some subset of the same kinds of operations, can be useful if for no other reason that multiple kinds of these specialized objects behave similarly (e.g., the low-level screen bitblt code and the window-system bitblt-in-a-window code). Note that the key thing here isn't purely the file-like behavior; the notion that many types of objects inherit behavior from some common class is part of it. It may be that "file" isn't the right class, but.... >>The same applies >to many network connection types. > >Well, on the network side, we have IP (record oriented). Most programs don't talk raw IP. Some talk UDP, or SPP, or... (record oriented) and, as I noted, the "write() sends a single packet, read() reads one" model still holds. >On top of that, we put TCP to make it reliable. Many protocols I've seen put >records on top of TCP, because the behaviour is inherently record- >oriented. Which, of course, says nothing about the advantages of byte-stream-orientation vs. record-orientation in UNIX; the byte-stream-orientation vs. record-orientation is a characteristic of the protocol. Most programs don't >>Even "/proc" actually seems to fit >the file model pretty well. > >Say what?! It fits the name-space model OK, but the idea that >/proc/1406/status is a file containing an ASCII representation >of the CPU time used so far is nothing to do with a process being >a file. Yup, it's more that a process is a *directory*. :-) >I think that /dev/kmem is much more `file like' than >/proc is, but I don't think /dev/kmem is the way to go either. "/proc/1406/mem" is a file more like "/dev/kmem" (and, in S5R4 and, I think, the Research UNIXes that introduced "/proc", "/proc/" is a file containing the virtual memory of the process). >Lack of ACLs; lack of file passwords; Why are file passwords a good idea? I'm genuinely curious; what do they buy you that either 1) file encryption with a password or 2) some access control mechanism like file modes or ACLs doesn't? >for non-privledged stuff (i.e., setUID) I presume here you mean "i.e., not setUID". >lack of any good way to know that it is right and won't trash or >permit access to other files of the same account; Or perhas you mean "privileged stuff (i.e., setUID)"; i.e., if you write a set-UID program, there's no good way to verify that it's secure? Or you *did* mean non-privileged stuff, and the complaint is that you don't know that running some J. Random program won't trash *your* stuff? >lack of any good network security; etc. To what sort of network security are you referring here? Security problems with allowing network access to files without providing some network authentication scheme such as Kerberos or the "DES authentication" scheme in ONC RPC?