BlueEyedOS Project FAQ

• There are many groups right now working to recreate the BeOS. What makes B.E.OS different from the others?
B.E.OS can be compared to OpenBeOS, the project aims to recreate a free BeOS. The biggest difference is about the technical choices. We are not recreating things like the kernel and drivers from scratch. We have also decided against binary compatibility, which is more, a limit (due to the number of workarounds needed) than a 'feature'. Cosmoe is using a Linux kernel too, but the reuse of AtheOS code means a totally different approach of a 'new BeOS' in comparison with OpenBeOS or B.E.OS.

• Guillaume, out of curiosity what led you to start working on B.E.OS instead of working with one of the other groups?
When we started, no other groups existed! That's simple! But today, from my point of view, there is no good reasons to prevent a merger between OpenBeOS and B.E.OS, we could merge our work and use the OpenBeOS kernel AND the Linux kernel. There is really no need to develop 2 media_servers, 2 app_servers, 2 libbe.so, etc. even if we use a XFree86 or not. As a software engineer I can't resign myself to 'spend' hours developing them and see my work used in commercial applications. I'm not sure that people who are developing code under a license like BSD see the importance of this drawback.

• The task is too huge, BeOS has been in development for 12 years now...
Be has not been 30+ engineers big for 10 years, only in the 5 last years, plus they spent much time on design, which we'll save by "copycat'ing it (for the sake of the community) plus we are re-using some code (Linux..) at least at the beginning; anyway just look at AtheOS: it demonstrates what you can do in a (_relatively_) short time if re-using to the maximum some external code out there and doing some external code out there and doing trade-offs that can save you some time.. Just imagine where AtheOS would be now if worked on by 5 or 10 people, with the clear goal of being source compatible with BeOS's API?

• Why do you want source compatibilty?
In fact, we believe that if developers use the BlueEyedOS API, to compiling / porting the applications to BeOS will be easy. Both APIs will be similar; BlueEyedOS will add some features that can be ported on BeOS quickly. For starters, BlueEyedOS applications will be developed on BeOS, while BeOS compatibility is incomplete.

• Why is BlueEyedOS NOT under a GPL license?
The development of an OS must be managed, otherwise a lot of duplicated works or mistakes can be easily made. Our goal is no to really close the source code, just control it. What's more we want prevent any commercial use of our work, we are doing it for free, and it will ever stay free. But to not be in violation with the GPL, parts of the OS will be under GPL (the kernel, for example).

• I've be deceived as a user and developer once with BeOS (and even twice if you count the Amiga), losing all I had done when the mothership went to bankruptcy... why would I trust you/BlueEyedOS even though you're not Opensource?
We're a different kind of "mothership": we're not money-driven, no investors dictating us what we have to do, it's a labour of love done in our spare time (we all have day jobs (software engineers) so the only reason we'd have to stop) so the only reason we'd have to stop it is loss of user interest. We won't end up the way Be and Amiga did, frustrating users who wanted the story to go on, we'll only end if there are no users left who want us to!

• Who are you?
See the organization page! Software engineers, high school students, "geeks"...

• How I join me with you?
First be sure you have A LOT OF time and motivation! If you think that you can help, see get involved page. After, write us a mail with you name, age, job, interest, what you can do for the project and start to do something. A mailing list is already open, you will be subscribed to discuss about your first steps with us.

• Why are you using Linux as BlueEyedOS kernel?
Because he already is a mature kernel. Remember that we not want reiventing the wheel! The linux kernel is free, portable, fast and a lot of developers are working on it, then drivers and low level portability are not an issue for BlueEyedOS. What's more, BlueEyedOS is able to launch Linux applications (Wine, Gimp, Maya and others applications needed).
With preemtive patch and low latencies patch, the Linux kernel can easily compete with the BeOS one. First benchmarks with the Kernel kit API, showed that on the same computer, our kernel related functions are faster than BeOS.

• Are you applying both the latency and the preemtive patches to your custom Linux kernel? Users claim that these two patches are making Linux and XFree's UI very responsive.
Sure! We are using a Linux kernel 2.4.12 modified with the Alan Cox's low latency patch. In order to make our Kernel kit work, We made few changes in the Linux IPC limits.

• By changing the Linux kernel to the custom BeOS needs, you may end up breaking source compatibility with future versions of the Linux kernel. Are you willing to completely fork the Linux kernel or you are interested in keeping compatibility with future versions and only apply a number of patches for your purposes?
We simply don't want to break any compatibility with Linux, that's why we are applying only patches, we are abstracting the kernel problems with the kernel_server.

• Under BeOS, installing a driver is a dead easy situation, while under Linux it may even require recompilation of the kernel or in the best case, the use of cryptic CLI module loading commands. How are you going to simplify things like Translators and device driver installations? Will your system resemble Linux's user difficulties or will it be closer to BeOS?
The main reasons why we don't like Linux are the non-flexibility and the "chaos". On BeOS, when you want to play an mpeg file you don't have to search a specific library to do it, the same mechanism is planed for BlueEyedOS, translator will be implemented (not from scratch, because there are already good implementations of all needed codecs "somewhere", we will integrate them in our Translators). Regarding drivers installation, the kernel is compiled with all the drivers in, in order to be most "hardware" compatible. The goal is clearly to be as close as possible with BeOS.

• How do you think to go through the limitations of current Linux filesystems?
The first idea was to abstract the idea of FileSystem and only send queries to a server which will manage the indexes, by using global index tables and file resources (implemented by .rsrc or .info files...). But now we are focusing on using ReiserFS and/or XFS extended features.

• Are you going to port OpenTracker and Deskbar or recreate it from scratch? (what is a BeOS without its Tracker? ;) Will you create a BFS layer on top of the Linux filesystem?
The goal is source compatibility, to have OpenTracker/OpenDeskbar "for free" as well as open-source apps, and apps that devevelopers will accept to recompile (rather than /port/) for us. The Opentracker/Deskbar source code are already present in our /home/cvs/blueos/opentracker/ directory, 90% of it compile is and maybe soon 100%, but even compiled, it cannot run today, we used it to see if the transition from BeOS to Linux is possible. BlueEyedOS will have a fully working OpenTracker and a working BFS layer.

• Why are you using XFree?
To complete the abstraction and compatibility the graphical interface is being developed on XWindows (which has been ported to a number of platforms).
XFree86 allows us to use hardware acceleration for 3D applications and games.
By using a Linux kernel and XFree86, we allow the execution of "standard" and useful Linux applications like:
> the lastest versions of development tools;
> a Java Virtual Machine;
> an support of hardware accelerated 3D;
> games (Quake 3, ...);
> emulators, like Wine or VMWare (to use apps from Microsoft);
> professional applications like Maya.

• How do you think about BlueEyedOS GUI in XFree?
We are not mapping the BeOS interface on the XWindow system. We are currently developing 2 graphical rendering engines, the first is the X11 compatible display, we use BeOS-like XWindow manager, however, this "window manager" does more than the rest, as it use a real app_server. In the first screenshot you can see an application that is not Gnome-based, but is coded using this BeOS C++ API. "Slow" you think? No. The second graphical rendering is a (full "from scratch" coded) fast window managing system. It uses low level function in order to have really impressive performance (even better than the BeOS one, because use the hardware accelerated functions of your graphical card).

• I remember reading that your group was planning to use an existing Linux window manager in the beginning but then implement your own later. Is this true? If true, why was this route chosen instead of writing your own from the start?
That is incorrect. What you may be referring to is our rendering methods. We currently have two forms of rendering: the 'native' one (hand written by us) and the 'XWindows' one. The first one uses our own window managing system and the second use an XWindow one. These two rendering methods can be used at the same time. To give you a quick idea of the user experience, we can sum up by: you are on a BeOS like environment (Tracker, Deskbar), you play with your favourite apps, all is fast, responsive. But then you decide to run a 'must have' commercial Linux apps like Opera, Maya, JBuilder, etc. You launch it as a BeOS app (i.e.: a double mouse click), the app_server then uses an XWindow with a window manager (like Sawfish with a custom BeOS theme) to display the app. After that, you are free to continue your work in this environment or to switch to the "native" mode where only B.E.OS apps appear (your linux apps are not closed, not stopped, but just waiting for you in the 'XWindow' rendering). In order to make it more BeOS user friendly, things like the Gnome desktop or launch will not be installed in the X11 mode. In terms of performance, by using an offscreen bitmap for every window, the rendering performance of the "XWindow" rendering is pretty good and, of course, the "native" one is very, very good.

• BeOS is great for drag-n-drop operations throughout the system and it's Cut/Copy/Paste works perfectly. I can't say the same for XFree though because it has so many protocols, standards and toolkits that it makes it not so consistent. How are you going to overcome the problem?
We will try to be compatible with the existing protocols and implement the "magic" drag-n-drop features that you find in BeOS.

• How much of the BeOS API has been re-writen for XFree? Will it be possible to port BeOS applications over with a simple recompile?
We are not rewriting the BeOS APIs for XFree. High level classes like BButton are using ONLY the BeOS APIs. The XFree dependent parts are small (in term of number of functions) and are present only in classes close (not really "inside") to the app_server (BWindow, BView...). Today, we have replacement classes like BButton, BBox, BCheckBox, BControl, BStringView and more... these classes are working fine on BeOS.

• Will BlueEyedOS be able to run XFree applications? If yes, won't all the GTK, TCL/TK, Motif and QT applications create a pretty "mixed up" feeling to the BeOS users regarding the "pureness" of their new GUI?
BlueEyedOS is designed to be "Linux compatible", it means too that XFree applications will be able to run. I believe that people who will use BlueEyedOS, will mainly use BlueEyedOS apps ported from BeOS, that's why the "mix up" don't worry me. People will have the choice to run XFree apps or not, according to their tastes.

• Many of the released screenshots show an interface that is very close to the now famous Gonx design. Why did BlueEyedOS choose the Gonx design and has it posed any challenges with regard to implementation?
Our UI closely resembles the Gonx design because it's the work of the same talented graphic artist: see http://cotito.free.fr!!!
The implementations is not a real challenge, the difference between a "standard BeOS look" button and a "BlueEyedOS look" is about 20 lines of code.

• Multi-screen?
Yes! A new button on windows will appears to easily jump windows on a different workspace or an other display (possibly on another computer). A nice menu with a list of preferred displays could be nice... but today we are focusing on the first step, which is to be "BeOS like".

• How do you feel that these differences will help set B.E.OS apart from the others in regards to performance, usability, and overall feel?
In terms of performance, using a Linux kernel doesn't necessarily mean poor performance. The BeOS kernel is not exactly the greatest kernel either, for example, people often believe that BeOS has the lower hardware latency. But if you do a quick search for information about this subject, you will find that a custom Linux kernel can easily achieve a 3ms latency.
I can also point to many examples regarding file-system performance, graphics throughput, inter process communication (IPC), etc., but as BeOS users we believe in BeOS :) In many cases the OpenBeOS group has shown that it can be faster than BeOS, we are working to achieve this as well.
In terms of usability, it's too early to speak on this, we can't compare. Today, Cosmoe wins, tomorrow someone else may be in the lead we will just have to wait and see :) Personally, I want to able to boot under B.E.OS and be unable to tell if I'm under BeOS or BlueEyedOS.

• My understanding is that you are re-writting from scratch the BeOS GUI toolkit. Will that be C++ and responsive as the original BeOS was? Font sensitive too? Please talk to us about the speed you measured so far.
We are making more than a GUI "toolkit", it's a complete OS. People always think (because we use a Linux kernel and use XFree as a "2D/3D driver") that we are coding a new Linux distribution. Which is not the case! Today, surely, it looks like a Linux distribution, developers have to install a "standard" Linux distribution, and then install our specific kernel and all needed stuff... but tomorow it will be like BeOS: easy to install, easy to use...
In tests made with Dual Pentium 3 and our low latency patched kernel, the XFree can be as fast/responsive as BeOS if it's correctly used. (By using only blit functions to fill the XWindows and avoid "deep computing" of proteine in callbacks... :) ), "sensitive and antialiased font without fear" would impress even Gnome addicted people. Speed "benchmarks" have been done objectively on write_port/read_port and show that the BeOS kernel is "slow"! The BlueEyedOS implementation of ports is two times faster than BeOS 5.

• When the BlueEyedOS R1 is to be expected? What are the plans for BlueEyedOS R2?
It's difficult to answer. We are progressing quickly. BlueEyedOS R1 will be a 100% working clone of BeOS, the road will be long though... all I can say is that you will probalby be able to launch OpenTracker in few months (maybe 3-4 months) and compile applications which use the app_server. The Media Kit is a big part, Brice Wernet (the author of Maxisound driver on BeOS) is working hard on it's design.
For "performance" addicted people, a version of the app_server which will only use the XFree86 drivers will appear on the BlueEyedOS R2, it means that BlueEyedOS will not use the XServer anymore!