Haiku OS – Fundraising 2015
haiku-os.org
haiku-os.org
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.
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?
It always runs quite fast compared to a lightweight Linux distro.
"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.
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.
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.