Re: What would be a truly relational operating system ?
Date: Wed, 11 Nov 2009 05:39:51 GMT
Message-ID: <H6sKm.52356$PH1.25791_at_edtnps82>
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. 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.
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.
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! Received on Wed Nov 11 2009 - 06:39:51 CET