3 ms·

Why would relying on an existing kernel (linux, bsd) 'nuke' the point of Haiku ? The API's (kits) would not have to change in any way, which is the part that a

Why would relying on an existing kernel (linux, bsd) 'nuke' the point of Haiku ? The API's (kits) would not have to change in any way, which is the part that application developers face, and from a user perspective the only difference would be better performance and much better hardware support. The 'point' of Haiku (and BeOS before it) has (in my opinion) always been to provide an OS that is designed for desktop use with the apps integrated well with the desktop environment, I don't see how that in any way excludes using existing kernels since the 'desktop part' is outside of the kernel anyway.

joshuapants 12y ago
For one I'm pretty sure it would wreck binary compatibility with BeOS without the addition of a compatibility layer. Whether you think that's a worthwhile goal or not, it is a stated goal of the project. Linux also lacks the pervasive multithreading that BeOS and Haiku have. Again, maybe that approach isn't the best one, but it's a pretty big feature of BeOS/Haiku and switching to something else would make them more ordinary. I think they only have a chance to survive as long as they're novel.
- gillianseed 12y ago
  >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.

joshuapants 12y ago

For one I'm pretty sure it would wreck binary compatibility with BeOS without the addition of a compatibility layer. Whether you think that's a worthwhile goal or not, it is a stated goal of the project. Linux also lacks the pervasive multithreading that BeOS and Haiku have. Again, maybe that approach isn't the best one, but it's a pretty big feature of BeOS/Haiku and switching to something else would make them more ordinary. I think they only have a chance to survive as long as they're novel.

gillianseed 12y ago
>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.