1. How many people consist BlueOS? Are these people long time BeOS developers?
Guillaume Maillard: A bit of everyone really, people like Frans VanNispen are experienced and well known BeOS developers; they are all enthusiastic devs as this is their first big project; we're trying to distribute work according to everyone's skills and so far it works fine. (Scott Lindsey from Gobe joined us, but seems to be busy with his real work...) To sum up, the team is composed by 26 members, and 4 more coders will join us very soon. The core of the team is composed by people who work (like Cedric Degea and me) in the computer science domain. Others members help us for documentations and tests. (I wonder if should I put the names of the members on the web site would be a good idea.)
2. Which filesystem are you using for your custom Linux kernel? How are you going to overcome the fact that BeOS supports indexing and Live Queries which is something that even SGI's XFS (allegelly the most advance fs from the ones available for Linux) does not support? (as for Live Queries, you need both filesystem and kernel support)
Guillaume Maillard: Both node monitoring and live queries need 'special' kernel support, that's true...
Today we are not dependant of a specific filesystem, but we choose ReiserFS (which is linked in our kernel). Index and queries mechanism which is an inner mechanism of BeOS, can run on top of an existing filesystem like ReiserFS, a specific "server" will manage the query mechanism. For example, attributes of a file called 'Hello' are managed in associated named Hello.rsrc. This system is transparent when you use the BeOS API. In term of performance is not slower, to search files with a specific file attributs, the "fs_server" read only the .rsrc files and keep the result in a table, etc... The kernel support is planned to be implemented on our kernel_server (which currently manages functions that cannot be directly wrapped on the Linux kernel)
3. 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?
Guillaume Maillard: The goal is source compatibility, to have OT/OD "for free" as well as open-source apps, and apps that devevelopers will accept to recompile (rather than /port/) for us. The Opentracker/Deskar source code are already present in our /BlueOS/develop/opentracker directory, 90% of it compile s and maybe soon 100%, but even compiled, it cannot run today, I used it to see if the transition from BeOS to Linux is possible. BlueOS will have a fully working OpenTracker and a working BFS layer.
4. Are you applying both the latency *and* the preemtive patches to your custom Linux kernel? (Get the preemptive patch and notes at the end of this page) Users claim that these two patches are making Linux and XFree's UI very responsive.
Guillaume Maillard: Sure! We are using a Linux kernel 2.4.12 modified with the Alan Cox's low latencie patch. In order to make our Kernel Kit working, I made few changes in the Linux IPC limits.
5. 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?
Guillaume Maillard: We are not rewriting the BeOS API for XFree. High level classes like BButton are using ONLY the BeOS API. 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, thanks to Frans Van Nispen who is working hard in the team.
6. 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'?
Guillaume Maillard: The main reasons why I 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 BlueOS, 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 the installation of drivers, 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.
7. Will BlueOS 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?
Guillaume Maillard: BlueOS is designed to be "Linux compatible", it means too that XFree applications will be able to run. I believe that people who will use BlueOS, will mainly use BlueOS 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.
8. When the release of BlueOS v1 is to be expected? What are the plans for BlueOS 2?
Guillaume Maillard: It's difficult to answer, we are progressing quickly, BlueOS v1 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 BlueOS v2, it means that BlueOS will not use the XServer anymore!
9. Do you share work, code and ideas with the OpenBeOS folks?
Guillaume Maillard: We are trying to avoid to duplicate code, that's why Frans is sharing with OpenBeOS the "high" level classes he is writing. Unfortunably, we can't share/merge things like the app_server, because it requires too many compromises and a lot of friction between the two teams during the design and coding process. Some of us on BlueOS are also subscribed to the OBOS mailing list.
10. How are you going to overcome the loading problem of the compiled C++ apps under Linux? It is known that Linux has some problems in the way it loads C++ apps, and this is why KDE could be recompiled with object prelinking.
Guillaume Maillard: The Linux team is working hard, I'm sure that these kinds of speed problems will disappear. :)
11. 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.
Guillaume Maillard: 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...
I made tests on my Dual Pentium 3 and our low latency patched kernel and I saw that 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 BlueOS implementation of ports is two times faster than BeOS 5.
12. 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?
Guillaume Maillard: We simply don't want to break any compatibility with Linux, that's why we are applying only patchs, we are abstracting the kernel problems with the kernel_server.
13. The Media Kit did not enjoy many applications over the years (main reason was because it was so barebones and low level that it was almost impossible to write a serious app based on it) and it will be maybe better to write something equivelant, but not just the same. But the Midi Kit was done right by Be, Inc. and it has a large number of apps found on BeBits that it would be nice to be ported to BlueOS. How easy or difficult would it be to recreate something like the Media or the Midi Kit?
Guillaume Maillard: You'd have to ask Brice ;) He told me that his version of the Media Kit is compatible with the current one but implements interesting stuff like 3D sounds and others goodies. More usable classes will appear in the near future.
14. Will BlueOS be binary compatible with Linux and maybe support something like the highly used RPM package manager?
Guillaume Maillard: We plan to run both BeOS (recompiled) applications and Linux (natively) applications. We will support RPM packages and a special package system for BlueOS (a BlueSoftwareWallet kind of system).
15. BeOS is great for drag-n-drop operations throughout the system and its 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?
Guillaume Maillard: Consistent? Hey, that's not a Linux word! :)
We will try to be compatible with the existing protocols and implement the "magic" drag-n-drop features you find in BeOS.
16. A final word?
Guillaume Maillard: We see always the same mistakes, people see "Linux" on BlueOS, thinking that BlueOS is "on top" of it... While "inside", could be the best word.
(I often hear : "Linux distribs are bad, then BlueOS is bad..." ) Linux... how to make them understand that we only use the KERNEL ?, it provides us, scheduling, memory management... and a lot of drivers, that's all.
We are still searching people who are ready and very motivated to code BeOS Kits, like the support or the storage kit in order to boost our development process and have something done RSN.