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,UTF8 Path: g2news1.google.com!news3.google.com!news.glorb.com!meganewsservers.com!feeder2.on.meganewsservers.com!feed.cgocable.net!read2.cgocable.net.POSTED!53ab2750!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: Microkernels & Ada (Was for the AdaOS folks) References: <41d011b6$0$320$ba620e4c@news.skynet.be> In-Reply-To: <41d011b6$0$320$ba620e4c@news.skynet.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID: Date: Tue, 28 Dec 2004 01:19:16 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read2.cgocable.net 1104214694 24.150.168.167 (Tue, 28 Dec 2004 01:18:14 EST) NNTP-Posting-Date: Tue, 28 Dec 2004 01:18:14 EST Organization: Cogeco Cable Xref: g2news1.google.com comp.lang.ada:7240 Date: 2004-12-28T01:19:16-05:00 List-Id: Adrien Plisson wrote: > Wes Groleau wrote: > >> or anyone else with similar ambitions. >> >> Read "Kill the operating System" >> page 32 of September 2003 Technology Review >> >> Not a prescription, but something to think about. > > This is a nice article. I agree with an earlier post that there is a certain "troll factor" to this article. Maybe that is required from time to time to get people motivated enough to do something about it, or, for lack of action, to at least discuss it. > he could also go a LOT further: most people are running PCs, a computer > architecture dating from an old age of computing. did anyone thought of > a newer architecture ? I think people are working on new architectures, but perhaps not as actively as 10-20 years ago. I am finally relieved that some hardware support is going into CPU instruction sets to alleviate the buffer overrun problem. However, more needs to be done. I've recently developed an interest in microkernel design and have been reading much of the monolithic argument against microkernels etc. Much of the argument is of course in support of Linux's design, it seems, to justify their design approach. The last article I read where Linus Torvalds critisized microkernels was on the general grounds (paraphrased) that "they promised to be more portable, but cannot be..". He makes a point there, and I do see references to that in the orignal literature. But portability was never the entire point of microkernels. Others criticize microkernels on the performance issue. This point is harder to ignore, but I personally believe that this also will become an insignificant issue with time. Each year we see more powerfull CPU chips, and in a short period of time, it looks like we may soon have dual, quad and octo-core CPU chips. The efficiency factor becomes less important with these types of advances in hardware. The other side of the efficiency argument IMHO is this: if people gripe about the inefficiency of Mach, and then run Java desktops, then what are they griping about? Java is inefficient too, yet some people find a reason to run interpreted code, whether it be Java, Perl, TCL, Bash, Python or BASIC. So the point I want to make is that if microkernels lead to safer and better operating systems, then why do we shy away from it on efficiency grounds? Here is my last point on the efficiency of microkernel design: Because the O/S is running in a bunch of user-mode servers, all passing messages etc., in nice modular fashion, it obviously does suffer from a number of costly VM TLB flushes, to carry out a user service (each user context switch). What I'd like to suggest, is that it is time for hardware people to look at this problem and improve upon the TLB flush problem. For example, cannot a CPU carry more than one TLB set of resources, so that a total flush is not always required? If increasing amounts of cache is held on chip, why not set aside more resources for say 8 TLB register sets to help with microkernel user-mode context switches? You can bet on the fact that if everyone used a microkernel designed O/S today, Intel, AMD, IBM and others would be working hard to fix some of that "overhead" problem. The rest of the overhead may not be worth going after, but the big problems would get attention. I have recently started experimenting with Ada user mode modules on top of a microkernel (GNAT). I would like to see more projects like this in the future (I plan to share the project and encourage participation). So far, I have proved to myself that it can be done with GNAT and with open sourced tools. Perhaps someday, someone else will provide the microkernel itself in Ada, in Mach or L4 microkernel like terms (or something better). > the interresting thing is : we can all think about it, but we also ARE > ABLE TO DO IT. My time is limited, but what I feel I _can_ do, is get an O/S project started, using an _existing_ microkernel. I suggested as much this last summer. After a month or so, the idea bother me so much, that I had to try something. I firmly believe that others could do the same thing. The point is that more _research_ needs to be done on _SAFE_ and _SECURE_ operating systems. We have enough fully featured (M$) and fast (*NIX) systems, but I'd like to see a secure and rootless O/S for starters. Anyway, I'd like to see more O/S research that employed Ada, and to repeat myself, one way to do this is to start with a microkernel, and use Ada on top of it. > so where is the problem ? why do we still use those weird old computing > standards when we could have much much more ? Two problems, IMHO: 1. The user wants one interface, and programs need another (programs don't like fuzzy file name references etc., yet for users this can be very helpful). 2. People are often stuck on what they know (look at all of the C/C++-like languages that get invented every year). While POSIX is good for UNIX and portability, when starting a new O/S, I think you need to say "who cares about POSIX?" Work from the requirements back to the implementation. POSIX embodies a lot of good ideas, and I don't suggest that we want to be different without good reasons for it, but I think some fresh thinking would be welcome. > the answer is in the text: "Computing’s standard model owes its success > to the economics of the computer industry". people are investing in > development. they don't want to lose their investment, so they target > what is widely used: This wasn't true when UNIX was being initially developed. It need not be the case for a new design. The design just needs to solve a problem. For example, a secure O/S is needed for firewalls (hence my interest in a rootless O/S). It doesn't need to take the world by storm either. It took years before suddenly everyone realized they needed a *NIX server (thanks to the Internet & www). I am sure that other opportunities are in the wing. > so do investors never take any risk ? Take your savings and invest it, and then you'll know what they are thinking. Everyone has a limited tolerance for risk, especially when it is your investment dollar. But where there is risk, there is opportunity also, if for no other reason than nobody wants to go there. > yes they do. sometimes something really new, something revolutionnary > comes out. it exists for some time, then disappear (see BeOS). those > thing so not disappear because their ideas are bad, no. they disappear > because people don't want to change: they don't want to risk investing > in something new. they wait and see if it really is worth the > investment. so investors that invested in the develoment of the new > ideas don't get any return, the idea fails on the market, the investors > abandon the idea, the idea disappear. With the desktop, you may be right. But that is not the only frontier for an O/S. There are millions of appliances running operating systems, many of them Linux now. With a microkernel approach, it _is_ possible to run multiple environments at the same time (Linux, *BSD, & maybe even M$ win32). Look for new ways to allow the user to migrate. Try things, many things. > so how to change this ? how to get new ideas accepted by all ? this is > the real question to ask... Well, the last thing I'll say is that if nobody takes the risk to produce a new O/S, then no one will risk using it ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg