Do you have a link to where this was considered? This seems like it would nuke almost the entire point of Haiku, since the goal isn't just to be a desktop environment.
The discussion was quite interesting. There were basically two camps. One that wanted to focus on the "product" side of Haiku and leverage the superior hardware support in Linux. The other saw the development of the Haiku kernel as a goal unto itself.
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.
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.
>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.
That's good, since I'd assume that if it were possible to deliver as nice a desktop experience as BeOS on an OS with the Linux kernel someone would have done it by now.
Then again, maybe it really has been X's fault all along. I guess we'll find out with Mir and Wayland.
It would have been interesting to create a version which was a Linux binary compatibility layer, essentially compiling libbe.so for Linux, with the intent of swapping it for a native kernel later. However, I think this might have been technically difficult since iirc beos uses the same interrupt for syscalls as Linux but does not use the odd Linux syscall standard (where short parameter lists are put into registers) versus the stack, like freebsd. I think freebsd might have been a better choice for that reason and also its performant kernel.
One of the goals of Haiku is to be able to run BeOS software unaltered, and an unfortunate side effect of this is that the ABI for BeOS software is compatible with 1998 GCC, version 2.9 or thereabouts.
I can see the "focus the effort" part, but it has always seemed like a case of personal determination amongst core members.
It's been argued that if the ABI compatibility were not considered a requisite, this effort would have shipped some really cool stuff by now.
I just want to know which BeOS software these people have that they need to run. They've never made clear just which software requires this extend-efforts-by-a-decade-or-more requirement.
As someone who played with BeOS in my younger days; I'm pretty curious about this project, does this use any of BeOS's code or is this a reimplementation of BeOS ideas with it's own codebase?
Haiku reimplements both the BeOS technologies as well as the end user experience, but it is far from being based on BeOS from a code base perspective. The only BeOS code that has made it into Haiku are Tracker and the Deskbar (the file manager and the equivalent of the start menu/taskbar, respectively). These were open sourced by Be Inc. back in 2001, later forked under the OpenTracker project, and eventually merged into the Haiku code base. The rest is either homebuilt code or derivatives of existing open source software."
The one thing the Haiku website really seems to be missing is a solid elevator pitch. Its got some fuzzies, but nothing that tells me in what manner Haiku wants to improve on the existing OS landscape.
> Linux-based distributions stack up software -- the Linux kernel, the X Window System, and various DEs with disparate toolkits such as GTK+ and Qt -- that do not necessarily share the same guidelines and/or goals. This lack of consistency and overall vision manifests itself in increased complexity, insufficient integration, and inefficient solutions, making the use of your computer more complicated than it should actually be.
> Instead, Haiku has a single focus on personal computing and is driven by a unified vision for the whole OS. That, we believe, enables Haiku to provide a leaner, cleaner and more efficient system capable of providing a better user experience that is simple and uniform throughout.
After reading this, I full-heartedly support this project.
Man, I've been sold on that design concept since the mid '90s.
It's pretty amazing how much power old code and old designs have over us. I don't use Windows, so I can't comment on that but as far as I know every other OS still employs those designs which the BeOS developers identified as making things far more complicated than they should actually be.
To this day, I'm not sure that I've ever met anyone who could produce a credible explanation that, however complicated modern Operating Systems have become, they're as simple as they can be and any reduction in complication (this isn't really complexity) would certainly require a reduction in necessary features, usability, reliability, or security.
The only guys I even hear talking about anything even vaguely related are the Library OS/Rump Kernel/UniKernel crowds and they're focusing on applications running in Data Centers.
I have used BeOS 5 & HaikuOS as my no distraction operating systems. It can't do much, but it has a text editor, c compiler, and a web browser that is sufficient for most documentation and Safari.
It always runs quite fast compared to a lightweight Linux distro.
I was on the BeOS team for many years.
While we did many interesting things, and especially kernel and driver layers were more modern than the alternatives, Palm threw away those pieces. If I were to build (or fund) a new OS today, I'd drive the state if the art forward.
Especially the GUI layer is too reliant on '80s style implementation inheritance, rather than fast, strict protocols and minimal abstraction costs.
I've been following the project since it's birth and it is amazing what have been created, but it seems there is a far way to go. I bet your knowledge would be valuable to the project.
Before the whole thing collapsed, I was using BeOS for my desktop at home and had a skunkworks project going on at work trying to demonstrate BeOS as platform for our diagnostic devices.
We were transitioning from a 2-line, 32-char LCD display to QVGA colour touch screen and the experience was become painful. I really thought I had found a much better alternative than the RTEMS, VxWorks, and Windows based options we were looking at.
And then it seemed like everything fell apart. I don't actually remember if it was Be Inc, or what I was working on and then where I was working that folded first but for me it was like a very long line of falling dominoes resulting in a lot of interesting and promising tech being abandoned.
Worse, after all the dust settled in my professional career, all that was replaced with stuff with a lot more familiar names but that was more difficult to get right. It pains me to even say it but I worked on four projects over six or seven years that never made it out of R&D.
29 comments
[ 2.2 ms ] story [ 76.1 ms ] threadThe discussion was quite interesting. There were basically two camps. One that wanted to focus on the "product" side of Haiku and leverage the superior hardware support in Linux. The other saw the development of the Haiku kernel as a goal unto itself.
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.
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.
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.
Still the discussion it generated was interesting.
Then again, maybe it really has been X's fault all along. I guess we'll find out with Mir and Wayland.
[edit] fix broken sentence
It's been argued that if the ABI compatibility were not considered a requisite, this effort would have shipped some really cool stuff by now.
I just want to know which BeOS software these people have that they need to run. They've never made clear just which software requires this extend-efforts-by-a-decade-or-more requirement.
They talk about it here. They say Linux is needlessly complex for a desktop OS.
"Is Haiku based on BeOS then?
Haiku reimplements both the BeOS technologies as well as the end user experience, but it is far from being based on BeOS from a code base perspective. The only BeOS code that has made it into Haiku are Tracker and the Deskbar (the file manager and the equivalent of the start menu/taskbar, respectively). These were open sourced by Be Inc. back in 2001, later forked under the OpenTracker project, and eventually merged into the Haiku code base. The rest is either homebuilt code or derivatives of existing open source software."
> # Why not Linux?
> Linux-based distributions stack up software -- the Linux kernel, the X Window System, and various DEs with disparate toolkits such as GTK+ and Qt -- that do not necessarily share the same guidelines and/or goals. This lack of consistency and overall vision manifests itself in increased complexity, insufficient integration, and inefficient solutions, making the use of your computer more complicated than it should actually be.
> Instead, Haiku has a single focus on personal computing and is driven by a unified vision for the whole OS. That, we believe, enables Haiku to provide a leaner, cleaner and more efficient system capable of providing a better user experience that is simple and uniform throughout.
After reading this, I full-heartedly support this project.
It's pretty amazing how much power old code and old designs have over us. I don't use Windows, so I can't comment on that but as far as I know every other OS still employs those designs which the BeOS developers identified as making things far more complicated than they should actually be.
To this day, I'm not sure that I've ever met anyone who could produce a credible explanation that, however complicated modern Operating Systems have become, they're as simple as they can be and any reduction in complication (this isn't really complexity) would certainly require a reduction in necessary features, usability, reliability, or security.
The only guys I even hear talking about anything even vaguely related are the Library OS/Rump Kernel/UniKernel crowds and they're focusing on applications running in Data Centers.
It always runs quite fast compared to a lightweight Linux distro.
Especially the GUI layer is too reliant on '80s style implementation inheritance, rather than fast, strict protocols and minimal abstraction costs.
I've been following the project since it's birth and it is amazing what have been created, but it seems there is a far way to go. I bet your knowledge would be valuable to the project.
Has anything like this been attempted?
We were transitioning from a 2-line, 32-char LCD display to QVGA colour touch screen and the experience was become painful. I really thought I had found a much better alternative than the RTEMS, VxWorks, and Windows based options we were looking at.
And then it seemed like everything fell apart. I don't actually remember if it was Be Inc, or what I was working on and then where I was working that folded first but for me it was like a very long line of falling dominoes resulting in a lot of interesting and promising tech being abandoned.
Worse, after all the dust settled in my professional career, all that was replaced with stuff with a lot more familiar names but that was more difficult to get right. It pains me to even say it but I worked on four projects over six or seven years that never made it out of R&D.