After Palm announced the buyout of Be, Inc.’s intellectual property & Technology and after some consequent indications from several key people that Palm has no interest at Be’s products and especially in BeOS, a number of the BeOS believers tried to find a new home. Some found confort in AtheOS, others joined BeUnited’s effort to license the BeOS source code, while some developers formed efforts like OpenBeOS and BlueOS. OpenBeOS (OBOS for its friends) consists from a number of BeOS developers who are trying to recreate the BeOS Kits in a form of a new, complete and open source Operating System that has source and if possible binary compatibility with BeOS 5. One of the most important people in this effort, Michael Phipps, also part of the kernel team, is here today for an interview to OSNews.1. The project started almost two months ago. Was any serious code written so far, except the kernel contributions?
Michael Phipps: Much serious code has been written. We haven’t posted much to source control. For example – the printing kit is pretty close to done. The screen saver kit is nearly done. The interface kit is well underway.
2. What are the bigest obstacles you have encountered so far? Undocumented APIs, not enough developers or something else?
Michael Phipps: Lack of developers is certainly an issue. Many people believe that this is a job that is not realistic and/or are pinning their hopes on a licensed BeOS from Palm.
I am trying to point out to people that Be used to re-write pieces of the OS for every release. From bfs in DR9, up to BONE/OpenGL for R6. Even if the code does get licensed, our work would not be/is not in vain.
Personally, working with Sourceforge/CVS has been the largest problem. It works … sporadically on my machine/setup. Sourceforge and I are working to resolve that.
3. Does OpenBeOS have any ties with BeUnited or the two projects are completely independant?
Michael Phipps: I am in touch with BeUnited. I fully support their efforts to license the code. There are several reasons for this. One is that backward compatability would be MUCH easier that way. 🙂 Another is that some of the things that we want to do would be aided a great deal by seeing the code (bfs, for example).
4. Who is working currently on the NewOS/OpenBeOS kernel except Travis Geiselbrecht and yourself? Does lot of changes have to be made to achieve BeOS compatibility?
Michael Phipps: The kernel is an interesting story. It gets the most volunteers, actually. 😉 To some degree, Travis’ kernel is exceptional because it sprang from one mind. For that reason, he and I agreed that he would do the design and major development. Until, that is, he reaches a certain point where he wants to take the kernel into decidedly
non-Be like directions. At that point, we will fork the code. But that is a long way off. I took a little time off of kernel to do screensaver. One reason was to prove/disprove the binary compatability issue. Another was that we needed a completed kit or three to inspire and serve as examples. Shortly I will be returning to the Kernel with tons of things to do and ideas.
5. Has work started for the App_Server and the Interface Kit clones? Are there any working/alpha code on the CVS to be found for these two kits? Are these kits going to be written from scratch or alternatives like QT 3 may be considered (QT is a GUI Toolkit that resembles lots of the BeOS API functionality and C++ OOP coding style)?
Michael Phipps: Work has started, and these will be from scratch. Several ideas were batted around concerning where to begin. Nothing seemed to really completely fit the BeOS model. So we started from scratch.
6. If Palm decides to continue support of BeOS and maybe even release a new version (however it seems extremely unlickely), will the OpenBeOS team continue working on the project?
Michael Phipps: Yes. Even if Palm makes 1 new release, will they make 2? 3? 9? I don’t think that many people in the BeOS community really want to trust another company like that again – especially a small, underfunded company. :-/
7. Has OpenBeOS tried to approach ex and Be engineers to help in the difficult task?
Michael Phipps: Yes. Unfortunately, there are two issues here. The first is NDA – how much could they really help? Second is real life. The events at Be were not really very pleasant the last year or so. And most of the engineers are either burned out on BeOS or are super busy getting their post-Be lives together.
Having said that, I would be *THRILLED* to have ANY former Be engineers help.
8. Are you mostly interested in source or binary compatibility with BeOS 5? Also, are you going to implement the bugs of the OS? (it seems necessary, if you want to achieve perfect compatibility)
Michael Phipps: We would prefer binary compatability. Early results seem to bear out that this is possible. If we really hit a bad problem, we will reconsider. But there is no reason to give up without a fight.
As for the bug issue, I guess it would depend on the bug and the impact. Many bugs can be fixed without breaking any compatability. For those that can not, we will decide as the time comes.
9. Why don’t you use a forked AtheOS as the base of the project, as AtheOS is already quite far down the line, and lots of its API is already similar to BeOS?
Michael Phipps: This was another possibility that was considered. Design decision were made in AtheOS that make it different from BeOS, internally. Also, AtheOS is GPL’ed and OBOS is not.
10. Are you going to implement BeOS exactly as we know it, or you may introduce new elements to the system, for example new widgets and functionality?
Michael Phipps: Yes. 🙂 The goal for R1 is 100% compatability. Some things that would not effect that (new widgets, for example) could be added if time permits. But we are focused on getting a release out, not improving R5. Some things will be better as a result of the rewrite (the kernel and bfs come to mind).
But wait until you see R2. 🙂
You could help the OpenBeOS team if you are experienced C/C++ coder. You can subscribe to their developer’s mailing list by sending an email to [email protected] with ‘subscribe’ in the Subject field or by logging into the web interface at FreeLists.
Any chance the OpenBeOS kits could be ‘retrofitted’ to work with BeOS R5? I think about the printing kit, and at some point they’ll have a reworked networking kit. Since these are substandard in the current version of BeOS, would they be able to release the OpenBeOS kits to work in BeOS?
I hope that question makes sense…
I agree with Big Al. I will jump to OpenBeOS when it’ll be at R1
, but until that time releasing kits for BeOS would be a great thing.
1st: because that way ppl can try if there is full compability.
2nd: because it would improve BeOS.
The thing is that it may not be an R1 if you don’t join and do some CODE today (this is for everyone, not just for Shard or BigAl).
OBOS needs real coding and less talk (from what I can see comparing their CVS and their mailing list). Discussing about standards and stuff is good, but most of the people seem to just talk in that mailing list and not do some real coding. (Read the ReactOS interview we held here in OSNews a week ago regarding OBOS to see what I mean).
Also, it does not make lots of sense to back port the newly written kits to BeOS 5. It may need so much time (as all the code is still pre-alpha) that it is better spend on evolving OBOS, not BeOS (which needs lots more than just a new priting kit. Kernel bugfixes to enable it to boot to newer hardware is the most essential of all and that can only be done from Palm or Be unfortunately).
The only problem I have with OBOS is that I believe that they are starting the building of this new OS the wrong way: upside down. It is like placing a TV antenna while you don’t have a foundation and a roof yet. Writting the printing kit and the screensaver kit while you don’t have a BeOS-enabled kernel or app_server yet, to me looks plain wrong and it will require them to rewrite/fix these kits if and when the foundation is complete.
I have read almost everything posted to the mailing-list mentioned (yes even the IRC logs posted).
I think they plan all OBOS kits to be able to function as replacements in BeOS R5. That way they can release kits as they are completed and they can be tested on compatibility in a already functioning OS.
One thing I’m not clear about is binary compatibility. It seems you can have different source code and still be bin. comp. , you would be required to have the same functions. But since they plan on at least the same API, I don’t understand why they would need to re-implement the bugs of R5.
I would like to know what would be required for binary compatibility. (URL?)
You’re right Eugenia. Too bad i’m so crap coder, almost without free time, my help is useless
>>…while some developers formed efforts like OpenBeOS and BlueOS.
What’s happening at BlueOS? Is there a lot of achievments in their corner?
We will have some <A HREF=”http://blueos.free.fr“>BlueOS news soon, and maybe even a screenshot.
While I appreciate the effort for the BeOS clones, many of the key parts of BeOS were licensed and are not easy to develop.
I have no doubt that these folks can come up with a resonably good OS that even mimicks BeOS. It would probably take them a long time to get to the R5 level and I just don’t think it would Be as cool as the real thing!
ciao
yc
linux as the kernel. how do they plan to get that
running anything like beos. they will not have the
system_time() and snooze_until() anywhere near
as accurate as the original beos ones.
what the use of running linux with x using a c++
gui api designed for another os. there are other
c++ api one could use.
and then it’s closed source. and probably written by
idiots (, or they wouldn’t have chosen the linux as
their kernel).
no, i don’t think i like this blueos…
blueos…
they have a consortium area.
not much information on the site.
the guy who started blueos probably isn’t
even a programmer.
Eugenia, the reason for working on the kits parallel with the app_server and kernel is this:
a) we’re a volunteer group so we rely on the generous contribution of folks. If someone wants to work on a particular kit, then we encourage that help. We are not in a position to tell people, “no dammit, that’s not important, work on the kernel!”. Not everyone has that knowledge or interest. We want people contributing where they can. It will all be needed in the long run, so effort is not being wasted
b) no kits should rely on the internals of the kernel. In fact, most of these kits are relatively independent of each other. That’s how we can have different groups working in parallel. This is actually faster — it’s multi-threading where project groups are the threads! Granted, some linkages will crop up and we’ll deal with them as they occur. But by and large, the development can and will carry on in parallel tracks.
Oh, and one more thing. I don’t think there is more talking than coding going on (well, maybe in my case, but it’s kinda my job to blab alot). It’s just that the CVS repository doesn’t reflect the test code that developers are working with. I think that given the very early phase that the project is in, tho, having a higher dicussion-to-coding ratio is perfectly appropriate. We need to have people thrash out ideas, problems, and methods of attack before they jump headlong into coding. This ratio will alter as time goes by. If six months go by and we still see what you’re talking about, then I would agree with your complaint. For now, I think we’re reasonably on track.
I think it’s sad that they are splitting up the “few” talents there are in different camps. I don’t feel encourage to help when it is like this…but if BeUnited could get a “lifetime” license for the BeOS source I would help if needed.
Actually, BlueOS was started by a programmer, and we have made a ton of progress. We’re rewritting the kernel/x11 to suit our needs. Don’t dismiss BlueOS yet. Whats’ happening behind the scenes is pretty exciting. :]
…and don’t say that ‘the programmers must be idiots’ … that’s just flamebait and non-constructive. Keep it off this board…
The rule in Free Software (whether they like it or not, and it seems that mostly they don’t like it, OpenBeOS is a Free Software project) is “Code is King”.
So far except for the kernel, which was never supposed to be anything to do with BeOS in the first place, OpenBeOS consists of an empty CVS repository and several collections of “test code” most of which are not publically accessible.
I have one of these components (allegedly a proof-of-concept App Server) in front of me and it’s less than a day’s work, 1000 lines or less. <sarcasm>I never knew App Server was so simple</sarcasm>
It doesn’t include any licensing info, so we still have to take Michael’s word for it that this is a project under the MIT license. Put in that boiler plate guys! It exists for a reason.
At the weekend Michael Phipps had an opportunity to show that this project was serious by releasing a drop-in compatible screensaver, or at least the source that would one day be such a component.
Of course a screensaver is not much, but it would have been evidence that OpenBeOS could be built over a number of years and achieve its official goal one day. Instead the screensaver, supposed to be available “soon”, was quietly forgotten after this interview. Maybe it will appear later this month, or next month, but really the message is “OpenBeOS is not something BeOS users should be looking forward to any time soon”.
I still think OpenBeOS is a better idea than either BlueOS (which is basically a Linux distribution with a BeOS flavour – “who cares”) or BeUnited which is trying to do something Be Inc. failed to do for 10 years, make BeOS a financial success.
In the worst case a lot of people will learn lessons the hard way (I look forward to seeing performance numbers from the networking-in-a-process model OBOS want to use, after BeOS already demonstrated how badly that works IRL). In the best case maybe in a couple of years OpenBeOS will really be a 2nd coming of BeOS. I’ll be happy to wait and see.
Hi BeOS guys,
As an AmigaOS user I can sympathise, back in 1995, a group of AmigaOS developers started a similar type of project called AROS – they are now finally getting it into a usable state – so good luck and ignore your doubters because it can be done! These great OSes must live on
To the guy who was dissing Linux, here’s the clue stick.
1) I am the world’s biggest BeOS fan.
2) Linux totally kick’s BeOS’s kernel’s ass in every possible way. The filesystem (XFS) is faster and has all the attribute goodness in BFS. The VM system much better (unified buffer-cache/page-cache) and has great performance. Audio latency (with the preempt patches) is lower. Linux is perhaps the fastest OS kernel available in many standard system calls like mmap. The networking code is light-years ahead. More drivers (like full support for the SBLive, unlike BeOS’s lack of hardware accelerated anything!).
3) The BeOS userspace one-ups KDE/GNOME in lots of ways, but loses in lots of ways too.
4) X isn’t that bad. Its blazingly fast, but has terrible responsiveness.
“2) Linux totally kick’s BeOS’s kernel’s ass in every possible way.”
That’s a fairly broad statement, but I suppose there might be some truth behind it, seeing that the Be kernel hasn’t been updated in, uh, two years… (and never will be)
At least with Be I rarely had to bang my head against the computer because I couldn’t get a piece of hardware to work right :]
To say that the linux kernel “kicks BeOS’s kernel’s ass in every possible way” is not fair imho. Sure, the BeOS kernel needs improvements, but the filesystem really isn’t that bad, even compared with XFS, which isn’t in the standard linux kernel afaik and ext2 is not as good as BFS. Even if you use the preemptable kernel patches, i don’t think latency is really lower than under BeOS, or lower than it could be in BeOS. And the BeOS has a user space software mixer only adding about 1 millisecond latency. You won’t see that in Linux for a while yet. Linux is often fast, but often so at the cost of disabling interrupts for 100+ milliseconds. There is still a lot of work to be done on the kernel to remove that, since reliable audio latency is thus still 200+ milliseconds even with the kernel patches. And obtaining accurate time information is not possible with linux as it is with BeOS, which has very accurate time measurement/scheduling needed for media applications.
Are the OBOS and BlueOS guys working together in analyzing the various parts of BeOS? If no: Why not?
Just like to wish both OpenBeos and BlueOS the best of luck.
HarjTT
; o )>
Good luck to you both.
This is really cool! I commend these programmers who are taking the initiative to do something! I will be just as excited to boot into OpenBeos R1, as I would be to have BeOS R6, even if it was only small programs or screensavers. The point I like to keep in mind is that things are LOOKING UP !! It may take some time, it may not be binary compatible, but the thought of a GOOD OS progressing is very positive. Forget the nay sayers. Look at it as a learning experience also. Nothing wrong with learning OS design. If you listen to the pesimists, then NOTHING would progress !!!
Hey people! I am curious, in the OpenBeOS project, is there someone paying close attention to avoiding, and fixing cyclic dependencies when they appear?
This is an issue that appears to exist even with the low levels of BeOS, and happened all the time with example Be OS programs, even those written by the Be engineers. I have brought this issue up with Travis in the early days of the NewOS kernel (before the death of Be Inc. was pronounced) as I noticed it even then.
No, this is not an issue unique to Be OS programs – not by a long shot! The standard MFC programs written for Windows using the AppWizard/ClassWizard strongly encourage the creation of these hairballs. Many books by so called Windows programming “Experts” show how to create these hairballs, and indeed, the “Scribble” demo application is a good example of what you should NOT do. And no, it isn’t just a C++ issue, either – it can exist in many different languages.
Why is this important to be concerned about? There are many reasons:
1. It is much harder to understand systems that have cyclic dependencies, as everything has to be understood as a complete system, and can’t be easily and completely understood as a separate part by itself.
2. Bugs! Because of the interconnected nature of a cyclic dependent beast, bugs are more likely, as the neck bone can be directly connected to the hip bone, so to speak.
3. Testing! With a system that has cyclic dependencies, you can not test the system starting from the low level and go up in a defined order that is guaranteed to test everything, at least not in a good isolated testing method. When you test one bit of code, you need to execute and link all the code that it depends on. With the common cyclic dependencies that often exist in projects, that is likely going to require testing the entire program just to test a single class/function.
4. Parallelism! You can not easily parallelize the task of development when the system(s) are connected in such a way. You will end up spending oodles of time coordinating small changes, as things will constantly break. Making a single, small change in on header file is likely to cause the whole project to be rebuilt, even if it is not really needed (directly) by many things.
5. Extendability! A system with cycles in it is very difficult to extend in a reasonable fashion. Having worked with applications of over 200,000 lines of code that had cycles in it, I can speak from experience of how nasty it gets trying to figure out where to add something in to a system that is snarled. A system without these snarls can be extended much more easily.
What IS a cyclic dependency? I am so glad you asked!
OK, so maybe nobody asked, but consider this review if you already know what a cyclic dependency is, and consider it valuable education if you don’t already know what they are. Let us imagine that we have a small application that has several classes, one for the main application (BApplication derived) several BWindow based classes, and several views. We all know that the BApplication derived class, at a minimum, will need to have some kind of #includes, though it is possible that the main.cpp could, in main(), assign the windows to the application. For the sake of this discussion, though, let us assume that the application class includes and depends directly on the BWindow-derived classes. These BWindow-derived classes, in turn, likely depend on BView-derived classes, etc. until done.
Now, let us have the BWindow-derived classes call on methods defined for the BApplication-derived class – specifically, methods that are not defined in BApplication (the base class) itself. This forces us to #include “BApplication-derived-class.h” inside of the BWindow-derived class. We now have the simplest example of a cyclic dependency in the system. We can not use or test the BWindow-derived class unless we compile and link the entire application. If we even make a change in the header to the application class, the BWindow-based class will need to be recompiled and relinked.
Now, imagine that the BView-derived classes also relied on methods in the BApplication-derived class, methods that BApplication itself does not define. In good practice, BView-derived classes should be easy to rip up from one project and add to another, and that should be possible without any changes – true code reuse. Now that we have added a dependency to the BView-derived class that forces it to #include the definition of the BApplication-derived class, we have a problem: for all intents and purposes, the BView-derived class depends on every single class in the system, in terms of compiling and linking, and testing are concerned, because the BView-based class is dependent on what the BApplication-derived class is dependent on. Since the BApplication-derived class is (logically, theoretically) at the top of the dependency hierarchy, and depends on everything else, we have the problem.
How feasible is it to create software without these problems? Very feasible- easier, in fact, in the long run to create software without cyclic dependencies than to create it with them. Initially, it seems easier to create the cyclic dependencies, and not worry about them. They will come back to bite you sooner or later, as build and link times and complexity increase. Oh, as a reminder, with cycles in the system, link orders become impossible to put in a nice order, and build times increase in an exponential manner.
Is there good material that explains how to properly deal with this issue? Yes, there is! Go to your favorite local bricks-and-mortar bookstore, or to an online bookstore, and get yourself a copy of “Large-Scale C++ Software Design” by John Lakos, with ISBN of 0-201-63362-0 to get a more complete explanation of the problem, and how to fix it, as well as a lot of other good information on structuring large applications.
Wish I had some spare time and a proper computer to help you guys…
I suppose these people should be given kudos but I tend to look at history of an opensource OS before doing so. What is the goal of such projects? I hope it is not to get the OS into the mainstream. It will be doomed. How many mainstream OS’s are out there? I can count 2 maybe three – Windows, Mac OS and possibly Linux, although I think people are using it more for development and server applications than as a mainstream OS (to do everyday, non-computer-related tasks). I would definately say two, the two mentioned already. How did these two succeed? MS “gave away” their OS with a PC purchase. Apple has proprietary hardware for their OS to run on. Both got in before the mainstream had computers. How does a company break into those areas? If you know, you’re lying. No one has succeeded in that arena and probably never will, until the day Microsoft finally breaks enough laws and they are barred from stealing….ah, I mean innovating.
I wish the plans good luck, although do hope that somehow Palm decide to release R6 before throwing it away, even if it’s just to keep us happy. I’d love to help with the coding, but not being a hardcore C++ coder, I’d be of little to no use, although if there’s anything less techie that needs help with let me know and I’ll see if I have the time to devote to it.
To say that the linux kernel “kicks BeOS’s kernel’s ass in every possible way” is not fair imho.
>>>>>
Maybe I should have phrased it, “the linux kernel gives BeOS’s kernel a slap on the wrist.” You’re right, the differences aren’t ALL dramatic.
Sure, the BeOS kernel needs improvements, but the filesystem really isn’t that bad, even compared with XFS, which isn’t in the standard linux kernel afaik and ext2 is not as good as BFS.
>>>>>>>>
Actually, BFS is really good. Its probably faster than Reiser and a little slower than XFS. Still really fast, though.
Even if you use the preemptable kernel patches, i don’t think latency is really lower than under BeOS, or lower than it could be in BeOS. And the BeOS has a user space software mixer only adding about 1 millisecond latency.
>>>>>>
BeOS latency is closer the 3ms, and audio latencies on Linux (with the low-lat patches) are down to 0.5ms.
You won’t see that in Linux for a while yet. Linux is often fast, but often so at the cost of disabling interrupts for 100+ milliseconds.
>>>>>>
There are only a few places where interrupts are disabled for several milliseconds, and none of them occur on the normal path. Just make sure you don’t switch tty’s while doing audio processing…
There is still a lot of work to be done on the kernel to remove that, since reliable audio latency is thus still 200+ milliseconds even with the kernel patches.
>>>>>>
Except its not. See relavent benchmarks at Andrew Morton’s website.
And obtaining accurate time information is not possible with linux as it is with BeOS, which has very accurate time measurement/scheduling needed for media applications.
>>>>>>>>
Actually, it is trivial on any x86 OS to use the rdtsc instruction to get a timer that is incremented on every clock cycle. That’s 0.5 nanosecond resolution on a 2GHz P4.
>>And obtaining accurate time information is not possible with linux as it is
>>with BeOS, which has very accurate time measurement/scheduling needed for
>>media applications.
>Actually, it is trivial on any x86 OS to use the rdtsc instruction to get a
>timer that is incremented on every clock cycle. That’s 0.5 nanosecond
>resolution on a 2GHz P4.
you can’t schedule on that though, i.e. scheduling is still 10ms accurate on linux for x86, but i may be wrong. and does this work for smp? are these timer the same on all cpus?
Here is a link to a presentation made by Jon Watte
http://www.b500.com/~hplus/aes-2001/
An excerpt:
—–
Interrupt Latency
Internet appliances typically use a single general purpose CPU for all their needs. This means that many different requests are made of the CPU to process user interface, video, audio, networking and other information based on the system user’s actions. In BeIA, like most operating systems running on a single CPU, a device may temporarily monopolize the system by turning off interrupts, in effect preventing the current task from being interrupted and other tasks from being scheduled. The maximum length of time during which interrupts are turned off by any device on the system is known as that system’s interrupt latency. Long interrupt latencies may cause such artifacts as audio drop-outs or stuttering, jerky cursor movement on the screen, and even network disconnection.
The BeIA driver development policy is to defer as much work as possible to user-mode threads or kernel-mode deferred procedure calls. This allows it to run with interrupts turned off only briefly. The goal is to not have any driver turn off interrupts for longer than 50 µs on a current “desktop” system, here most closely resembling the Celeron reference platform. By and large, we meet this goal, although some third party modem device drivers may incorrectly disable interrupts for extended periods of time when initializing or shutting down the device. Top measured interrupt latency during heavy run-time system load is 80 µs on the Celeron system, 190 µs on the Geode system, and 1000 µs on the Crusoe system2 .
—–
So that’s giving figures of 0.08 ms worse case interrupt latency for a 600Mhz Celeron system.
I don’t know how ppl like me (knowing just a bit of C + or -) can help in OpenBeOS project at that time, maybe in the future (hopefully)…