Which is filled with security bugs. Consider the conventional sysadmin wisdom that if someone gets a shell on your box, it's as good as owned, due to a no doubt fertile field of privilege escalation vulnerabilities in the kernel.
Don't get me wrong -- the Linux kernel is a magnificent piece of engineering, and an excellent choice for hosting a mainstream server, I run a number of such myself -- but let's not kid ourselves about its security limitations.
Drivers in (everything, possibly Ocaml/Lua/Common Lisp/C++)
Os in everything.
The Linux kernel is not written in C but in a DSL that there is not yet a compiler to generate C. This is the same like Enlightment Object System and GObject.
moreover drivers should be written in a DSl language (Termite-like) that supports concurrency and provided by spec writters as an appendix.
The driver is two parts. The OS adaptation Layer and a Formal description of modus Operandis.
Consider USB, normally the spec provides an implementtion i a DSL that "compiles" to the prose.
One can mechanically check for invariants and properties and
compile to an OS package.
I think it is possible. Packages for example could describe transports
e.g. module BT uses an Ocaml-like interface for transport that can have various implementations like USB transport.
But all could be written in the same DSL.
Of course Kernel developers are allergic to memory management. Rust/Ocaml/D are the anti-histamine.
i'm sorry, but proof by convention or consensus is not a proof. you have an idea of the linux kernel, and it's not entirely unwarranted. but whilst there have obviously been security issues, it would be a mistake to suggest that they are the fault of C.
Let's just say that it's not C's fault. It's just that C is particularly well suited for creating security problems. The base semantics is dangerous, the undefined behaviors are lurking everywhere, and the compilers writers don't care ("it's the user fault if they go in undefined behavior that we put everywhere, and they'd better says thank you that we didn't ring their phone while they were in the bath the last time they did an integer multiplication without checking overflow, because the spec said we could have done it").
Sometimes I think the ebola crisis is created by a GCC developer. "I'm sorry for those people, but I was entitled to it, that guy there dereferenced a wild pointer, I could have cured cancer instead, but no".
Strictly speaking, you are correct. But saying C is not at fault is like finding the trivial solution to a polynomial -- it is correct but not very useful.
No, C is not at fault. The programmers are at fault. But it is prudent to ask, when some of the world's foremost programmers produce an apparently limitless number of CVEs as they do, whether they could use some help from the language. If the answer is yes, we should recognize that such help cannot come from C.
You can attribute fault to the programmer, or you can attribute fault to the language, but for every problem there is a solution that is simple easy and wrong.
Don't get me wrong -- the Linux kernel is a magnificent piece of engineering, and an excellent choice for hosting a mainstream server, I run a number of such myself -- but let's not kid ourselves about its security limitations.