eXpert Zone reports: “Straight from haiku-announce: “I’ve been thinking a lot lately, and I decided that I’m going through with finishing the USB stack (even though I don’t really like it). For my reasons of the delay, and what I’m doing about it, check my blog, I’ve just written a long post on the subject.” A first milestone release is in the near future.”
Niels, I know of you primarily through the excellent code-commitment summaries that you used to write for the OpenBeOS newletters not too long ago.
Please know that your contributions to the Haiku project, like those of all contributors, coders and non-coders alike, are much appreciated and admired by myself and innumerable others in the BeOS community.
Thank you, Niels. Keep your spirits high!
Czeslaw
…for your work, Niels. Please don’t become discouraged, even tho’ it is boring and frustrating stuff, you are a hero!
๐
Mike
Beos is holding on by a thread.
Efforts like this man’s are what keeps BeOS alive. From what I hear Haiku aims to modernize the OS. I for one think it would be wonderful to have a new-age Be operating system. I’m waiting patiently for something to boot with ๐
Depends how you define modernizing. They intend to fix the various problems with memory, new CPUs, etc. that BeOS R5 had, certainly, but at present they’re also directly cloning the APIs and apps, which, given that those haven’t changed in approximately 5 years, are rapidly showing their age, especially as compared to the offerings of the competition. Time will tell.
And yes, I’m aware of the reasons why it’s been decided to clone the R5 API ; I simply disagree with them.
Have you ever tried programming for the R5 API? Compared to something like, say, the GTK+ API (the one in C), it’s quite nice. Not perfect, but probably better than whatever a modern replacement (such as SkyOS’s) would be.
Been programming with the R5 API since R5 came out. That doesn’t mean I think it’s perfection. Try looking at something like Cocoa.
Something like Cocoa would also be impossible to do in C++.
Cocoa is heavily based on the assumption that you can simply send messages to objects, something that has immense overhead in C++ (since it is not built into the object model).
Now, what I’d like would be Cocoa for BeOS… that would rock; however, since there currently is no current GCC, porting GNUstep probably wouldn’t be too easy…
I am just developing a small app – I need something to control things via IR remote, and instead of using BeRC or something I set out to do it myself as an excercise in BeOS programming. The first impression I got is that BeOS API is really simple – I mean when I looked BeBook my first thought was: where’s the rest? Plus everything is quite transparent, no black magic. Looks like the creators resisted the temptation to use each and every trick they could think of, so it is a great API for novice C++ programmers too.
On the other hand… I’ve noticed that you quickly find doing what I, coming from the MS world, would call “advanced techniques”, whether you like it or not; multithreading, serialisation, entry/node type of file access, add-ons (plug-ins) and so on… but overall no problems so far. As for some modern features, I think BeOS API could easily be just extended to include them …
I installed BeOS for the first time two weeks ago as part of compatibility testing for a new OS database project, http://www.genezzo.com. Unfortunately the Perl implementation for BeOS was no stable enough for the project at present.
I love BeOS and hope to see more forward development.
A database on perl? are you on crack?
It’s not On Perl, it’s written in Perl. The project is lead by former Senior database architects from both Oracle and Siebel. This is not a MySQL/PostGres knock-off project, it’s goal is to implement massive, highly configurable, highly reliable, database clusters. Soemthing that isn’t easy to do today without an army of serious DBA’s.
A year or 2 ago, I had no problem compiling the latest GCC release (3.2 IIRC) with objective C, fortran, and java support (though I couldn’t figure out how to test fortran and not all of the java runtime libraries would build).
Anyhow, I was able to build the GNUStep base library (NSString, NSHash, NSDictionary, etc) and it worked great.
My opinion was the GNUStep GUI frontend/backend design would never work with the OO BeOS GUI classes to any satisfaction. However, with access to the BeOS Window Server internals, you could have a mighty slick BeOS GNUStep GUI.
I’ve been thinking a lot lately, and I decided that I’m going through with finishing the USB stack (even though I don’t really like it).
Deep thoughts of late
hardened my resolve
It really sucks though
That, my friend, is a haiku.
Don’t give up, buddy. I’ve only glancingly played with a BeBox but it looked nice. I have no idea why it never took off. It’s a far better idea than Windows ever was.