Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool2.mu.edu!sdd.hp.com!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: <42350@nigel.ee.udel.edu> Date: 21 Jan 91 21:36:56 GMT References: <5337@auspex.auspex.com> <42014@nigel.ee.udel.edu> <5394@auspex.auspex.com> Sender: usenet@ee.udel.edu Organization: University of Delaware Lines: 71 Nntp-Posting-Host: estelle.ee.udel.edu In article <5394@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Or did you read me as saying that >I presumed that the line numbers in your files *were* just ordinal >numbers? Yes. Sorry. >I presume such systems exist, but I don't know how common they are. Sadly, not too common. Although I don't think keyed text files are the only reason to have keyed files, it was helpful at the time I was using them. My main thrust is not that I want keys on text files, but that I want keyed files, and if such files are implemented, it should be possible to use them for text files. This is not the case in UNIX, because even though I can implement keyed files, I cannot store text in them and expect tools to recognise it. >Lots of us don't really have the hardcopy problem as you >present it.... Lots of you never worked on a hardcopy-only terminal. Being able to go back three of four pages and look to see what you did is a great help. I could edit faster on 300 baud decwriters that I often can with modern editors. How much would you enjoy using *any* of the UNIX editors on a decwriter? EMACS, vi, ed, take your pick... >I guess that seems sufficiently like a sufficiently rare problem to me - >and probably to lots of other people, which may explain why I've never >run into any systems that maintain text files as keyed files. Sure there are always workarounds. However, I've seen EMACS users say how terrible vi is because it doesn't have this and that and thother. I'm saying UNIX doesn't have this and that and thother and you're saying "well, there is this great workaround called blah, and besides I've never needed it." I suspect that you *have* needed keyed record files and have reimplemented them every time you need them. For example, passwd must read the entire password file, *find the right record by key*, make the change, and write it back out again as an atomic operation, requiring extra locking files and all. With keyed files, one would simply read the record into memory, make the change, and write it back out again. No locking, no messy error-recovery files, no user-coded lookup mechanisms, no problems with large passwd files running you out of memory, etc. I recognise that this is kind of bogus in that passwd records usually don't change length and that passwd files are not large enough to run you out of memory, but the analogy is still good. Another file needing keyed records (where it was assumed from the start that it would need fast random access) is the terminal descriptions. Termcap (or is it terminfo?) uses file names inside directories as keys for one line of information. Why not have one keyed file with the terminal name as the key and the record holding the description? because UNIX does not support keyed files and it is easier to make them separate files. Actually, there are many programs that maintain text files as keyed files (via DBM), and the passwd file is often one of them. If it is such a rare problem, why have we seemed to have fixed it? I contend that it is because we have finally gotten to where we have systems large enough that simple bytestream text files are not good enough. This is the same reason we moved from HOSTS.TXT accessed via FTP to the DNS heirarchy. Unfortunately, every solution ends up being ad hoc, inefficient or buggy in some way, or incompatible with the old way of looking at files. I had hoped that at the base level, Plan-9 would have rethought this and chosen differently. I have no doubt that they rethought it, but I am a little suprised that they did not redo the lowest interface (as I understand it). -- 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 ... +=+=+=