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."
Image all those webpads or Tablet PCs and arrange a setup of those components (TC 1000 or a cheap webpad) it will cost about 2000$/EURO, put a Open Source OS and a Point-of-Sale software on it and safe money
I think all embedded solutions with OSS have a big potential.
Ok not to sound mean but aside from niche markets why would someone want to take BeOS serious, and I'm asking this as if I were a CTO'ish person. For one, with all the garbage being funneled into things *Open Source* by companies like SC(um)O and Mickeysoft, the entire *Open* anything is something I would (if I were purhasing) stay away from until the smoke clears.
Now I'm not saying BeOS is garbage in fact I have an older cd lying around somewhere, and it's pretty neat, but why (aside from geekiness) would I want to look to BeOS when there is so much confusion going on as is in the Open Source community for one, secondly it would have to mean I would have to take a backseat and chop up tons of code to get other programs I use frequently -- that are ported to other implementations of *nix (bsd/linux) -- to work on the BeOS machine. Meaning, if I downloaded just about any distro of BSD or Linux, I am almost certain I could get most 3rd party packages/ports to work, in BeOS (and yes I am assuming here) it's more than likely I would either have to wait or redo some code, so its not an option for me since I have no time.
Really I think its nice but nothing more than a hobby, I wish more developers however would come together under one roof and make he all-in-one super-ninja-hop-chop-socky OS without one having to wonder if a) there is support, b) it's cross `distro-able`/`platform-able`, etc.
My rants for the day fire away
MoFscker
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.
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.
I'd rather see a unified and open driver interface that multiple operating systems and architectures could use without the porting. Then you'd only have to implement the interface, and just nick the drivers from somewhere else.
(oh, OT: yeah my website is down for the moment. Working on it)
>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..
Most of these people even think that Linux developments are a waste of time.
Linux gets some new kick-ass threading? WAH, it breaks Wine. Bruce Perens is coming out with a new distro? WAA, just use Gentoo. Oracle is making Linux their primary platform? BOOHOO, use mysql. RedHat has a new C++ compiler? MOMMMY, it's not an official release.
Basically you are dealing with the Technology Taliban here. The only stuff that's "good" is Unix and Perl and other "Back To Basics" fundementalist crap that's older than they are. Everything else is "bad" by definition.
I think the best news in the whole interview is that they will change sockets to be more like file descriptors.
"but money is the God of Algiers & Mahomet their prophet." - Rich. O'Bryen June 8th 1786
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.
Well, "Technology Taliban" might be a little harsh, but you're examples all show the basic insecurity that most people share.
People fear change in general, and when you've invested a lot of time & mental effort in learning a certain OS or language, the threat of having to learn something new, and all the associated stress can cause people to enter whine mode pretty easily.
Yes it's true, BeOS traded off REAL performance (as in operations actually completing faster) for responsiveness.
So that the system feels faster. Which is when you think about it perfect for a desktop user since they rarely actually need any true performance. The mouse was responsive, things appear on the screen in a blink... to a desktop user that's heaven, even if it takes 4hrs on to apply a basic gaussen blur to an image in photoshop on a 3ghz processor with a gig of ram.
Being a long time Mac user, I liked the features and responsiveness of Be, but overall the potential of the OS came from the fact that it had a comprehensive, predictable environment. Like Mac OS you could just tell that there were certain rules at work. The GUI was consistent. The programs all behaved according to an understood structure and it was easy to see that in a few years the relatively nasty command-line-esque parts were going to be relegated and the whole OS was going to be a GUI power tool. It was the leanest, trimmest thing out there and this is what pro designers etc. want with their tools. Even today with OS X, there just isn't the feeling of power or freedom to do things as quickly as you want. Windows and Linux are like sludge in comparison, not just for pure speed but in the endless UI clutter everywhere. I think finishing what Be started is a great goal to have. In the least it will set the bar high for the commercial OSes and perhaps finally force Linux to get its act together on the desktop.