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.
about not using linux or a bsd kernel. then they'd get all the drivers for free that those projects have... think anyone's going to bother writing drivers for ANOTHER kernel with a fraction of the mindshare? dream on.
... :(
He even says in the interview that the kernel is one of the 2 areas most in need of development help. Wake up!
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
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?!
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.
Sure BEOS has some neat tricks (don't they all?). But what features does it have that are (as good as) impossible to port to Linux?
10 ?"Hello World" life was simple then
AmigaOS and BeOS, both great OS's but dead in the real world and finding niche markets or just fanboys.
Well, I won't be convinced until I see the Netcraft results to prove it. I'm no Kreskin.
We can neither love nor pity nor forgive. If you make a slip in handling us you die!
You're stupid. BeOS, failed? As if one failure is a reason to stop doing something...
...
OpenBe is wonderful. Having numerous OS choices to select from is wonderful. Cheers to everyone who wants to and does make their own Operating System
Having all these OS's around will serve one purpose: it'll devaluate the OS market. Good.
That needs to happen.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
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.
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.
"Why do people not port their projects -- BeOS -- to Unix (clones)"
Because it wouldn't be "BeOS" then?
"Every BeOS project owner waiting for a fortune will get demotivated sooner or later."
Maybe there are more important things then 'fortunes' that motivate people...
We apologise for the fault in this post. Those responsible have been sacked. -- Signed RICHARD M. NIXON
The point of computing is to solve problems, once your problem is solved move on.
This whole "re-inventing the wheel" NIMBY bullshit is why Free Software is a huge joke in the corporate world.
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.
Ok, so what happens when you get for example a wireless card that isn't supported by your distro or pretty much any distro? you download driver code and have to compile it of course.
This is not just an example, this is exactly what I have had to do with all the distros I have tried on my laptop.
I do, for precisely this reason. ;) However, there are plenty of people who judge the entire speed of desktop Linux off of Gnome and Mozilla.
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!
And why is that an invalid set of criteria? If your apps are slow, the end result is your computer using experience is slow. To a user, it doesn't MATTER where the problem is at.
I wanted to take a BeOS test drive, and potentially use it in the future if I like it (...more than Linux) but I'm not sure where the OpenBeOS development is, is it something I could just install and use, or is it like 90% placeholders, "not implemented yet", "this thing will go here", and I should just go with the old original BeOS closed-source binaries?
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
There's some neat things in that OS for sure. But I thought they renamed it to WasOS?
but why (aside from geekiness)
For godsake dude, where are your priorities?!?!
-- MarkusQ
P.S. I am serious as I ever get.
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.
I would like to know what the performace issues were that kept them from using Linux (or a BSD for that matter) as the kernel of OpenBeOS. I read some comments that said that Linux wouldn't provide the right feel. What does that mean? I know the scheduler makes a difference in GUI app behavior but that is something which can be tuned to different behaviors. In any case, I'm sure that OpenBeOS with a linux kernel on current hardware would provide the right feel... fast. I know it must be cooler to develop NewOS, but the practical thing would have been to use the tens of thousands of developer-hours of the major kernels (Linux, BSDs). Maybe they just didn't like the ambiguity of using a mainstream kernel. After all, when we talk about OS's we usually talk about kernels. If they used Linux as the kernel, then it starts to look like they are developing OpenBeDE (Desktop Environment) instead of OpenBeOS. But that doesn't seem like such a bad thing to me. Modern, C++ based, great API DE, runs on Linux! That is exiting. An operating system with sketchy hardware support is not.
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.
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.
You're telling them and us that there is no value in them producing a non-Linux/non-BSD kernel and therefore, to get there quicker, they should use Linux or BSD. I'm telling you that there is value, and therefore they're justified in taking the extra time to do it.
And I'm pretty certain they'd consider it a trade-off that's not only valuable, but absolutely necessary to produce an OS that works the way they want it to. Linux is not the greatest kernel ever written. It's not the solution to every problem.
And, of course, there's Syllable, which works the way you want it to (a BeOS-like user-land on top of a Linux kernel.) So it's not as if OpenBeOS is preventing you from getting the OS you want.
So, in the nicest possible way, mind your own business! And my best wishes to the OpenBeOS people, I really hope something comes out of this project.
You are not alone. This is not normal. None of this is normal.
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
That Explorer freezes on a file-tree expand is the fault of Explorer, and it would be Explorer's fault under BeOS if it were written that same way. The kind of fined-grained I am talking about is on the submillisecond level, important if you are doing video frames where a 10 ms lock will cause a frame to glitch. Those 10 ms locks are deep in the OS, and faster CPUs have reduced them to 1-2 ms locks. And as for hyper threading, its existence may encourage kernel designers to tune for allowing more preemption without worrying that the system will stall doing context switches.
Well, once you get a few more CPUs, and you learn to push the vector math to the vector processor, then you begin to feel the difference.
BeOS predicted that eventually, Moore's Law would begin to fade or would periodically dip so that SMP systems would be employed to gain performance. The heavy threading will make it trivial to scale performance approaching linearity with the number of processors.
Think about fiber busses on the system board. Think stackable external CPU modules. Think Beowulf... (sorry, couldn't resist)
--- Nothing clever here: move along now...
not using linux or a bsd kernel.
Are you suggesting they make BeSD?
You like your new Mac more than you like me, don't you, Dave? Dave? I asked...She said Yes.
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.
I did, in fact, mean NIH.
Thank you for clarifying that for me.
I am not saying that I agree with the stubborness of the OBOS group, I was simply pointing out that from my admittidly *limited* understanding of the original BeOS, it is effectively different than Linux, and that Linux is not a one-shoe-fits-all solution -- rather there are perfectly valid reasons for wanting to implement something on the order of the original kernel rather than grafting just the 'experience' of the BeOS onto another existing kernel...even if that reason is essentially novelty.
We apologise for the fault in this post. Those responsible have been sacked. -- Signed RICHARD M. NIXON
Well, not exactly. If memory serves, Syllable is an actual fork of Atheos. Perhaps you're thinking of Cosmoe.
xScruffx
D'oh! Yep, I meant Cosmoe.
You are not alone. This is not normal. None of this is normal.
... why to reinvent the wheel?
IANAL but write like a drunk one.
The Linux guys are saying: "look, do not waste time, use the Linux kernel, twist it and get the same functionality you used to have, that way you get drivers and many other things without the innordinate effort (we are talking about millions of loc!)".
If I see a felow pedestrian going to fall in the same hole in which I just falled in, what I am suppossed to do? Warn him or wait there to laugh at him once he falls?
IANAL but write like a drunk one.
Mmmmmhhhhh
IANAL but write like a drunk one.
http://www.blueeyedos.com/project/license.html
otherwise they lack any credibility due to the confussion....
IANAL but write like a drunk one.
Damn, you're right. Thank you.
/. as a silly message board, and not a goddamn term paper or something where I have to proofread and edit my shit five-hundred times.
The thing that bothers me is that I wish I could treat
I always notice things I wish I could revise but don't have the ability to. Oh well. Fuck it.
We can neither love nor pity nor forgive. If you make a slip in handling us you die!
The nvidia driver doesn't use hardware acceleration for the RENDER extension ... at least not by default. The README reads:
"Option "RenderAccel" "boolean" Enable or disable hardware acceleration of the RENDER extension. THIS OPTION IS EXPERIMENTAL. ENABLE IT AT YOUR OWN RISK. There is no correctness test suite for the RENDER extension so NVIDIA can not verify that RENDER acceleration works correctly. Default: hardware acceleration of the RENDER extension is disabled."
I don't know whether you specifically enabled hardware acceleration for RENDER, but if you didn't then GTK+ ought to perform similarly using the closed drivers and the open drivers. Last I heard, only Matrox cards supported hardware RENDER acceleration in a non-experimental way.
I enabled RenderAccel. Its a nice boost for Qt/KDE (where it makes text highlighting and scrolling much smoother), but using the nvidia driver at all (RenderAccel on or off), makes GTK+ resize even worse than it does already.
A deep unwavering belief is a sure sign you're missing something...