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-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> <52fBd.42256$nV.1324414@news20.bellglobal.com> <_gHBd.14666$0y4.10314@read1.cgocable.net> <8rz51zshvp8k$.gvir0kpiedzk.dlg@40tude.net> <1cza5d5x7snmd.lr7wfm9fdsvd.dlg@40tude.net> <1hwsfqc0hx63i$.1dl0hkengaf6i$.dlg@40tude.net> <1klgtuv6sbypt.1wlc9u1ixz7ua$.dlg@40tude.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 04 Jan 2005 12:44:07 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1104860577 198.96.223.163 (Tue, 04 Jan 2005 12:42:57 EST) NNTP-Posting-Date: Tue, 04 Jan 2005 12:42:57 EST Organization: Bell Sympatico Xref: g2news1.google.com comp.lang.ada:7432 Date: 2005-01-04T12:44:07-05:00 List-Id: Randy Brukardt wrote: > "Warren W. Gay VE3WWG" wrote in message >>>But in our hypothetical OS each possible way of access will be >>>represented >>>by some safe system object. These objects, when properly designed will >>>provide necessary administrative services. >> >>If you are a night watchman for a Mall, which situation makes it >>easier to sleep at night when you've locked up and gone home? >> >> 1. A mall with one or two doors on the outside to be >> locked and checked. >> 2. A mall with thousands of doors on the outside to be >> locked and checked. >> >>The answer is obvious. Sure, it is ok for other doors to exist >>inside the mall (for each store), which can be locked, but it >>only makes sense to choke the security at a minimal number >>of points. > > There are other requirements than security! Of course. Did I ever claim that this was the only requirement? > I think the fire dept. would be > pretty unhappy with (1) - at least if you ever let anybody in. Same holds > for OSes; you're going to need multiple ways to get things done; you can try > to minimize the number of "doors", but its unlikely that you can get down to > just one. Yes, practical issues prevail, but to use a different example, I doubt that banks would like the idea of buying vaults with more than one door. I was illustrating a "general principle", and I stand by it as a principle. Will there be exceptions to it? Probably and it depends on the specific problem you are solving. Exceptions are generally understood to exist when discussing general principles. > BTW, I think Dmitry's grand vision is on the right track. The tough part (as > always) is mapping that to something that still is practical. Exactly. We can all talk about grand visions until the cows come home, but that doesn't get us anywhere. I don't have a problem with "vision", but it needs to be discussed in the context of "how are we going to accomplish it?" Otherwise, it is a vision that will never be. > Why shouldn't > an Ada OS take advantage of Ada's features to provide persistence, > synchronization, and the like? I'm not against these basic needs, and certainly not against Ada, or Ada methods (this is the whole reason I embarked on this project). But Ada BTW, is where some of the work belongs (for example Ada.Streams). In the mean time, the project will have to at least consider alternatives if portability becomes one of the goals (I am not sure that it must be). > Sure, you'll have to go beyond that, too, but > why not start with Ada's fine features in this area? Randy, this is precisely the issue (going beyond that). How? No "how" is being offered in the present discussion. I am pretty open minded about things that make sense to do, provided that they _can_ be done (and provided that all of the extra work doesn't fall to me.) I can talk about a lot of pie-in-the-sky stuff too. But if we don't ever take it beyond that, it will just become another empty project on Source Forge. There are enough of those already. In fact, the "registry" issue always seems to bring out strong feelings. So I say, go off and SF a project to fix it the way _you_ want it to work. It need not require a new O/S to prototype So if someone wants to prove me wrong with a prototype - I welcome the event! As a side note, my little project will eventually be put up on SF, so that others can meddle with or otherwise contribute to it, if they want. But my suspicion is that a lot of hand waving will disappear when it comes to actually implementing something. ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg