F A Q :: Frequent Asked Questions regarding BlueEyedOS
Why did you change the name of the project?
BlueOS was a good name, but already exists... when we realized that there was
too much confusion with www.BlueOS.com, we changed! Now it's Blue Eyed OS
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
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.
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
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
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
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.
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!