What would be a truly relational operating system ?
Cimode
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:
> 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:
> Can current CPU architectures, RAM and disks adressing schemes sustain such model.
> What would be benefits ? The threats ?
Regards...
paul c
No answers, just some probably rambling comments. I think these are
really useful questions, maybe not for implementing a 'DBOS' but for
appreciating the few things that a dbms really needs to do. Even if one
thinks one knows them, they are easy to forget when one takes on a very
ambitious task - in the last few days even the language experts on the
TTM discussion list have gotten themselves tripped up over the
difference between recording a function invocation and a function value,
reminds me of the criticism I made here about confusing logical variable
names with attribute values. Ideally, chief among the 'few things'
would be figuring out how to make a typical physical machine look
declarative.
One perhaps tangential problem is that mainstream OS designers aren't
really into making coherent interfaces, let alone applying information
theory, even though some of them jabber about that. There is a huge
bio-feedback loop between the OS and HW designers and another one
between the HW and compiler designers. Each group looks at what the
other two did in the latest release and reacts to it. I guess there are
three big loops altogether. To a big extent they are isolated from the
rest of us, the loops create their own private logic. 'Good' marketeers
understand this and know that they are not necessarily selling what's
apropos rather what's available.
Years ago, I had to cope with an IBM mainframe OS called MVS (a
successor to the original 'OS/360' which many referred to as 'Obstacle
System/360'). The vendor documentation was extremely uncoordinated,
arcane, obtuse and never-ending. I thought the reasons were often
deliberate. I didn't learn to make my way around MVS until I found a
non-IBM book called 'Invitation to MVS'. This was a pretty short book
while at the time IBM was said to be the second-largest publisher in the
world, next to the USA government. It explained MVS in terms of the
relationships between its key storage structures but didn't do much good
since very few MVS users were aware of the book. But things have
changed and today the desktop OS's are more complicated than MVS ever
was (eg., it was designed to communicate with 'dumb' terminals and a
very small selection of devices).
There have been similar though much thicker books about Unix but today
it's ironic that even the Linux developers operate in just as adhoc a
fashion as the others who have various corporate baggage on their backs,
plus other insecurities. I guess part of the reason is that they have
some baggage too in the form of Unix compatibility so technique
impersonates real design. Of course the marketeers help confuse things
with their doubletalk, 'baggage' doesn't sound so bad when you call it
'legacy'. It all reminds me of how a genome researcher I knew explained
what he did: "It's a big race". In other words, nobody knows where
they're really going. The lack of consistent lingo, also what Edward de
Bono called 'porridge' words and the general decline in the ability to
read critically is also a big impediment (not just in IT, the recent USA
health-care debates show this - those against universal health care
scare their constituents with TV ads' that talk of unrestricted cost
increases, which is the basic problem with their private system in the
first place!)
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.
Around the time Codd was writing his first papers, IBM had a project
called 'Future System' which resulted in a scaled-down product called
the System/38. It was only packaged as a mini-computer because the
mainframe sales force was afraid a bigger one would cut into the large
system sales that had better margins and bigger maintenance dollars. It
had a linear address space, eg., you didn't have to cope with disk or
memory architecture, and an abstract machine language but copped out
with most of the same procedural application languages that the
mainframes used. At one time, I was unknowingly in charge of a
System/38 until one day the customer engineer showed up to look it over.
Took an hour to find the room it was locked-up in. It was actually a
development machine, but nothing ever went wrong with it! At the time,
this was unheard of, even among the mini makers of the day, Dec, Prime,
Data General and some others I forget. I think part of the reason was
not to do with hardware, it was hard for application developers to bring
things down. I remember working for a competitor where the doors were
locked, not to keep secrets in, but to keep certain IBM materials out,
for fear of lawsuits, but somebody sneaked some S/38 material in. The
reason I mention S/38 is that I think the designers of it were hip to
the idea of logical-physical separation even though IBM never tried to
sell that idea.
I'm probably an old-timer compared to most people in this group and
remember having to squeeze IO support that worked fine on a 128K cpu
into 16K. In those days IBM expected programmers to know and use disk
architecture, it was called 'channel programming'. The channel was a
mini-processor in its own right. Today even the software technocrats
miss the point - it's laughable to me how much horsepower gets spent on
off-base technique, eg., XML fans think the message is the medium,
failing to understand that the key ingredient is compatible database
definitions at the message ends, if they did then there would probably
be only three kinds of messages between db's, eg., insert, delete,
replace or maybe just assert and retract. Or maybe something totally
declarative. I've mentioned here before how I think if today's memory
space had been available thirty years ago, the database implementation
field might be much different today, eg., there might be very little
need for paging memory support in the typical OS that is concerned with
database. One little craziness is the segment registers of the early
Intel processors. At the time they were needed because of the small
word size. Now that consumer cpus' have gigabyte and larger word sizes
the OS people, eg., Windows, have hidden them from the application
layer. This is a shame, because they have obvious uses for a dbms that
can manage its own memory much better than an OS can. Meanwhile
Intel/Wintel regularly add machine instructions to optimize graphics and
multi-media.
The reason I mentioned messages has to do with implementation. Just for
argument's sake, assuming one wants a 'DBOS' that uses today's hardware,
the obvious bootstrap is to use existing hardware drivers, eg., to avoid
all the bootstrapping work that Linus Torvalds had to do. Most people I
know aren't aware that many drivers are proprietary, one of the
semi-secrets of Windows commercial success. If somebody wanted to make
a similar solitary effort, this might mean eschewing anything to do with
Windows which might in turn mean avoiding, for example, graphical
presentation functions so I'd think one really wants a very limited kind
of OS, which means depending on more general OS'es on separate
motherboards. Maybe paging support isn't needed, but I think the two
main breakthroughs needed would involve a relational translation
compiler and a database-to-database communication theory. The first
matters if dependence on today's baggage-laden, bio-feedback driven
cpus/motherboards/storage devices is to be avoided and the second
matters if one wants a single-purpose 'DBOS' platform. Back in the
1970's there was much inventiveness among the calculator manufacturers,
basically there were no taboos in a new field. Now there are market
taboosToday there are single purpose calculators, sometimes called
'personal organizer' or even cell-phone but they aren't what I would
call DBOS platforms because their programming interfaces are application
interfaces, not db interfaces.
But practically, if I wanted to make a DBOS, I think I would not start
with the hardware, rather something that already exists, such as the
physical layer of some relatively open-source dbms, maybe sqlite, maybe
a non-Java version of Berkeley DB, anything that has its own abstract
interface, but skip the sql layer. One interesting aspect of sqlite is
that its virtual machine opcodes are exposed, another is that it is part
of the Firefox package which might have some distribution advantages,
also maintenance advantages for a small-team or solo effort.
Well, I've rattled on too long but even at that have left lots out!
Casey Hawthorne
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
paul c
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.
Cimode
> Cimode wrote:
> > 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:
>
> >> 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:
> >> Can current CPU architectures, RAM and disks adressing schemes sustain such model.
> >> What would be benefits ? The threats ?
>
> > Regards...
>
> No answers, just some probably rambling comments. I think these are
> really useful questions, maybe not for implementing a 'DBOS' but for
> appreciating the few things that a dbms really needs to do.
seem to have an ability to intuitively guess the hidden intent.
Limiting the implementation realm of RM to table based presentations
is a clearly a limitation of its potential.
> Even if one
> thinks one knows them, they are easy to forget when one takes on a very
> ambitious task - in the last few days even the language experts on the
> TTM discussion list have gotten themselves tripped up over the
> difference between recording a function invocation and a function value,
> reminds me of the criticism I made here about confusing logical variable
> names with attribute values. Ideally, chief among the 'few things'
> would be figuring out how to make a typical physical machine look
> declarative.
Yes. And how to make the presentation layer more versatile. Both
come hand in hand.
> One perhaps tangential problem is that mainstream OS designers aren't
> really into making coherent interfaces, let alone applying information
> theory, even though some of them jabber about that. There is a huge
> bio-feedback loop between the OS and HW designers and another one
> between the HW and compiler designers. Each group looks at what the
> other two did in the latest release and reacts to it. I guess there are
> three big loops altogether. To a big extent they are isolated from the
> rest of us, the loops create their own private logic. 'Good' marketeers
> understand this and know that they are not necessarily selling what's
> apropos rather what's available.
Yes.
> Years ago, I had to cope with an IBM mainframe OS called MVS (a
> successor to the original 'OS/360' which many referred to as 'Obstacle
> System/360'). The vendor documentation was extremely uncoordinated,
> arcane, obtuse and never-ending. I thought the reasons were often
> deliberate. I didn't learn to make my way around MVS until I found a
> non-IBM book called 'Invitation to MVS'. This was a pretty short book
> while at the time IBM was said to be the second-largest publisher in the
> world, next to the USA government. It explained MVS in terms of the
> relationships between its key storage structures but didn't do much good
> since very few MVS users were aware of the book. But things have
> changed and today the desktop OS's are more complicated than MVS ever
> was (eg., it was designed to communicate with 'dumb' terminals and a
> very small selection of devices).
Yep. Good memories about JCL, object catalogs and IDCAM's come
back...
> There have been similar though much thicker books about Unix but today
> it's ironic that even the Linux developers operate in just as adhoc a
> fashion as the others who have various corporate baggage on their backs,
> plus other insecurities. I guess part of the reason is that they have
> some baggage too in the form of Unix compatibility so technique
> impersonates real design. Of course the marketeers help confuse things
> with their doubletalk, 'baggage' doesn't sound so bad when you call it
> 'legacy'. It all reminds me of how a genome researcher I knew explained
> what he did: "It's a big race". In other words, nobody knows where
> they're really going. The lack of consistent lingo, also what Edward de
> Bono called 'porridge' words and the general decline in the ability to
> read critically is also a big impediment (not just in IT, the recent USA
> health-care debates show this - those against universal health care
> scare their constituents with TV ads' that talk of unrestricted cost
> increases, which is the basic problem with their private system in the
> first place!)
Well it is a shame that OS designers are most conservative than
anybody.
> 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.
> Around the time Codd was writing his first papers, IBM had a project
> called 'Future System' which resulted in a scaled-down product called
> the System/38. It was only packaged as a mini-computer because the
> mainframe sales force was afraid a bigger one would cut into the large
> system sales that had better margins and bigger maintenance dollars. It
> had a linear address space, eg., you didn't have to cope with disk or
> memory architecture, and an abstract machine language but copped out
> with most of the same procedural application languages that the
> mainframes used. At one time, I was unknowingly in charge of a
> System/38 until one day the customer engineer showed up to look it over.
> Took an hour to find the room it was locked-up in. It was actually a
> development machine, but nothing ever went wrong with it! At the time,
> this was unheard of, even among the mini makers of the day, Dec, Prime,
> Data General and some others I forget. I think part of the reason was
> not to do with hardware, it was hard for application developers to bring
> things down. I remember working for a competitor where the doors were
> locked, not to keep secrets in, but to keep certain IBM materials out,
> for fear of lawsuits, but somebody sneaked some S/38 material in. The
> reason I mention S/38 is that I think the designers of it were hip to
> the idea of logical-physical separation even though IBM never tried to
> sell that idea.
I wish I had more material about S/38. Especially the math behind it.
> I'm probably an old-timer compared to most people in this group and
> remember having to squeeze IO support that worked fine on a 128K cpu
> into 16K. In those days IBM expected programmers to know and use disk
> architecture, it was called 'channel programming'. The channel was a
> mini-processor in its own right. Today even the software technocrats
> miss the point - it's laughable to me how much horsepower gets spent on
> off-base technique, eg., XML fans think the message is the medium,
> failing to understand that the key ingredient is compatible database
> definitions at the message ends, if they did then there would probably
> be only three kinds of messages between db's, eg., insert, delete,
> replace or maybe just assert and retract. Or maybe something totally
> declarative. I've mentioned here before how I think if today's memory
> space had been available thirty years ago, the database implementation
> field might be much different today, eg., there might be very little
> need for paging memory support in the typical OS that is concerned with
> database. One little craziness is the segment registers of the early
> Intel processors. At the time they were needed because of the small
> word size. Now that consumer cpus' have gigabyte and larger word sizes
> the OS people, eg., Windows, have hidden them from the application
> layer. This is a shame, because they have obvious uses for a dbms that
> can manage its own memory much better than an OS can. Meanwhile
> Intel/Wintel regularly add machine instructions to optimize graphics and
> multi-media.
Yes.
> The reason I mentioned messages has to do with implementation. Just for
> argument's sake, assuming one wants a 'DBOS' that uses today's hardware,
> the obvious bootstrap is to use existing hardware drivers, eg., to avoid
> all the bootstrapping work that Linus Torvalds had to do. Most people I
> know aren't aware that many drivers are proprietary, one of the
> semi-secrets of Windows commercial success. If somebody wanted to make
> a similar solitary effort, this might mean eschewing anything to do with
> Windows which might in turn mean avoiding, for example, graphical
> presentation functions so I'd think one really wants a very limited kind
> of OS, which means depending on more general OS'es on separate
> motherboards. Maybe paging support isn't needed, but I think the two
> main breakthroughs needed would involve a relational translation
> compiler and a database-to-database communication theory. The first
> matters if dependence on today's baggage-laden, bio-feedback driven ...
>
> plus de détails »
It is reasonnable to assume that not only a driver needs to be
developped but also a filesystem that represents the relation. As the
result of the last 10 years researchm I do have a promising filesystem
but I am studying the opportunity of building on the top of a driver
as opposed to the host OS.
Regards...
Cimode
> Are you talking about a truly relational file system?
> As opposed to a truly relational O/S.
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.
> 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.
> Regards,
> Casey
Cimode
natural habit.
Rob
>
> I never undesrtood the hierarchical obsession. It is like a bad
> natural habit.
>
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
paul c
>> 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).
Cimode
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
Cimode
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.
paul c
...
> 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.
Anne & Lynn Wheeler
> 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.
clone controllers were supposedly primary motivation for future system
project ... an extrodinary complex machine with complex instructions.
future system was targeted at completely replacing 360/370 and as
different from 360 as 360 had been different from prior computer
generations. future system was canceled w/o ever being announced
... some past posts
http://www.garlic.com/~lynn/submain.html#futuresys
Amdahl gave a talk in large MIT auditorium in the early 70s about
leaving ibm and starting his own clone processor company. he was asked
what justification he used with investors regarding his company. he
replied that that ibm mainframe customers had already invested $200B in
developing mainframe software ... and even if ibm were to completely
walk away from 360 (which might be construed as veiled reference to
future system project), that would be enough software to keep him in
business through the end of the century.
it has been claimed that the pre-occupation with future system (going to
completely replacing 360/370) allowed the 370 product pipeline to go
dray. with the demise of the future system effort, there was mad rush to
get products back into the 370 hardware and software pipeline. However,
the lack of 370 products is claimed to have contributed to allowing
clone processors (like amdahl's) to gain a foothold in the market.
I've also claimed that big motivation for John doing 801/risc was to go
in the opposite extreme from what was going on with future system. lots
of past posts mentioning 801, risc, iliad, romp, rios, power, power/pc,
etc http://www.garlic.com/~lynn/subtopic.html#801
this is old email mentioning the mip lisp machine group trying to get
801/risc chips
http://www.garlic.com/~lynn/2003e.html#email790711
for other drift ... this talks about shootout between QBE & system/r
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Shoot-ou.html
original relational/sql was done on vm370 ... and compare&swap was part
of the 370 instruction set. The discussion regarding compare&swap (in the
above) strayed a bit (& got the details wrong).
charlie had invented compare&swap instruction doing parallel, fine-grain
multiprocessor locking work on cp67 (360/67 virtual machine precursor to
vm370) at the science center ... misc. past posts mentioning the science
center (note compare&swap name was chosen because CAS are charlie's
initials)
http://www.garlic.com/~lynn/subtopic.html#545tech
initial attempts to get compare&swap into 370 architecture were
rebuffed. the favorite son operating system claiming that test&set
instruction was more than adequate for multiprocessor operation. the
challenge was that to get compare&swap instruction into 370
architecture, a non-multiprocessor specific use needed to be
created. Thus was born the example use for application use ... still
included in current principles of operation.
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/A.6?DT=20040504121320
since then many hardware architectures have implemented comapre&swap (or
very similar instructions) and have been widely adapted by multithreaded
applications (including most DBMS implementations) ... regardless of
whether running in single processor or multiprocessor environment. misc
past posts mentioning multiprocessor work and/or compare&swap
instruction
http://www.garlic.com/~lynn/subtopic.html#smp
misc. past posts mentioning original relational/sql implementation
http://www.garlic.com/~lynn/submain.html#systemr
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
paul c
Thanks, very interesting. Regarding C&S, I don't know that that has
anything to do with database logic per se, rather it's for serialization
in general. Regarding VM/CMS I used to know a guy who did a lot of work
on the sql/ds optimizer. I remember him scoffing in the early 1990's as
various improvements to the DB2 optimizer came out: "ha, sql/ds had that
five years ago!"
I still imagine that Gene Amdahl had a different vision of complex
instructions, ones that would be closer, in a sense, to applications. I
knew another guy who remembered the Amdahl processors being planned on a
whiteboard in Amdahl's office at IBM. But he lost control of his
company before he even went into production when IBM announced 'virtual
storage' he had to change his designs and needed Fujitsu money to keep
going. Ten years ago, at a ripe old age, he was still working full days
at one of his successor companies, if his secretary was at lunch, he'd
answer the 'phones himself.
paul c
> it has been claimed that the pre-occupation with future system (going to
> completely replacing 360/370) allowed the 370 product pipeline to go
> dray. with the demise of the future system effort, there was mad rush to
> get products back into the 370 hardware and software pipeline. However,
> the lack of 370 products is claimed to have contributed to allowing
> clone processors (like amdahl's) to gain a foothold in the market.
One of his long-time associates told me that a big part of the early
purpose was to build the then big expensive processors and peripherals
much cheaper by eliminating most micro-code then selling them for 10%
less than IBM which was a significant savings for customers and still a
nice mark-up for Amdahl.
Anne & Lynn Wheeler
paul c <toledob...@oohay.ac> writes:
> Thanks, very interesting. Regarding C&S, I don't know that that has
> anything to do with database logic per se, rather it's for
> serialization in general. Regarding VM/CMS I used to know a guy who
> did a lot of work on the sql/ds optimizer. I remember him scoffing in
> the early 1990's as various improvements to the DB2 optimizer came
> out: "ha, sql/ds had that five years ago!"
re:
http://www.garlic.com/~lynn/2009p.html#82 What would be a truly relational operating system ?
i handled some amount of the tech transfer from sjr (system/r) to
endicott for sql/ds
one of the people listed as being at jan92 meeting in ellison's
conference room ... mentioned here
http://www.garlic.com/~lynn/95.html#13
claimed to have handled the tech transfer from endicott back to STL for
(mainframe) DB2. There are two different DB2s ... the original mainframe
DB2 and the one running on other platforms. this is thread discussing
some recent news item about the non-mainframe DB2
http://www.garlic.com/~lynn/2009p.html#43 From The Annals of Release No Sfotware Before Its Time
http://www.garlic.com/~lynn/2009p.html#46 From The Annals of Release No Sfotware Before Its Time
the non-mainframe DB2 started out as RDBMS for OS2 ... it took quite a
bit of work to get much further than that.
http://www.garlic.com/~lynn/2009p.html#35 DB2 announces technology that trumps Oracle RAC and Exadata
Cimode
> paul c <toledobythe...@oohay.ac> writes:
> > 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.
>
> clone controllers were supposedly primary motivation for future system
> project ... an extrodinary complex machine with complex instructions.
> future system was targeted at completely replacing 360/370 and as
> different from 360 as 360 had been different from prior computer
> generations. future system was canceled w/o ever being announced
>
> Amdahl gave a talk in large MIT auditorium in the early 70s about
> leaving ibm and starting his own clone processor company. he was asked
> what justification he used with investors regarding his company. he
> replied that that ibm mainframe customers had already invested $200B in
> developing mainframe software ... and even if ibm were to completely
> walk away from 360 (which might be construed as veiled reference to
> future system project), that would be enough software to keep him in
> business through the end of the century.
>
> it has been claimed that the pre-occupation with future system (going to
> completely replacing 360/370) allowed the 370 product pipeline to go
> dray. with the demise of the future system effort, there was mad rush to
> get products back into the 370 hardware and software pipeline. However,
> the lack of 370 products is claimed to have contributed to allowing
> clone processors (like amdahl's) to gain a foothold in the market.
>
> I've also claimed that big motivation for John doing 801/risc was to go
> in the opposite extreme from what was going on with future system. lots
> of past posts mentioning 801, risc, iliad, romp, rios, power, power/pc,
>
> this is old email mentioning the mip lisp machine group trying to get
>
> for other drift ... this talks about shootout between QBE & system/rhttp://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Shoot-ou.html
>
> original relational/sql was done on vm370 ... and compare&swap was part
> of the 370 instruction set. The discussion regarding compare&swap (in the
> above) strayed a bit (& got the details wrong).
>
> charlie had invented compare&swap instruction doing parallel, fine-grain
> multiprocessor locking work on cp67 (360/67 virtual machine precursor to
> vm370) at the science center ... misc. past posts mentioning the science
> center (note compare&swap name was chosen because CAS are charlie's
>
> initial attempts to get compare&swap into 370 architecture were
> rebuffed. the favorite son operating system claiming that test&set
> instruction was more than adequate for multiprocessor operation. the
> challenge was that to get compare&swap instruction into 370
> architecture, a non-multiprocessor specific use needed to be
> created. Thus was born the example use for application use ... still
>
> since then many hardware architectures have implemented comapre&swap (or
> very similar instructions) and have been widely adapted by multithreaded
> applications (including most DBMS implementations) ... regardless of
> whether running in single processor or multiprocessor environment. misc
> past posts mentioning multiprocessor work and/or compare&swap
>
> misc. past posts mentioning original relational/sql implementationhttp://www.garlic.com/~lynn/submain.html#systemr
>
> --
> 40+yrs virtualization experience (since Jan68), online at home since Mar1970
Thank you for this.
paul c
>> plus de d�tails �
> It is reasonnable to assume that not only a driver needs to be
> developped but also a filesystem that represents the relation. As the
> result of the last 10 years researchm I do have a promising filesystem
> but I am studying the opportunity of building on the top of a driver
> as opposed to the host OS.
If I understand what you mean, I have to say that it would be a mug's
game to try that because you'd have to interface to the many arcane
aspects of the typical OS's internal interfaces. Maybe I have
mis-interpreted but if not, I'd say that it is more important to map to
various typical filesystem interfaces. I realize this is another layer,
but to me that's really the name of the game. One of the Xerox Parc
notables remarked something to do with recursion in programming concepts
being omni-present and I think similar is true of indirection.
Tonci Korsano
> Cimode wrote:
> > On 11 nov, 05:39, paul c <toledobythe...@oohay.ac> wrote:
> >> Cimode wrote:
> ...
> > It is reasonnable to assume that not only a driver needs to be
> > developped but also a filesystem that represents the relation. As the
> > result of the last 10 years researchm I do have a promising filesystem
> > but I am studying the opportunity of building on the top of a driver
> > as opposed to the host OS.
>
> If I understand what you mean, I have to say that it would be a mug's
> game to try that because you'd have to interface to the many arcane
> aspects of the typical OS's internal interfaces. Maybe I have
> mis-interpreted but if not, I'd say that it is more important to map to
> various typical filesystem interfaces. I realize this is another layer,
> but to me that's really the name of the game. One of the Xerox Parc
> notables remarked something to do with recursion in programming concepts
> being omni-present and I think similar is true of indirection.
This is an interesting idea.
I don't know about making an os really relational.
However, it can still be a databased oriented or driven os.
For example, registry from windows, configuration files, and other os
files, could be xml.
I really mean a xml database oriented and driven operating system.
Xml files can store encrypted or ciphered data without problems (this
data is most of the time passwords).
Xml databases can look like tree structures, so since current registry
is a tree structure, it can be made a xml database.
Part of my point is that a xml database oriented os can be queries
with current and future implementations of xpath, sqlxml, and other
xml query languages.
These queries are faster (sometimes) than parsing text files, binary
files, or querying relational databases.
In a way, it is like having all info about an os, plus its file
system, in xml databases.
It resembles having a hirerchical database in several points.
Still, making a file system of an os based on relational databases
(which still hold a lot of xml data), is a very interesting idea.
Best regards,
Tonci Korsano
"What you think doesn't matter! What matters is evidence..."