
Haiku OS – Fundraising 2015 - zura
https://www.haiku-os.org/
======
Quequau
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.

------
jwatte
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.

~~~
tmikaeld
Do you work on HaikuOS? If not, why not?

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.

------
orbitingpluto
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.

------
d3141
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?

~~~
cgh
[https://www.haiku-os.org/about/faq#top_6](https://www.haiku-
os.org/about/faq#top_6)

"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."

~~~
d3141
Ah I missed that, sorry. Thanks for pointing it out.

------
flurpitude
Why? Is Haiku just an exercise in nostalgia or are there reasons why one might
actually choose it over other OSs for practical use?

~~~
didyoucheckthe
[https://www.haiku-os.org/about/faq#top_5](https://www.haiku-
os.org/about/faq#top_5)

> # 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.

~~~
Quequau
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.

------
wmf
What was the outcome of the discussion about switching to the Linux kernel?

~~~
joshuapants
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.

~~~
gillianseed
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
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
>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.

