Linked by Thom Holwerda on Wed 18th Aug 2010 21:02 UTC, submitted by koki
BeOS & Derivatives "Back in mid-2001, when the news that Be Inc. had sold its intellectual property to Palm hit the streets, what many had suspected and rumored for quite some time - that BeOS development was headed towards closure - finally became a reality. This news and the sad realization that it ensued hit hard the developers and users of BeOS; but many of them did not give up on the idea of letting the operating system of their dreams die, and instead embarked on the daunting task of recreating BeOS in an open source fashion. This is how OpenBeOS - now known as the Haiku Project -- was born."
Thread beginning with comment 437605
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Not bad..
by vodoomoth on Fri 20th Aug 2010 15:35 UTC in reply to "RE: Not bad.."
vodoomoth
Member since:
2010-03-30


On the other hand, Haiku has now tutorials on developing applications, developers/user conferences.....will it now go in hyperbolic development? Sincerely hope so (and best wishes to them).

Just to reply on this point, I think one straightforward way to get this hyperbolic development is by opening the flood gates to Java and other virtual machine-based things. The amount of software in Java is just huge. Problem is, the OpenJDK port was announced in January 2008 and still no release date that I know of. The motto should be "reuse as much as possible". In that sense, the FreeBSD networking stack is a good move but the OS needs more of that.

Another way, less easy in my opinion, is the developer momentum. I think Haiku has gained it, at least, they've earned me and I knew strictly nothing about BeOS and Haiku before this year. The general view seems rather favorable as I have never read anything negative about Haiku anywhere on the web, which is a rare fact.

What do you think?

Reply Parent Score: 2

BlueofRainbow Member since:
2009-01-06

I have looked at various programming languages available for BeOS/Haiku as I'm not a C/C++ person. The one I would have a preference for (Oberon which was ported to BeOS in the form on an Oberon-to-C translateor) has completely dis-appeared from the Web. So, I may have to become more fluent in C/C++.

There has been a few of Java VM porting projects to BeOS/Haiku over the years. BeKaffe appears to have stalled in 2006. The Sun sanctioned JVM port to BeOS/Haiku (same as the OpenJDK?) appears to have stalled late 2008 when the developer at that time decided to re-prioritize his life.

Perl and Python have been ported to Haiku and this suggests that porting a language is technically feasible.

The Java VM in it-self likely brings a higher level of complexity in the porting exercise in relation to API. The security model inherent to the Java VM may also impede porting to the BeOS/Haiku API which is described as weak in this area.

The "code once and reuse many times" concept allowed by a VM is attractive. However, would this allow access to all the distinctive features of the native API? Probably not.

It looks like experimenting will be the only way to find-out.

Reply Parent Score: 2

vodoomoth Member since:
2010-03-30

The Sun sanctioned JVM port to BeOS/Haiku (same as the OpenJDK?) appears to have stalled late 2008 when the developer at that time decided to re-prioritize his life.

It's still alive. I've asked a few weeks ago how I could contribute and someone on the mailing list pointed me to a Wiki page. Just days before that, I read a post (not necessarily on the mailing list), by someone who seemed (to me) to be one of the current leaders, stating that, contrary to what was commonly thought, the port isn't dead...

The "code once and reuse many times" concept allowed by a VM is attractive. However, would this allow access to all the distinctive features of the native API? Probably not.

I think the point of VMs is to offer a well-defined subset of features (VirtualBox comes to mind). The subset does not have to cover all imaginable features found in the real hardware/OS that's being accessed. The JVM has the JNI, which is a significant asset in terms of extensibility, isn't it?

Reply Parent Score: 1