>For one I'm pretty sure it would wreck binary compatibility with BeOS without the addition of a compatibility layer. There's already 64-bit Haiku binaries whi

>For one I'm pretty sure it would wreck binary compatibility with BeOS without the addition of a compatibility layer. There's already 64-bit Haiku binaries which can be used alongside the old BeOS binaries so I doubt that this is an issue, it's not as if programs call the Haiku kernel directly, it's done through the Kernel kit. >Linux also lacks the pervasive multithreading that BeOS and Haiku have. Again, maybe that approach isn't the best one From what I've read from the guy who is working on improving Haiku scheduling (pawel), the thread scheduling was really bad in Haiku and scaled poorly, he was also positive (despite all his work on the Haiku scheduler) of using a Linux/BSD kernel to improve performance. It's not as if rendering a tea-pot while opening 3 videos is causing any modern kernel scheduler to choke these days, it was impressive back when people were running windows 95. In short, I don't think BeOS pervasive multithreading offers any benefits against modern kernel schedulers of today. >I think they only have a chance to survive as long as they're novel. I agree, however I don't think Haiku's novelity lies in which kernel it uses as it is such a low level part of the stack, it's in the API's, the desktop environment and the file system, in other words, user/developer facing components.