Daniel Switkin, a long time BeOS developer and former Be Inc. employee, has submitted an editorial on "Writing A BeOS Replacement". It aims to bring together the various efforts out there and define a plan which has the greatest chance of success. Click Read More to see the entire article from Daniel.
Post a Comment
While I'm not the biggest fan of BeOS, I think you've hit most of the important points. I've always wondered why there are four different open source BeOS clones.
I agree with you, that it's important to use the Linux kernel. However, I think you're going to meet alot of resistance here. Many purists seem to want a custom kernel. In addition, I hear that there are some things Be does (like the filesystem) that can't be very well implemented in Linux. But maybe I'm wrong.
Basing a BeOS replacement on an existing kernel seems like a good idea to me. But wouldn't it be better to focus on developing a strong alternative to X and porting one of the 'smaller' window managers as example application? KDE 3.1 Beta is really great, I enjoy working with it, but it's still not as responsive as the Windows XP GUI. And there is the font-rendering issue. Everyone claims that X is the real problem, yet I see only very few working on replacing it?
(Addition to my comment: I really don't want to hijack this 'thread', but I believe discussing the need for a BeOS replacement is appropriate and important.)
then make a modula to impliment the FS.
then for the gui, I would recomend making a server that is binary compatable with X but with none of X's problems, make it closer tot he hardware. it can be done I am sure.
There is no reason to rewrite the beos kernel. It would be much easier to focus limited volenteer kernel hacker time to add befs code to the linux kernel then to rewrite vm, real networking, multiple arch support, smp, frame buffer, video drivers, sound drivers, ide, scsi, etc... Why not reused the hacking time of the linux hackers and the debugging time of all the linux users. If you still want a microkernel, then you can boot strap it off of linux.
I have never understood why obos wants binary compatiblity. Compatibility for what apps??? They aren't any beos apps.
I'd love to see a beos clone. I just think that if the beos has such clean api and microkernel design, it shouldn't be too hard to port to linux. The linux kernel will always be faster. Period. Users don't care if the kernel is monolithic or micro. I love the microkernel design, but I like working sable code better.
I think all BeOS projects should start talking to each other and unite. Why waste so much energy by different Beos groups? Looks like every group has almost the same goal. Recreating BeOs. But every group is trying to reinvent the wheel... by making it more round?. Common guys. Let's start talking. We short on developers, Lets start working together. Lets not have 1000 different BeOS's like some other os's. Is it that hard to get along...
> Compatibility for what apps??? They aren't any beos apps.
There are a lot of little apps and a trackload of utilities. BeBits.com has 3,050 entries, but only about 2,500 of them are real C/C++ apps. The good thing about these little apps, is that they are little. 
Which means that they can easily ported/recompiled to a "new kind of BeOS". So, they are apps for BeOS, but they are not big. Which is a good point to NOT go for binary compatibility.
These are all my thoughts exactly.
However:
I think that a problem of open source saturation is going to severely hinder such a project. The people that are most interested in this type of project are probably already busy working on other things. I would love to work on it, but simply have my focus elsewhere.
The people that are working on BeOS resurrection project are probably not willing to dump what they are working on, and start something new.
In addition:
If such a project did get off the ground, using Linux as a base, I think that the project could possibly attract some developers who have been involved with Linux, Gnome, KDE, etc. Efforts need to be made to have this happen.
For building a new OS, having C++ be the primary application development language is dated. Of course old Be apps should be able to be ported, but I would like to see a new language such as C# to take over the reigns. To take this idea even further, I think that Mono needs something for people to use GUI apps with (specifically an implementation of Windows.Forms) besides hacks into GTK and QT. A new BeOS of sorts could be a perfect opportunity to use Mono as an extra boost into being "something new and cool" to gain interest among everyone.
So anyway, those are my thoughts. My main point here is that more needs to happen that just provide a platform for BeOS applications to be ported for this to be a successful project. It needs to be so good, that it pulls developers away from othe projects. Any other ideas?
Daniel, thanks for a thoughtful article. As a fairly recent convert
to BeOS, I think I agree with you regarding use of an existing kernel; Linux is the obvious (but not the only, or best) choice.
One reservation: I have made BeOS my primary desktop OS because it is fast (wow is it fast! - especially compared to Linux). If this speed (especially boot speed) is lost in the complexity of linux,
the excercise loses most of its value.
It is nice to see old x-Be people are still thinking about BeOS
=)
4 kids standing on the ground can't reach the cookie jar on the top shelf.
Stand on each others shoulders and cookies all round.
It's that simple.
Daniel is right on the money here -- and *he's* the kind of developer you want to attract to work on a project like this.
Drop BC,
go with gcc 3,
Linux/LGPL,
*unite*,
and watch for some serious SERIOUS worm-sign.
Sometimes I just can't figure things out.
#1 If there are linux drivers then how did someone get that info?
#2 If linux is so open sourced that why isn't that driver info easily removed from the linux sources?
#3 It may be the words Linux that keeps me away since I was never a fan of waiting and the slowness. Would a linux kernel based BeOS be just the same to the user? Fast, responsive stable?
#4 Wasn't one of the good things about beos was that it was supposed to be easlily ported to different processors and platforms? When I peek into files I see more than x86 things.
Just wondering.
Hrmmm ... I was really interested in this article up to this point ...
"BeOS clone on another open source kernel, probably Linux."
Yukkk ... I hate Linux more than Windows.
This editorial isn't really saying anything new. I'm hardly qualified to speak on the technical merits. Obviously, if binary compatibility is too difficult to maintain, then no, they shouldn't stick with it. But it's not up to me to say what constitutes "too difficult", but up to the OBOS developers, although I will say that I find B.C. desirable.
But the main issue is the developers themselves. They don't really have the same goals in each of their projects, although they are obviously similar. It's just not realistic to expect them to make *big* compromises merely to have everybody working on a single project.
And fussing over the kernel obscures the issue. Important as the kernel is, it's the BeOS API that seems to be the most important issue. While it's unrealistic to expect everybody to work on the same project, I don't think it's too unrealistic for the groups to have open lines of communication between themselves, and especially to work towards a standardized API. This would not only help maintain the core of what made BeOS unique, it would also help make the multiple projects complementary to each other, increase cross-compatibility for developers, and would increase the value of all the involved projects.
...and PalmSource owns the source code!
If PalmSource does not release a desktop BeOS derivative (or transfer the source code), BeOS will die! It's that simple. PalmSource knows this!
While engineers can develop various operating systems, none of them will ever Be the BeOS. They won't be as fast, they won't match the BeOS low latency, they won't match the BeOS API, the file system, the demos, the fans, the spirit!
BeOS is NOT easy to make folks. It took some very talented and motivated people 10 years and a lot of money to make.
I am waiting for PalmSource! I would like to have something by second half of next year. If I don't hear anything by end of next year, I will probably give up and join the Penguins. More than ever, I believe that Resistance is NOT Futile.
ciao
yc
This was a very well written and thought out article.
Many of his points I agree on.
I would *love* to have the Blue folks work with us. I have invited them many times. The MIT license just doesn't suit them. That isn't a criticism of them. Just a statement of fact. I know next to nothing about the other groups (Leonardo, in particular).
I think that hardware support is far less of an issue going forward than it was for Be. Compare the state of hardware now to 5 years ago. Parallel and serial are dying, USB is now. USB has standard APIs for printers, scanners, keyboards, mice, joysticks, etc. Much easier. How many video chipsets are there? You can count them on one hand (by family, not permutation). Etc. I think that hardware wise, the new OS's are in much better shape than Be was, in a lot of ways.
For licnese reasons, among others, the Linux kernel would not work for OBOS. We would need to make many changes to Linux to make it Be-like. Many, many. I have spent enough time in that code to know that it isn't a place that I would volunteer to be. I considered the BSD kernels. They bring a lot of the same "stuff" that Linux does. But I think that the smaller, (hopefully) faster kernel that we will end up with will be worth the time and effort. Certainly the learning has been. Interestingly enough, no one has ever said that they don't think that we will do as well as Linux. Just that we are wasting time. This is a slower route. But I think a rewarding route overall.
Daniel makes some very good points about binary compatability. Particularly with Be's applications. They were something that we abandoned early on - their undocumented nature made them too tough. If we are binary compatible to the BeBook's specs, we should support nearly everything out there. And despite what it seems like, it has cost us very little coding time and effort. Certainly no where near what the community thought that it would. Yes, it has "stuck" us with GCC 2.95.3. That hasn't been a major point of pain, either, since most of us are developing on BeOS. In fact, it has been a necessity. And I am very glad that we didn't bet the farm on 3.0 or 3.1. As far as STL, that could very well be problematic. We haven't spent nearly enough time on that. A final note on BC - this is not a permanent state. It is like a car seat - it helps to keep the infant upright, not to be the last chair he ever sits in.
We chose CVS because Sourceforge offered it for free. And it is familiar to me, personally. I am not particularly addicted to it.
Licensing is a tough call. Let me say this - I have had more hate mail and more "praise mail" over this one thing than any other. It is the worst thing in the world - no matter what you choose, you are wrong. LGPL would be considered a sell out by everyone, I think. My take on it, simply put, is this - I think that it would be the epitome of hubris to think that Microsoft (let's be real here - who else wants OS code) would come and steal our code. Yes, I know about the BSD networking stack. Still, I think that it is pretty prideful to think that. If Microsoft wanted the code that badly, they could have had it for $11 million, 1 dollar. They didn't bother. I think that we are pretty safe.
All in all, I think that OpenBeOS is the place to be. We welcome anyone who wants to contribute. We have made a lot of progress but still have far enough to go that people can make a big impact. One of the things that I don't think that most people realize is that the way to succeed in an OSS project is to take initiative. To look at something and say "That needs to be done. I will go and do it." Just let us know, first, so you don't replicate someone else's work. ;-)
> BeOS will die
BeOS *is* dead, no matter if it runs on your 2 years old PC or not. There is no company behind BeOS, there are no real updates for 2.5 years now. Please spare us YC.
>I am waiting for PalmSource
You will wait for a long time.
What are we really talking about here?
It seems to me that there are a lot of technical issues that people feel very strongly about. When someone says, "use the Linux Kernel" does that invalidate the design of BeOS? Is it BeOS, what is BeOS if it is not the BeOS kernel? In order to get the suggestion of having everyone work together to create this "UnitedBeOS" I think we all need to agree on what BeOS is.
So what is BeOS? Is it the technology that went into it? Or is it the results that that technology produced? I would submit that it is the results that really matter. BeOS was unique because it allowed a certain set of abilities to exist in an operating system, to perform in a certain way, that no other operating system before it had. That's what makes it BeOS. Now, if the SAME functionality can be achieved using different technologies, can we call this BeOS?
Take the Turing test on this one, if you use it, is looks like it, behaves like it, and works like it, then it must be it... in other words, if the Tracker and Deskbar can be implemented on top of the latest Linux Kernel with the XFS journalling file system and the super new Threads package, and it performs exactly as BeOS did, then to me this is also BeOS... it's really all about what it does, not how it's made, or how it does it.
To me, and this is my personal view, if I could get a system that worked like BeOS did, and had the apps that I can use, and the support of thousands of driver writers and financial support from companies like Sun and IBM that are betting on Linux to take them into the next century, then I would want to use it, not because it's the linux kernel, but because it is a working copy of BeOS, and has the functionality that I crave in a computing experience.
Then again, if I can get the same functionality out of NewOS, then I would want that too. I don't care as a user which kernel I'm running. It's about what works.
So in the end, I support choice, but I also wish that all the people working on BeOS would get together and work collectively in the same direction, rather than appart, which is why I am such a believer in standards for these projects.
Thanks again for the thought provoking article, and if you want to ever submit your apps to beunited.org just drop me a line =)
At last there's a voice of reason.....These are my thoughts almost exactly.
I have to say tho...instead of using the linux kernel in whole...why not use NewOS as a base and port over the best of the best of componetes from Linux ,*BSD, and any other os that would be usefull.
That kernel, the new Cosmoe Appserver and the ui that Syllable is creating we'd have a damn good os....and it could be completed (at least booting) in months.
Let's all remember Transformers: The Movie
"One day one shall rise from our ranks and light our darkest hour....
'Til all are one"
Douglas Lockamy
dlockamy@nc.rr.com
I enjoyed the article, as it was well-reasoned and didn't attempt to put forth anything except one man's opinion -- and it's a solid opinion, at that.
I'd like to respond to this question, from a commenter:
"What is BeOS?"
As a non-programmer who really really really loved using BeOS, I wanted to offer what I want as a BeOS replacement (obviously, your mileage will vary).
1) Super-fast booting. This ROCKED.
2) A journaled file system that allowed me to recover from a power outage without scandisk or other nonsense. This ROCKED.
3) The ability to move an installation from one partition to another by launching the installer and moving everything over. This ROCKED (do you see a pattern to my enthusiasm here? I'll stop saying that now).
4) The boot manager that could boot BeOS, Linux or Windows with little muss or fuss.
5) The DriveSetup application.
6) The fact that a complete installation took less than 200mb.
7) The lightweight and responsive GUI.
8) The straightforward preference apps, installation tools and menu configurator.
9) The ability to have my hardware recognized if the driver was present, with no "new hardware detected...." nonsense.
10) The ability to play multiple mp3s, at different speeds, in forward and reverse, without skips, pauses or hiccups.
11) The ability for Pulse to reflect CPU activity in real time, instead of every few seconds.
12) The searchable filesystem, live queries and custom file attributes (my mp3 collection may never be that well-organized and easy to search again).
13) The ability to write quick USEFUL apps in a terminal window.
It's a lot of things. Some may or may not have been made possible by the kernel, and may or may not be possible using the Linux kernel, but I don't >care< what kernel we use, or what makes it work -- I just want it back, and want it to run on my machines.
Religious wars aside, BeOS was great for how it worked for the end user as much as for how it worked for developers (if not moreso).
Okay, end rant. And I really did like the article. 
I personally think that OBOS is the real deal. If these guys are a little nutty and want to write their own kernel, so be it. Binary compatibility is even nuttier. But, they seem to be the most dedicated to replicating the BeOS experiece exactly as it was "back in the day". You have to love that. It takes some testicular fortitude.
Using a linux kernel somehow seems wrong to me anyway. Linux and BeOS are pretty much total opposites in my mind. Monolithic and Be just don't sound right in the same sentence. I booted into Be because it started up fast as hell and did things I didn't think were possible on a crappy Celeron 300. Have you ever tried to boot linux on a Celeron 300? Yeah, the one without any L2 cache. Even with my RAM maxed out at 256 megs and a new 60 gig hard drive, KDE runs painfully slow.
I know. I know. Buy a faster computer!
This is tangentially related because someone *did* make a comment about fonts in X. Fonts in X can look r3333l pretty. Gentoo users type 'emerge freetype'. It'll install 2.1.2 (which just got unmasked in the last day or two), which is a big step up from 2.0.x. At this point, it'll be only a little while until FreeType matchs Cleartype in quality.
>>BeOS *is* dead, no matter if it runs on your 2 years old PC or not. There is no company behind BeOS, there are no real updates for 2.5 years now. Please spare us YC.
I disagree! BeOS is alive and well otherwise we would not be discussing it, people would not be writing code for it, people would not be writing articles about it, people would not be trying so hard to clone it!
While I say kudos to the engineers attempting to clone BeOS, and may even try out their OS, I know that BeOS can only come from PalmSource!
I know it, you all know it, and PalmSource knows it!
Wether we admit it or not, we are all really waiting for PalmSource.
Eugenia, I know you really care about BeOS, I know that you don't believe it's dead, I know that you're still hoping that PalmSource will make an announcement soon, I know you want to write articles about new BeOS technologies, I know, I know, I know...
Guest what, PalmSource knows it as well because Sakoman and most of the engineers who worked hard to build it are there! Gassee is on the BOD! Make no mistake, BeOS lives (dormant or NOT) between the walls of PalmSource and on the desktops of the fans.
ciao
yc
I don't think the goal of OpenBeos is to take over the computer world in the shortest amount of time. I for one am very happy they decided not to use the Linux kernal ( and X windows.....acccckkk!!!). I don't want to have to recompile a kernal when I change a hardware device. I'd go back to win95 before that. NewOS might take some time, but in the end, I think people will end up praising the decision. For pushing the envelope and creating something better.
Breaking binary compatibility should be considered if it means having a good compiler. Dan brings up some excellent points on this matter. Besides, I can keep a R5.0.3 PE partition around for older apps if I need to. If the end result is worth the effort, then do it.
My votes:
-Linux kernal ( its turdly !!! keep it on a server where it belongs). Yea for NewOS, even if it does take some time.
-gcc3+ and BC would eventually need to be done. Do it now.
-MIT's a good license if you ever want commercial apps developed, or be taken seriously by commercial entities. GPL is good for people that want everything for free.
Dan- thanks for the editorial.
Mike Phillips - your doing a good job. many thanks
Thank you to everyone who read the article and took the time to offer an intelligent response. Let me try to reply to some of them:
Mikey: "Compatibility for what apps??? They aren't any beos apps."
Sadly, I have to agree. There are very few that are unique, that we couldn't live without, or whose author's might not open source them.
Eric Murphy: "For building a new OS, having C++ be the primary application development language is dated."
While that's true, it's also the overwhelmingly dominant lanugage for desktop apps out there. I'd hate to be in the MacOS X position, shouting "Objective C really is better!" and watching thousands of developers shrug. Call it lazy or shortsighted on their part, but it's reality.
johnG: "...and watch for some serious SERIOUS worm-sign."
Ah, a Dune reference. LOL. "We have wormsign the likes of which god has never seen!"
Sikosis: "Yukkk ... I hate Linux more than Windows."
I should have pointed out that I'm not a Linux fan specifically. I've got an old Mandrake install that I was never very impressed with, so I'm hardly an advocate. I'm simply being pragmatic - Linux is where the hardware support is. No matter how great a product you create from scratch, if it doesn't boot on my machine, I won't use it.
Michael: "It's just not realistic to expect them to make *big* compromises merely to have everybody working on a single project."
You're right. I'm not very optimistic that it will happen. But I think given the goals I outlined, it's the only way to get there.
If you want to use the Linux kernel and then start porting things like KDE, what you have is a mutant linux not BeOS, like Mac OS X is to BSD. I think the people at OpenBeOS have the right idea clone R5 from the ground up just the way it was and should be. I believe OpenBeOS could be a much better OS then Linux. Sure it's a lot harder to do it this way, but thats just the way it is. A lot of what makes BeOS great is in the kernel and maybe it will be even better in the NewOS kernel. Im not saying it would be bad to have a Be clone on a linux kernel, mite turn out to be a fine os, but it isn't BeOS. I would much rather support a true from the grownd up clone with little chance of becoming mainstream than a project that settles for something less just because it's supported. If we always did that and never started from the ground up we would never have something like BeOS to begain with.
"So what is BeOS? Is it the technology that went into it? Or is it the results that that technology produced? I would submit that it is the results that really matter."
Simon, I am very impressed by your response. I was going to write something much along these lines. We do need to figure out what people loved about BeOS so much and make that the main goal. I also agree with your conclusion - I think ultimately the results matter much more than how you get there.
I have a strong feeling that OBOS R2 will arrive before R1. Why? It is common knowledge that the last 10% of code takes 90% of the developers time. Once OBOS is close enough to working, it will get compiled with GCC3.2+ and be called R2, with lots of open-source apps targeting it. It wont officially be called R2, but thats how it will be known amongst the community. I think even OBOS teamleaders will realise that it's not worth the effort of spending more time on R1 to get the last 8-10 closed source apps working, especially not when we've got OpenProductive and Mozilla already working on R2. So binary compatibility will be foregone, in order to move forward. Wasn't that the BeInc philosphy, remove the cruft, the old bloated binary compatible sludge, and start fresh. BeInc broke binary compatibility with almost every major release.
I disagree with Daniel on the Linux kernel issue. Even though it has matured nicely, the world at large still hasn't migrated to it, and frankly never will. Even though it has received major financial/developer support, it still only occupies a niche. Linux missed its window of opportunity, and thus will eventually fail. The biggest argument for an OSBeOS to use Linux is the drivers issue. As FL2 (fearless leader #2) mentioned once, the diversity in hardware land is shrinking, with only a handful of 'real' vendors left. The number of drivers which need to be writen will be smaller in 2003 than in 1999. X11 based video drivers are useless for an OSBeOS, since none of them wish to use X11. Using a lighter kernel (NewOS) allows OBOS to integrate a DirectFB solution to the kernel for a better desktop experience (like R5, Windows, Mac classic, Amiga...), unlike X11 which we all love to hate.
As for 4 different BeOS projects, there is nothing we can do about that - its human nature. I guess that evolution will prevail and the fittest will survive, hopefully sooner rather than latter. I prefer the direction taken by OpenBeOS, it just seems 'right', and is the most open of the four. The other 3 projects can utilise the work done by the OBOS crew, ie. they can copy the new BeFS, so I guess that they can divert manpower elsewhere. Its funny, I see the BlueEyed guys as Linux porters - they will port all the great BeOS stuff to Linux. In order to port stuff, you need both platforms running. So they will never sway too far from OBOS.
I was impressed by this article too.
An I agree that results are important, perhaps more important than how you get there. But I think that for some in the community, the 'trip' is more important than the 'destination' in some respects, since it's all about doing it for fun.
If I was building this as a commercial venture, I certainly would have picked many of the technical choices you presented, because they do have the potential to reach the results faster, but for coders that are doing this out of love, it's not the point for them.
Take AtheOS as an example. Kurt built this out of his own interest, and never wanted it to be anything more than a learning experience. And I respect that too.
But I still think that there is a common ground out there that can bring the separate projects together in some way. At least standards is a starting point for discussion among the groups, and beunited.org is working to make that happen.
Time will tell =)
Gscott --
> X windows.....acccckkk!!!
just because you use the linux kernel dosn't mean you have
to use X...Blue Eyed OS is using the linux kernel and don't plan on using X...so stop being and ignorant moron
> have to recompile a kernal when I change a hardware device.
thats funny, i have been using linux for almost 5 years and
have NEVER compiled a kernel and i have added, changed, removed hardware components all the time...the REALLY funny thing is that linux usually just boots and deals with the changes, when i rarely boot into my windows partition, windows goes nuts (if you want to go back to that be my guest)
hardware support, like everything else in the linux world,
is getting better in leaps and bounds...
> Linux kernal ( its turdly !!! keep it on a server where it belongs).
so while you are using an OS that is in, what i would say "a coma" (since it's not actually dead), i will be using Linux
jefro wrote:
> #1 If there are linux drivers then how did someone get that info?
Don't forget, the GNU/Linux dev community are typically a wily and subversive bunch of hackers.
> #2 If linux is so open sourced that why isn't that driver info easily removed from
> the linux sources?
Read about GNU and their GPL http://www.gnu.org/ and pay particular attention to compatibility of various licenses.
> #3 It may be the words Linux that keeps me away since I was never a fan of
> waiting and the slowness. Would a linux kernel based BeOS be just the same to
> the user? Fast, responsive stable?
Heh. The kernel that is Linux is very configurable. It's very fast and very stable. I've heard some say it's not pretty to work with though. I'd be curious to hear the OBOS kernel folks' reasons for choosing NewOS over a *BSD kernel. Just curious anyway.
> #4 Wasn't one of the good things about beos was that it was supposed to be
> easlily ported to different processors and platforms? When I peek into files I see
> more than x86 things.
The kits/servers are. They talk to the kernel. The kernel is what takes the most porting. That and all the drivers.
Greg wrote:
> Monolithic and Be just don't sound right in the same sentence.
Informed persons have told me that BeOS indeed has a monolithic kernel, although a very modular one at that.
hehehe... yc, you're a funny one. Still waving the that flag!
I feel that Linux would be a good choice but not the best. Linux really isn't all it's made out to be, nor is Windows. I think the big question is this,... What does the computer user population need? Do we really need another clone of this or that? Sure, each OS offers things that other does not, but why does it have to be one or the other? Taking advantage of whats already out there is a great place to start. But it should stop there. It's time for something new, different, unique, better.
BeOS was a great OS, it could of been the leading OS. The potintial was there, and possibly still is. Where do I think a good place to start is? Gather all the open source resources there are, evaluate them, and design something completly new and unique. Better yet, can we all say cross-compatability? Why? Think about it for a moment. In it's own way, its OS racisim. Windows is better, Linux is better, MacOS is better,... bah I say! I say make an OS that is compatible with everything and offers what the others lack. Ask your self why Windows is the most widely used OS. Put aside your feelings about what you think is best and search for what makes it the worlds most popular Operating System on the planet. Then, you go from there.
To Michael Phipps,
You have so many good points that I'll need to write you offline to address them properly, or perhaps I'll write a follow up article.
Dave Owen: "It's a lot of things. Some may or may not have been made possible by the kernel, and may or may not be possible using the Linux kernel, but I don't >care< what kernel we use, or what makes it work -- I just want it back, and want it to run on my machines."
As my boss likes to say, I'm in violent agreement! It's the overall experience that matters.
Greg: "I personally think that OBOS is the real deal... <snip> It takes some testicular fortitude."
No doubt. And the geek in me understands the appeal. It's the side of me which knows how unbelievably hard this task is that wants to cut it down to something more reasonable (by leveraging existing efforts). And even then, it's very ambitious. The R5 app_server code alone would put the fear of god in anyone.
Gscott: "I don't think the goal of OpenBeos is to take over the computer world in the shortest amount of time. I for one am very
happy they decided not to use the Linux kernal ( and X windows.....acccckkk!!!). I don't want to have to recompile a kernal when I change a hardware device."
Agreed, taking over the world isn't the goal. But it would be nice to be more than a niche hobby project. And I agree again on your second point - it is completely unreasonable to expect this from desktop users. There would have to be a system of detecting hardware automatically and installing the correct modules for it in a simple, foolproof way. I don't know Linux well enough to know if this is possible.
Eric Olson: "Im not saying it would be bad to have a Be clone on a linux kernel, mite turn out to be a fine os, but it isn't BeOS."
I hear your concern. But is MacOS X any less MacOS because it's based on Mach and FreeBSD? On the contrary, it's a much better system under the hood, but still retains everything slick, simple, and beautiful that Apple is known for. Check out Simon's post about this for another viewpoint.
the author is right, trying to clone beos is foolish. how's this for a plan
-
linux kernel (why develop/maintain a kernel at all, let a MASSIVE community do it for you)
write a low level x replacement
wrap the beos api
-
this idea is already tried and true, it's called os x (ok, so they use mach, but it's the same idea)
As a former BeOS user, I know as well as anyone the sad state of applications for the BeOS. But let's be fair to those who have spent long hours writing/porting apps to the BeOS - it's not that there are no apps, it's that there are no CURRENT apps.
The BeOS was a productive and featured environment for a while (no pun...)
It's not productive or modern *anymore*
you BeOS is alive folks make me laugh...guess what DOS is more alive than BeOS...OS/2 is more alive than BeOS...Amiga is more alive than BeOS
this is not a troll...i just think you people need to realize that BeOS truly is dead...development of it as you knew it has long since ceased...leaving you with two options...hack away with what you have or reinvent the wheel...but no matter how much you scream BeOS is alive because you use it...won't bring it back
also, redundancy isn't such a bad thing...if one effort fails completely...the next one can pick up the slack
i say let the best BeOS clone win...the clone wars have begun
-bytes256
"...Blue Eyed OS is using the linux kernel and don't plan on using X...so stop being and ignorant moron"
Are you sure about that one? Check out these screen shots. Some of the fonts look mighty ugly. If it looks like X and acts like X then what's the point of not using X? Or may be they are using X atm
Look at these screen shots:
http://www.blueeyedos.com/screenshots.html
Looks like they are runnung GNOME here:
http://www.blueeyedos.com/news/2002.02.good01.jpg
This one looks better, more BeOS like:
http://www.blueeyedos.com/news/2001.11.slider.png
Well, I use BeOS everyday. I am also the port lead for Mozilla among other projects for BeOS. At work, I use Linux, for its stability compared to Windows, and it has a JVM (I'm a Java dev by trade).
Really, I just like BeOS. I have not decided which project I like better, though, but have always leaned towards OpenBeOS, just because they are more "open" and I can see the progress. I'm a computer nut, and it interests me.
But, if B.E.OS comes out with a release, I'll probably try it. If it does not react like BeOS, I'll continue to use the original, and wait for another release. At the same time, I'll keep following the OpenBeOS developerment, waiting for a release, and judge it the same way.
So, I agree with both Simon and Daniel. It is the experience that motivates me to use and work with BeOS. This is why I support all the projects, by continuing to develop BeOS applications. I too wish they could work together more, and perhaps, maybe sometime in the future they will. In the meantime, I'll still be here, watching, waiting, working on applications to run under BeOS, no matter the license, the kernel, or whatever.
-paul
p.s. - I am very productive under BeOS. I'm writing this comment from with BeZilla :-)
It's small, It's simple, It's very fast, It has an ultra-fast IPV (the servers could be so fast as a monolitic kernel), It's stable, It's working, It performs very well, It has optimizations for x86 ...
"Ohhh! Clap! Clap! Clap! Clap!"
Hi Daniel!
I was waiting one position of some ex-Be engineers about the BeOS clones, since Aug, 16.
Firstly, I want say "Thank you!" for this article!
Why several ex-Be engineers abandon the community after BeOS death? Why you, keep silence until now? (ok, Dominic already did it, but...) Why you, only now, want keep contact with us, the real community, the die-harders?
Ok, you left Be. I understand. But several BeOS users (I'm included) cried for BeOS funeral without you? Ok too. Sweep tears is NOT your job!
Where in the world is your NDA? If you don't know, JOIN US! hehe
To be crystal clear, I would love see and read more article like this! THE WHOLE COMMUNITY NEED OF YOU HELP!
Thanks a lot!
Michael Vinícius de Oliveira
BlueEyedOS Webmaster
"Are you sure about that one? Check out these screen shots. Some of the fonts look mighty ugly. If it looks like X and acts like X then what's the point of not using X? Or may be they are using X atm"
Yes! We are using X, Linux and Gonx design to interface. But X will be abandoned in R2, because our app_server will be UNIQUE in BlueEyedOS
Michael Vinícius de Oliveira
BlueEyedOS Webmaster
My love for BeOS came around 1996 or 1997 when I booted D3 on a PowerMac. I was so impressed by it's responsiveness. I have always had a fascination with OS's and my favorite was the Amiga (my first real OS love). BeOS was my second wind. I joined the Be Developer family in 1998 so I could have the inside scoop on what was going on. Then purchased R4 (I still have my receipt from BeDepot) and was so excited when R4.5 came in the mail for free. I also wanted to learn to program. R5 was a dream come true.
Although I never created any applications, I loved BeOS and it has saddened me to see it's code locked in the Palm Penitentiary in solitary confinement.
It was BeOS's features that grabbed my attention. And it was BeOS's commitment to Be different, and stay ahead of the other's because they could (no legacy code).
Sometimes I say to myself, "where are you JLG!?" Only to realize that he is locked up to.
< Dido's arougthopher-thoughts Posted on 2002-09-24 04:24:27>
About the license: I think Daniels best point in the article was about the license. The GPL license is way too restrictive to companies. It doesn't allow them to gain any competitive edge over their competitors, because they are forced to hand over everything they have developed to their competitors. On the other hand, the MIT license, give too much to companies. A company that develops parts of OBOS are not likely to release that code, in the name of competitive edge. That is the nature of business. We've seen it many times in history. Companies will abide by the letter of the law (in this case licenses) and will give as little as possible (unless it suits their needs). Many people have voiced (or typed concern that Microsoft would steal the code and make it their own, if the MIT license is used. They are not the only opertunistic shark in the water.
It seems that the Mozilla license offers the best blend of both worlds. It gives a company the right to keep it's own modules and additions private, which I'm all for. It also, prevents any company from taking the code, changing it, fixing bugs, and keeping that information form the source of the hard work. I don't think that is too much to ask. The reason, it seems that OBOS is under MIT is to not discourage corporate interest. I think it has been proved that companies will choose to live with a slightly more restrictive license, such as the BSD or Mozilla licenses.
I see the OSBOS projects as a beacon of hope, for desktop users, who are stuck in an expensive Microsoft world. In my opinion, the OS is just too important to be left up to one company to decide it's fate. An open-source (and hopefully free, or at least less expensive) desktop OS is the only way we can see true choice in the desktop OS arena. This does not mean that their cannot be anything proprietary about the distributions. There is still plenty of room for companies to add "middle-ware" and features that will make them stand apart from one-another. Imagine AOL, Real Audio, or Opera branded OBOS distributions.
I second Anonymous. What the BeOS guys think about L4?
Personally, I'm a GNU/geek waiting for the Hurd, but I'd like to have a nice, beautiful and intuitive system for my family. Windows sucks and MacOS X is great, but too expensive. So I'm rooting for OBOS (or B.E.OS, wichever comes first).
I htink it should be an evolutionary process.
In the Beginning There were BeOS developers and it was good, oh ,whoops
Lisence: why not Dual GPL/Commercial or LGPL/Commercial like goBe.
Kernel Wise: Linux -> HURD
Linux will provide a stop gap measure to get going. Then have some developers preparing for the Coming of Be to HURD and to help get HURD to the point of handling a BeOS system. HURD will provide a good non-monolithic kernel for it especially with teh L4 microkernel port when it is done. From watching the Linux kernel news, teh driver API is evolving to maybe be a good common API sicne it will be hard to get people to use UDI and split Linux sub systems into HURD servers, keep driver API, change the backend.
Graphics System: X (Cosmoe-like ssytem if can get Kurts permission for Lisence change) -> Fresco
X is like Linux, a stop gap measure. Fresco would help provide future elements. People want to program in a more "modern" language then C++? Corba would let you do this with Fresco.
One of the main reasons for these choices (Linux/HURD, X/Cosmoe/Fresco) is that they are here NOW to one level or another and this plan takes advantage of where tehy are now and what the future holds
The Kits can run across them and you have the API evolve among them so it isnt a drastic change, Loss of binary compatablity is teh only problem but once you reach the end components then you dont have to worry as much.
Running Linux The Kernel doesnt mean you ahve to run ANYTHING else like all of the daemons. I do like Runlevels. There is a program to speed up Linux booting by starting runlevels in parallel and it handles all the dependencies.
when people complain about LINUX being hard to configure, you are talking about teh system on top of it, and a BeOS system on Linux doesnt mean youll ahve teh extra garbage floating around but can make config easy ftrom teh start.
Concluding, which is more important to gaining more community (not as in trying to take over teh world but growing/being better): Taking 5 years to get every system binary compatible or getting a crippled OS release taht anyonbe can use now and with a look to teh future to improve everything (Like Linux).
SmallStepForMan: "BeInc broke binary compatibility with almost every major release."
That's not true, compatibility between releases was a huge priority at Be (Dominic insisted on it). R3/Intel apps still run under R5. And don't quote me on this, but I think either PR1 or PR2 PowerPC apps still run under R5 (it's been a long time, my memory is a bit fuzzy).
Simon: "But I think that for some in the community, the 'trip' is more important than the 'destination' in some respects, since it's all about doing it for fun."
Sure, and that's completely valid. I tried to express that the article only makes sense if you agree with the goals I set out. Writing an OS from scratch would be a fun challenge all by itself, but 99% of the time you're going to trade wide-spread acceptance. To each his own.
Adam Scheinberg: "But let's be fair to those who have spent long hours writing/porting apps to the BeOS - it's not that there are no apps, it's that there are no CURRENT apps."
My apologies if I sounded overly harsh. I have friends at Beatware who certainly spent a lot of effort to write quality apps, as did many others. As you said, these projects are all discontinued or incomplete, and that's what makes them nonviable. In addition, there was never the "tractor app" that we all hoped for in the early days, something so unique and compelling that you had to run BeOS just to use it.
Michael Vinícius de Oliveira: "I was waiting one position of some ex-Be engineers about the BeOS clones, since Aug, 16."
I need to be very clear about this - I don't speak for anybody but me. I don't know how other former Be employees feel either. I'm just writing as a user/programmer of BeOS who happened to work at Be for a while, nothing more.
MVdO: "Why several ex-Be engineers abandon the community after BeOS death?"
I assume for the same reason that so many users left also - the company was gone, and the product was a dead end (sadly). I'm sure if I wasn't using BeOS at work I would have moved on already (and I will need to move on soon anyway).
Kevin Newman: "I think Daniels best point in the article was about the license."
That's funny, I thought it was the weakest point of the article.
I'd like to clarify something though. I personally don't have a preference as to how to license this effort (so long as it isn't GPL). Any other alternative is fine by me as long as the source is available. I could live with MIT easily - I only suggested the others to offer a compromise to the BlueEyedOS folks. My opinion really doesn't matter here, the point is just to get these two groups working together.
I wish the OBOS guys all the best inspite of a week of not very helpful press. Hope they keep their heads up and make Christmas 2003 as happy as winter 2000(discovered BeOS) was for me. I'm not interested in the other 3 projects would rather see Syllable or NewOS go somewhere instead.
I didn't use BeOS because it was good but because I loved it.
I use Windows for the following reasons only.
1) Internet Explorer (Not a big fun of Netscape and webpages look better)
2) Heavily patronized P2P file sharing software
3) Playing scrabble* on Games.com (Their jsp and java applets don't work too well on Macs or Linux boxes)
4) MS Office & Visio
5) CD Burning (my ultra cheap burner doesn't work well on Linux)
6) Proprietary formats wma,asf,doc list goes on of files I will not be able to view or edit anywhere else.
* Games solely available on Windows
I only hope Linux or FreeBSD or OBOS will someday soon free this windows slave.
this is not a troll...i just think you people need to realize that BeOS truly is dead...development of it as you knew
it has long since ceased...leaving you with two options...hack away with what you have or reinvent the
wheel...but no matter how much you scream BeOS is alive because you use it...won't bring it back
when was the last time you spent time in the BeOS community?
there is a lot of activity there. and there is a lot of development going on, even large applications.
sure the company support is gone, and the original BeOS won't be developed anymore, but that doesn't keep us from using it and developing for it.
we have no fear of BeOS dying, it's just morons like you who makes us respond back that BeOS is still very much alive. It's not like we sit here screaming all day long in fear that the OS will die in our hands. Within the community it's not really anyone who cares if the OS is dead or alive.
I don't think that BeOS will ever be the mainstream OS, even in the Be days that wasn't something I was hoping for. Simply because I don't care. As long as I'm happy using it. It's just that simple.
It's the same with music, I don't care if what I'm listening to is popular or not as long as I enjoy it. Why would it matter? that's just stupid.
It doesn't matter if they manage to get a fully working BeOS clone out there. Even though I would be really happy if they did. What matters is that I enjoy using the BeOS that I have, and if the code I write now will be able to live on in future clones of BeOS, I'd be very happy.
So instead of arguing over BeOS being dead or not, try to do something useful, perhaps write an app for the OS _you_ prefer using.
And why am I arguing? Becuase I want you to stop saying "Move on BeOS is dead" in every BeOS related thread, it's really getting old.
I'd say, time to move on, cause your arguments are dead.
save yourself the trouble and move over to linuxland right away, cause it won't happend.
I'm saying this cause when I see the blind hope you have, I can only see you getting hurt in the end. Reminds me of the hope you have of getting back together with a girl after she brakes up with you.
So either stay in BeOS and wait for a clone that might come or move over to linux and wait for a clone that might come.
That's at least my recommendation.
oh and btw, it won't take 10 years to rewrite the OS. they did a lot of stuff all those years. like research, driver development, porting to other CPUs, rewriting large portions of the OS etc. It will take time, but not 10 years.
Terry Brennan: One reservation: I have made BeOS my primary desktop OS because it is fast (wow is it fast! - especially compared to Linux). If this speed (especially boot speed) is lost in the complexity of linux,
the excercise loses most of its value.
*sigh*. Why do everyone think Linux is slow. Linux is slow because most distributions load up all kind of crap servers a BeOS replacement would never need. From the default RH Null installation, I manage to cut down boot time by almost 50% by dissabling stuff I don't need.
So, yes, Linux would be responsive if done properly. There's no reason to say otherwise. In fact, probably it would be even faster than BeOS.
----
Anyway, on co-operation, I think this is impossible. Comoe, OBOS, B.E. OS and Leonardo all have different goals and different directions. What is needed is an standard API between them. That means if my app is made for OBOS R2, it would work for B.E. OS and Cosmoe and Leonardo with just a recompile.
One avenue I suggest to create a standard API between projects is BeUnited.org, where code is released under the MIT/X license so all can use the code.
Another thing is standard drivers interface, so that drivers working on OBOS can very well work on Linux-based works.
One thing I don't want to see with BeOS, is another linux clone. There are sooo many of them. I remember reading an article on this site by some user who said he didn't have a clue which one to choose as there are so many.
Besides, Linux started cos Linus ripped the kernel and everything else from elsewhere -- does that make him smart ? or does that make him lazy ?
Fantastic Article!
I would like to add one point. An operating system/platform is choosen because it allows a user to get "something" done/accomplished. An OS that does allow its users to get "something" done better than other choices, _will_ attract more users.
Some examples (yes, yes, people do choose alterantives to these)
- palm OS -- users can quickly lookup phone/addrs, calendar, make notes - it works, and works effectively
- unix -- users can run _really_ large data server applications - the datasets and memory used can be business sized
- amiga -- users could do graphic work with NTSC video (paint, titling, animation, switching)
- mac -- users have the applications for working with professional page printing, interfaces to typesetting machines, etc.
Technology is neat, and fun, and can be a great learning experience, but users are attracted by the ability to use that technology for something that they want to do.
Others have asked, well what does BeOS do? When talking about a BeOS clone/replacement people should consider what it is that people will be able to do with it. What is going to be different than what Linux, Mac, Windows, already provide? Try to be more specific than "the beos experience". If you think that the UI should "respond" they way BeOS did, great. Try to think of specific examples, and how they differ from other platforms.
Maybe it's enough that people want to experient with a VM system, or network stack, or C++ compiler. Great. However, I feel any project will need to do more than just this to live on.
Back in the day, my thought about the BeOS was wow, here is an OS that because of its framework and architecture can provide near "real time" responsiveness to do performance audio. (sigh, I still shake my head. 1.4 Billion cycles every second and windows still can't always keep a 44 kHz sample playing. Don't click that mouse cursor on a menu, it might interrupt the audio stream). There are of course other solutions, but the BeOS solved this problem better and more effectively. The BeOS was real time enough and yet it also had a full blown desktop OS software framework.
To recap, think about what it is that the "new BeOS" should be able to do that is different. What is it going to enable people to get done. If you can achieve this, users and developers will come.
It is great to have such a thoughtful article to use as a reference to this discussion. I still use BeOS, but it gets harder and, as some have suggested, is sort of sad to use because you know that, each day, it is more dated than ever. I have thought and thought about the current Be projects.
I have come to think that. although ideally it would be great if most everyone was working on the same project, perhaps it is good that there are two "main" projects - OBOS and Blue Eyed OS. My tendency is to favor OBOS. The potential of the NewOS kernel seem great to me - clean and fast. And, I agree that hardware support is actually simpler than it was at one time. In fact, before they added FireWire, Apple had nothing but USB on those original iMacs for some time and helped revolutionize its mass adoption. I see a clean line of simplicity that is possible through NewOS. Ultimately, as Simon said, the results are what matter.
But, I also think it good there a Linux kernel group working away. Perhaps at some point, it will become evident which is succeeding more, which one has things falling into place more smoothly, which one is less problematic and so on. It could be that, at some point, the projects could merge if final decisions were made. So, perhaps it's a good thing there are these two -it could be a boon in the end.
I've used BeOS since 3.0 (before Eugenia! - and she knows a hundred times more than I do :-) and I'd just about give my right arm to have a new, improved, modern BeOS. Yes, results are what matter!
I think there's no need to implement a linux kernel. What you really need are drivers, not a monolithic and complex kernel design like linux.
So why not just implement a translator for windows drivers ?
It can work like a simple compiler and I think is easier to implement than a kernel module for linux !
When people consider the Linux kernel for another BeOS I very much doubt that they're considering the Linux kernel without X and without dozens of libraries and one of those damn desktop environments. http://pliant.cx is an example of a Linux kernel taken elsewhere with healthy results.
The technical differences that exist between a Unix kernel and BeOS will become less and less in years to come. The work-arounds required to use Linux are greatly outweighed by the mature code of BSD or Linux. Take a lesson from Mozilla, folks - don't head off into the wilderness for five years. (disclaimer, I love mozilla: http://holloway.co.nz/mozilla/splash )
The annoying cliche is the 'not invented here' syndrome. Offload the kernel to someone else (hell, choose a BSD if it make you feel better). You'll get drivers and tested code and you can concentrate on the GUI, and the responsiveness, and that's what BeOS is to me. 6 months later you resync and get free bug patches and an O(1) scheduler. w00p.
For me, Linux isn't even there yet for a desktop. Word '95 wasn't ready (they hit it finally with Word '97). That's the maturity that BeOS 5 was getting to. Software takes a long time to get there and with OBOS or any BeOS clone I don't expect to be able to use it for work for 5 years.
Programmers tend to underestimate when their software will be usable for the masses.
My take is - when people aren't installing it any more on their new PCs
Sorry, ELQ, but I think by my definition its getting close.. As with O/S2 the userbase of enthusiasts will go on and keep developing apps.
I heard the dead horse is gonna get a facelift *real* soon now...
First, thanks very much Daniel Switkin for writing such an informative article. It echos almost exactly what I've been syaing in the OSNews forums for a while now :-)
Second, I'd like to respond to Michael Phipps reply, which is also quite enlighting.
I think that hardware support is far less of an issue going forward than it was for Be. Compare the state of hardware now to 5 years ago. Parallel and serial are dying
Parallel and serial ports are probably one of the easiest things to drive. As for the protocols that were used over these ethers, they were also much easier to decipher because the electrical scheme is so easy. Reverse engineering USB protocols is much more involving. But it's true, serial/parallel devices are pretty much dead (not counting my Samsung SGH-T100 GSM phone :-)
How many video chipsets are there?
Not many, but when BeOS was at its top (around 1999) there were pretty much the same amount of (wortwhile) video chipsets to support, BeOS did a pretty poor job even so.
However, the quantity of chipsets is not important, their complexity is. Today's chipset are a great deal more complex
which means the drivers also takes (much) longer to mature. The so called unified driver architectures that many chipset vendors are using (or moving to) are also not (fully) open source, because of intellectual property issues. This means that in practice you'll have to persuade the hardware manufacturer to allocate resources and port their drivers to your platform. I don't see that happen anytime soon with OBOS, sorry :/
Etc. I think that hardware wise, the new OS's are in much better shape than Be was, in a lot of ways.
I really think you are underestimating the, still, huge problem of driver support for alternative OSes. Linux is getting quite good at driver support, because many manufacturers support Linux right out of the box. And for the devices that still need drivers there is enough critical mass in the Linux community to support their creation. Again , this is not the case, and probably never will be for OBOS.
Just look at Atheos for a recent example.
We would need to make many changes to Linux to make it Be-like. Many, many.
I asked this question in an earlier forum too, but haven't got a satisfactory answer yet. The question is: define Be-like. And if there are so many changes needed, can you state, say, the five most intrusive ones? Thanks.
In fact, it has been a necessity. And I am very glad that we didn't bet the farm on 3.0 or 3.1
I'm sorry, but what farm are you referring to? :-)
IMHO betting the farm on gcc 2.95.3 right now will have some serious consequences in the future:
- What if you stumble upon a GCC bug that absolutely needs fixing in 2.95.3 before you can continue? You will be forced to delve into gcc and try to fix this yourself, diverting sparse engineering resources to something that is not even part of your goal.
- Daniel states that for true binary compatibility you will even have to take care to keep the class members in the same (memory) order. I wasn't aware of this requirement, and it makes the constraints you are bound to even stricter. He also makes a very good point that every worthwhile binary-only application on BeOS is either badly outdated already, or is being released as Open Source, negating the need for BC alltogether.
- You inherit the Fragile Base Class problem form BeOS, possibly the suckiest aspects of BeOS ever. And you are
forced to recreate this horror, from scratch nonetheless! 
A final note on BC - this is not a permanent state. It is like a car seat - it helps to keep the infant upright, not to be the last chair he ever sits in.
You have to ask yourself if you don't hinder the toddlers development in a negative way. Doing so in the early stages can have serious consequences for the rest of its life!
Licensing is a tough call
I will not touch this topic other than stating that the
GPL nature of the Linux kernel has not stopped companies from creating binary only solutions for it. Just take a look at NVIDIA's excellent 2D/3D drivers for Linux. There is a kernel component that is distributed in binary only and it has worked beautifully so far!
Just let us know, first, so you don't replicate someone else's work. ;-)
IMHO you guys are not only replicating unneeded work, you're in essence reinventing the complete kernel wheel from scratch! This is not a problem, but the lack of sufficient engineering resources means your development time will be a lot longer. By the time you are finished your work might not even matter anymore :-(
Remember, the really fun stuff happens in user space!
-fooks
Swallow it down, Daniel Switkin was not paid by the B.E.OS (BlueEyedOS) team and is not working with us.
And you know what? The only future he see about a BeOS clone is something like an opensourced B.E.OS.
I thought I wrote months ago, that when B.E.OS 1.0 will be released the source will surely be available.
Anyway, it's time to code, not to discredit technical choices that noone understand now and try to interpret.
"Hey guys, they are using Gnome!" lol, do you know that we preffer to develop with XEmacs than with vi in console mode?
I clearly understand that people are impatient and only want "screenshots".
Here is the last screenshot I did and sent on our ML.
http://blueos.free.fr/new_app_server.jpg
Yes, it's the new app_server rendering in the X11 mode, you will see nothing interesting. But you know what? It works great, it doesn't (yet) compile with gcc3.2, it's not yet finished.
Regards,
Guillaume
First of all, thank you Daniel. I had the luck of meeting you in person once, if you remember a rainy day in Santa Cruz (Hey, can I get copies of the pictures you took? 
You bring up some valid points and I mostly agree with them. Unfortunately some people writing comments here seem to react allergical to words like "Linux" or "GPL" and consider using either of them as selling your soul.
Let me speak on the GPL first: I don't like it. It's a good licence for many things, but I would prefer the LGPL almost any time. But the GPL is not as bad as people want to tell you, and most importanly it does not scare commercial developers away. Fact is that there were, are and will be commercial applications for GNU/Linux and the least problems they ran into were licencing. Corel Draw failed, but that was not the GPL's fault.
Linux. Linux is not an innovative, exciting or beautiful kernel. But it does its work and it does it good, and it's better than anything we could whip up in a year or two. Stop overrating the kernel, it's not a religion. It's just one piece of the puzzle, and if we can get that one for free - why not? It will save us a lot of trouble and deliver not only things we aren't even remotely working on right now (NTFS, USB, IEE1394, RAID, PPC support, ALSA, fork()) but is in fully tested production quality, constant updates and has support from hardware vendors. Get over it. The GPL will allow us to rename it if you don't like the name Linux... We will also be able to (Axel, forgive me) to not have to reimplement BFS but use XFS in all its glory.
Did you follow Cosmoe closely? Do you read the mailing list? Someone named Kyle reported having built a Cosmoe system on top of a Linux kernel without it being too unixish, using a renamed directory structure and the like. It is possbile to use Linux the kernel without being GNU/Linux the OS. We don't need X11, Cosmoe runs fine using DirectFB.
What makes GNU/Linux slow is not the kernel, not X11 and not any other part. It's the cruft that comes from building it all together in an ancient Unix structure. The parts for themselves are great - so why don't we pick them up, build our kernel with XFS, preempt patch and ALSA, use the Cosmoe app_server on DirectFB and start building a modern, heavily BeOS-inspired OS from there?
One last question I have seen on why all the Ex-Be engineers are so quiet: It's because you take everything they say too seriously. Really. Stop treating them like gods, start treating them like normal people. Working on a product whose followers are as enthousiastic as BeOS or Apple fans, I had to learn myself to shut up, because everything that can be misunderstood will be misunderstood and held against me.
The BeOS clones are indeed fragmented, but some people want the Linux kernel and some the NewOS. I think it would be a good idea to keep OBOS and B.E.OS from merging, but merging Cosmoe and B.E.OS would be a good idea
http://www.beunited.org/
It's about having common, open standards that all five major OSBOS projects (will) support. Choice and compatibility - you can have your cake and eat it, too...
As far as working together on coding, look at it like the BSD world: Darwin, FreeBSD, NetBSD, OpenBSD, etc.. Each project has different goals and developers with different specialties. They all benefit each other, sometimes directly, but often indirectly. So shall it be with OSBOS's.
Look, if you're so fscking in love with Linux you can contribute to it, or you can contribute to B.E OS. Why force OpenBeOS, that had the guts of going with a modern and exciting new kernel (instead of what I consider an utter piece of hodge-pdge horseshit - Linux) to switch? If you don't like it, get the fsck out. I know I would not be the least attracted to OpenBeOS if it used Linux. I have been working (not at home, at -work-!) with Linux since 1995, I know it's personality, I have had the opportunity to evaluate it for large databases, and I know full well that it's development model is rotten. If you disagree, that's fine! If you want to keep hyping Linux, that's fine, too, but leave OpenBeOS alone.
Sure OSnews is doing it's best to undermine OpenBeOS. I'd lke to see some articles about why B.E OS is on a route to failure, for example? Naaah, can't happen, this is Osnews.
The app/interface kit and the preference apps are not kernel specific. This is one area where the diferent BeOS projects can colaborate. I think someone from B.E.OS said that they will use some OBOS app kit code? Then it will be nice if they contribute some code back to the OBOS project. Or better yet - merge the app kit projects.
(Oh boy. I wish I tried out BeOS when I had the chance.)
> (Oh boy. I wish I tried out BeOS when I had the chance.)
You still have: check free Personal Edition to download from http://www.bebits.com/.
"Licensing seems to have divided the largest two projects, OpenBeOS and BlueEyedOS. I'm happy to see that both reject the GPL as an option, due to its viral qualities and the fact that it discourages commercial development and contributions."
Sorry? Viral? What's wrong with protecting your own code? If I want my code to be free (or closed or whatver), thant I have every right to protect my work.
And about commercial support and commercial support: check linux. Yes, more and more commercial drivers are written to work on GNU/Linux. I would really like GPL'ed drivers, but the fact that closed source