What would be a truly relational operating system ?

#1

The current hypes about operating systems (Windows, Unix, Mac OS
Linux) gave to think about how RM main principles could be implemented
to extend the possibility of having a TRDBMS being implemented at a
lower physical layer (I mean on current disks, RAM, and CPU
architectures). That said, I am curious onto which prerequisites
should be respected on a lower level to respect independence between
the data layer and the physical layer when thinking of an operating
systel that would manage the relationship between thethe two layers.
I came up with the following ideas I would glad to exchange upon:

Quote:

The operating system should be IO relation-aware (for a lack of a better word) meaning that it should implement a physical storage mechanism that minimizes the number of logical operations required to represent a in memory relation and relation operation logical .
The operating system should not be a direct image system, meaning that all information(files, file groups) should only be a result of a logical relation operation at runtime. As a consequence, the information can not be physically stored on an as-is basis. In other words, a traditional file would be a relation that would not exists before user interpretates it.
The mechanism by which a file would be represented at runtime would be as a particular case of presentation of a relation, the same way an RTable could be one presentation.

Here are few ideas that came up but it brings other questions:

Quote:

Can current CPU architectures, RAM and disks adressing schemes sustain such model.
What would be benefits ? The threats ?

Regards...

#2

Are you talking about a truly relational file system?
As opposed to a truly relational O/S.
The O/S knows where it's data structures are and what they are used
for, so I don't see the advantage of the overhead of a RDBMS for O/S
files.
Although, the Windows registry could benefit from having an RDBMS
version copy of itself, since it would be easier to do ad-hoc queries
on this important structure.
--
Regards,
Casey

#3

Casey Hawthorne wrote:

Quote:

Are you talking about a truly relational file system?
As opposed to a truly relational O/S.
The O/S knows where it's data structures are and what they are used
for, so I don't see the advantage of the overhead of a RDBMS for O/S
files.
Although, the Windows registry could benefit from having an RDBMS
version copy of itself, since it would be easier to do ad-hoc queries
on this important structure.
--
Regards,
Casey

Since the first Windows NT, I've scratched my head over what could
possibly have been the motivation behind making that registry a tree.
If it had come from unpaid amateur volunteers maybe I wouldn't, but it
didn't. No comment about the functionality but I'm very suspicious
about its overhead. I'd be grateful if anybody could point to a design
rationale.

#4

On 11 nov, 23:42, Casey Hawthorne <caseyhHAMMER_T... (AT) istar (DOT) ca> wrote:

Quote:

Are you talking about a truly relational file system?
As opposed to a truly relational O/S.
A truly relational O/S would require a truly relational file system

since current filesystems are primarily designed for direct image
systems.
Building a relational OS on the top of a direct image file system woul
dbe equivalent to building a ferrari with a poor man's car wheels.
The filesystem and the storage mechanism would have to be specifically
though to minimize IO operations into representing a file as a
relation presentation. The role of the relational filesystem would be
that representation.

Quote:

The O/S knows where it's data structures are and what they are used
for, so I don't see the advantage of the overhead of a RDBMS for O/S
files.
Although, the Windows registry could benefit from having an RDBMS
version copy of itself, since it would be easier to do ad-hoc queries
on this important structure.
Why should we only limit a relational OS to querying. Once every

element is a relation representation
, the possibilities are endless.

Quote:

Regards,
Casey

#5

On 12 nov, 00:38, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

Quote:

Casey Hawthorne wrote:
Are you talking about a truly relational file system?
As opposed to a truly relational O/S.
The O/S knows where it's data structures are and what they are used
for, so I don't see the advantage of the overhead of a RDBMS for O/S
files.
Although, the Windows registry could benefit from having an RDBMS
version copy of itself, since it would be easier to do ad-hoc queries
on this important structure.
--
Regards,
Casey

Since the first Windows NT, I've scratched my head over what could
possibly have been the motivation behind making that registry a tree.
If it had come from unpaid amateur volunteers maybe I wouldn't, but it
didn't. *No comment about the functionality but I'm very suspicious
about its overhead. *I'd be grateful if anybody could point to a design
rationale.
I never undesrtood the hierarchical obsession. It is like a bad

natural habit.

#6

On Nov 12, 12:54*pm, Cimode <cim... (AT) hotmail (DOT) com> wrote:

Quote:

I never undesrtood the hierarchical obsession. *It is like a bad
natural habit.

A person of your obvious intelligence and proficiency in

matters relational has no problem interacting with databases.

That is fine for you, but for the vast majority of people (not just
IT people), database interaction will be impossible without
a level-appropriate interface, preferably graphical.

I've never seen a non-proprietary graphical database interface
for RDBs that was not basically textual. I know there are
database experts in cdt who will disagree with me on this,
but I believe that the common man understands hierarchical
intuitively, whereas tabular/textual interfaces are incomprehensible
when the amount of data that can be displayed textually
exceeds the size of the screen. Graphical representation
of hierarchies using color, size, shape, icons and action
are so much more compact.

If you extrapolate backwards from what I say to "we should
go back to hierarchical DBMSs," you are wrong. What I want
to see are hierarchical interfaces to RDBMSs.

Hit me!

Rob

#7

Cimode wrote:

Quote:

On 11 nov, 05:39, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
....
There have been a few embedded special-purpose OS's that had minimal
(ie., only the essential) logical and coherent programmer interfaces.
If I had to give the main design goal of an OS, that is it. But there
is a big difference between an interface to hardware and an interface to
a logical machine. Probably none of today's mainsteam OS's could adapt.
Unix originally had what Fred Brooks called 'conceptual integrity' or
suchlike with its file-stream metaphor but like the others you mention,
it certainly doesn't have any comprehensive foundation theory akin to
relational algebra and the emphasis remains physical, with lots of
physical device library functions, each expressed in terms of the
device's characteristics or the underlying machine language. In theory,
such a base, if it existed, would offer similar advantages to a
relational dbms, tight definition, logical rules for manipulation and
therefore prediction and correctness proof.
Could you give me some pointers. As far as I know, logical storage
mechanisms were never designed with the purpose of reducing runtime
declarative representation of relations. IN order words ra never made
it into storage physical data retrieval.
...

I didn't mean to suggest otherwise. There was a snow-flurry of them and
various special OS extensions in the 1980's. Didn't have much to do
with them and can't remember the names, although I recall one of the
special-purpose languages for one of them was Forth, something from
Xerox Parc too. This was before it was clear that the Intel instruction
sets would dominate, even before MicroSoft started selling mice (about
the same time as Prolog was being criticized for not being able to
update a database).

#8

On 13 nov, 16:09, Rob <rmpsf... (AT) gmail (DOT) com> wrote:

Quote:

On Nov 12, 12:54*pm, Cimode <cim... (AT) hotmail (DOT) com> wrote:

I never undesrtood the hierarchical obsession. *It is like a bad
natural habit.

A person of your obvious intelligence and proficiency in
matters relational has no problem interacting with databases.

That is fine for you, but for the vast majority of people (not just
IT people), database interaction will be impossible without
a level-appropriate interface, preferably graphical.

I've never seen a non-proprietary graphical database interface
for RDBs that was not basically textual. I know there are
database experts in cdt who will disagree with me on this,
but I believe that the common man understands hierarchical
intuitively, whereas tabular/textual interfaces are incomprehensible
when the amount of data that can be displayed textually
exceeds the size of the screen. Graphical representation
of hierarchies using color, size, shape, icons and action
are so much more compact.

If you extrapolate backwards from what I say to "we should
go back to hierarchical DBMSs," you are wrong. What I want
to see are hierarchical interfaces to RDBMSs.

Hit me!
No time. Databases and RM have nothing to say about user interfaces:

they are in separate layers. If you ask me, I am not convinced either
that hierachical displays are a good way to display or even
navigate.
Say GOOGLE

))

> Rob

#9

On 13 nov, 16:56, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

Quote:

Cimode wrote:
On 11 nov, 05:39, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
...
There have been a few embedded special-purpose OS's that had minimal
(ie., only the essential) logical and coherent programmer interfaces.
If I had to give the main design goal of an OS, that is it. *But there
is a big difference between an interface to hardware and an interface to
a logical machine. Probably none of today's mainsteam OS's could adapt..
* Unix originally had what Fred Brooks called 'conceptual integrity'or
suchlike with its file-stream metaphor but like the others you mention,
it certainly doesn't have any comprehensive foundation theory akin to
relational algebra and the emphasis remains physical, with lots of
physical device library functions, each expressed in terms of the
device's characteristics or the underlying machine language. *In theory,
such a base, if it existed, would offer similar advantages to a
relational dbms, tight definition, logical rules for manipulation and
therefore prediction and correctness proof.
Could you give me some pointers. *As far as I know, logical storage
mechanisms were never designed with the purpose of reducing runtime
declarative representation of relations. IN order words ra never made
it into storage physical data retrieval.
...

I didn't mean to suggest otherwise. *There was a snow-flurry of them and
various special OS extensions in the 1980's. *Didn't have much to do
with them and can't remember the names, although I recall one of the
special-purpose languages for one of them was Forth, something from
Xerox Parc too. *This was before it was clear that the Intel instruction
sets would dominate, even before MicroSoft started selling mice (about
the same time as Prolog was being criticized for not being able to
update a database).

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:

Quote:

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.

#10

Cimode wrote:
....

Quote:

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.