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."
Where can I pre-order an OpenBeBox?
At the very least, the Linux desktop movement can learn from BeOS's legendary responsiveness. Kernel 2.6.0 is a good step in the right direction, but GTK+ still just feels painfully slow.
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.
while I applaud the efforts to re-write beos, I wonder where these guys find the time to do so ! And even more : the funding, as I assume they still need $ to feed their families.
I've done some small-scale OS projects, and even those took a serious bite out of my spare time, up to a level where I was getting sloppy in my day-time job... I could not, in any way, manage such a huge project unless some company paid me for it. (and even then i'd probably wouldn't have the skills, but thats another matter)
When will I end this grieving ? When will my future begin ?
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.
You mean: "Who cares about this open source project I don't like. How about working on a project I do like ?"
That's the fun with hobby projects. Programmers work in their spare time on what they like and see as worth doing.
I like BeOS and I help out with an open source project for it. Would I work on another project that you think requires more support ? Only if it's fun. It's my free time and I don't get paid for it, after all.
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.
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.
You may consider it a waste of time but I assume those involved in the project don't. For example, do you consider watching a movie a complete waste of time, how about playing a board game or D&D, what about any sort of hobby you may have that really benifits no one but yourself. How about art -- maybe that doodle you did that no one else will see. Is all of this a complete "waste of time" ? If it is so what, they are doing something they enjoy for whatever reason.
No they are not required to contribute to a project that you view as more important, nor are they required to not "waste" their time. So piss off and let them have fun, hell others may benifit at the same time even if you don't see it.
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.
and make he all-in-one super-ninja-hop-chop-socky OS]
According to what standards ? or better whose standards?
Do you honestly think that all the needs of the diverse environments can be filled by a single os? Think of the difference between the server , desktop and mainframe,
Second, is the cross-distro-platform thing desirable always? doesn't it also mean that you get the denominator of all but not the 100% for the particular platform?
Third, what happens when the super-ninja approach is proved wrong, or when it hits a wall (where radical innovation is no more possible or is painful) as it seems to be happening in X servers
surely it is better to have on of the alternatives at hand (that may not have the limitations) than having to invent something from the scratch
~561
Here, here!
If Windows and the UNIXes are to survive at all, it will be among OS dilettante dabblers.
We can neither love nor pity nor forgive. If you make a slip in handling us you die!
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.
And then we'd have just another generic distro of *nix. BeOS is different, and proud to be so, to dilute the concept by using "another *nix kernel" would be to defeat the whole purpose.
I for one am very glad they don't, I really don't like *nix (or MS for that matter, but that's another topic altogether)
So rise up, all ye lost ones, as one, we'll claw the clouds.
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.
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 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.
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)
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.
Why do you NEED a reason OTHER than for sheer geekiness? Be proud of your geekiness. Revel in it! If geekiness is a crime, LET ME BE GUILTY!
Even if I agreed with you, which I do not, you are wrong even on your own premisses.
Problems can be solved in two ways. A point solution and a general solution.
Point solutions as you advocate tend to created further problems down the line so they are sub-optimal when looked at in a larger context.
Since you seem to value the Eco-system comparison, your suggested point solution is like the Koala Bear only being able to eat Eucalyptus leaves.
Not a good idea when the eucalyptus plant is disappearing. Compare this to a Rat that eats anything. FOOS development process secures that mostly Rats is being created not pretty and cuddly proprietary Koalas.
Help fight continental drift.
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..
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.
once your problem is solved move on
what makes you think the problem is "solved"?
has any OS achieved perfection?
Owen Taylor discussed GTK+ performance on OSnews recently. He wrote: "A big bottleneck right now in GTK+ performance is the poor performance of the RENDER extension drawing anti-aliased text. Even without hardware acceleration, it could be tens of times faster than it is now. I'm hopeful that the X server work currently ongoing on freedesktop.org will result in that being fixed." Neither Linux nor GTK+ are the problem. X is slow. BeOS doesn't use X. BTW, this isn't an attack on X, which I think is great. It is slow though.
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.
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...
Actually, for what it does (draw graphics on the screen) X is really fast. I've benchmarked it myself, as have many other people. The problem is in the toolkits and the applications. Its really hard to get good GUI feel* and you'd be surprised to see the number of "tricks" you notice in Windows to make it feel faster. Owen Taylor's comment about GTK+ seems dubious to me --- RENDER is accelerated (that subset used to draw anti-aliased text anyway) on NVIDIA's binary drivers, and GTK+ isn't any faster on those than it is normally. GTK+ is definately glacial. Qt, however, is pretty damn fast, as is KDE overall.
*> Things get much easier if you do what OS X (and now freedesktop.org's new X server) do. They back-buffer all windows, so the app never needs to handle expose events. They also synchronize all resize events, so the window frame doesn't enlarge until the app can draw the new contents.
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
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.