Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haiku OS – Fundraising 2015

haiku-os.org

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Haiku OS – Fundraising 2015

#21

Post by Torgo »

dnautics wrote: post #15
gillianseed wrote: post #4

Earlier quoted context omitted.

It seems it was just someone trolling, no code has surfaced at all. Still the discussion it generated was interesting.

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)…

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.

Re: Haiku OS – Fundraising 2015

#22

Post by 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.

Re: Haiku OS – Fundraising 2015

#23

Post by geon »

Torgo wrote: post #21
dnautics wrote: post #15

Earlier quoted context omitted.

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)…

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 think that is only a goal until the 1.0 is reached, in order to focus the effort.

Re: Haiku OS – Fundraising 2015

#24

Post by tmikaeld »

jwatte wrote: post #22

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.

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.

Re: Haiku OS – Fundraising 2015

#25

Post by adamnemecek »

jwatte wrote: post #22

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.

> Especially the GUI layer is too reliant on '80s style implementation inheritance, rather than fast, strict protocols and minimal abstraction costs.

Has anything like this been attempted?

Re: Haiku OS – Fundraising 2015

#26

Post by ab5tract »

geon wrote: post #23
Torgo wrote: post #21

Earlier quoted context omitted.

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 think that is only a goal until the 1.0 is reached, in order to focus the effort.

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.

Re: Haiku OS – Fundraising 2015

#27

Post by 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.

Re: Haiku OS – Fundraising 2015

#28

Post by Quequau »

didyoucheckthe wrote: post #19
flurpitude wrote: post #13

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

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…

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.

Re: Haiku OS – Fundraising 2015

#29

Post by joshuapants »

gillianseed wrote: post #6
joshuapants wrote: post #3

Earlier quoted context omitted.

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.

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…

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.

Re: Haiku OS – Fundraising 2015

#30

Post by gillianseed »

joshuapants wrote: post #29
gillianseed wrote: post #6

Earlier quoted context omitted.

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…

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…

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

Post reply on HN