Why port the Linux kernel to Lisp? What advantages would it have that would justify the huge amount of work that would have to go into it before it could even begin to compete with Linux?
Linux took many years to get to the point where it had the stability and performance to be able to compete with commercial operating systems. Users of Linux will not care what language the kernel is written in. They're only going to care whether it will run all of their existing applications without changes, as fast and reliably as Linux does. If the new system doesn't, it will never have any users. (People were willing to put up with the early versions of Linux because it was free and its competitors were not. Any new OS would have to compete with an existing free OS.)
Who would write and maintain it? Linus and most of his followers would stick with the C version, which they know and love, so where are we going to suddenly find the hundreds or thousands of contributors who are both expert Lisp programmers and expert kernel hackers?
This seems like a perfectly reasonable reaction :-)
I would add: if someone really _did_ do all the work to write a whole modern operating system in Lisp, it would be criminally unimaginative to use the Linux ABI as your interface to the world.
You would have to write your own userspace too for the whole enterprise to be worth bothering with. And then you have basically written SqueakNOS (http://squeaknos.blogspot.ch). :-)
For many of the same reasons people started writing OS kernels in C rather than assembly: Less scut work, wrong code looks wrong more often, and more opportunity for code reuse.
Other reasons include being able to provide a higher-level API, which only kinda happened with the move to C. A Lisp API would enable things like system-level garbage collection and possibly things like a single-address-space OS where the kernel is responsible for fine-grained memory protection and multiprocessing becomes as cheap as multithreading without becoming as unsafe as multithreading.
But that wouldn't be Linux anymore, I suppose; it would be a Linux-compatible system with extended features beyond what the C kernel provides. On the other hand, is Linux 3.11 the same as Linux 1.0 or is it merely mostly-compatible with Linux 1.0?
Comments
Why port the Linux kernel to Lisp? What advantages would it have that would justify the huge amount of work that would have to go into it before it could even begin to compete with Linux?
Linux took many years to get to the point where it had the stability and performance to be able to compete with commercial operating systems. Users of Linux will not care what language the kernel is written in. They're only going to care whether it will run all of their existing applications without changes, as fast and reliably as Linux does. If the new system doesn't, it will never have any users. (People were willing to put up with the early versions of Linux because it was free and its competitors were not. Any new OS would have to compete with an existing free OS.)
Who would write and maintain it? Linus and most of his followers would stick with the C version, which they know and love, so where are we going to suddenly find the hundreds or thousands of contributors who are both expert Lisp programmers and expert kernel hackers?
This seems like a perfectly reasonable reaction :-)
I would add: if someone really _did_ do all the work to write a whole modern operating system in Lisp, it would be criminally unimaginative to use the Linux ABI as your interface to the world.
You would have to write your own userspace too for the whole enterprise to be worth bothering with. And then you have basically written SqueakNOS (http://squeaknos.blogspot.ch). :-)
For many of the same reasons people started writing OS kernels in C rather than assembly: Less scut work, wrong code looks wrong more often, and more opportunity for code reuse.
Other reasons include being able to provide a higher-level API, which only kinda happened with the move to C. A Lisp API would enable things like system-level garbage collection and possibly things like a single-address-space OS where the kernel is responsible for fine-grained memory protection and multiprocessing becomes as cheap as multithreading without becoming as unsafe as multithreading.
But that wouldn't be Linux anymore, I suppose; it would be a Linux-compatible system with extended features beyond what the C kernel provides. On the other hand, is Linux 3.11 the same as Linux 1.0 or is it merely mostly-compatible with Linux 1.0?
Less scut work is a good arguement when writing a kernel from scratch. The scut work has already been done in the linux kernel.