A few days ago we hosted an interview with the OpenBeOS team leader but I received a number of emails asking us for more information regarding the other effort to ‘save’ BeOS, BlueOS. BlueOS uses Linux kernel 2.4.12 as its basis, and Xfree. For now, they are building a BeOS look-alike Interface Kit and the app_server on top of XFree, so it is not just a simple window manager, but a whole new API and environment. In future versions, the BlueOS team will completely bypass XFree and have a stand alone BeOS compatible app_server which will only use some of the XFree’s system calls to be able to use its 2D/3D drivers. But let’s read what the French coder Guillaume Mailard has to say about the project. Guillaume also sent us a screenshot which shows the custom BeOS-alike GUI the team have already coded the last few months, currently running under BeOS (and this is why they have shared that code with the OpenBeOS team) and it is currently ported to Linux.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.
Wow, I’m quite impressed, I must say I am/was one who was not very found of the idea of building a beos with linux kernel. But it looks like its working. Also i like how it looks like it won’t be so much of a beos emulator on linux but more of a true beos but got a jump start by using the linux kernel. I’m curious on how the final implementation will be. If it can boot quick like beos and not have password prison like crazyness of linux it will be real nice. Basicly if i can’t tell there is any linux/unix in on or under what i see when using it i will be happy. Go BlueOS
Finally some more info about BlueOS.
hmm I wonder if (open source) beos drivers would compile on blueos, and how that would be done. The linux (or should i say BlueOS) drivers would probably be faster, but how much?
Anyway, thanks Eugenia Loli-Queru and Guillaume Mailard for the interview.
Nothing personal against the BlueOS team .. .
It looks like BlueOS is going to be a bit messy. C’mon, theirs a million Linux distro’s TONS of developers have been TRYING to make Linux “easier” and “faster” (i.e. more like BeOS) for years now.
You’re average Linux distro is more bloated and slower out-of-box than even Windows or MacOS X. And you’re telling me that this small group of developers is going to build an OS that will run Linux apps AND BeOS apps while keeping BeOS’s speed and ease of use? Buy the time this is accomplished (if it is) it’ll likely be too late.
A small group of volunteers (FreeDOS) can’t even “clone” a 20+ year old simplistic, well documented OS like DOS are the BlueOS developers just that much smarter? I think this project needs to look at a different path to achieve a BeOS compatable OS. Or just work on OpenBeOS, as its idealogy seems a bit more realistic. Of course, as a BeOS user – I believe ANY developer interest in BeOS is GREAT, and I *DO* hope my thoughts are DEAD WRONG and this project (and others like it) all accomplish their goals.
Many of the OBOS kits should be quite unlinked from the kernel so you can maybe work togeder to get them compile and build on both OS.
BTW why just using linux standard kernel? L4-linux on top of L4 or L4ka should allow you to have the *_server act more likely BeOS ones (kernel_server and the app_server should take advance of that), I’m not talking about HURD even if mach/hurd and L4/hurd need lots of help and a project like BlueOS make get the developement faster^^
In fact, Caldera is not using the Linux kernel, it replaced it with the more scalable UnixWare kernel.
BlueOS: You guys rock! I had real doubts when I read your first announcements, but now you proved me wrong, and I’m glad about it!
In future versions, the BlueOS team will completely bypass XFree and have a stand alone BeOS compatible app_server which will only use some of the XFree’s system calls to be able to use its 2D/3D drivers.
So what does that sentence say to us? Will it completely bypass XFree only to use some of XFree’s system calls?
I wish they would bypass Xfree from the beginning…
This sentence says to you that for the version 1, BlueOS will use XFree, the way KDE uses it.
For version 2 (as Guillaume told me), they will use their own app_server and they will only have an interface to XFree just to be able to use their 2D and 3D drivers. They won’t be using anything else from XFree, just their drivers.
The goal that is met by using the Linux kernel is hardware support. If you used L4, you’d have less hardware support than BeOS R5.
So, Euguenia, if you had to bet on which BeOS effort were to bring users to the closest experience possible…?
>So, Euguenia, if you had to bet on which BeOS effort were to bring users to the closest experience possible…?
BeUnited.
A) The Linux kernel rocks. Most of the problems people see with Linux are at the GUI level, not the kernel level. As for drivers and such, Linux is of the mind that drivers should be totally automatic, and 2.5 will see to that.
B) XFree86 isn’t that slow. If you get down and dirty with xlib (which BlueOS presumably will) the XAA driver architecture allows for VERY fast accelerated graphics (especially on NVIDIA hardware). In my own tests, XFree86 4.1 does pixmap blitting almost as fast as DirectX (which is a much more low-level API). What makes Linux GUIs sucky is that the toolkits on top are really slow and bloated. Plus, if you retain X at some level, you get accelerated OpenGL for free.
C) L4 or Mach would be a dumb idea. First, Mach sucks. Second, L4 is written in assembly and incredibly difficult to maintain. Fiasco isn’t production quality yet. Besides, there is no point in adding yet another abstraction layer beneath the Linux kernel.
>The Linux kernel rocks.
Regarding the open source kernels, my vote would definetely go to (unreleased yet – but in beta) FreeBSD 5.0.
I agree that the Linux kernel is generally faster than BeOS’ though. BeOS has a good FSIL implementation, a VERY good Scheduler but the rest, just sucks (especially the VM).
One wonders how Eugenia arrives at the grand proclaimation that outside of the FSIL and scheduler that BeOS’ kernel sucks, given that she neither has the source code nor the qualifications to make such a judgement (any more than the typical OS advocate of the “Linux Sux!/Linux Roxx0rz!” variety does).
Do you have any idea who her husband is? I’ll give you a hint… He used to work for an OS company
-G
I’ve only used beos for short spans of time, as my video and network cards were always less than supported, so I must say that this sounds wonderful. What seems odd is that its built around a linux kernel that is around two weeks old and the project released “libroot.so” on (ugh) 9.11.2001. I imagine that was based off an earlier kernel, but it seems a bit strange at first glance. I’d love to see this thing deliver what it is shooting for, but it certainly seems a long way off, and currently no source is available (publicly) to look at. Good luck to the project though. I’d love to help out one day, but I suppose I’ll wait until the source is online for the general public, it seems like a great project.
Eugenia drums at her own beat…we will keep laughing at her ‘wise’ comments.
Keep drumming EUGENIA
Just because she married to an OS developer, does not give her all the insight into making some of her most ludicrious comments as we have seen above
Hahaha… It is SO funny.
<P>
Mac people say (flame) that I am sold to BeOS. BeOS people say that I am sold to Linux. Linux people say that I am sold to Windows.
<P>
Get a grip people, I am always write and say what I believe and know is right in each situation. I am NOT taking sides for any OS. This is why I have 7 OSes installed in my PC.
<P>
I guess, living in the same house with 4 (ex) Be engineers, has nothing to do with my knowledge about the internals of *several* Operating Systems.
In fact, Two of these people were designing their own OSes as well, all they did (when they were not hooked on the PS2) was to discuss operating system design, compare kernels, compare algorithms etc. And I was there.
<P>
Why you people only want to hear what you want to hear?
That I didn’t help with Eden…
You rock, mon frere.
Sandwich Boy
Eugenia, maybe if we could get a list of areas where the BeOS kernel is weak and needs improvment that could help out the BeUnited, OpenBeOS and BlueOS people =)
Just a thought I guess.
-James H
>a list of areas where the BeOS kernel is weak and needs improvment that could help out
<P>
I am already helping BeUnited and Michael Phipps from OpenBeOS as much as I can. No question about that.
When it comes to *technical* information I am always trying to help and also say the truth, regardless of what my favourites are (and you all know that I like BeOS – I have spent months porting these 80 applications found on BeBits!).
<BR>
By dreaming that “the beos kernel is better than Linux” we are not helping anyone, because it is simply not true. Both kernels have their goods and their bads. We all love BeOS, BeOS has some good qualities in its kernel, in fact it has a kick-ass Scheduler, but for the most part, the BeOS kernel is outdated (or should I say ‘primitive’?), slow (the latencies to enter the kernel/VM are bad) and feature incomplete (no mutexes, VM is no re-entrant). Like it or not. The Linux kernel has other problems of course, but it is generally speaking, faster than BeOS in stats, forking, throughput, VM. However, BeOS on the other hand, has a fully preemptive kernel, it has lower ‘media’ latencies and a great Scheduler. So, while both kernels are different, in ‘everyday simple usage’ and *especially* in server operations and gcc compilation timings, the Linux kernel will prove faster than what BeOS can give you. However, when it comes to Media performance, BeOS will perform WAY better. So, pick your fruit…
Hi all BeOS fans !
Just wondering if it would be possible to build some basic Beos layer…
Where could I get some info about BeOS binaries and system calls ?
The system calls are not documented and the source code is not open.
What you can do though, is to dissasemble the libroot.so found in BeOS and also find an object file (scalls.o or something, can’t remember how it’s called) in the BeOS commercial CD (around $40 USD). There you will find all the system calls you need, but remember that dissambling that stuff is illegal.
To check out BeOS (if you already haven’t), <A HREF=”http://www.computerchannel.de/download/dl_detailseite3_db.phtml?pro… the 45 MB Free BeOS edition which can be installed through Windows (the commercial version installs in its own BFS partition by default). Better use the BeOS boot floppy disk to boot to it after you install the bootable image file in your FAT or NTFS partition.
If you run into trouble, email me privately and we will go from here.
Question for the developers of BlueOS or anyone else might be able to shine some light on this. Just recently, there was a slasdot discussion about the pros and cons between DirectFB and XFree. Wouldn’t it be better to use DirectFB instead of XFree because it’s cleaner, smaller memory requirement, better overall performance, etc.? What’s your thought about this?
DirectFB
http://www.directfb.org
Slashdot Article on DirectFB
http://slashdot.org/article.pl?sid=01/10/23/1252214&mode=nested
-kenneth
How is the Linux kernel when it comes to SMP? I thought I heard it was nowhere near BeOS, but then again I have no clue myself.
So…
>>Today we are not dependant of a specific filesystem, but we choose ReiserFS.
Maybe AtheOS-FS would be a cool solution. AFAIK, It’s quite simmilar to BeFS.
That Interview’s left me confused. Is the GUI gonna be a ported Open Tracker or is it gonna be a custom built one?
Open Tracker != GUI
Open Tracker: ported
GUI: custom built
Too many open-source projects will spoil the game and guess who will benifit from that … A simple study of Webserver-OS “market share” for last year would reveal who gained and who lost.
Some people claim that KDE/GNOME etc. are “bloated” and Slow, then why not do some improvements for yourself, after all, the source code is available for just that.
I just wish these developers would get together to improve the alerady available OSs and add/improve application rather than start all over again.
>> Some people claim that KDE/GNOME etc. are “bloated” and Slow,
>> then why not do some improvements for yourself, after all,
>> the source code is available for just that.
Do you realize that most people cannot programm or don’t have time for it?
> between DirectFB and XFree
Not enough driver on DirectFB today, but if a day DirectFB support more cards than XFree
you will see a special app_server using DirectFB….
:o)
As one of the developers of the BlueOS app_server and InterfaceKit, I can tell the following:
The screenshot provided with this interview is taken on BeOS R5, running completely reprogrammed GUI widgets created for BlueOS. I also make these classes available for OpenBeOS so no one needs to duplicate sources.
The BlueOS interfaceKit is NOT build on X but native ! BlueOS will only use the Xfree as driver for graphics output. Also the InterfaceKit is extended in this way: We have more widgets, more keyboard navigation, more user settings, slightly different widgets in some places.
The changed things at this point: The button has different default draw mode. I did not like the large border that is displayed on BeOS when a button is default. A textControl can have a different background color if it has focus. The widgets have customizable tab stops (order of tabbing). Using the up/down keys behaves like tab and shift-tab.
There are currently two different GUI styles. These can be more by user design.
The things I wrote here are not things I would like to see, but it is just the way I coded it at this point ! For the ones that would like to see the prove that the code excists, I can just say: join our team !!!
We are NOT writing a Linux clone, but rather an OS that is BeOS source compatible, has the userfriendlyness of BeOS but access to all the drivers and apps written for Linux ! This is the only way we can think of to get an OS on a reasonable time-table that is capable of conquering lots of new users that can experience that losing BeOS is a waist.
Regards,
Frans van Nispen.
Code as fast as you can! We are waiting for BlueOS!
Now i think that maybe it will be ok
THX Frans for info. I only hope it will be as fast and responsive as BeOS.
Now i think that maybe it will be ok
THX Frans for info. I only hope it will be as fast and responsive as BeOS.
I remember jbq posting on Be*Talk (dunno if it was user, dev or code) that BeOS’ SMP had an so enourmous overhead that some apps ran faster with 3 cpus than with 4.
However, in terms of “feeling fast”, BeOS on a dual-P3 beats the crap out of Win2k.
Thanks for clarifying the BlueOS Goals. From reading the earlier article and other sites pointing to this article… I initially thought, BlueOS was merely a Linux distro that will run BeOS Applications. I was impressed with BeOS in terms of it’s smooth multi-tasking and awesome 3D rendering as well as it’s simplicity. I look forward to previewing a production release of BlueOS when it becomes more useable.
However, by the time that happens, Linux distro’s will also have improved…
So I will have to make a full comparison at that time. Surely by this time the Enlightenment e17 (or e20…) will be shipping it’s new embedded shell features. i.e. file management, etc. Also allowing for a GUI shell. i.e. pull up a list of MP3 files and filter them by typing a wildcard onto the GUI window.
I am an engineer and I like and use many different systems. I support all Open development and will choose what suits me best at the time. Enough of this MacOS sux, Linx sux, Windows sux, etc. crap. To each his own. In the end it will all sort itself out. Keep in mind that the computer revolution is still very young. It will take about 5 to 10 more human generations before things get ironed out fully. By then I will surely be dead (unless we all download our brains into machines that is)…
Actually, I think the best filesystem for BlueOS would be XFS. It has all the features of BFS (attributes, node monitoring, etc) and ACL’s to boot!
Some points about the two systems.
1) Both systems should be similar for SMP. Linux has some technical advantages (such as extremely low context switch times) but BeOS is more multi-threaded in general. BeOS also scales better to 4-way+ systems.
2) The BeOS scheduling system IS better. BeOS’s scheduler is designed for desktop usage, and thus gives preference to interactive applications over compute-bound applications. This means that compiles may take 5% longer, but the system won’t become jerky while compiling something. Also, BeOS gives GUI threads higher priority automagically, while on Linux this has to be done manually (which means it usually isn’t done at all).
3) Linux’s audio latency is theoretically better. The kernel itself has audio latencies down to around 0.5 ms (with low-latency patches), but the OS is hindered by a cruddy media framework. OSS (Old… I mean Open Sound System) is really a bad sound driver architecture, and ALSA (Advanced Linux Sound Architecture) isn’t standard yet. Also, the media frameworks leave much to be desired. The major one is aRts, which will be used by both GNOME-2+ and KDE-2+. While it has tons of features, it does mixing in software (it doesn’t support many of the hardware features exposed by ALSA) and it has fairly bad latencies (it is not very optimized ATM). So, the tools are there in Linux (low latency, fast IPC, etc) but aren’t being used properly.
4) The Linux graphics system is better. XFree86 4.1+ really is fast in terms of raw graphics throughput. For example, it blits bitmaps about as fast as DirectX in Windows. Plus, it has good accelerated 3D. However, it has bad response times (partially due to the fact that the Linux kernel doesn’t give GUI threads priority by default) and the toolkits built on top of it are really slow. Also, it isn’t as unified as it should be. Lots of cool new features exist (like the XRender and XRandR extensions) but they aren’t automagically used by all applications and the old cruft is still in there. Also, font handling is really bad, since until recently, apps had to do much of their own font management.
I did not really like the idea of BlueOS till I read this artical. I do now.
Next, could you and OpenBeOS form some form of group when it comes to the magical ‘r2’ features (such as the XML, Crpto kits etc) as I don’t really want to have to source-code incompatable varents of BeOS.
Mlk
What do you use for the input system ? keyboard, mice, tablets, USB ?
Hiho,
two things:
<p>
a) Kenneth (above) said it: if XFree will only be used temporaly, why not using DirectFrameBuffer from the start???
b) in addition to the last para of the article (“we do not use Linux, we use its kernel”): Linux IS the kernel!</p>
seeya, Blaz
“we do not use Linux, we use its kernel” , Ok Linux is the kernel but people always consider that a Redhat, Suse,… distributions are Linux.
It’s to be clear
We don’t use DirectFB today, because today not enough card are supported, the drirect use of XFree86 drivers is planned for BlueOSv2 because, we want first keep the X11 compatibility and mainly because it’s faster to develop our app_server on top of it. I’m really conviced that XFree is the best choice today.
About XFS, live queries and other BFS specific stuff are not a priority today for us, to read/write in BFile is the most important.
We are developing step by step.
The input_server is X11 dependent (on V1). If your device works on Linux, it will works fine on BlueOS too.
To improve the responsivness of graphical applications, we will see if we can easily use realtime priorities of Linux or use a negative ‘nice’ value.
If you have information about “how to boost X / how to code efficiently XFree4.1”, send us an email whith a code example or explainations, your help is welcome.
so, to be clear… this project would be BlueOS/Linux, in the same manner that “linux” distros are actually GNU/Linux…
> If you have information about “how to boost X / how to code efficiently
> XFree4.1”, send us an email whith a code example or explainations, your help is > welcome.
You can also send that to the KDE and GNOME developers too. They need it.
I read the whole interview a few days ago and resisted to comment info that was presented, but couldn’t stand now as it was published on our beloved /.
Quote 1:
“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.”
Hmm, I think this should be Robert Love and not Alan Cox, bad skill of copy/pasting
Quote 2:
“The main reasons why I don’t like Linux are the non-flexibility and the “chaos”.”
If you don’t like it why do you use it? No offend in that, I’m just interested what the rationale behind thinking it’s bad and using it is.
Quote 3:
“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!”
I’m quite interested how he will do this.
I read nice things so far about BlueOS – guys you use Kernel 2.412 – Mandrake switched to Enterprise Kernel 2.4.8 SuSE to 2.410, 2.5 is planned.
How do going to avoid this kernel updating confusion?
How do you going to implement the bombastic networking stuff ?
That’s mostly running in kernelland on Linux ?
Do you monthly recompile a new actual kernel, and leave the average user alone with it – like Linux Distro’s actually do ?
The Linux Kernel update issue drive me nuts !
To the FS choice : as long as ReiserFS runs & cleanly sync’ed befor shutdown, it makes no troubles. But believe me, after some serious hangups & crashes, several brutal restarts we easily brought the ReiserFS to crash – so you won’t be able to boot into Linux after that. That’s really happening (F.ex. pushing 3 times to reset during or after a boot – the ReiserFS was unusable after then – or continuous hang ups while it tries to mount a raid controller which it hasnt got a driver for – a stupid thing : why do you try to mount something you see but you don’t got a driver for it ?).
FS-Crash – a thing I never saw at the BFS – as long there is a bootable BFS partition & the disk is o.k. that baby will boot – no matter how brutal you interrupted it….
Will BlueOS have a typical Linux directory structure?
it’s realy great to “merge” 2 operation systems, because of
2 reasons: 1)save beos
2)make linux easier and more multimedia capable
>> Will BlueOS have a typical Linux directory structure?
I’m sure that the Linux and the BeOS directory structure will be in BlueOS. Open a BeOS Terminal window and enter “cd /” you’ll see a Unix like dir structure. “boot” is the real partition while “/” is generated. It’s quite easy to play whith symlinks to have a Linux structure.
Hi,
I would like to say that, though this project has great develpoers, and is a great idea, in reality, it just another LINUX.
Say Again? Yep, If your using the Linux Kernel it’s LINUX Period.
Heck, I can Create a desktop that looks like BeOS for Windows, but it’s still a crappy ass windows kernel and file system.
The most impressive thing about BeOS was its Kernel Design, Specifically the SMP part. While everyone knows or at least should know, you wast money buying a 2,4,8… Multiple Processsor Windows Machine, yet get more bang for the buck with a multiple processor BeOS machine. And best of all, Your BeOS applications will benifit! They do not need to be specifically designed to work with multiple processors, as other OS’s require.
I’d prefer to see more development in necessary applications for BeOS R5.
Why? Because, if there were a Photoshop Clone, Corel Draw Clone, and 3D Studio Max Clone for BeOS, maybe Palm will Release Version 6, since a real promise of users would exist!
As for OpenGL Excelleration, sombody find the person who released those beta test of frame rates at BeNews, kick his ass and take that code!
But seriously, someone could leak it to the public. What harm could it do?
Microsoft News Flash “According to Microsoft Press, BeOS R5 OpenGL Beta Drivers that were leaked to the public are faster that Windoxs XP DirectX 9.0 Release, and therefore Microsoft has filed suit against the DOJ and MasterBeatas HeadQuarters claiming: 1) A Beta Product may not meet or exceed a competors non-released final product. 2) John Q. Public must remove all Beta OpenGL drivers from his/her BeOS Machine and use Windows with DirectX”
If you can’t tell, yes the above New Flash is What Harm it could Do.
-jason
In response for kenneth on DirectFB…
XFree or DirectFB has intersting architectures. It is evident that this system will adopt the best technical of both. When we’ll have the core, we can evolve in independent way by keeping a compatibility with Linux and Be (OpenBeOS) app. It is already necessary to have an environment structured to adapt it then, see rewriting it totally for keep the best performance. On the other hand, it is necessary to keep OpenBeOS contact for their precious work and track all evolutions in the linux world.
But for BlueOS was not a unix like, it must take his independance.
It’s me again.
I read the preview message and I agree to it. The kernel is the heart of your system.
I know a other OS project that run befor beOS, it’s called AtheOS. This project is good for help BlueOS developpers.
look at : http://www.atheos.cx and the lines from http://www.osnews.com