Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The AdaOS Operating System (2000)

web.archive.org

Post reply on HN
Print view View original

21–30 of 56 posts

Re: The AdaOS Operating System (2000)

#21

Post by dapids »

thesuperbigfrog wrote: post #14

The biggest issue with all of these "write a new operating system in my favorite language X" (where X is Ada, C, C++, D, Rust, etc) is that in almost all cases the operating system design slowly morphs into a buggy, half-baked version of an existing operating system. Rarely are there compelling new designs that are sufficiently better than what currently exists or was previously created in a different programming lan…

I think you are missing the point of what Ada can accomplish in contrast to other languages in terms of memory safety and criticality.

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.

Re: The AdaOS Operating System (2000)

#22

Post by dapids »

jki275 wrote: post #12
kpU8efre7r wrote: post #7

Earlier quoted context omitted.

What? I just left a job in defense software that used Ada and it was a fairly new program.

Interesting to hear that. DOD no longer requires ADA, so many projects that did use it have converted to C++. There were even people brought in to do automated Ada-> C++ conversion a number of years ago.

With the creation of the MISRA C standards for JSF these memory safety issues have largely been accounted for in the MISRA standards review process.

Re: The AdaOS Operating System (2000)

#23

Post by SkyMarshal »

thesuperbigfrog wrote: post #14

The biggest issue with all of these "write a new operating system in my favorite language X" (where X is Ada, C, C++, D, Rust, etc) is that in almost all cases the operating system design slowly morphs into a buggy, half-baked version of an existing operating system. Rarely are there compelling new designs that are sufficiently better than what currently exists or was previously created in a different programming lan…

>The biggest issue with all of these "write a new operating system in my favorite language X" (where X is Ada, C, C++, D, Rust, etc) is that in almost all cases the operating system design slowly morphs into a buggy, half-baked version of an existing operating system.

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).

Re: The AdaOS Operating System (2000)

#25

Post by Twirrim »

tornato7 wrote: post #15
vips7L wrote: post #9

Earlier quoted context omitted.

Why is sourceforge's ui so bad? Why not display the files instead of expecting me to download some random zip file?

Sourceforge isn't a reputable website anymore. They have been known for bundling spyware/crapware with their installers of open source software.

That was under previous owners. They've since been bought out by a company that actually gives a damn. Unfortunately there's a good argument for too little, too late. The damage to the brand's reputation is immense.

Re: The AdaOS Operating System (2000)

#26

Post by zahllos »

thesuperbigfrog wrote: post #14

The biggest issue with all of these "write a new operating system in my favorite language X" (where X is Ada, C, C++, D, Rust, etc) is that in almost all cases the operating system design slowly morphs into a buggy, half-baked version of an existing operating system. Rarely are there compelling new designs that are sufficiently better than what currently exists or was previously created in a different programming lan…

Well, with the exception of the BSD-like systems, none of the systems being written will actually run software people want to run unless they target those kernels. By definition, none of these kernels will therefore likely see widespread use. You can see a microcosm of this with Linux: popular commercial software like games often doesn't come to linux. To make an operating system that sees popular use, you'd likely need to emulate the API of an existing system.

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 :)

Re: The AdaOS Operating System (2000)

#27

Post by ajxs »

I was just looking at this recently, funnily enough, while looking for other examples of x86 Operating-System development in Ada.

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

- https://sourceforge.net/projects/lovelaceos/

- https://sourceforge.net/projects/sx-ada-kalinda/

Re: The AdaOS Operating System (2000)

#28

Post by ajxs »

thesuperbigfrog wrote: post #14

The biggest issue with all of these "write a new operating system in my favorite language X" (where X is Ada, C, C++, D, Rust, etc) is that in almost all cases the operating system design slowly morphs into a buggy, half-baked version of an existing operating system. Rarely are there compelling new designs that are sufficiently better than what currently exists or was previously created in a different programming lan…

Your post doesn't address the point that many of these "write a new operating system in my favorite language X" projects have great pedagogical value to the individual developing them. I've done plenty of experimentation in this area and I harbor no illusions that my efforts will ever be adopted into the mainstream. Operating-system development is an extremely broad and deep area of study. Writing toy operating-systems remains the best and most fulfilling way to learn.

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.

Re: The AdaOS Operating System (2000)

#29

Post by ajxs »

dapids wrote: post #22
jki275 wrote: post #12

Earlier quoted context omitted.

Interesting to hear that. DOD no longer requires ADA, so many projects that did use it have converted to C++. There were even people brought in to do automated Ada-> C++ conversion a number of years ago.

With the creation of the MISRA C standards for JSF these memory safety issues have largely been accounted for in the MISRA standards review process.

MISRA C definitely makes many improvements in this area. However, writing decent Ada code is so much easier than writing C code that conforms to MISRA ( or JSF ) standards.

There's a pretty good comparison here: https://learn.adacore.com/courses/SPARK_for_the_MISRA_C_Deve...

Re: The AdaOS Operating System (2000)

#30

Post by zozbot234 »

dapids wrote: post #22
jki275 wrote: post #12

Earlier quoted context omitted.

Interesting to hear that. DOD no longer requires ADA, so many projects that did use it have converted to C++. There were even people brought in to do automated Ada-> C++ conversion a number of years ago.

With the creation of the MISRA C standards for JSF these memory safety issues have largely been accounted for in the MISRA standards review process.

> ... C ....

> ... these memory safety issues have largely been accounted for ...

Hahaha. Hahahahahaha.

Post reply on HN