🚀 go-pugleaf

In article <BzIxqo.C90@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
>In article <BzIG5M.GDo@pix.com>, stripes@pix.com (Josh Osborne) writes:
[..."filetypes" in Unix should be done at the lib (user) level, but
this isn't a good comp.arch topic...]
>But it is the paucity of software that prevents anything more novel than
>floating point accelerators for standard Von Neumann machines gaining wide
>acceptance.

You forget bitblt'ers, and line drawers.

[I am word wraping the following text...]
>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.

The we need a way for user level code to tell the OS what file info is
important to cache, and what isn't.  Then you can be almost as efficent
as VMS/RMS (you will have extra context switch overhead for the extra
syscalls), but you will still be able to allow any user to create new
filetypes.
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall