People might be interested in Ada OS but most do not want to spend the time to build an Ada OS or convert an existing dead one. Now in saying this you can see this in the following project. Just expand this concept into the world of an OS. You can see that an Ada OS will never get done other than the projects that are in the works today. And they kind of limit the Ada OS to the kernel only based on a Posix interface. The example is the "c2Ada" project. Which is now hosted by sourceforge. Simonjwright with help from jcream unzip the last 2007 Linux based file and placed the source files into SVN tree area. Why? If they were into Ada like they suggest they are. They would have: 1. Placed the original zip file into the download area stating that this was the original code and is stored for archiving purposes only. 2. Documenting the following steps ( 3 .. 5 ). 3. Compile the program. 4. Using the c2Ada to convert the original "c2ada" C code to a standard Ada 95 code. 5. Editing the 20% of the code that the program bypasses. 6. Placing this new "ADA ONLY" version into the SVN tree as well as an archived version in the downloading area. 7. Insert the documented transition (from step 2) into the web site. Time Table: A couple of weekends. Basically while watching TV on Saturday and Sunday afternoon. One weekend for converting the program and a second for correcting the documentation and uploading. Then later: 8. Update the program for Ada 2005. NOTE: c2Ada -- The original converts C to Ada 95 only. In doing this they would prove the program works and how hard it is to use (Documentation). But has this happen. No, Why not? That's the question! Both "c2ada" project admins post in this newsgroup along with the other two admins, so you could ask them. Their answers might give you more of the true reason why a Ada OS is unrealistic. In , "I. Levashew" writes: >Peter Hermann �����: >> Randy Brukardt mentioned the idea of an operating system all in Ada >> which he ranked as unrealistic. >Well, it isn't. I'm a bit more optimistic about it. > >What if we choose a bit another way of accomplishing this non-easy goal? >What I mean: not to do it from scratch, but reengineer existing system. >Infect Open Source. > >It's about motivation. How much effort one must spend to get any result. >I think the one willing to see something rewritten in Ada should >concentrate on providing easy way to infect C programs. That is, it >should be easy to get any open source tarball-distributed utility and >put a bit of Ada source into it. It should be benefittable to write >addons in Ada, not in C or C++. Once the society realize that many >tarballs contain Ada code, Ada may become more common PL than ever. >Currently we can obtain (for example) Leopard double-layer(!) install >DVD. Install DVD always contain developer tools. There is Perl, Python, >Ruby, Tcl/Tk, etc inside. But on the whole double-layer DVD there wasn't >any GNAT despite being part of main GCC distribution. Ada lock-ins will >ensure higher availability of GNAT. > >There were times when Perl was the only scripting PL widely used in *NIX >("Swiss Army Chainsaw" of *NIX). Now we can see Perl and Python sharing >this niche. What if the same thing to some extent is applicable to Ada? > >I'd like to start infecting projects that are not developed anymore, but >still used. That way : >a) original authors shouldn't care about inclusion of Ada in sources >b) Ada programs wouldn't be rare aliens. > >ShakesPeer, a Direct Connect client for Mac OS X have all the repertoire >of bugs specific to (Objective)C. Will it be rewritten in Ada, it'll >become better, thus raising reputation of Ada. >(For several reasons writing something in Ada is insanely difficult on >Mac OS X, so I can't even get started doing it.) > >If there was many successful experiences of C(++) project converted to >Ada, idea of rewritting C(++)->Ada would be more popular. Thus we could >have much more coder hands willing to rewrite. > >It's just a wild idea.