The AdaOS Operating System (2000)
web.archive.org
web.archive.org
While a different programming language can enable different levels of expressiveness, elegance, or nuance of control when interacting with hardware, ultimately it is the higher-level design concepts and design maturity that come into focus over time. (Does the design work in the real world? Is it "battle tested" and can address / overcome various failure modes?)
These forces have shaped the operating systems that we have today into what they are through years of heat and pressure. If you are contemplating writing a new operating system in your favorite language X, take a few years to study and understand how current operating systems solve real world problems and ask yourself how your ideas / designs will be as good as or better than what currently exists.
I personally think AdaOS is very compelling if you want a unique perspective on memory safety at such a large scale.
It's much more than a "favorite" language and certainly not even in the same realm of application as a language such as C.
Misra C in contrast to Ada, now that's a comparison. Not D, C++, etc.
I have no doubts about Ada or SPARK. I am questioning what is needed to make a new operating system design viable other than "it's written in Ada". What is needed to make an operating system that can be as good as or better than the POSIX-based operating systems that dominate computing.
The whole point of writing a new OS in a language that prioritizes memory safety and provable correctness, like Ada or Rust, is specifically to explore the possibility that by using a better language, the OS won't morph into a buggy spaghetti code thing.
Safe languages impose fundamental constraints on the complexity of the system, that C/C++ and others do not, and eliminate entire classes of bugs and vulnerabilities at the compiler level.
People wonder why all our systems these days are insecure and getting hacked left and right. Provably correct software and compiler-enforced memory safety are two tools that will be part of the solution (maybe not sufficient, but absolutely necessary).
POSIX is a great standard, but it is too tightly coupled with C. If a similarly mature and open Ada-based standard could be designed and created, that would be great. If such a design were created, what would it look like? How would files be represented and stored? How would you start, stop, or communicate with tasks? (POSIX-style signals? Rendezvous? Something else?)
There needs to be an open design that is as well thought out as the Ada programming language to really take advantage of everything that it offers.
I am aware of Interfaces.C and the non-standard but highly-useful GNAT.OS_Lib. Any others would be nice to know about.
POSIX is a mature set of APIs and designs, but it is C-centric. It is an impedance mismatch discards many of the advantages of using Ada in the first place.
This is actually fine. These systems aren't really trying to do that because they're created for other reasons. Maybe it is to learn about building operating systems and the author picked a not-C language? Maybe it is an academic research project like seL4 and the question being asked is "can we formally verify a whole kernel?" Maybe the kernel will use some esoteric feature of the processor, like i386's hardware threads or POWER's hypervisor? Maybe it is to produce a security kernel like GEMSOS or a separation kernel like Windriver's vxworks or Muen (which is written in Ada). Or it could be to build a different design of kernel, like a microkernel or unikernel. There are many reasons, and some of these are sold commercially and used in critical environments, albeit not on the scale of say Windows or Linux.
I don't think there's anything wrong with trying to build a kernel in a new language for many of the reasons other commenters have suggested. Perhaps it is simply to see if the language is suitable for kernel development? Maybe it is just to learn, and the developer in question picked their favourite language? I do agree with you though that doing some research is absolutely necessary. Writing a kernel is not a small project and it helps to decide what your aims are :)
But wait a second, if the favorite language X operating system would implement these handful of POSIX APIs then look how much software could probably run with just a few tweaks. Except the POSIX APIs do not get implemented completely right. Or they suffer from terrible impedance mismatches due to the design differences or safe ideals that have to be relaxed in order to have them work. For example: Ada has unchecked conversion, unchecked deallocations, etc. Rust has unsafe.
A big part of the reason that GNU and Linux have succeeded is that they implemented Unix APIs with some innovations and improvements along the way.
The crossover is: "Any sufficiently complicated, real-world operating system contains an ad-hoc, informally-specified, perhaps buggy, implementation of half of Unix."
While I can't speak for D, Rust, etc, I can speak for what Ada can offer the field. Ada, and especially its formally verifiable subset SPARK are languages designed with secure and maintainable development in mind. I think there's tremendous value in continuing research into the formal verification of operating-systems. SPARK is a much better option for this purpose than many of the other languages available.
I agree, formally verifiable operating-systems should really be the future. Take a look at Muen, they've done an amazing job at making a formally verified kernel in SPARK.
Here are a few other examples of Operating-System development in Ada, in various levels of completion.
- https://github.com/ajxs/cxos
- https://github.com/Lucretia/bare_bones
- https://marte.unican.es/todo.htm
Back when it was based on OpenSolaris:
https://web.archive.org/web/20090314042407/http://auroraux.b... (Main Page)
https://web.archive.org/web/20090415214139/http://auroraux.b... (About)
Then DragonFlyBSD:
https://web.archive.org/web/20110824053558/http://www.aurora... (Main Page)
https://web.archive.org/web/20110824053558/http://www.aurora... (Why Ada?)
https://web.archive.org/web/20110904173302/http://www.aurora... (System Overview)
https://web.archive.org/web/20110904171806/http://www.aurora... (Project Goals)
https://web.archive.org/web/20091127065848/http://www.aurora... (Hydra Package Manager)
I believe I can get in touch with someone who was really enthusiastic about the project! He was like 14 years old at the time, really really zealous so I would like to think that he made backups. I got the links above from him a couple of weeks (or months?) ago when we were going down the nostalgia lane. :) For what it is worth, I met him on IRC (freenode), in #ada.
Muen is implemented in SPARK, and has been formally proven to contain no runtime errors, which is an incredible accomplishment.
And then there was the Rational/R1000s400, the first only and last "Ada-only" Computer.
http://datamuseum.dk/wiki/Rational/R1000s400
https://en.wikipedia.org/wiki/Rational_R1000
The R1000 was a workstation released in 1985 by Rational Software for the design, documentation, implementation, and maintenance of large software systems written using the Ada programming language. The R1000 featured an extensive tool set, including:
- an Ada-83-compatible program design language
- an integrated development environment that doubled as an operating system shell
- automatic generation of design documentation
- source-language debugging
- interactive design-rule checking and semantic analysis
- incremental compilation
- configuration management and version control.
Excerpts from Articles Filed Under: Rational 1000
http://www.somethinkodd.com/oddthinking/category/rat1000/
Rational 1000: A Time-Travelling Debugger with No Future
http://www.somethinkodd.com/oddthinking/2006/03/25/rational-...
https://sourceforge.net/projects/pkgconfiglite/
There's so much crap on that page I couldn't even begin to care about. On the top half of the page: downloads this week, share this, open source software, business software, services, resources, sourceforge's twitter account, sourceforge's facebook account, sourceforge's linkedin, sourceforge newsletters, and of course a gigantic sourceforge banner.
If you go further: user reviews, recommended projects, top searches, other useful business software, similar business software, more twitter links unrelated to the project, related business categories.
SourceForge is a freaking dumpster fire even if they're no longer bundling malware.
https://cs.uwaterloo.ca/~Brecht/courses/702/Possible-Reading...
What does this mean? Something like certified forks of g++?
It never went anywhere => ie. it never left.
Still used for what it was used => ie. the same kind of software (defense, etc).
There's a pretty good comparison here: https://learn.adacore.com/courses/SPARK_for_the_MISRA_C_Deve...
> ... these memory safety issues have largely been accounted for ...
Hahaha. Hahahahahaha.
Once again largely, C is a language not the compiler providing its implementation.
They won't be replaced in the next decades, and even some new systems might be implemented in them.
Languages for production were often designed to address a set of (hard) problems, as opposed to general-purpose languages (Python, Java, C++, etc.)
Sure, there are some web servers/apps written in Fortran or Ada. But those are examples of what the languages can achieve, not how they are actually used in production.
Spark, a subset of Ada 2012 supports formal proofs of program properties ranging from absence of run-time errors to functional correctness (compliance of the code with formally specified requirements).
If you're curious, you can learn more at https://learn.adacore.com/courses/courses.html
https://www.adacore.com/uploads/books/pdf/AdaCore-Tech-Cyber...
https://www.adacore.com/gems -> https://blog.adacore.com/
https://web.archive.org/web/20190709111613/http://www.drdobb...
https://github.com/Componolit/libsparkcrypto
https://people.cs.kuleuven.be/~dirk.craeynest/ada-belgium/ev...
https://www.adacore.com/uploads/books/pdf/ePDF-Implementatio...