The new OpenBeOS newsletter is discussing the new VM and file caching implementation for OBOS.
VM, File Caching and You
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The CVS-thing was a good idea, makes it easy for people to see what is going on
I like the update list for OBOS in their newsletter. I hope it continues with the upcomming newsletters.
If the CVS status updates are appreciated, I am more than willing to continue assembling them.
Yes, the CVS status update is VERY appreciated! Me and many other BeOS fans/groupies/evangelists check the status of OBOS daily.
Updates are appreciated especially at recent times of frustration, fragmentation and in a few cases,descent.
Peace, love and OpenBeOS!!! (…so sue me ;-P )
-shaka
Concerning the CVS digest:
I am wondering what the guys at TBJ will now come up with to still be able to promote incompetent coders like DW 😉
@ The 1noticed:
Why is DW an incompetent coder? Just curious… (and no, I’m not DW
I for one, DO appreciate the time & effort you spend to make the CVS digest. PLEASE keep up the good work.
Hmm Iam also thinking why he is incompetent?
Ive seen someone said that before, but I really want to know why YOU are thinking it, please join them if you think you can do a better job.
Thanks Nils for the CVS updates, its nice to read that, I dont have time to follow every little check-in so its nice that you added them.
/Konrad
the cvs & vm-articles are really interesting. thank you.
I really appreciate the CVS digest. Please continue investing time into this.
Thanks
Okay, it’s been asked before, and will almost certainly be asked again: why oh why are the OBOS crew developing their own kernel?
Reading an article like the one linked above, I can’t help but shake my head in disappointment that so many brain cycles are going into an already-solved problem, esp. considering the importance of a good VM subsystem in the performance and stability of an OS. If you don’t like the Linux kernel, or its license, there are plenty of other places to look for stable, portable kernel code: NetBSD has an excellent unified buffer cache design for I/O and VM pages, the Mach and L4 research groups have gone over microkernel systems many times in the last 15 years, etc., etc.
I understand the desire to have a completely “built from scratch” system, but unfortunately, still think its incompatible with the desire to have a complete, working system any time soon. And no, I don’t consider running OBOS servers on top of a BeOS binary kernel to be a good option: it’s illegal for many uses, encourages the continuing (and eventually, wasted) efforts to write new drivers for an obsolete kernel API, and fails to take advantage of even the “state of the art” that existing open source systems can offer.
In a word, Amiga. Such a cute, tight, tiny kernel. But, oh, the power. I think people would do well to study Intuition in depth.
BeDoper is dead?
Okay, it’s been asked before, and will almost certainly be asked again: why oh why are the OBOS crew developing their own kernel?
Did you read their FAQs, yet? 😉
http://open-beos.sourceforge.net/print/print_faq_html.php?id=25
http://open-beos.sourceforge.net/print/print_faq_html.php?id=26
Well, because writting our own kernel is part of our objective. The reason we are doing this is probably the same reason why some of us decided to have kids when it is usually much easier not having them.
Of course, once we have them we usually do not regret that. 
I guess I am terrible at analogies.
-Bruno
So you can have the perfect kernel for an OS as cutting-edge as BeOS. Linux is not an option be it is monolithic so you need not mention it. BeOS’ strengths have always been in its performance and its tight kernel was to thank for that. So they’ll get to the party a little late (or perhaps even a lot late) but they’ll arrive looking better than everybody else.
One of the things to keep in mind about BeOS is that it has never been about being first to market. It is for people who value quality over rapid-availability.
First, let me apologize for bringing up what is obviously an issue that has been talked to death here and elsewhere. However, the only valid reason I’ve heard so far was Bruno’s comparison to child-bearing — essentially, it seems as though the creation of a new kernel is its own justification.
To tell the truth, I have no problem with alternate OS projects doing everything “from scratch,” if their goal is to innovate and push the boundaries of what operating systems can do. However, OpenBeOS, as a recreation of an existing (and rapidly growing less innovative) design, is already accepting a set of goals somewhat less aggressive than that.
I’m a huge BeOS fan. If I could reasonably use it as my primary worksation OS, I would do so. Unfortunately, the lack of modern drivers, security and stability updates, and critical mass of users all combine to force it back down into a position of “hobby OS.” While I respect and admire the drive of the OBOS folks, things like the kernel issue make me question whether they’re going to be able to finish their “dream OS” before it’s completely obsolete.
Of course, the kernel isn’t the only issue; keeping binary compatibility with the old BeOS, while a noble goal, also means that they’ll be stuck with the 2.X brach of the GNU compiler toolchain indefinitely, which loses them many easy performance advantages in the new C++ compiler. Using the old BeOS server interfaces means that they’ll sometimes be unable to improve on things that really need it (accessibility, networking, security). And the list goes on…
In short, I think that the OpenBeOS project has great potential, but as long as they stay committed to creating an exact reproduction of the original BeOS, they’ll be stuck with the technology and design decisions Be made in the mid-90s. Meanwhile, Linux, Windows, OS X, and any number of more flexible alternatives will all be moving on into the current decade/century/millenium of operating system research and implementation.
> And no, I don’t consider running OBOS servers on
> top of a BeOS binary kernel to be a good option:
> it’s illegal for many uses,
Even if OpenBeOS R1 objective is running them on top of *our* own BeOS binary compatible kernel, I can’t see what’s may illegal about running alternate or new “servers” applications providing new or BeOS R5 compatible services on top of a BeOS kernel?
Or are you talking about building a distro here, in fact?
In this case, we all agree with you then.
> encourages the continuing (and eventually, wasted)
> efforts to write new drivers for an obsolete
> kernel API,
Here again, I don’t see what could be considered as an obsolete kernel API in BeOS R5 kernel. We aim to binary compatibility, that implies being compatible with large numbers of drivers already available today for BeOS R5.x:
network cards, sounds cards, graphics, etc.
On areas where such drivers don’t exists, that’s right, we may choose to come up with non-compatible API, but only if it won’t hurt anybody…
> and fails to take advantage of even the “state of
> the art” that existing open source systems can offer.
Like?
A journaled file system with indexable attributs and live queries?
A data format translation API and addons?
A non-bloated, clean, object oriented API?
A very effective and responsive system, even more on SMP machines?
Sorry, we already have this.
Be sure we’re often looking at what could be improved over BeOS R5, even for first OBOS release, while it could be binary compatible. These “state of the art” open source technologies are and will carefully look at. For example, we’ll use FreeType2, instead of writing our own type engine…
Like all coders, we’re lazy 🙂
Oh, BTW, there is no brain-cycle “wasted” here: it’s our project, we do it because we want to, not (only) because people wait about it…
…they’ll be stuck with the 2.X brach of the GNU compiler toolchain indefinitely, which loses them many easy performance advantages in the new C++ compiler.
Although the R1 libraries will be compiled with GCC 2.9x the future versions will come with updated, not binary compatible libraries compiled with GCC 3.x togather with the old ones(which will be kept for some time for binary compatibility).
Hi!
I agree with you. OpenBeOS *IS* the true BeOS clone, but it looks usable only in R2 (with Glass Elevator ideas). It’s sad, because I want a 2003 ready OS, and OpenBeOS isn’t.
When I joined in BlueEyedOS, I saw it. But OpenBeOS is a essencial project, because reveal us the true power behind BeOS.
Michael VinÃcius de Oliveira
~ BlueEyedOS.com Webmaster ~
Actually, I have a good feeling that OBOS will be using a later version of GCC. We at yellowTAB use GCC 3.something, and have a system for backward compatibility.
When Zeta comes out and becomes standard in the community, OBOS will only need to worry about being compatible with Zeta apps, if they want to. Code in the very least.
Binary compatibility I have been told is very very simple in this situation, but I am not in the center of OBOS, just yT 🙂
–The loon
I agree with you. OpenBeOS *IS* the true BeOS clone, but it looks usable only in R2
If R1 meets it’s design goals what exactly will make it unusable? Sure it will have some glitches – old GCC, no multiuser, etc., but does this make it unusable?
The biggest usability problem that it will have is app support and drivers. This has nothing to do with R2 though.
The average end use does not care which version of gcc is used or whether the API has been updated. All he wants is two things:
1. Applications
2. Everything just works
Although Linux gets better in #1, it is very far from acheiving #2.
Hi!
*USABLE* not to me (I still use BeOS like my main OS, because I have *All* drivers for my machine), but to world use in Banks with Java (which will be available only in OpenBeOS R2), etc.
Michael VinÃcius de Oliveira
~ BlueEyedOS.com Webmaster ~