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."
This is not a development effort of "just because I want to". A new OS that is open source increases the size of our OS ecosystem...this is one of the greatest threats that Linux poses against MS. Linux today enjoys widespread support, but having more choices out there is a very good thing. Who can say what the OS landscape will look like in 5-10 years? Think back even five years and you'll see what I mean!
As a supposed Linux user, would you then bash OBOS because it wasn't Linux? That's hypocritical at best, and spiteful at worst.
You can have my one-button mouse when you pry it from my cold, dead fingers.
that OpenOS/2 is where its at?!
Driver support shouldn't be that much of an issue - the beauty of Linux and the *BSDs is that if they have a driver and your GPL'd OS doesn't, you can take it. It's just a matter of finding a programmer with some spare time.
IIRC, Sun even has a set of libraries for Solaris to make it easy for someone to recompile a Linux driver for certain types of device to run under Solaris. Created much controversy when it first came out because SunOS isn't GPL'd, until someone realised that this would only ever get used by vendors of equipment (who'd written their own Linux drivers and thus own the copyrights) and end-users (who do not need to worry about relicensing GPL'd code as they, by definition ("end-users"), will not be releasing it to third parties.)
I'd have thought the OpenBeOS people could do something similar.
You are not alone. This is not normal. None of this is normal.
It's horses for courses. As the article says, Linux was designed for server use, and the BeOS for desktop use. The BeOS had a special feel to it, as the most responsive and multimedia capable OS of it's time. It was designed to handle large numbers of tiny threads and fibers well. Sure you mould a BEOS lookalike system around a Linux Kernel, but it doesn't mean it would feel like BEOS.
In Kurzweils excellent book Age of Spiritual Machines he is referencing some computer experiments on developments of Artificial "Lifeforms".
One of the unexpected things the researchers found (can't remember who it was) was that increasing the "Mutation rate" was not enough. You needed a complex and rapid changing Ecosystem.
OS's that finds it way into new application areas provides presicely such an Ecosystem that the dominant OS might later adapt to.
As an axample we can look at embedded devices. The pressure from Symbian in the Smartphone market causes Linux and Windows for that matter to change and adapt. The adaption does not need to be Monolithic as is the case with Windows but an OS bifurcation is fine and actually more akin to the real world evolution. In that sense OpenBeOS can be a real plus to everyone. User or not
Well, Your point is well taken
Help fight continental drift.
BeOS news always generates the same responses: it's unnecessary, it's unteneble, it falls short of expectations, etc. BeOS seems to receive more criticism than most other underdog OS's because--to some minds--its irrelevance has already been "proven" by Be, Inc's failure, while most others have still to define their niche--or are still too immature even to fail to compete.
At this point I don't know whether I consider BeOS to be worth defending. I guess it comes down to these questions: is BeOS fundamentally a more efficient platform for multimedia development? Is Linux architecture so different as to be incapable of matching BeOS performance in regards to MIDI performance, audio processing, nonlinear video editing, or 3D development? Is the performance gap substantial?
Even if the answer to all of these questions is "yes," surely it is not so when comparing 64-bit Linux to the BeOS (with the exception of MIDI performance). And if 32-bit Open BeOS is so difficult to realize, then how much moreso for a 64-bit BeOS?
BeOS has a potential market in that there is no other "multimedia OS" as defined by Be, and for that reason there are hangers-on. Sadly, the implications brought up in previous BeOS discussions suggest that BeOS itself fails as a multimedia OS. If anyone has any encouraging counterpoints, please share.
It seems to be a /. point of view that anything outside of the Linux arena is a waste of time in some manner. If these folks want to try to revive BeOS, what business is it of yours, and why go on about it?
There's 3 things BeOS had going for it - lighting fast GUI responsiveness, excellent handling of both audio and video media, and a way before it's time journaling FS that allowed you to yank the AC plug out of the wall with no data corruption. I daresay only one of these has been implemented on *nix ( the FS ) and the other two are still MIA. Until you open source guys get linux up to the same speed in the other 2 areas that they are concerned with, dont bother asking why they are working on OpenBeOS. They are doing it becuase even after 5 years not one operating system made compares in those 2 areas.
And in general, pissing on other peoples parades shows insecurity about what you are doing. Let em alone.
The whole time, being a Linux user and developer, I was talking about opensourcing this and that, there was so much opensource in BeOS to begin with, why not take the bull by the horns. Be used Linux as a host platform to develop beos. Be used GCC. Be carped driver designs, and an OS platform from GPL libre software. Nothing ever happened. I even wrote to the company and explained it, the response is that we don't want to help linux, we want to be Be. Now the community is doing this and they are still against Linux; their FAQ even mentions that OpenBeos on linux would be an extension to linux and that is somehow a bad thing.
Long story short, I've got no sour grapes, I don't care about the money, time, effort or anything else, I think some of the ideas behind beos are cool. What chaps me is the unwillingness to play ball and the simple lack of a techincal explanation as to what Linux or BSD kernels (which ones did you look at?) doesn't do that the be kernel needs. Are we talking new APIs? Are talking messaging queues? Latency isn't there (I call bullshit on this one, especially with 2.4 and now 2.6) what exactly is it? In the interview he even says outright that he hasn't gone very deep, pretty much just dismissed it.
Be's problem as a company and a community has always been lot's of talk with no beef and some awful fear of playing with others. "Pervasive threading this," "media OS that" what does that mean? Why is it good? You'll never get an answer with numbers, at best "it feels" will be said. Further, in specifics, what is it that you need the linux kernel to do and why is it easier to start from scratch rather than fix linux to do that? Even if it isn't rolled into mainline, look at ucLinux, rtLinux, and other "forks." I'm simply asking as an engineer, which problem space is bigger? Again, I wish them well and have no real sour grapes other than I really want a project like this to succeed and from the information presented to me from them they aren't making good engineering decisions and aren't making a plan for success. If it's simply an experiment and they want to do it all then say that, but they aren't saying that and that makes me think they either don't know or it's some cultural flaw and either way I don't think it is a good thing for their success.
There's some neat things in that OS for sure. But I thought they renamed it to WasOS?
>What features does it have that are (as good as) impossible to port to Linux?
:BeOS used the standard BiOS..
:-(
I don't know if those feature are impossible to port on Linux, but so far they haven't been replicated on Linux:
1) fast boot time: BeOS booted to the GUI on ~10s (to a usable GUI! Not like WinXP..), on Linux it take far longer, booting the kernel is slow, and KDE is quite slow to start too.
Usually, after this, someone remarks that with Linux, you don't have to stop your computer, true, but my computer is very noisy and I like to sleep at nights!
So fast boot time is quite interesting for desktop users, and no LinuxBiOS or equivalent doesn't count
2) responsiveness: BeOS apps felt very responsive, you were never "blocked", I think that the extensive usage of thread in the apps was the reason.
As a counter-example, there is Mozilla: if it doesn't manage to reach a server for a new page, the whole window can become freezed, in a responsive application, I should be able to continue browsing with the other tabs..
Unfortunately I don't really think it was a BeOS kernel thing, otherwise it would be easy to replicate, I suspect that BeOS guidelines for programming apps were pushing the usage of thread which explains the smooth end-user experience..
And changing the design of Linux applications to become smooth will take a looonnng time, if ever.
Oh and I'm not trolling against Linux, I just explain what my end-user experience of BeOS was: much better than any Linux so far, but with too few apps!!!
All BeOS technical prowess meant nothing as there were far too few apps..
While Java tries not to be tied to any one OS, you kind of see the OS poking through. Java too has a single-threaded GUI, and you are not supposed to invoke methods on any GUI object from other threads apart from InvokeNow() (guess what -- SendMessage()) and InvokeLater() (also guess what -- PostMessage()). The advantage of the single-threaded GUI is that any GUI method is in effect synchronized -- each GUI method is essentially its own critical section that won't get stepped on or poked at for the duration of its execution, and variables won't get changed unless you SendMessage() or PostMessage() (i.e. cooperative reentrancy) to somewhere else.
How does this work when you have a multi-threaded GUI -- are you declaring entire methods "synchronized" or have to have locks up the wazoo, or are there some easily-understood protocols?
Now apart from the single-threaded GUI, Windows has a way of "going away" for 10's of milliseconds at the system level -- disk reading is very coarse grained, and they say it is for performance reasons. These hyperthreaded Pentium 4's are creating very cheap context switches while the processors are getting so much faster that what used to be 10's of ms is now in single digits, so Windows and Linux and whatever are perhaps getting to multimedia Nirvana by brute computing power. Moore's law, yes BeOS can do it all on a 60 MHz Pentium I, but no one is running a 60 MHz Pentium I these days.
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.