Indian Developers Redesigning Linux Kernel With OOP, C++ Support

[Luke]

Interpreted kernel modules?

Moving to an object-oriented language is a great idea, but C++ is too old and complicated and programmers would still have to deal with memory allocation. Would be better to use a microkernel with XML API and loadable modern OO language (Java or C#) servlets for all ?kernel modules and drivers. We could call it Fluck, to signify all the objects working together.

Moving even more code from compiled binaries to interpreted code strikes me as a bad idea that would create slow code that responds poorly. I just switched from Cinnamon to MATE, even though I really love the Cinnamon environment, simply because all those interpreted JS elements plus the Clutter toolkit make it so slow. They inherited that from the GNOME team, whose code they forked. MATE and compiz are compiled and compiz can deal directly with OpenGL. In other words, removing a toolkit layer and using compiled binaries really speeds it up. Now imagine having a kernel that is as much slower than Linux today as GNOME 3 or Cinnamon is slower than GNOME 2 or MATE! We are going the wrong way.

JavaScript is said to be 20x faster than python, yet it still has to be far slower than any compiled code written by someone of comparable ability. OK, now we have the issue of getting enough programmers. There is a nasty barrier for any newcomer seeking to use a C tutorial: incompatability among compiler versions. I've yet to see a C tutorial where anything beyond the first 4 or 5 exercises will compile on the newest version of GCC. Ever wonder why we have so many more shell and Python coders than C coders? Maybe the solution is for C tutorials to be shipped as complete live OS disk/USB images, so as to guarantee that all exercises will compile properly.

[Luke_Wolf]

Moving even more code from compiled binaries to interpreted code strikes me as a bad idea that would create slow code that responds poorly. I just switched from Cinnamon to MATE, even though I really love the Cinnamon environment, simply because all those interpreted JS elements plus the Clutter toolkit make it so slow. They inherited that from the GNOME team, whose code they forked. MATE and compiz are compiled and compiz can deal directly with OpenGL. In other words, removing a toolkit layer and using compiled binaries really speeds it up. Now imagine having a kernel that is as much slower than Linux today as GNOME 3 or Cinnamon is slower than GNOME 2 or MATE! We are going the wrong way.

JavaScript is said to be 20x faster than python, yet it still has to be far slower than any compiled code written by someone of comparable ability. OK, now we have the issue of getting enough programmers. There is a nasty barrier for any newcomer seeking to use a C tutorial: incompatability among compiler versions. I've yet to see a C tutorial where anything beyond the first 4 or 5 exercises will compile on the newest version of GCC. Ever wonder why we have so many more shell and Python coders than C coders? Maybe the solution is for C tutorials to be shipped as complete live OS disk/USB images, so as to guarantee that all exercises will compile properly.

C# and Java are JITed not interpreted, and if a compiler implementation supports it they can be fully ahead of time compiled (as long as you're not using any dynamicism features that require the JITer). Which Microsoft and Android (with the new Android L) are doing. Although when it comes to responsiveness being asynchronous is really more important than being fast. What really makes Javascript slow though is that pretty much everything is dynamic and so it has to determine it at runtime, which means that it can't be optimized at those sections.

That said people aren't learning C because C is hard, a lot of the core built-in functions are marked off in red tape as 'UNSAFE: DO NOT USE", there's no built in way of handling strings nicely, you don't have templates or generics so you're essentially required to build your own collections, you've got to deal with manual memory management in an untyped fashion, and yeah it's just painful to work with as a result vs other languages. Now the reason we've got a lot of python coders is because everyone is being told if they're beginning to learn programming that they should learn python, and shell is popular because just like batch it's really just a small extension off of what they already know if they know their command line.

I know this is going to be an unpopular opinion but personally I believe C# is really the prime language to teach people on, and so when people show interest in coding I bring them up on that. The reasoning is rather simple, it's basically the easiest statically and strongly typed mainstream C-Family language, because it's like Java with some additional niceties and no checked exceptions. Plus the highly tooled workflow means that as long as you know the logic behind what you want the code will almost write itself. Once they understand C-family grammar then it's pretty easy for them to move to C++, Java, JS, etc with just having to learn the quirks of the language.

[erendorn]

I know this is going to be an unpopular opinion but personally I believe C# is really the prime language to teach people on, and so when people show interest in coding I bring them up on that. The reasoning is rather simple, it's basically the easiest statically and strongly typed mainstream C-Family language, because it's like Java with some additional niceties and no checked exceptions. Plus the highly tooled workflow means that as long as you know the logic behind what you want the code will almost write itself. Once they understand C-family grammar then it's pretty easy for them to move to C++, Java, JS, etc with just having to learn the quirks of the language.

Seconded.

[johnc]

Moving even more code from compiled binaries to interpreted code strikes me as a bad idea that would create slow code that responds poorly. I just switched from Cinnamon to MATE, even though I really love the Cinnamon environment, simply because all those interpreted JS elements plus the Clutter toolkit make it so slow. They inherited that from the GNOME team, whose code they forked. MATE and compiz are compiled and compiz can deal directly with OpenGL. In other words, removing a toolkit layer and using compiled binaries really speeds it up. Now imagine having a kernel that is as much slower than Linux today as GNOME 3 or Cinnamon is slower than GNOME 2 or MATE! We are going the wrong way.

JavaScript is said to be 20x faster than python, yet it still has to be far slower than any compiled code written by someone of comparable ability. OK, now we have the issue of getting enough programmers.

Completely agree with the above.

I don't know if there's a shortage of programmers or a shortage of interesting projects to work on that provide any benefits to the programmer.

[WorBlux]

Moving to an object-oriented language is a great idea, but C++ is too old and complicated and programmers would still have to deal with memory allocation. Would be better to use a microkernel with XML API and loadable modern OO language (Java or C#) servlets for all ?kernel modules and drivers. We could call it Fluck, to signify all the objects working together.

Anything with a needed runtime expecially a VM is a no-go as a serious general-purpose OS. Small .NET or jave kernel can be great to run as virtual machine for single tasks. Hoever they won't ever be big-iron material.

D or haskell are potential options. D however needs some more compiler work, and nobody really knows how to do a full kernel with functional programing.

[mmstick]

Anything with a needed runtime expecially a VM is a no-go as a serious general-purpose OS. Small .NET or jave kernel can be great to run as virtual machine for single tasks. Hoever they won't ever be big-iron material.

D or haskell are potential options. D however needs some more compiler work, and nobody really knows how to do a full kernel with functional programing.

Why not Rust? The API isn't stable yet, but it will be soon.

[Luke_Wolf]

Anything with a needed runtime expecially a VM is a no-go as a serious general-purpose OS. Small .NET or jave kernel can be great to run as virtual machine for single tasks. Hoever they won't ever be big-iron material.

D or haskell are potential options. D however needs some more compiler work, and nobody really knows how to do a full kernel with functional programing.

Actually VMed languages are really interesting for microkernel based designs, because this allows you to rely on software memory protection instead of hardware and thus allows you to avoid the context switch between user-space and kernel-space, which means that a VMed language microkernel design could in principle actually run faster than one that is not written in a VMed language

[Guest]

Memory allocation doesn't play a role here, kernel doesn't have malloc()/new keyword or other perks that userspace code has.
If you want memory, you have to manually allocate it, page by page.
Kernel uses OOP in few places, like VFS layer that translates between syscalls and various filesystems and OOP style code is possible to do in C too.

I do believe there is a nice FAQ on kernel.org about why they won't switch to C++ and 'C++ makes people do bad code' isn't part of it, it's a myth anyway.

[Ansla]

Actually VMed languages are really interesting for microkernel based designs, because this allows you to rely on software memory protection instead of hardware and thus allows you to avoid the context switch between user-space and kernel-space, which means that a VMed language microkernel design could in principle actually run faster than one that is not written in a VMed language

And they would also allow cooperative multitasking, all that preemtiveness adds way to much overhead!!!

Do you have any ideea what you are talking about?

[gens]

Memory allocation doesn't play a role here, kernel doesn't have malloc()/new keyword or other perks that userspace code has.
If you want memory, you have to manually allocate it, page by page.
Kernel uses OOP in few places, like VFS layer that translates between syscalls and various filesystems and OOP style code is possible to do in C too.

I do believe there is a nice FAQ on kernel.org about why they won't switch to C++ and 'C++ makes people do bad code' isn't part of it, it's a myth anyway.

actually it has, kmalloc
it's still not that simple, the memory management
another fun fact it that there are 3 types of pointers used in the linux kernel
more on that in http://lwn.net/Kernel/LDD3/

funny thing that OOP is not a well defined term at all