Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!udel!ee.udel.edu From: new@ee.udel.edu (Darren New) Newsgroups: comp.os.misc Subject: Re: What constitutes a good OS? Message-ID: <41772@nigel.ee.udel.edu> Date: 15 Jan 91 20:14:31 GMT References: <5233@auspex.auspex.com> <41679@nigel.ee.udel.edu> <5258@auspex.auspex.com> Sender: usenet@ee.udel.edu Organization: University of Delaware Lines: 89 Nntp-Posting-Host: estelle.ee.udel.edu In article <5258@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >I.e., are you complaining about the fact that UNIX doesn't come standard >with an ISAM package (some vendors may actually provide one standard >with their UNIX releases, I dunno), or about the fact that UNIX doesn't >come standard with one *below user-mode*? 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. >>in spite of the fact that 99.44% of programs I've seen >>want records, and most want keyed records. > >Different people see different things; most of the programs I've seen >recently want lines or byte streams (not necessarily *character* >streams, just *byte* streams - and yes, I include compilers/assemblers >and linkers into the latter category). And lines are records, are they not? I think it is incorrect to state that compilers want byte streams. 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. Even C knows that things are records, because it gives error numbers in terms of lines. >>UNIX then seems to attempt to stuff every object that *isn't* a file >>into this same mode, and poorly at that. Plan-9 seems to be going the >>same way. > >Eh? To which objects are you referring? Many devices either fit the >byte-stream model, or the sort-of record model wherein each "write()" >writes one record/block and each "read()" reads one. 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. 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, and has all the same problems. The terminal is record oriented (unless you switch it to raw). The mouse is clearly record oriented, in that reading half a `record' tells you nothing. The paper I read indicated that IOCTLs are used to do bitblts to the window (if I remember right), and that isn't like a file either. >The same applies >to many network connection types. Well, on the network side, we have IP (record oriented). 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. >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. 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. >>They have put the windowing stuff neither in the kernel, where you >>would expect it to have to work to be commercially viable, >DEC, Sun, IBM, HP, etc. all seem to be commercially-viable companies >making products that use a window system implemented *not* in the >kernel of their systems, but in a user-mode process that accepts IPC >connections.... (You may not *like* X, but it seems to be "good enough" >for lots of people.) OH!!! I see why so many people misinterpreted what I meant! I mistyped!!! I meant to say "They have *to* put the windowing...", i.e., either it is in the kernel and works or it is not in the kernel. I meant to make the statement a conditional, not past tense. Sorry for the confusion! >>I suspect that the security features of the file systems are just as >>bad as on UNIX too; however, I have no evidence to that effect except >>that they have kept the rest of the uglynesses too. > >To what are you referring here? The lack of ACLs? Something else? Lack of ACLs; lack of file passwords; only two privledge levels (root and non-root); for non-privledged stuff (i.e., 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; lack of any good network security; etc. -- 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 ... +=+=+=