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!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks Date: Sat, 1 Jan 2005 13:53:48 +0100 Organization: cbb software GmbH Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net 0PSWzAwNw93DQMVmSe2FIQVsWZ12/XQVT/h9BAspQdiDYR7n0= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:7369 Date: 2005-01-01T13:53:48+01:00 List-Id: On Fri, 31 Dec 2004 11:24:40 -0500, Warren W. Gay VE3WWG wrote: > Dmitry A. Kazakov wrote: >> On Fri, 31 Dec 2004 06:30:51 -0500, Warren W. Gay VE3WWG wrote: >>>The kernel only needs to be able to provide "hooks". It is the >>>user land OS modules that neeed the networking, not the mk. This >>>discussion is basically a disagreement on "core functionality" >>>for the mk. I just don't see networking as being "core", IMO. >> >> But how could it become distributed? That "hook" should be there. > > The hook can forward message requests to a networking "module", which > is run outside of the mk. Yes, that is what I meant. >> An >> implementation could be a module, no problem, but all system objects, >> synchronization mechanisms, queues etc, should be designed in a way that >> would allow distributed behavior (no matter would it be local symmetric, in >> a cluster, random networking). This is what I would define as "true" >> networking. From this perspective neither Windows nor Unix are networking. > > There is an "application view" and a "microkernel view". I think you > are mixing the two. > > All of the infrastructure that you talk about is built outside of > the mk. The mk's purpose is to provide the basic needs for an OS, but > _not_ be the OS itself. In fact, using a mk approach, application and > OS modules conceptually run beside each other, perhaps only differing > in the privileges they have (ports that they have rights to). I agree in principle, but disagree in details, in what are these basic needs. I think that a kind of "protected object" should be provided already by the kernel as a building block. >>>This is a different problem (complexity). No amount of registry/ >>>database/repository design is going to change that for you. You >>>have complexity because of the applications -- not because of the >>>registry. At best, you might organize away some of the complexity, >>>but storage of registry values and the complexity of the same >>>are two different problem domains. >> >> Right, but if registry does not help much you to organize, and it does not, >> then it means that registry provides too low abstraction level. Technically >> it is the same level of abstraction as raw files. So you cannot get here >> much more support than from a file hierarchy. It only adds a bit type >> safety (one can query the type of a key). This means that registry is >> unsuitable to serve as an interface for any complex object persistence, as >> carrier, yes, as an interface no. > > Well, there are two general approaches to API development, that I > can think of: > > 1. Develop a general API to leave flexibility in the hands of the designer > 2. Develop a strict API to "straight-jacket" the users into a certain > set of "policies". > > I tend to shy away from #2, if there is no good reason for it. But in > either case, the user can choose to use it wisely or abuse it. It becomes > more difficult to abuse in #2, but abuse is usually always possible. > > The point I make is that software cannot organize things for you, unless > some person has worked it out for you ahead of time. That person can't > do that for my software, and I doubt he/she can for yours either. [ In general neither 1 nor 2 is right. When we know little and just start to explore a new field of computing, we always start with 1. Then we gather knowledge, get frustrated with "flexibility" of making errors and switch 2. That happens when we already know how-to. But having reached the stage 2, we find it possible to do things we could not approach before and so open a new field. Then again first 1, etc. ] The point is, it seems that with installation/properties/profile issue we have reached the stage when we could start to think about 2. > To date, the registry idea has gone further than the /etc/file approach, > and I have yet to see a better practical solution proposed. Of course I > would be glad to hear a better approach if one exists. ;-) > >>>My point is simply that programs (including installers), need a >>>programmatic way of testing what is installed etc. on a system. >> >> Yes, but I would formulate it in more general way: >> >> 1. object persistence (must be) >> 2. object containers. An application can be viewed as a container for its >> "mortal" instances and "immortal" persistent data. > > What does "object persistence" have more than a "set of values"? How > is an "object container" any different than a directory/subdirectories > containing "values"? The difference is that the above is untyped or weakly typed. An object is not just a value but also the methods to apply. This firstly would prevent abuses, and secondly, we could define somewhere an abstract interface to be implemented and so enforce proper behavior. >>>>Consider a simple diamond diagram. Application A >>>>uses B and C, they in turn use D. This cannot be represented by a tree. So >>>>you need a folder to keep them all. Let's name it "/etc". Welcome to back >>>>to chaos. >>> >>>I don't see any unsolvable problem here. Links and symlinks can >>>create any kind of network you need. >> >> Compare it with a network of pointers in C (memory~files, pointers~links). >> Not an unsolvable problem, right, but... > > But you have not proposed any solution. You keep saying that > "I don't want to be responsible", but there is nobody/nothing > left to fill that void. In OO the object is responsible to provide an implementation. A minimal kernel should give an ability to define some system object. A pair levels above there should be defined an abstract interface of application persistent data. Each application that possesses such data have to implement that interface etc. > Not everything manifests itself as a diamond (obviously). If a > hierarchy or "node network" doesn't satisfy your needs, then > I'd like to hear just what other structure can. You can't > just close your eyes and say "just make it happen". We don't > enjoy that luxury! 8-> Node network, relational data base, tree-like structure with links, all that are just implementations of an abstract interface of what a repository should provide. We will go no further if we will try to put the cart before the horse. First we must define the interface, its implementation is a minor problem. >>>All it becomes is just different terminology, but you'll still have >>>similar levels of abstraction (short-term memory vs long-term etc. >>>for example). >> >> Yes, but I do not want to expose it in API. It is comparable with evolution >> of programming languages: from assemble with clear distinction between >> registers and memory, modern languages which hide it. Caching should be >> OS's business, down with files and I/O! > > So you don't want an API, and yet you want it to happen somehow. No, I do not want to see Read_Block and Write_Block in API. Writing an Ada program, I do not see LDA, STR, MOV. They are still there, somewhere beneath in the Underwolrd, but I don't care. > Somehow, > some piece of software/hardware/system is supposed to know what pieces > of information are configurable elements, know how to organize it, > know how to identify it and share it in a safe way with other processes > and users on the same system/network? The answer is ADT. As long these pieces are just bytes, there will be nothing much better than Windows/UNIX. It is time to make a technological leap. > Well, its ok to consider these kinds of questions, but if you really expect > that to happen any time soon, I think you're more of a dreamer > than I! Yes I am. I also fully agree with Nick Roberts when he says that developing an OS is tightly related with the language. It is clear to me that Ada should be used for new OS developing. Purely theoretically it could be C, but practically the result will be null. Then even Ada is still unsuitable for this, as long as there is no great type unification, which would allow to develop user-defined protected objects, tasks, access types etc. This should become the basic gear to build OS types. I also cannot imagine any decent OO design of OS without MI, MD and interface inheritance from concrete objects. Alas there is no visible efforts in these directions. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de