🚀 go-pugleaf

In article <BzIG5M.GDo@pix.com>, stripes@pix.com (Josh Osborne) writes:

|>In article <1992Dec19.012355.26665@ll.mit.edu> ejon@ll.mit.edu (Eric Jones)
|>writes:
|>>In article <1gt111INNt3b@hpscit.sc.hp.com>, tim@computer.bri.hp.com (Tim
|>Phipps) writes:
|>>|> In a previous article Phil Hallam wrote:
|>>|> [...The OS kernal only supports sequential files...]
|>
|>[someone else said, no fseek means they are random access files... then: ]
|>
|>>But isn't that exactly his point?  Sure you can write an ISAM file 
|>>structure using fseek (and if you're REALLY smart, you might even
|>>write an efficient one), but then how's anyone else going to use
|>>your files?
|>
|>If you want others to access your files you make a lib that has functions
|>to access them.  For example: libdbm, libdbz, and libgdbm, and 4.4's libdb.
|>
|>This has many benifits, and many drawbacks.  Take it elsewhere to disscuss
|>it, it's gone far astray from comp.arch (assuming comp.arch is really
|>comp.arch.hardware, as the FAQ seems to imply).

But it is the paucity of software that prevents anything more novel than
floating point accelerators for standard Von Neumann machines gaining wide
acceptance.

If you want to discuss hardware, you cannot ignore the software aspect. Take the
above for instance. In RMS the filestore offers high level functionality. In
UNIX only low level functionality is offered. Now let us consider the
difficulties of producing an intelligent filestore:

VMS/RMS,
	Done years ago with the HSC. Nothing special about VMS here of course. ICL were
offering intelligent filestores that could do sorting years ago.

UNIX,
	Because the filestore knows only about the fopen, fseek, fread, fwrite and
fclose operations it is easy to interface to any sequential device. However when
the filestore receives an instruction it is only told *what* to do. There is no
clue as to *why* to do it. In this circumstance it is very difficult to do any
form of intelligent cacheing.


--

Phill Hallam-Baker