From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3cd3b8571c28b75f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-01 09:29:07 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: aek@vib.usr.pu.ru (Alexander Kopilovitch) Newsgroups: comp.lang.ada Subject: Re: A Customer's Request For Open Source Software Date: 1 Sep 2003 09:29:06 -0700 Organization: http://groups.google.com/ Message-ID: References: <3F44BC65.4020203@noplace.com><20030822005323.2ff66948.david@realityrift.com> <3F4828D9.8050700@attbi.com> <3F4EA616.30607@attbi.com> <3F512BD1.8010402@attbi.com> <3F52AA5F.8080607@attbi.com> NNTP-Posting-Host: 62.152.65.111 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1062433747 26330 127.0.0.1 (1 Sep 2003 16:29:07 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 1 Sep 2003 16:29:07 GMT Xref: archiver1.google.com comp.lang.ada:42037 Date: 2003-09-01T16:29:07+00:00 List-Id: Robert I. Eachus wrote: > It is a resource issue. It would be nice to have a son of Multics > implementation in Ada, but the cost of doing that for any real platform > is prohibitive. I think the last time I seriously looked, Multics ran > to over 20 million lines of (almost all PL/I) source code. That does > include the compilers, mail system, emacs, relational data base, etc., > but it gives you some idea how large the Multics environment was. Well, this is understandable. But I guess that there may be non-conventional ways to get something like that. One way, which I imagine, largely avoids that "prohibitive cost" (although it still may be considered as a sort of a plot for an episode of the serial "Wild Investor" -:) : take existing open source OS - FreeBSD is, perhaps, the best candidate - and start to replace its layers from the ground, that is, from the kernel, following the Multics design, and making necessary bridges (between lower Multics-layers and upper FreeBSD layers) at each stage, thus maintaining functionality but not too worrying about effectiveness. > On the other hand most RDBMSs have options for bypassing the file system > and managing disk storage directly. With a large amount of NVRAM, their > is no need for the file system at all. So my feeling is that the way to > get something to market at the right time is to concentrate on products > that can take full advantage of large (and non-volitile) addressable > memories. Well, I have vague only feeling about current state of RDBMSs, and it is not clear for me whether people in that area will see that as major improvement (for what I constantly hear, their main practical problem regarding efficiency is just right index structure). But I have a friend who is an active professional in this area, both at academic side and at practical side, and I'm going to ask for his opinion on this matter (but it may take about 2 weeks, because just now he is busy at a DBMS conference in Germany -;) ... if his opinion will be positive then, perhaps, some of his Ph.D. students will become interested in such a project -:) . Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia