Re: What would be a truly relational operating system ?

Cimode wrote:
...
> Thanks...
> I came to think that the creation of a low level *relation extractor
> subsystem* would be the basic step to build a truly relational OS.
> The extractor would allow the following:
>

>> Organize metadata physically on disk according to an algorhythmics that minimizes the IO's required to transfer all necessary information into RAM necessary to rebuild the relation progressively
>> Based on already RAM loaded catalog information, Process the metadata on the fly to reconstitute a specific type of presentation (file, table, stream)
>> Physical independence would truly be implemented since only metadata is stored on disk and the file is only a relation representation.  One advantage would be that the same information could be used for various presentation.  Another one would be that the metadata *can* be compressed through a storage algorhythmics that is intervall based(one of the few credible discoveries about Transrelational Model) as opposed to direct image system general algoryhthmics.  In such perspective, it is highly likely that the main drawback would remain the physical adressing scheme of current memory chips.  On the other I don't see CPU as a big issue appart except for the caching part which'd require a particular buffering algorhythmics.

One ironic sense in which the cpu might be said to be not important has to do with how much it's delayed because today's capacious memory can't keep up, eg., ram speeds are usually less than a quarter of cpu speed. Granted, this was always the case but in olden days the much smaller memories were used mainly as a conduit between disk and cpu, today they replace disk as a programming medium (eg., suppose one has a ten-gigabyte db, how long does it take to read it into a 20 gigabyte memory at dbms startup time?). Some traditional performance bottlenecks have shifted and probably memory latency has become a bigger problem. A lateral reason why I fasten on this is that I smell yet another rat, yet another private logic excursion that influences against what people really need to do, eg., OS designers fall back on parallelism, the marketeers sell it and the rest of us start to forget the point, which I think in this case would demand physical storage representations that minimize latency.

I remember reading an Datamation interview of Gene Amdahl, long ago, must have been in the 1970's because that magazine was one of the few trade mags then. I still remember it because he was waxing on about his 1950's designs and what came to be called complex instruction sets. He was regretting that there was little industry enthusiasm for even more complex instructions, I got the impression that he had felt he was barely scratching the surface with ones such as 'edit and mark' or 'translate and test'. If I had to pick just one target for applying complex instructions, that would be something like the D&D A-algebra. (This wouldn't prevent parallelism under the covers.) Unlike most of us Gene Amdahl is able to visualize approaches that are contrary to what's already been built.

When Date first promoted it, the Trans-relational model seemed intriguing but I think it's useful to compare it with the 'image-based' stores that is criticized by the big names (who I admire for other reasons, nobody can be right all the time). I'm not convinced that all-round performance might not be the same if the tr-model structures weren't replace by an 'image-store' with nearly one index for every attribute. Still, neither approach avoids the need for compound sorts - even though Codd's model says nothing about those, I think consistent presentation ordering is at least as important as the various graphical techniques.

Apparently my opinion can't be disproved except on paper, because of patent problems we aren't likely to see implementations any time soon. Seems that even David McGoveran has patented a 'view update' mechanism!   I hope that McGoveran did that simply to prevent the corporations from profitting by it but in any case I found unnecessarily elaborate and nearly impossible to understand. Couldn't help but contrast it with other patents from a hundred years ago. It's amazing how authors are able to stick to essentials when the diagrams are hand-drawn and notarized. Received on Fri Nov 13 2009 - 23:03:50 CET