🚀 go-pugleaf

In article <28164@dog.ee.lbl.gov>, torek@horse.ee.lbl.gov (Chris Torek) writes:


|>This sort of thing---links via shared ideas that allow one to
|>understand part of a message, which then allows still further
|>understanding, and so on---is just what happened with the Rosetta
|>Stone.  Pre-Rosetta, trying to read Dead Sea Scrolls was something like
|>trying to read a structured file without any idea what the structure
|>was.  (I may have some details confused; I am not into archaeology.
|>But the idea is valid: you need to have some key to get started.)

Apart from the fact that the Dead Sea Scrolls are in Hebrew, some might possibly
be in Aramaic, both of which are living languages. The Rosseta stone was used to
decrypt heiroglyphs and was in hieroglyphic, greek and something else.


|>Of course, our computer systems are generally not as flexible as our
|>people, and our people have far more experience with various forms of
|>communication than do our machines.  So when we use a computer we
|>generally have to instruct it, in gory detail, as to just how we want
|>those 1s and 0s interpreted.  And here we reach the point where the
|>flamage occurs.  Some OSes provide an enormous collection of `standard
|>interpretations', and some provide only a few.  The VMS people insist
|>that it is better to have 16 built-in record formats; the UNIX people
|>insist that it is better to have none.
|>
|>Both are right, both are wrong; neither way is `better'.

Not true. UNIX was written in a great hurry and file type was something they
didn't want to bother with. To cover their tracks Thompson et al created a huge
wadge of waffle pretending that it was a deliberate optimization.

Try hooking up a HSC type device to UNIX and see where it gets you. Because
every application solves the file handling problem in a different way there is
no coherence. An O/S is an interface to the hardware. Just as sequential
languages like C/Fortran/etc limits the hardware you can exploit efficiently, a
limited O/S like UNIX is a handicap.


|>Let us suppose you want to, say, keep an inventory.  Under VMS, you can
|>choose a fixed block format with a particular record size, and store a
|>sequence of records: manufacturer, model, serial number, quantity on
|>hand, stock level, prices, date last ordered, date last sold, etc.  On
|>a UNIX system you have to package up the records yourself.  But this is
|>the easy part!  Managing a sequence of records is trivial.  The hard
|>work goes into deciding what data to keep, how to cross-index, what
|>operations to support, what kind of security to provide, and so forth,
|>and into developing tools for answering questions about the data
|>(`should we drop the Baby Spits Up doll?').  As far as I know, no OS
|>solves these problems directly (yet?). 

Because that is the next stage up in the hierarchy of abstraction. An O/S should
not be doing that sort of job. SQL is useful here of course. Perhaps one way
round the disaster of UNIX is to dedicate entire disk units to SQL databases.
Then you can let the database handle the I/O directly and optimize at that
level. Problem is that then you loose out on all the nice networking support
type ops.

|> One can buy canned solutions
|>for both VMS and UNIX systems, of course, but in that case the
|>underlying OS implementation is irrelevant; one can hardly argue that
|>having or lacking RMS is inherently superior just because FooBase sells
|>a system for VMS or UNIX (or both or neither).

Only if you don't care how fats the end product is. If you want speed you need
to be able to tune to the hardware. You do not want to do this at the package
level - you want a disk optimizer, the superior o/s here is the one that gives
most hints to the optimizer and allows it to do it's work best while requiring
the minimum amount of work on the part of the package to detect and adapt to the
hardware it is working on.

If you are content in running on the computer architecture of the early
seventies then UNIX may be sufficient for you. VMS allows you to use the
technology of the early eighties. There is nothing credible that allows you to
use massively parallel MIMD type architectures connected to intelligent
filestores in a sensible manner.

--

Phill Hallam-Baker