Guillaume Maillard of the BlueEyed OS is talking to TotallyBe. He speaks of the differences between their project and OBOS and Cosmoe. He also claims that when programmed for and/or patched the right way, the Linux kernel and XFree can be very fast and perform pretty adequately to BeOS 5 (UI responsiveness – the main advantage of the BeOS experience), while in most of the “other” cases, Linux is much faster than BeOS 5 (eg. server operations, compilation times, SMP scaling, VM etc). I have personally talked to Guillaume and also tested some of his BlueEyedOS code recently and indeed, XFree can be fast, when you know how to directly program for it (without using layers and layers of other libraries that is). No matter the tricks and optimizations though, XFree/Linux kernel can’t be as responsive as BeOS at the end of the day, because of the way the BeOS was built around the push programming model and extreme multi-threading (‘fast’ is not the same as ‘responsive’ – BeOS’s UI is extremely responsive, but the OS *underneath* is not ‘fast’ on many-many cases). These vast differences in architecture between BeOS and the other traditional OSes, made BeOS a heaven for the user but a nightmare for the developer whose applications involve more than one window or might be a bit complex.
Interview With Guillaume Maillard of B.E.OS. Project
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
any screenshots yet? i think they have a designer on board, whose beos-like interfaces look nice…
You never clicked on the first link didn’t you? There are screenshots linked from the BlueEyedOS homepage.
If what they said is true, it certainly would be interesting! Actually I’m very excited about the Gonx UI… SUPER LOVELY, very clean and has good usability… I want larger icons though.
I just hope they are planning for another OS rename. “Blue Eyed OS” is IMHO pretty horrible! I would vote for
“Best Ever OS” or something more catching.
-fooks
The one thing I agree with is the choice of kernels. The problem with the NewOS kernel, despite how modern is, is all the drivers that have to be written for it. I would have chosen a BSD kernel, that way you get all the drivers, etc, for “free’.
If pretty adequately was good enough, I would jump to Linux or Winblows etc…
You gatta have BeOS UI speed and low latency.
Frankly I think only PalmSource can deliver this at this point.
David Nagel missed with Copland, Sakoman kinda missed with BeOS R5. They need to join forces and deliver us from the evil empire! They have the resources to produce an absolutely stunning OS! They are NOT stupid, they will do it at the right time!
ciao
yc
“They need to join forces and deliver us from the evil empire! They have the resources to produce an absolutely stunning OS! ”
I’m wondering if there is an ‘applications team’ to go along with the OS developers? I mean, who cares if the produce a ‘stunning OS’ if the only apps we have is whatever was binary compatible with R5 ?
>They are NOT stupid, they will do it at the right time!
No offense YC, but the only “stupid” person here seems to be you. After years, you still haven’t accepted that BeOS from Palm/Be, as you knew it, is dead since April 1999 (yes, this is when the death started for Be’s board of directors and managers). Palm has no interest in creating a desktop OS that would succed BeOS or Windows. Their OS business is simply PDAs/embedded. End of story.
>Sorry, pretty adequately is not good enough for me…
You forget that when BlueEyed is going to get released, everyone will be running more than 3-4 GHz machines. Trust me, it will be fast enough, no matter what.
“You forget that when BlueEyed is going to get released, everyone will be running more than 3-4 GHz machines. Trust me, it will be fast enough, no matter what.”
And KDE will start up in .000001 seconds. Yea right. You forgot that software developers like to update their bloat.
>You forgot that software developers like to update their bloat.
This is true. But BlueEyed OS would only use a modified X installation. X hasn’t change too much over the years.
Say it with me…. B..E…..OS.
I like it.
I think all former BeOS-o-philes (and I’m one of them) should be forced to include benchmark results with everything they say. Here are some:
1) XFS can sustain 25 MB/sec large file reads on my Maxtor 20GB hard drive. BFS could do about 22 MB/sec.
2) Compiling a mix of GNU utilities on BeOS (gcc 2.9) took 10 minutes on Linux, 13 minutes on BeOS.
3) Sustained audio latencies for the Linux kernel are down to < 1 ms. For the BeOS kernel, they’re around 3 ms.
4) In Quake III (representative of most gaming benchmarks) Linux essentially equals Windows performance: http://www.evil3d.net/articles/linux/pageflip/?page=4.php3
Note, the odd results for some middle resolutions has to do with NVIDIA not having completely enabled page flipping for certain resolutions. This should be fixed in the next release. Also, note how at lower resolutions (where the benchmark isn’t video card limited), Linux is faster, indicating that the OS has less overhead.
5) Even with older drivers, pro-level 3D on Linux is essentially competitive with pro level 3D on Windows.
http://www17.tomshardware.com/graphic/00q4/001002/linux_nvidia-08.h…
6) The XAA accelerated primitives are quite fast. On my old P2-300 with RivaTNT, I did a test that drew some lines. I don’t remember the number of pixels per line, but I remember that my tweek software implementation did 60 thousand lines per second, GDI did 40 thousand per second, and X did over 100 thousand per second.
Plus, all references to BSD, Mach, OS X, QNX, etc being faster (desktop-wise) than Linux should be deleted unless the poster provides proof. Mach is an antiquated system that is widely regarded as a bad microkernel in comparison to modern systems. OS-X posts lmbench (tests basic UNIX kernel operations) half that of Linux: http://clustermonkey.org/~laz/pbook/rob.lmbench.txt
BSD is fast in many ways, but suffers from high latencies (and the SMPng project hasn’t matured to the point where the time consuming process of identifying all long-held locks has been completed) and a fairly outdated version of the OSS audio system. QNX has a horrendously slow filesystem (on IDE drives) slow networking, and a real time scheduler entirely inappropriate for desktop applications.
Look, Linux does have a lot of problems. But let’s try to keep things grounded in reality and facts, not abstract idealistic hopes.
No, Rayiner. YOU look. You posted this huge rant over here, which reads like that you reply to someone who said something that beos is faster than linux, while no one said that.
I am THAT close of moding down your comment (while I AGREE with it in most of its parts (but not all)), just because your post reads like an angry reply to someone that does not exist.
Even in the news post, I clearly say that BeOS only had a responsive UI and on the rest operations Linux is generally faster. So, WHY was a need for this rant, when we all agree? I really do not understand it! I mean, really.
Your post reads like this:
“Oh, no one actually said that beos is faster than linux? Well, I will write this comment, so I can start a fight, even if there is no need for one, and even if everyone seem to agree with me overall…”
I am really puzzled.
When I first experienced BeOS(R5), I was amazed by its visual beauty and clean structure, compared to Linux I had been introduced to several years earlier. For me it was like Mac compared to MS DOS(My first computer was a 8086 PC and the second Mac Classic till Pentium 133 got really cheap).
But I never understood why there were several conf files in BeOS. There was a possibility to store e.g. kernel settings in attributes of, say, kernel_x86 in a perfect world, wasn’t there?
I think that there was already too much legacy in BeOS imho, considering what Be’s marketing said about BeOS’s capabilities. And there’s even more to come, considering Linux kernel. There’s already a need for several directories, for boot, X11 &c.
Unless several modifications are made in the “standard” Linux structure , the same clutter remains. They may say that they have eliminated the clutter but that may break the compatibility…
i believe he was responding to yc’s and chris’s post about linux being substandard for responsiveness (broad term) compared to bsd and beos. i rather agree with his post (though he did have an angry tone as you point out)
we keep thinking back to the good ol days of beos, how slick and responsive it was. i think hes merely contending that its not as though the beos kernel had magic dust sprinkled all over it… there is no reason why linux (today) can’t do all the things that the beos kernel did so well.
Thanks for the clear up Joshbuddy.
My opinion and personal experience with all these OSes I run here, is that BeOS had and will have for the years to come the best UI responsiveness, because of its architecture. No other OS will be able to match it, simply because none of the other OSes try to mimick the “push programming model” neither they are so multi-threaded (AtheOS/Syllable is not so much either, and it is not complete either, e.g. they have no real VM system, very basic scheduler).
But when it comes to real speed under the hood (and not what the user *thinks* that’s fast), Linux, BSD and Windows are faster than BeOS.
BeOS 6/Dano with BONE had a lot of such fixes for networking speed while some good changes to the kernel was going to happen as well, so BeOS could match or become faster of the above OSes. But that was never finished… (and please don’t tell me about OBOS and B.E.OS, both are years away from their targets).
“Frankly I think only PalmSource can deliver this at this point.”
I’m not going to hold my breath waiting for Palm to deliver anything, and if they do, I doubt that they’ll be too concerned about delivering the “BeOS experience”.
No, the only way BeOS will continue is through one of the projects, like OBOS.
A BSD license is a big risk in my opinion as nothing will prevent Microsoft from taking the code and selling copies of OpenBeOS
If I was to write a piece of code, I have no problem with this. But I doubt Microsoft would use OBOS code because OBOS is so technically different to Windows.
As a software engineer I can’t resign myself to ‘spend’ hours developing them and see my work used in commercial applications.
Many of the people behind OBOS plan to have some commercial activity. Using a copyleft license would only hamper them. Take WINE for example, before it was relicensed, CodeWeavers could make their distinct product, Transgaming could make theirs… (though I think Lindows pushed for CodeWeavers to relicense the code).
Another good example is BSD themselves. If BSD was under the GPL or LGPL, Apple wouldn’t consider BSD. If they would consider it – why choose it over Linux? Now, look, many of the core BSD developers are now getting a good salary from Apple. While projects like FreeBSD goes on as usual, in fact probably with a bigger momentum.
GM: Because of the license issue, B.E.OS can’t join OpenBeOS but OpenBeOS could join B.E.OS.
I don’t think that’s a very good idea. What is a better idea is to have source compatiblity between the two projects.
GM: OpenBeOS: This project has a good chance to succeed (even though I believe that binary compatibility will slow down their progress)
Binary compatiblity can be easy in OBOS’s case. Why? Take OpenBFS for example, you just drop it in a standard BeOS installation and replace BFS. The authors can detect crashes by apps after the replacement. The same goes for all other parts.
BC on B.E. OS would be very hard, because Linux is an alien platform, which is the reason why WINE doesn’t work that well.
Besides, on QONX, it really looks nice. But some of the stuff I see doesn’t have any practicallity behind it….
I just got to thinking…are any of these BeOS clones using, or planning on using, the OpenTracker/Deskbar code since it was open sourced by Be a while ago?
I just got to thinking…are any of these BeOS clones using, or planning on using, the OpenTracker/Deskbar code since it was open sourced by Be a while ago?
IIRC, OpenBeOS plans to use it. For B.E. OS, I’m not sure (you think Apple develops its stuff in very close enviroments, check out B.E. OS development!)
Hello I just want to say that XP/windows2000/Linux or whatever OS doesnt have “that” feeling when you are using the OS as BeOS has.
BeOS is more joy then sorrow, and I havent experienced that with the other OSes.
And to all the B.EOS I really like your work, but guess what.. you are recreating a new Distrubution of Linux (what I know the Kernel *Is* Linux)
And you can run the other things with Hurd etc…. But I might be wrong Iam not a Linux User.. and I will not be until B.EOS release its new Linux Distrubution that lookes and acts like BeOS.
I think the name BlueEyed OS is rasistic, and dont fit for a name for an OS. Why not change to Best.Enviroment OS or something similiar.
Its also easy to read DOS on the end..
I know that It sounds like a paradox when I am writing,.. (didnt get so much slepp this night)
Quotes from the interview, comparing BeOS and Linux speeds, implying as untrue that BeOS is always faster:
>>
In terms of performance, using a Linux kernel doesn’t necessarily mean poor performance. The BeOS kernel is not exactly the greatest kernel either,…
I’m always surprised me to see how linux and XFree can be really fast (and better than BeOS) if correctly used…
Forget what you have seen when booting a linux distribution! Linux can reach easily 3ms about audio latency, can boot in 20s and can be as easy to use than BeOS. XFree86 is not a slow beast…
>>
You don’t necessarily have to anwser a previous post, you may perfectly anwser something that the topic stated tacitly and/or explicitly regarding BeOS and Linux speeds. That is simply what Rayiner Hashem was calmly doing, adding his comments to those of GM regarding a supposedly untrue assumtion. And that is something that has hurted the real natural self righteous ranter, she is a modding down expert.
I believe that from a user’s experience point of view, first you have to select which kind of completed environment we are comparing (not alpha projects), then you have to consider all the OS features, not picking up for benchmarking only this or that. And it would also help to benchmark something that the targeted type of user (not just any user) *is* using. Having all that in mind, to date, it is ridiculous to say that a Linux graphical desktop with similar features is faster than a BeOS graphical desktop.
BeOS is long ago dead, and improvements in Linux will naturally will show faster speeds, but I use both systems, and no *actual* benchmark will convince me of Linux being faster on a similar graphical environment. Tough reality is that nowadays, unless lousily hacked (not for production purposes), “X is dog slow” and the “DOS of windowing systems” (Maarten Hekkelman and Matt Dillon dixit). Too many people don’t understand, that’s an old problem with Unix.
“No matter the tricks and optimizations though, XFree/Linux kernel can’t be as responsive as BeOS at the end of the day”
You’re forgetting ‘Moores Law’ Eugenia… every 18 months Linux gets faster and BeOS won’t boot
I agree with you: the Linux kernel is more powerfull than BeOS kernel.
Still, I can remember that when I tryed BeOS, everything was more responsive and non-blocking
1) More responsive: even if raw X can be fast, I think that piling layer over layer slows down end-user application because it’s hard to say who is the culprit.
I remember that someone said that he hope that the “shared reference” problem of KDE will be solved soon because this way application programmers will stop using this excuse to explain bad perfomances.
2) non-blocking: many application in BeOS were multi-threaded, so when one windows was busy doing complex thing, you could still work in another window.
I’m using Mozilla and I like it but sometimes in one tab it is temporary freezed and I cannot switch to another tab to continue working..
These userspace problems of Linux applications cannot be easily benchmarked..
You’re forgetting ‘Moores Law’ Eugenia… every 18 months Linux gets faster and BeOS won’t boot
It will be faster in not booting 🙂
The appeal of BeOS was the overall impression, it was reasonably fast, and very easy to install most of the time it just worked.
Sure there are a lot of things which could be improved, the listview is slow, directory listings crawled with a large number of files… and It needs a better browser and more drivers.
But it was fun running BeOS.
Hi…
I have not used BeOS (tried installing PE5 but couldnt run on my PC). People keep saying its the most responsive, best looking GUI.. etc etc.
Linux kernel can be tweaked to get the desired responsiveness, cant it ? (I know that realtime OS (eg Qnx) can adjust process priorities. Also Mr Rayiner Hashim’s post in different thread about changing process priority in Linux ie using command nice ).
Thanks for your benchmarking post..
> QNX has a horrendously slow filesystem (on IDE drives) slow networking, and a real time scheduler entirely inappropriate for desktop applications.
Appreciate if you (or anyone) could elaborate more pls… Thanks.
However, I agree that qnx fs is slow for desktop purpose though. But for embedded devices, I think the qnx people still think qnx fs is good compare to other fs.
BeOS vs the rest
I am running BeOS 5.0.3 with two instances of setiathome and BAIM — the BeOS version of AOL Instant messenger, Opera with 5 open Windows and Mozilla with 5 open tabs. I am using every cycle of my CPU to keep all of this running, and I just started a large download and had to browse to the folder to place the file. I see no slow down when the system is under this heavy of a load. There is no hourglass or clock icon for the mouse curser in BeOS as the system places the user input and most recent selection at the highest priorety it safely can. Windows XP, 2000, 98 and Mandrake Linux all seem dog slow when placed under a similar load. BeOS rocks!
If BEOS can reproduce this kind of user experiance using a Linux kernal then BEOS Linux just might take over the Desktop from Micro$oft.
Eugenia, help please.
I don’t think I’ve seen the term “push programming model” before. I did a quick search on Google for the phrase and didn’t see it (though I only spent a few minutes searching), and the index in Tanenbaum’s “Modern Operating Systems” has only “push server,” which is a server that pushes data to the user, rather than the user (the program on the user’s machine) having to make repeated “read” calls to keep the data coming.
So does “push programming model” mean organizing the system around sending data to the caller without the caller having to keep asking for it?
with having almost the same stuff on top of the kernel it will tell each kernel developer what could be squized more of the system. At least until both are equal speed.
It will be good for the “consumer” even if it’s not commercial stuff
Sega used to always have 2 team to develop their console in paralell then choose the best aproach. I think more company should do that, intern competition is the best idea since the manufacturing chain of Henri Ford.
Here is an example to understand it, and it also demonstrates HOW the BeOS UI was able to be so responsive.
Let’s say that you are programming a word processor and that you are trying to parse a big document that might require some more CPU cycles because of its complexity (eg. a big doc file or a big pdf).
Let’s say that the user pressed the “Save” command and the document is trying to save the document, while might take some time to do so because of the complexity involved. Now, let’s say that the user presses the menu bar, or one of the icons in the icon bar. **ALL** other OSes, LOCK the UI when something like a “Save” process is taking place to ensure that nothing gets screwed up. This locking on other OSes, make them feel “slow”. On BeOS, this does not happen. The UI is *live* at ALL times. Now, think that the user wants to make a change in the document and types something, while the document is still saving in the background! What does the OS does? It allows it!
It is the programmer’s job to think about ALL the possible scenarios of what the user might do in the situations (that on other OSes the UI would have been locked). It is a lot of work for the programmer, and with the complexity of the multi-threading programming (most programmers do not know how to write mt code) it really makes programming for BeOS a huge pain in the a$$, when the application does a bit more than a “hello world”…
In the push programming model, you got all these BMessages that you need to process at ALL times, even when you do something else.
Because of this, the BeOS UI is and will be forever the most responsive UI ever. Users of the world rejoice. But with a huge price for the developer. No wonder that many porting processes were doomed to failure; these apps were not designed to work the way BeOS expects them to behave and in many cases programmers just couldn’t figure out how to program for BeOS.
BeOS was/is just very different from the rest. With the good and the bad things that come with this.
Thank you, Eugenia. I think I understand: The OS “pushes” new messages (notifications of events) onto the app, so the app has to be ready to accept them at any time no matter what it’s doing. The OS doesn’t just send messages to the app asynchronously and wait for the app’s response; the OS can’t just let the app “pull” messages from its “inbox” at its leisure, or system responsiveness would suffer.
Sorry if my first post came across as a little angry, I’m just a little tired of everyone on this board bashing Linux without any real substance behind their arguements. I was trying to preempt some poorly concieved comments, not start an arguement. And don’t tell me that people don’t bash Linux unnecessarily. Just read through previous threads. Whenever Linux or X come up, people make all sorts of comments that are blatently untrue. Reminds me a lot of what /. people used to do to BeOS. One poster even called the B.E.O.S guys “stupid” for working with it. Another talked about the “cruft” of Linux and X. Even the interviewee in this article recognized the amount of backlash against his project and tried to cover his ass before the flaming started.
As for the QNX filesystem, I agree its perfectly fine for embedded spaces. I was taking the desktop angle here. But you can find out more on this thread: http://groups.google.com/groups?
hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=Voyager.001205001855.16795B%
40wooga.wooga.passageway.com&rnum=7&prev=/groups%3Fq%3DQNX~*~@ ~2Bfilesystem%
2Bperformance%26hl%3Den%26lr%3D%26ie%
3DUTF-8%26oe%3DUTF-8%26selm%3DVoyager.001205001855.167 95B%
2540wooga.wooga.passageway.com%26rnum%3D7
Rayiner wrote:
> Another talked about the “cruft” of Linux and X.
Yes, that was me in a different thread. Though, I believe that either I was unclear or else you misread my comment. It was:
| …Folks have the impression that BlueEyedOS is compromising by
| including a crufty old kernel and display server like Linux and
| X.
You need to convince them (us) otherwise.
Note the winky. The point I was making was: I believe that folks have an incorrect impression of the “cruftyness” of components being used by B.E.OS. That’s why I wrote that they (the B.E.OS’ers) need to convince them/us otherwise.
“Sorry if my first post came across as a little angry, I’m just a little tired of everyone on this board bashing Linux without any real substance behind their arguements. I was trying to preempt some poorly concieved comments, not start an arguement. And don’t tell me that people don’t bash Linux unnecessarily. Just read through previous threads. ”
Ooooo come on ! For the last 5 years or so, I grew *TIRED* of tons of Linux zealots bashing without any proofs or any basic logic. Against Windows. Against BSD. Against MacOS.
And now that some people don’t like Linux, they just start whining. Beleive it or not, peoples have right to hates an OS like Linux, exactly like there’s tons on Linux zealot that hates Windows without any good reasons.
That’s the life. And it doesn’t excuse the stupidiest quote I’ve read so far on this board :
“Plus, all references to BSD, Mach, OS X, QNX, etc being faster (desktop-wise) than Linux should be deleted unless the poster provides proof. ”
Yeah. Right. I hope you realize the gravity of what you said.
Personnaly do I need numbers ? No. On a same PC, I installed Windows XP, QNX/RTP 6.2, BeOS R5.2 and Mandrake Linux 8.2. The three first OS give me a wonderful desktop feeling. And the Linux one make me squeak and look the most amateur.
Well, Linux can be manually tweak ? I don’t care ! The three first OS give me what I want right out of the box. Why bother ?
Hi all,
I have come across this “BeOS is a pain in the ass to program” rant before (from JBQ for example). As a developer of a couple of larger BeOS applications, I can say this is a very distorted statement. Let me explain: Obviously, using multi threading to enhance the user experience is desired. (Why would people be so pleased by the BeOS UI experience if otherwise?) It is true that if you want to take full benefit from it, you have to design your applications appropriatly. Multiple threads accessing the same data requires proper locking. Now, taking your example from above: The user choses to save a large document which is going to take some time. You COULD go about allowing the changing of the document while it is being saved, and it might be difficult, depending on your design. However, implementing it this way, is NOT the only way to reflect the BeOS user experience in your app. The user has NO problem understanding that a process is going to take some time. However, what means implementing the BeOS UE, is allowing other documents (of the same app) to still be accessible, while the user has to wait for one document to be saved. For example, other large applications on other operating systems allow you to have multiple documents open. So far so good. But what happens if you do something that takes time in one document – should that keep you from working in another document? No! There is no logical relation between the multiple open documents, the user should expect to be able to work on something else (in the same app) while another “unrelated” task is being executed. However, many applications have their multiple documents *related* under the hood. That is, by the *one* main thread. This makes for bad user experience, and for no good reason whatsoever. AND it makes the user waste time, while waiting. Even if it takes BeOS apps longer to save the document if BFS is slower than XFS or whatever, the user actually still saves time by being enable to work on something else in the mean time. Even – and especially – in the same app.
Here is a real world example of all this: My (actually “our”) largest BeOS application is “eXposer”. For those of you who don’t know it, it’s an application that enables animators to capture an animation into the computer and arrange the individual frames on a time line, to get a preview of their animation. This application is used in production enviroments. Indeed, eXposer is capable of rendering an animation to AVI/Quicktime, while allowing the user to change that exact same document while it is still being rendered. This didn’t take much programming work at all – once the application was designed well from the beginning.
Think about it – BeOS was about a new way of computing, which also encouraged new applications (and new application design)! It was not about porting other applications to this new design, so the argument BeOS is a pain to program for, because some port turns out to be a huge problem, is a pretty lame argument in itself.
And another thing: While it did some figuring out how to design applications to benefit from multi threading for me, I probably saved that time and much more by programming this wonderful API. Multi threading also relieves you of many problems you would otherwise have, namely when multiple things are to go on at the same time in your application. If those things are “fairly” unrelated, but need to happen synchronously, using multi threading is a huge time saver. The OS is executing those things in parallel for you. eXposer for example can (all in the same document) load images from disk, play the animation preview, play the sound, have the user edit the animation – all at the same time. I don’t want to imagine the headache, if all of this was to happen in the same thread. The only thing I need to take care of, is proper locking of data. And there are some nice tricks you can play there as well, for example read/write locking. It’s not that hard after all, and the API provides many classes supporting you to do the right thing.
And guess what – it pays! The users will love your program if it enables them to work faster by being multi threaded.
JBQ has brought up the argument (way back then) about “forcing MT onto developers”, which was, in his opinion, one of BeOS major design flaws. Heck, if you don’t agree with MT, BeOS is simply not your playground.
-Stephan
> Heck, if you don’t agree with MT, BeOS is simply not your playground.
It is not about “agreeing”. It is about PINCHING and SELLING that OS to developers. For you, it was great, because you are among the, what, 30-40 third party developers that “got the idea” about multi-threading and knew how to do stuff all these years? The rest of the devs, never “got it”. Yes, they were not more than 40 devs who knew how to do advanced stuff with BeOS. This was one of the main reasons why there were never created or ported important/complex apps to the BeOS.
And this costed JBQ his *job*.
It is not about games, playgrounds, or agreements. It is about WHAT SELLS and what is plausible today for the kind of knowledge most of the developers around the world have.
BeOS is different as I said earlier. With the good and bad things that come with it.
I don’t agree with a couple of points. First of all, Microsoft killed BeOS for the most part, not a “difficult” programming concept. Secondly, if Be wouldn’t have made The Focus Shift, at least some of the larger scale apps would have been finished for BeOS (or distributed because they already had been finished), like Nuendo (which alone would have made an impact, I would guess). The developer who did that port is pretty skilled, and figured out his own “multithreading workarround” for the single threaded Nuendo. It wasn’t easy, but I guess when BeOS was designed, nobody thought about making ports easy. Doh, that was the essence of BeOS, being something new!
Be also had the good approach of helping people port apps to BeOS, like what happened with Bias Peak or Mozilla. But all of these (except Mozilla) have never happened because of the Focus Shift. Why the Focus Shift happened at a time when so many apps where just arround the corner probably only Be knows. But I guess, it just became clear that Microsoft had too much power. Be could not sell BeOS through the important OEM channels.
I’m going to repeat myself: Multi threading makes much sense, obvioulsy the users like it, so it must have something to it. It is much more becoming a buzzword these days. Many projects seem to pick up on the idea, like for example the VideoLAN client. You cannot sell something these days that doesn’t have at least multi threaded rendering. Intel is making Xeon processors, that have multiple cores specifically to speed that up.
And in BeOS you didn’t exaclty have to do the most brilliant and throughrough implementation of MT to get things working for a start. And again, for many cases, multi threading is actually easier and more intuitive as I pointed out above.
Large scale apps take time, that’s why something like Photoshop has been arround for years. And some of them have been close to being finished for BeOS, and they were canceled after the Focus Shift, not before. Be also got itself a somewhat drastic change of attitude towards its developers after it filed its IPO.
So it has been lots of things, on both sides, not only developers never finishing apps and that’s what killed BeOS. That’s simply too easy. And the reason for apps not getting finished was not because of multi threading being forced onto the developers.
After all, BeOS wouldn’t have that much of a reason to be here, if it didn’t offer new ideas and concepts, of which MT was one of the more important ones. If all what sells is what people know and are used to, BeOS shouldn’t have been made in the first place. But that’s what makes a vision a vision, doesn’t it? I think BeOS made for a vision that wasn’t even too much ahead of its time. It has been other reasons that made it fail.
For your interest, I learned programming on the BeOS, I wasn’t a programmer that “knew how to do stuff all those years”.
-Stephan
Stephan, I’m sorry for being so ignorant but what is “The Focus Shift” and “IPO”?
Thanks
Peter
The Focus Shift happened when Be declared it’s intention to shift its focus away from BeOS on the desktop and concentrate on BeIA (for information appliances). The Desktop BeOS was ment to be the developmend platform for BeIA (nothing more) in this new strategy.
I don’t know what IPO stands for, but it is when a privately held company enters the public trade market. (That is, if I’m not completely full of it, I haven’t slept for almost two days… 😉
Regards,
-Stephan
it’s clear now
Thank you
Inital Public Offering
> The developer who did that port is pretty skilled, and figured out his own “multithreading workarround” for the single threaded Nuendo. It wasn’t easy, but I guess when BeOS was designed, nobody thought about making ports easy.
That developer, GeB, is a personal friend of ours. We know him in “real life”. And guess what?
GeB is an ex-Be engineer. He is not a “random” developer who “figured out how to do this”…
The port took him A LOT more than it should have to, because he pretty much had to create a huge lock of his app and turn it to single threading…
And GeB is a VERY talented programmer, who knows about multithreading a lot. So, if HE had to go in such a pain, now imagine the average programmer that comes from the Windows land and he wants to port his app to BeOS…
> like what happened with Bias Peak or Mozilla
The port of the Bia PEAK was ALSO made by an ex-Be engineer. Does that tell you something?
As for the Mozilla port, it was UNUSABLE until Mathias and Daniel Switkin (BOTH ex-Be engineers) decided to sit down for a whole month and fix it.
Now, don’t tell me that people know how to handle complex BeOS programming. They don’t. There are 30-40 third party programmers out there that can. The rest, don’t have a clue besides a “hello world” type of app. You were always one of the good ones. But don’t have fantasies about the reality of the rest.
As for multithreading that is good, yes IT IS GOOD. I want it TOO. But not when the price to pay is “no applications, because of lack of dev knowledge”. That WAS one of the reasons that killed Be. It was not JUST Microsoft.
The other “big” application ports, like Bryce3D and the Tascam Device, were also ported by ex-BeOS engineers that found new jobs to companies that wanted to port some of their products to BeOS before the focus shift.
Of course, this is not to say that there are not good third party developers that can’t “get” mt. But these, are not too many. Not enough to support a whole operating system with the kind of apps it needs.
I have personally talked to Guillaume and also tested some of his BlueEyedOS code recently and indeed, XFree can be fast
Yes ,it is
No matter the tricks and optimizations though, XFree/Linux kernel can’t be as responsive as BeOS at the end of the day, because of the way the BeOS was built around the push programming model and extreme multi-threading (‘fast’ is not the same as ‘responsive’ – BeOS’s UI is extremely responsive, but the OS *underneath* is not ‘fast’ on many-many cases).
I disagree!
1/The latency of linux can reach the BeOS one
2/The B.E.OS app_server is multi-threaded as the original one.
2bis/The IPC (inter process communication) of linux is faster than the BeOS one.
3/The ‘global lock’ of the BeOS app_server is at the gfx card level, the one of B.E.OS is at the ‘gfx output’ (low level X11) level. No fundamental changes here.
4/B.E.OS apps are the same as BeOS one, ie multithreaded.
Conclusion, I still disagree with your conclusion/theory
Today I tried my code on a P4 + GeForce4, whaaaaaooooo, I have to find a word for “more fast than fast”.
Regards,
Guillaume
Eugina wrote:
“Let’s say that the user pressed the “Save” command and the document is trying to save the document, while might take some time to do so because of the complexity involved. Now, let’s say that the user presses the menu bar, or one of the icons in the icon bar. **ALL** other OSes, LOCK the UI when something like a “Save” process is taking place to ensure that nothing gets screwed up. This locking on other OSes, make them feel “slow”. On BeOS, this does not happen. The UI is *live* at ALL times. Now, think that the user wants to make a change in the document and types something, while the document is still saving in the background! What does the OS does? It allows it!”
>>>>>>>>>> **ALL** other OSes LOCK the UI ? does a deterministic OS such as qnx LOCK too ? Can anyone confirm this?
Eugina, you don’t need to make your comments sound more knowledgable with statements like you know that guy personally. I knew what his name was, and have had contact with him before. However, I didn’t think I needed to write this for my argument.
When BeOS was designed, I don’t think they were giving the porting of existing large apps so much thought. I can remember Be wanting new apps, not ports (see News Letters).
As we both seem to agree, MT is an interesting technology, that can greatly enhance the user experience (that’s what counts in the end (and sells)). Computers with multiple CPUs start to make more sense, and all of the original Be machines (on which BeOS was designed) were multi CPU machines. A dual CPU computer makes BeOS *really* shine. If you think BeOS is responsive on a one CPU machine, wait till you see it on a dual CPU machine!
Alright, I do agree, that multi threading can make your life harder, if forced on a single threaded design. Maybe it was *the* major hold-up for those ports. I can’t really say. However, I think to really get an opinion on the issue, you have to look closer. It all depends, and you will come to a different conclusion, if you don’t look at all facts.
The following you most likely know, it is here for other intersted readers. Each BeOS app spwans a couple of threads. One thread for the application, and one thread for each window it opens. (There are even more threads, in the app_server, but those you can ignore.) Each window processes the user (or system) events in it’s own thread/message loop. I think most other systems have one event loop per application or even a global event loop (like Window has (used to have?) That’s why windows feels unresponsive even *across* apps).
One of the facts that need to get examined, is that this multi event loop design in BeOS is there, but there is nothing preventing you from passing all events through a single event loop, for example the one from the application’s thread. You can simply forward the messages (overhead), or directly lock the application and call MessageReceived() on it. I never tried this, but I would guess there are no problems here.
There are other possibilies, like aquiring a global lock in each thread before processing a message. This is just like a single threaded thing then. Of course there is more to it. Some messages get processed by the BWindow class itself (not in your derived class), for example draw messages. If you have the same data represented in multiple windows/views, you might have to aquire a global lock before drawing anything or otherwise accessing the data in each view in order to make it effectively single threaded.
All of these possibilities would be “workarrounds” for the multi threaded design in BeOS. And they are quite easy.
Let me look closer at your original example. The user choses to save a large document. You say other operating system “lock” the interface. That’s a pretty vague statement. I don’t know what exactly you mean by that. Here is what happens in BeOS: There is two possibilities:
1) You have set up the menu item to send the save message to the application thread. It’s true the window would continue to work, while the application processes the message (saves the document).
2) It sends it to the window. If you process the message right in the window thread, you would indeed lock the GUI! So it works just like on other platforms (which is just to say your example was badly chosen)! But even in a single threaded enviroment, locking up the GUI is never desired, especially when something takes time, you want to give the user visual progress feedback, hopefully with an option to cancel the job. So locking up the GUI (ie doing a time consuming thing right in the event loop) is not what you want to do even in a single threaded environment.
To sum this up: processing events right in the window thread will lock up the BeOS GUI just like it would lock up a single threaded application. When you have a multi document application, the multi threadedness is a very nice design indeed. You can use the application thread for nothing more than handling the spawning of new documents and such things. Everything will be quite easy to design.
Things get more interesting when you are displaying/accessing the same data from more then one window/thread. That’s when you can’t do without locking. However, it’s not really that hard to understand, especially when you design your application on BeOS. When you are porting, things might be more complicated. I’ve never done that.
I guess, what I really want to say is that I forgive Be for that “flaw”. MT is the right thing to do, especially when you’re designing a new OS, and don’t consider ports to be such a desired thing anyways.
When I was to port one of my applications to, let’s say, MacOS, I would have a hard time learning that design (or even new coding language). And maybe my port would suck, because I didn’t have MacOS in mind when I designed my application. In case Apple depeneded on people like me to get their ports finished, but it took them quite long to learn the new design, would you say MacOS had a major design flaw?
-Stephan