It also depends on where your major/minor cutoff is located.
I don't really know where the major/minor cutoff is myself. :)
Pretty much every OS I can think of is in C - Windows, *nix, RTEMS, INTEGRITY, VxWorks
Well, Muen is done in SPARK but it's a separation kernel rather than full OS:
That it was integrated into GenodeOS framework shows one could build a system around it but it's not quite one itself. There's also the JavaCard OS's for low-level stuff and even Java CPU's on market.
http://stackoverflow.com/questions/6398305/operating-system-... lists some OSes written in Ada.
Thanks for the catch. No telling how many ways I've messed his name up.
"What does the author propose instead? Is there a major OS that has a kernel not written in C?"
There's a lot of languages you can use in place of C that are fast, safer, can do low-level stuff, and sometimes compile faster. Any of Wirth's are an example. Modula-3 was cleanest at negotiating among many tradeoffs, Modula-2 being one of simplest built on PDP-11, & FreePASCAL well-supported on many architectures. Ada w/ SPARK is the most thorough in removing defects but steepest learning curve. C++, coded like C++ not C, has significant advantages over C with Ironclad C++ adding lots of safety. Its unofficial, successor D language is even better esp w/ SafeD subset. Rust is promising with many advantages over C, strong integration w/ C apps, and temporal/concurrency safety features. PreScheme, in Scheme48, was a fast, simple, low-level LISP that compiled to C or ASM if you modified it. Advantages of C and Scheme but no GC. COGENT at NICTA is functional language for easier, formal verification plus verified compilation to C. Amateurs rewrote ext2 in it successfully. There's a few.
Far as OS's, eh it's more about how we should incrementally re-write or improve them as OS market is a done deal. Components are simply too huge to replace, although embedded has potential. There were OS's not written in C. Examples include ultra-reliable AS/400 (used PL/S), OpenVMS (used BLISS & macros), Oberon System (A2 Bluebottle is latest), Edison System on PDP-11, many in C++, a few in Ada (including OSS Martes), JX OS in Java, and (recent/active) Redox in Rust. Lots of academic or hobbyist stuff including Mesa (Xerox Palo Alto language inspired Modula's/Java), COSMOS (C#), JNode (Java), House (Haskell), and LISP machine clones. It can definitely be done and gradually if language is designed for clean integration with C codebases.
The author seems to wish that Algol had won instead. I can't imagine that the level of complaining would be less in that hypothetical world...
We don't need to hypothesize as Wirth and Hansen took the path of subsetting and improving ALGOL instead of BCPL. We get to see the result. :) The C alternative would've been a subset of ALGOL like Modula-2 or something. Gradually-improving type-safety, memory-safety by default, option to remove checks for performance, modules, less undef behavior, better linking, easier analysis for optimization, and quicker compile/test cycles. Having coded performance-sensitive applications in languages like that and C tells me the level of complaining would be much lower if it's in any way tied to number of vulnerabilities, time spent debugging, or ease of modifying legacy systems without major breaks.
It's also not hypothetical: all kinds of developers use such languages. C is the exception to the rule these days. Even in UNIX & C's domains, there's new comers kicking the crap out of it in terms of balancing development speed, production speed, safety, and extensibility. Redox in Rust comes to mind given the OS and language attempt a Right Thing approach to bootstrapping an OS with small team. Progress has been impressive.
> Conclusion 3: C and UNIX should be avoided where possible because they're Bad by Design for reasons that stopped applying sometime in the 80's or early 90's.
What does the author propose instead? Is there a major OS that has a kernel not written in C?