Slashdot Mirror
Interview with OpenBeOS Leader Michael Phipps
Gentu writes "Koki from the japanese site jpbe recently interviewed Michael Phipps, the project leader of OpenBeOS, the open source re-implementation of the BeOS. Read here for the english version of the interview where Michael is discussing the roots of the project, the current status, the roadmap, the choice of the MIT license, its relationship to YellowTAB's Zeta and the other efforts to resurrect BeOS, BeUnited and the Sun Java port and more."
The basic advantage of BeOS is that it's modern. It's designed with current computing principles. Windows and the UNIXes are all based on old cludge.
Be was not immune from making mistakes - their 'focus shift' to an embedded OS cost them their company.
If OpenBeOS focuses on being the happy medium between Linux and Windows, I can see it making great strides.
If Linux could get the raw speed and a consistent GUI interface that BeOS has, I could see it being a waste of time. I don't think that's going to happen. Linux and its GUIs are trying to be all things to all people.
It's not about choice in this case - it's about one thing that works (ala the ideas behind UserLinux, OS X)
OpenBeOS will be fine if they focus on the desktop, and the things that BeOS (was) good at: Audio and Video. It might be a bit vertical, but that didn't stop Linux/BSD from taking over the server market.
I look forward to the release of OpenBeOS (you can read my first Journal entry for a clue as to why).
You can keep in mind that this is the first release - the goals for this release are to recreate BeOS with binary compatabillity. Ideas for R2 are already out there and RFCs are being worked on.
I predict that we'll see some great things from OpenBeos and it's kin. Its a matter of waiting, contributing and helping where one can. Like any other Open Source project.
"A good, FOSS, real-time microkernel kernel would be a very good contribution to free and open source software."
Well, I don't know if it's realtime, but you might find this interesting:
http://l4ka.org/projects/pistachio/
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
It was designed to handle large numbers of tiny threads and fibers well. ;
>>>>>>>>>>>>>>>
No, it wasn't. BeOS didn't have fibers at all (fibers are lightweight user-scheduled threads on NT), and its scheduler started choking at around 400 threads on a 300MHz PII. What made BeOS feel fast was:
1) A preemptible, low-latency kernel, which Linux has now,
2) A scheduler that was really good at seperating interactive from non-interactive processes, which Linux is getting towards with O(1) and Con Colvias's work,
3) A GUI API that basically forced you to seperate GUI threads from computation threads.
The third one caused a lot of problems for developers, and made it hard to code really large applications and port foreign applications, so it probably wasn't a practical idea.
A deep unwavering belief is a sure sign you're missing something...
Discussions on Slashdot are good, but sometimes sterile. Do you think the Linux kernel would be a better kernel for OpenBeOS? Cool! Go help the BlueEyedOS guys. Of course, that would involve a lot of donated work to a software that may never see the day of light, but, if you enjoy coding, go for that.
I've applied gaussian blurs on images in BeOS (obviously not in photoshop, but in natively written image editting programs in BeOS), and at most it has taken a minute and a half to apply the effect. And a large part of that was buffering the image for an instant undo, if needed.
I've had similar experiences with audio effects. BeOS was written to speed up multimedia opperations as well. I don't know where you got your idea that BeOS traded multimedia performance for desktop snappiness. That's just not true.
my pet machine
One place where BeOS was beginning to see some success (before the fscking "focus shift") was as the OS behind dedicated audio devices. iZ used beos as the OS for their Radar 24 hard disk recording station, and Tascam used BeOS as the core of a couple of devices that they released. Mr. Phipps and company are hoping that openBeOS might be able to pick up where the BeOS left off in those markets. the inability to have binary drivers could turn off some of those companies from using a particular OS; furthermore, those companies might want to be able to make hardware specific changes to the kernel without having to sacrifice any information about their "trade secrets." As such, a non-GPL'd kernel would be better, from those companies' point of view. This doesn't explain why they don't use a bsd kernel (my guess is that it simply hasn't been developped in the way that they would like), but it does show why they wouldn't want to use the linux kernel.
As far as the comment from the FAQs on the openbeos site, I agree. Using linux doesn't recreate BeOS, which is what the project is aiming to do, but rather extends linux. There's nothing wrong with that, but it isn't the goal of the project. the goal of the project is to recreate beos.
Also, Be, Inc. did start to open source some of the OS (OpenTracker and OpenDeskbar), and, according to an interview I read with a former Be engineer (I'm sorry, I can't recall his name) Be had plans to free more of the code, but found themselves in such a bad situation financially that they never had the chance to spend any time or money on opening any more of the code base.
my pet machine