OSNews:

Interesting

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:15:00 GMT

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.

Hmm ...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:18:00 GMT

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?

Small Addition

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:22:00 GMT

(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.)

use the Linux Kernel

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:28:00 GMT

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.

Right on brother

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:28:00 GMT

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.

Let's not be like Linux... kind of ....

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:29:00 GMT

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...

RE: Right on brother

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:31:00 GMT

> 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.

Intelligent

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:32:00 GMT

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?

Yes...but

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:34:00 GMT

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.

Thanks for the article

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:42:00 GMT

It is nice to see old x-Be people are still thinking about BeOS

=)

BeOS revival

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:43:00 GMT

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.

Hit the nail on the head

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:45:00 GMT

I agree with every single point!

excellent article

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:55:00 GMT

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.

Beos or another Unix forced on an x86 platform

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:57:00 GMT

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.

hrmm interested up to a point

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 01:58:00 GMT

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.

Nothing New...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:00:00 GMT

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.

There is and will always Be only one BeOS!

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:06:00 GMT

...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

Very Well Written

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:10:00 GMT

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. ;-)

RE: There is and will always Be only one BeOS!

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:10:00 GMT

> 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 is BeOS?

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:16:00 GMT

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 =)

How about the path of least resistance?

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:28:00 GMT

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

Good article

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:30:00 GMT

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 favor OBOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:32:00 GMT

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!

About fonts

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:37:00 GMT

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.

RE: There is and will always Be only one BeOS!

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:39:00 GMT

>>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

OpenBeOs is about something better; not taking over the computer world

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:44:00 GMT

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

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:46:00 GMT

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.

To use linux defets the point

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:48:00 GMT

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.

Re: What is BeOS?

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 02:54:00 GMT

"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.

R2

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 03:00:00 GMT

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.

Thanks Daniel

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 03:06:00 GMT

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 =)

Re: Gscott

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 03:11:00 GMT

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

more kernel chit-chat

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 03:16:00 GMT

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!

For better or for worse.

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 03:18:00 GMT

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.

More responses...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 03:19:00 GMT

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... 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.

my thoughts

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 03:34:00 GMT

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)

Please...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 03:57:00 GMT

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*

BeOS...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 04:09:00 GMT

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

To Brad

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 04:23:00 GMT

"...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

thoughts

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 04:24:00 GMT

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 :-)

What about the L4 microkernel (the one Hurd will use?

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 04:32:00 GMT

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 ...

This excellent article...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 04:39:00 GMT

"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

TO ALEX

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 04:43:00 GMT

"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

Where is JLG?

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 04:49:00 GMT

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>

A (slightly) more protective license...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 04:50:00 GMT

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.

L4 microkernel

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 04:57:00 GMT

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).

beOS Replacement Evolution

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 05:12:00 GMT

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).

Yet more replies

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 05:24:00 GMT

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.

BeOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 05:37:00 GMT

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.

re: bytes256 & Eugenia

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 05:41:00 GMT

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.

re: yc

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 05:48:00 GMT

Linux... sigh

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 05:54:00 GMT

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.

Yet Another Linux

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 05:58:00 GMT

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 ?

OS attracts users because it enables them to accomplish something they want to do.

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 06:06:00 GMT

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.

Be

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 06:08:00 GMT

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!

Linux kernal & BeOS Clone

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 06:29:00 GMT

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 !

Linux kernel

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 06:31:00 GMT

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.

When is an OS officially dead?

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 06:50:00 GMT

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

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 08:28:00 GMT

I heard the dead horse is gonna get a facelift *real* soon now...

Re: Very Well Written

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 09:03:00 GMT

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

Discredit

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 09:04:00 GMT

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

Linux, the GPL and the rest

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 09:05:00 GMT

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.

Different BeOS-clones

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 09:08:00 GMT

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

BeUnited

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 09:17:00 GMT

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.

I don't want Linux to assimilate OpenBeOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 09:36:00 GMT

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.

app kit

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 09:45:00 GMT

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.

BeOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 09:46:00 GMT

(Oh boy. I wish I tried out BeOS when I had the chance.)

Re: Eike Hein

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 10:03:00 GMT

> (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/.

GPL FUD

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 10:04:00 GMT

"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 drivers exist destroy your FUD.

C.

GPL2

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 10:17:00 GMT

"-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."

Correction:

GPL is good for people that want everything to *be* free (like in freedom).

Regards,

C.

Chances are nobody will read this, but

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 10:43:00 GMT

what made BeOS beautiful was not its kernel, it lacked a lot of features, example given: diskcache was not integrated with VM system.

Linux has all the features of a good kernel: module support (just like beos), good hardware support and a HUGE team of developers.

With the low-latency patch the Linux kernel can even keep up with BeOSon the audio side.

And please stop yelling "BeOS had a micro kernel". If you truly believe that go grab a book about operating system design and come back in 4 months.

I say Daniel is right and that Open BeOS should drop the NewOS kernel, and start using a tried and tested one.

Linux has support for an accelerated framebuffer and a fallback vesa driver. Building the BeOS servers on top of the Linux kernel is possible, and it is also a good idea. It should be possible to port OpenBFS to Linux and extend the VFS layer to support attributes,indexing and queries.

Linux has support for USB, Firewire and all the other goodies.. There is no reason to reinvent the wheel.

Perhaps the B.E.O.S people are on to something

Kind Regards
Michael Wulff Nielsen

let's just do this

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 10:57:00 GMT

let's just tell Palm that we'll never buy a Palm product ever again for the rest of our lives until they release BeOS!!!!!

Linux

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 11:17:00 GMT

There is something done with Linux. Accept it. Plus there is tons of existing Linux distributions. Use them if you have your mind set on Linux. Let the individuals (and projects) select what's best for them.

(I hate people that have to reiterate old decisions without looking up the facts. It stops progress.)

Re: Rumormonger

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 11:21:00 GMT

I have to agree. I really liked what Michael Phipps had to say:

Everyone seems to have a different expectation of OpenBeOS. Many people expect us to replace Be. They write to me about marketing, sales, QA, etc. They write to me about how we shouldn't overlook the PPC market, or how we should have used the Linux kernel or how great it is that we are not GPL. Everyone has a take on what OBOS should be. That is fine and good. I am glad that people are interested. Everyone needs to be aware, though, that no matter what we are, someone will not be happy. Some people would have us more regimented in our approach to things. Other people would not be interested if that were the case. Only when there is a clear and compelling one sided arguement for changing things should we do so.

Everyone, too, please remember that while we are putting a professional face on this, we are volunteers. Every minute of time on this is unpaid volunteer work. Our time is given freely. We work the way we are most comfortable with toward the ends that we choose. If you are not comfortable with the way that we work, you may certainly suggest changes which we will carefully consider. You may work in your own way and submit patches and changes without really being part of the group. Or you may choose to go elsewhere. We are doing the best we can, and giving it away as a gift.

Re. Chances are nobody will read this, but

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 11:26:00 GMT

I say Daniel is right and that Open BeOS should drop the NewOS kernel, and start using a tried and tested one.

I really hate this attitude. Why don't you work with B.E. OS that are using Linux, if you think it's so damn good? Is that "I like pizza, everybody must eat pizza" attitude of yours that pisses me off.

Go on and code for B.E. OS, they use Linux, they will make you happy.

Binary compatibility

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 11:33:00 GMT

>>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).

This is the reality, Be broke binary compatibility when Intel moved from PE to ELF executable format. This would be R3 -> R4... and possibly back in/before the PR days. (back when Tracker was Browser or for the old File system??)

You note that we PPC Be users don't ever mention Binary Compatibility as something Be took lightly. We have it from at least PR2, and we know it. Okay some things changed, but that was more to do with libraries rather than actually being able to start running the app, as with the shift to ELF.

I can run PR2 executables under R5 on my Mac. I do too!! The PR2 came with the Calculator App that Dano had and IconWorks - both work fine under R5.

Re: Linux kernal & BeOS Clone

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 11:33:00 GMT

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.

For the N-th time, the BeOS kernel is not a microkernel!!!

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 !

If it was that easy, don't you think it would have been done already?? Creating a windows driver loader means recreating the whole of the Windows kernel infrastructure (i.e. everything that lives in ring 0). Good luck with that! :-)

-fooks

anything but Linux

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 11:59:00 GMT

try NewOS, rewrite the kernel, steal code from Be... anything... but dont give me another Linux distro, we're flooded with them anyway. Who needs Benux?

sigh

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 12:38:00 GMT

I can't believe that things like this still get me excited; I've been living in Windows 2000 for almost a year now, and it Doesn't Suck(TM)... and I don't have to reboot just to play games, which is also a nice touch.

Building on top of a well-supported kernel is a great idea, but I have to wonder if this can be done without X... which would be the whole point, I think. X is clearly the biggest thing that makes Linux suck as a desktop OS, and there are a few projects out there (such as Berlin) working to get rid of it... but I think they all miss the "it's a desktop OS" target by a wide margin. They're just X on steroids from what I've seen.

The biggest challenge here would be to re-use the X drivers without requiring X, and allowing things that X has big problems with (direct framebuffer access and OpenGL). I have no idea if this is even possible.

If something usable and good grew out, I'd happily use it, and build things for it... it's been a long time since I did any coding. :-(

- chrish

Re: Linux kernal & BeOS Clone

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 12:45:00 GMT

"For the N-th time, the BeOS kernel is not a microkernel!!!"

haven't postume that.

"If it was that easy, don't you think it would have been done already?? Creating a windows driver loader means recreating the whole of the Windows kernel infrastructure (i.e. everything that lives in ring 0). Good luck with that! :-)"

No, you don't need to recreate the complete infrastructure of windows but a prototype library like a compiler! What I mean is a seperate program, which uses a windows driver binary as source to generate equivalent driver code like a c compiler uses sourcecode to generate programcode. By the way, that's not impossible. This strategy was often choose by emulators for older computer systems i think (like a spectrum emulator for the commodore 64 which was nothing else as such a thing). Personally I know a programmer how? implement such kind of translator to reuse drivercode for his selfmade hardware from cp/m 86 to windows 3.1.

Good article

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 12:48:00 GMT

if someone wants new BeOS as fast and as much supported as possible than probably linux is a good choice, BUT i don't understand why every linux-lover here shouts to make OpenBeOS on linux!? There is B.E.OS! Support it if You want! Geez You're acting like religious fanatics, who kill everyone believing in other things that You.

The kernels choice....

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 13:04:00 GMT

I agree with OpenBeOS decision of choose NewOS. I agree with BlueEyedOS for choice of Linux, too. Each project, have, in yourself, the same goal. Ok, OpenBeOS want be so closed in BeOS R5. BlueEyedOS WANT source-compatibility, new features and several improvements (being having until 10x more linux performance!!!!)

NewOS is very nice! I love it!
Linux too!
BeOS, too much!!!

Come on! use your minds, guys! The community only want our beloved OS running and pulsing again!

Michael Vinícius de Oliveira
BlueEyedOS Webmaster

Nice article

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 13:09:00 GMT

You bring up many strong and interesting points, but I tend to think a lot of them rather comflict with each other.

The prime example is to not use gpl yet suggest using linux.

Also the point with drivers is a valid one, except i don't believe linux will be overly usefull for this. I think the biggest advantage would be from the network drivers, but most network chipsets are quite open, and freely implemented in BSD.

The real problems will come from sound and video drivers, which are the most complicated to write by far and the most important, and where linux leaves a lot to be desired. I'm no expert but i would assume the X video drivers rely on X quite a bit, which is obviously a problem. The sound drivers also seemed a bit of a mess last time i used Linux on the desktop (admitidly a while ago).

It is also worth noting that not one linux distromaker has a fool proof plug it in and it just works way of dealing with the linux driver modules (at least none that i have seen).

I agree that in a perfect world no effort would be wasted and everyone would help each other. Unfortunatly this world dominated by corperates is about as far away from this idealism as we can get. In this ideal world no clones would even have to exist since the efforts of Be Inc wouldn't of been wasted by greed.

Since this is the case it is unrealistic (as you touch on) to expect the groups to merge. Though I would be really disapointed in the clones if they can't agree on a common API to use to allow source compatability between them, this is the bare minimum of cooperation that must be achieved between them IMHO. Some source sharing/codevelopment on some of the higher level kits would be something that could be achieved relitivly easly if liecensing and source control could be agreed on.

C:I would like to point out the irony of the 'freeness' of the GPL would limits what your allowed to do with the code compared to the MIT which has almost no conditions at all.

The thing that was special about BeOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 13:38:00 GMT

The one thread that I have picked up on that I can relate to is the thread that asks the questions about the true identity of BeOS. For me, these are the questions as to the reasons so many types of OS users have a warm and special relationship with BeOS. I believe I have an answer that requires a different question; who was the OS designed for? I think that BeOS and it's conceptual predecessor, AmigaOS, are special in that they are operating systems designed to be used by all types of users of an OS, and designed with excellence in mind instead of the more prolific mediocrity. BeOS is a wonderful end-user experience. BeOS is a great programmer experience. BeOS is a great hobbiest experience. BeOS is a great media experience. In truth, what other operating system, besides AmigaOS, had such a wide acceptance with such a diverse group with such different expectations and levels of computing proficiencies. BeOS was designed to be what AmigaOS and MacOS are for the general end-users and media users, what linux, BSD and NeXT are for programmers / power users, and what Windows is for corporate users. If that spirit of excellence, respect and co-operation (between OS developers and it's users) can be captured again, I know BeOS will live for many years to come. And all those that wish to reduce us to mere open wallets who have to beg for a small slice of the great user experience pie (IE Microsoft), beware; that which made AmigaOS and BeOS possible will not go away but instead will be back again and again until it triumphs. I have a dream

X has problems with OpenGL

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 13:50:00 GMT

Wow... Could have fooled me. Is that why I can play Q3A, UT, UT2003, RTCW, Descent 3, and a number of other OpenGL games?

Adam

Ores

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 13:57:00 GMT

> C:I would like to point out the irony of the 'freeness'
> of the GPL would limits what your allowed to do with the
> code compared to the MIT which has almost no conditions
> at all.

http://www.gnu.org/philosophy/free-sw.html

BlueEyedOS and some technical comments

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 14:06:00 GMT

First of all, thanks for your nice article, Daniel!

BlueEyedOS:
I would like very much to join with BlueEyedOS to reduce the efforts both of us are trying to achieve. And I also see no reason why they can't join OpenBeOS and still be a member of B.E.OS - i.e. we could work together on the Media Kit, Print Kit, Storage Kit, Registrar, preferences stuff, ... - both of our teams would still have their own kernel team, and they could just take the code we achieved together for their B.E.OS.
Although they would then have to stick with the Be API for the most part, they could also change things for their copy as well. AFAICT it would be a win-win situation.

And some technical aspects:
We will switch to 2.95.3, so we will have a much better and bug-free compiler than BeOS ever had - this will give us much less headaches than Be's version does. Furthermore, we could compile the whole kernel using gcc 3.

I see that using Linux as the base kernel would bring lots of drivers to the Be world. But I also think that the most interesting drivers to get are graphics cards and hardware-accelerated OpenGL - and it might be possible to have a compatibility layer for those.

And we can't drop 16 bit compatibility from the app_server; the least reason would be the VESA mode. But it's not like every colorspace would dramatically increase the code size - of course, you should optimize all often used colorspaces to be as fast as possible, but for those rarely used ones like RGB-15, we would just need a converter to/from RGB-32 - then you'll be able to convert to every supported colorspace, although it would be twice as slow (which I could live with, and which could be extended later on).

A unified BeOS clone

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 14:08:00 GMT

it will never happen. Too many people with too big of an ego. I really like BeOS but, time people, time. By the time a clone gets here, I will have moved on to something else. I am just a user, that feels abandoned. I watch each project, and I wish them the best of luck. But I have things that I need to do today, not next year or later. I agree if all these prjects had banded together we might have a BeOS clone today. Not BC, but something that might have been useful. Oh, well, the new Amiga OS 4 is looking rather nice.

RE: The thing that was special about BeOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 14:08:00 GMT

"beware; that which made AmigaOS and BeOS possible will not go away but instead will be back again and again until it triumphs."

Damn right! BeOS is *not* dead and isn't going to die. I just bought a second-hand Thinkpad so I can run Be (and to show off to customers).
I'm going to be using it for a LOOOONNNNGGGG time.

alt to Linux.. qnx

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 14:11:00 GMT

cant qnx kernel be a choice?
dont have to maintain kernel.. QSSL does that for you..

QNX Kernel

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 14:49:00 GMT

QNX kernel is commercial software, you have to pay to use it.

Anyway, its realtime, which isn't really what we are after.

Re: alt to Linux.. qnx

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 14:57:00 GMT

QNX is proprietary, so it wouldn't be open. That said, QNX is damn fast, & I'd wager a decent contender for replacement, save for a huge lack of apps at the moment.

Personally, I think Linux is a L-O-O-O-N-G way from being useful in a multimedia setting. And THAT'S what I need BeOS for.

Linux or not?

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 14:59:00 GMT

By reading everyone's comments it seems that there is a consensus that Daniel's thoughts on the BeOS future is on target (at least with everyone that has posted a comment).

I am not against using nux flavor kernel but there is several factors that make me cringe when I think of using it. Sure Linux has its issues, but if the core can be utilized and other pieces can be created to replace unwanted portions then I'm all for it. I have installed and tried to use several different versions of Linux over the years and all of them gave me the same resultI had to think way too much to get it to run.

This is why Linux has yet to break through the desktop market and become mainstream for home users. Linux does things so different than Windows, Amiga, BeOS, MacOS.
It's so different though that I really dislike using the OS.

Reasons why I dislike Linux:

1. It was the FIRST OS I had to buy a book on to understand how it works so THAT I can work
2. Was not designed to be intuitive (like Be is) in these ways:
a. GUI
b. File systems Structure (I'm talking about /etc, /root, /user, etc..)
c. Installing applications or unpacking them
3. Difficult for the non-geek to apply patches w/o the use of terminal. (is that possible?)
4. To many flavors to choose from
5. Not non-geek friendly (and seems as though it wishes to stay that way. Robust and free from form)
6. Verbose mode on bootup. (although this is nice for geeks, I guess, and sys admins I don't really care to see all that text. Give me a picture to look at. This seems to be the default mode for all nux flavors. Second, I don't see anywhere in the GUI that would allow me to easily customize the bootup and turn off the verbose mode. I'm sure there's a way thru terminal but I can't imagine where to look or where to start. Anyway, I don't know how to recompile a kernel, I don't want to recompile one.)

As an end user I want things to be simple and clean. So that I can create and feel unrestricted.

Amiga was the first OS build with the ideal in mind: color GUI, music, video, clean and FAST!!! Those concepts are still in effect today. In fact AmigaOS wins every year at a huge demo-making contest in Germany, and they went out of business in 1994!

What is the deeper issue? What keeps the spirit of BeOS alive? Our deeper issue is that we know that an OS can be done right and that we had it in the form of BeOS. And those things that made it great continue to do so while we strive to keep the flame burning.

Linux and multimedia

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 15:02:00 GMT

I think Linux is a L-O-O-O-N-G way from being useful in a multimedia setting
Wrong. Most distributions are. Linux as a kernel is suited for multimedia and realtime audio, I bet the FinalScratch people had their reasons to port from BeOS to Linux.
I also trust Daniel's opinion on that topic, he should know what a system need for multimedia applications - remember, he works at Tascam.

re: BlueEyedOS and some technical comments

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 15:10:00 GMT

I must say, I 100% agree with Axel on this comment:

I would like very much to join with BlueEyedOS to reduce the efforts both of us are trying to achieve. And I also see no reason why they can't join OpenBeOS and still be a member of B.E.OS - i.e. we could work together on the Media Kit, Print Kit, Storage Kit, Registrar, preferences stuff, ... - both of our teams would still have their own kernel team, and they could just take the code we achieved together for their B.E.OS.
Although they would then have to stick with the Be API for the most part, they could also change things for their copy as well. AFAICT it would be a win-win situation.

Some sharing of the projects would be extremely helpful. I don't think you'll ever get the projects to completely join together, but at least some cooperation. BeUnited.org is trying to bring the different players together, which is a start. Getting the different groups to agree on a common API is a VERY good thing. Now, if with that API, we could also get the groups to share some of the underlying code, that would be even BETTER.

In the meantime, I will continue to work with and develop for BeOS r5, which I've been doing for a while now :-)

-paul

Director of Deverloper Relations
BeUnited.org
http://www.beunited.org

Linux kernel is also viral, not due license, but nature and atmosphere

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 15:34:00 GMT

I wish to ask every LinBe advocate, including Daniel - do you remember Easel?

Re: Direct Link for this comment Linux kernel is also viral, not due license, but nature and atmosphere

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 15:40:00 GMT

I wish to ask every LinBe advocate, including Daniel - do you remember Easel?

Um, no. But I do remember Eazel. Their brainchild Nautilus is doing GREAT, despite their demise. I'm using Nautilus2 right now, it's part of GNOME2. Thank you GPL!!

-fooks

Linux + Multimedia?

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 15:41:00 GMT

Wait for version 2.6... there's been a lot of action in the kernel that isn't evident in the community as everybody is still in the 2.2.x / 2.4.x mold.

About linux and beos...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 15:45:00 GMT

I think the problem comes down to everyone focusing on the "goal" of (re)creating beos instead of focusing on the development process.

You can design your entire system to do the "right thing" in all aspects and still get nowhere, because it takes almost forever to implement everything you designed in. And by the time you complete the implementation of the design, competing systems (linux, windows, ...) will have surpassed yours.

See also "overdesigning", and "worse is better", and "biting off more than you can chew".

Some projects that suffer from this are Fresco (sadly, though I still think they can make it eventually), GNU Hurd, etc.

This also has an effect on mindshare: if your project continues to progress, but at glacial speeds, you will have alot of trouble attracting developers. Applications developers won't come if there's no usable system up yet, driver/system developers have to have a real reason/interest to switch to a not-yet-mature system too. If there's a promise of a kernel that's an order of magnitude better than what's out there, maybe. But I would argue that Linux is most definately not an order of magnitude worse than what's beos was, or newos will be.

By taking small steps, but making sure the system is flexible enough to be (sometimes radically) changed along the way, you can get good results quickly, and have everything you want in the long run. You just have to be unafraid of change, and then evolution can take over.

Linux does this extremely well - it evolves significantly with every major release, retains compatibility where it matters, and dumps it if they can really clean up their interfaces in doing so.

This does mean however that third-party drivers will never be guaranteed to work "forever" like with windows. The GPL helps alot with that aspect though: it's problematic to have binary-only drivers, but possible if it's really really worth it. Like in NVidia's case where a major part of the worth of Nvidia's hardware is in the excellent drivers. But for let's say network cards or sound cards, there's not that much incentive to really keep things closed. The major advantage if your driver is included in the tree is that it will usually get maintained and updated if things change in the core.

To get back to the topic: I can see why the OBOS people for instance go for something that at the moment is more clean/understandable. By starting practically from scratch they will have a much more intimate knowledge of the system. My point is that I doubt their code will be that much cleaner/better/whatever by the time they reach the feature-level of Linux. A lot of bright minds are working on Linux, and they DO have the experience.

Whoever brought up "The things that were so good about BeOS" was on to something:

- Boot times
Linux can be made to boot very quickly. I personally saw it boot in a couple of seconds. As for "prettyfying" it, Linus has said he will accept patches to clean up the boot/kernel messages, and there's patches out there that show fullscreen graphics when booting.

- Performance
There's nothing inherently slow about the Linux kernel, on the contrary, I'd say in general it performs better than most of the other kernels out there. It's moving towards a fully non-blocking and asynchronous design, has reasonably fine grained locking for SMP, is preemptable, can have very low-latency, etc.

- Fast graphics/Font issues/etc
That's a couple of layers up. X can be quite fast. But there's a whole bunch of reasons why the final result of GUI's based on X end up being slow. Nevertheless nothing stops these BeOS reimplementations from using X as a fat driver for now. It would get them accelerated 2D and 3D cheaply, and X can be stripped down a lot.
Personally I'd like something lower level than X. DirectFB is often mentioned, but from what I've seen from the code I wasn't impressed at all. I like KGI/GGI alot, but they "glacial" progress applies to them too. It's important that they do manage to support 3D though - 3D without X would be very cool in my mind. The GGI folk have recently been able to leverage the 3D DRI drivers (and also the 2D directfb drivers)

As for the Font issues: in my mind that's just a matter of standardisation/getting decent fonts/packaging it as a whole. The fact is: we have nicely antialiased fonts on Linux right now, the issues are just how to manage them. If you're thinking of even rewriting the kernel, surely you can solve this issue.

- Filesystem stuff
Extended attributes, multiple streams per file, etc have all been discussed, and will at some point be implemented for the Linux Kernel. Reiser4 already promises alot of these things. XFS is a very nice filesystem in its own right. (I think i've seen someone doing BeFS on Linux, might be wrong)
The thing that's needed is Live Queries (are these thesame as Views in Database parlance?) In any case, I think it's only a matter of time before that comes to linux, once there's enough filesystems in the tree that could make use of that, someone will find it interesting enough to design and implement it.

- General "unified" look and feel
That's the most important thing - pick and choose the components you need (MTA, UI, Apps, configuration, ...) and customize the ones you picked so they're unified.

- A nice API
I think instead of diverting all the resources in recreating the kernel, a lot more effort should be put in creating a nice API, surpassing the quality of Linux's UI APIs or Be's APIs. This is _the_ most important. Get this right and you can port your apps easily on BSD's with X, Linux with FB, or whatever kernel/combination you like.

Sorry for taking this long to explain everything. My point simply is that in general I agree with Daniel's points, that I think the kernel is a "solved problem" with linux, and that such scarce resources should be allocated where they are most needed: integration and front-end.

Death through Dissolution

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 15:47:00 GMT

Yes, Eazel.
Though, i'm sure, with linux kernel BeOS ressurection project will turn in YetAnotherWM or such.
And dissolute among others sourceforge fakes.
Even AtheOS derivatives seems more targeted to Be Different, Think Different.
I think, that in definition "What is BeOS" one of the most important part is BeOS soul and feel, which we definitely loose if join haxxorzz community, inspite backing by Big Players like IBM.

Fine Article

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 16:04:00 GMT

A fine article Daniel. I agree that uisng an extant core (such as Linux) would be an easier solution than reinventing everything. Michael Phipps and his team are walking down a really difficult path. I respect them taking the hard road though. It reminds me of an old saying, "A little adversity is good for a man. Kites rise against, not with, the wind." I wish them luck.

Dave Owen was right on target with the positives of BeOS. It was easy to install, incredibly responsive, booted fast and, if it had a driver for a particular card, it just worked. The file system was pretty much bulletproof too. Heck I even liked the UI. All in all, it was the most transparent OS I've used because I didn't have to manage it constantly.

experience

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 16:08:00 GMT

If using a linux kernel compromises the low latency, responsiveness, small footprint, and excellent multi-media performance of it then i'd say dream what others think is impossible:

Stick with OBOS and rewrite the kernel and/or keep bugging palmsource.

Cosmoe

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 16:15:00 GMT

Daniel never mentions it by name, but Cosmoe seems to follow his recommendations quite closely. As some here have noted, one of the problems with Linux on the desktop is X. For years now, the primary lure of X has been the body of applications built for it rather than the merits of X itself. Sound familiar?

Since a BeOS clone with source compatibility will start life with a pretty decent body of apps, it's free to cast off the heavy yoke of X for a new architecture.

It's easy to applaud the innovation and performance of a new kernel that is in use by only by only a handful of people. Once the number of people grows into the tens or hundreds of thousands, the immaturity of those efforts will become clearer. Except that the number will never grow to those levels, becuase the hardware support won't be there.
Not to say that projects like NewOS lack merit---I think they're absolutely essential, and I hope one day to see the new open-source BeOS ported to them when they're ready. But to get started---to get traction---an approach such as Daniel suggests and Cosmoe implements, is better.

Another temptation - yet another toolkit.Or toy.

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 16:21:00 GMT

If you use linux kernal as base, you always can substitute yet missing
app with Linux one, running under one of countless toolkits.
(someone here already wrote about "gaps" and how linux kernel help to fill it)
And i really don't see any reason for developers to write apps specifically for LinBe API. Inspite how nice it will be.

Until it goes messy and primitive and "mono-threaded".

So what is the sense to create LinBe? Just to let OpenTracker work on Linux?

Quicksand

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 16:32:00 GMT

I guess most people here would build their house on quicksand if it was faster or more convenient - just remember your house will sink after a little while.
Presumably OBOS will have a better base to expand upon because it is designed, not /grown/ like large parts of linux are (NOTE depending on who you ask linux is either a very solid design or not designed at all). If the design is decent then flaws will be much easier to locate and rectify.

Just another opinion in the never-ending thread!

Linux != Linux

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 16:38:00 GMT

A lot of folks here are confusing Linux the kernel with GNU/Linux the OS.

From a user and mostly the developer standpoint, a well-made BeOS clone based on the Linux kernel will be almost indistinguishable from BeOS R5. Using Linux as a kernel will not draw all the 1337 h4x3uRz to OBOS, it will not give us the X11 toolkit cruft, it will not turn OBOS into YAWM, it will not force you to compile kernels all the time. It will, however, take a huge pile of work off the Kernel and Network teams and let us focus on what made BeOS BeOS.

changing kernels

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 17:02:00 GMT

Excuse my lack of insight, this is an enduser speaking...
What does it take to change kernels?
I guess that the app_server, networking, media kit and, loosely as an add-on, the filesystem have ties to the kernel. Maybe other aspects as well.

Suppose, the OBOS development is progressing favourably. All, except the kernel which as a result of complexity or lack of knowledge/experience just won't reach maturity in time. Is it possible to have another look at the Linux (or BSD etc.) kernel instead or would that mean to scrap all the above mentioned modules as they tie in too deeply?
Maybe the B.E.OS guys would even be so gracious to donate their at that time thoroughly tuned Linux kernel.

I'd really love to see all the OSBOS projects work together on the kits where possible and then, putting them under their respective license, tune them according to their project's demands. If changing kernels turns out to be not an impossibly huge task, everyone can have a look and pick and choose between the offerings.

Last comment:
I keep reading about "big egos" standing in the way. IMO this is bull*. The leaders of every project have been thinking about the situation, about the goal of their project and how it is achived best. They picked their way after carefully considering the alternatives and worked many many hours toward that.
Who would demand to throw all that away and follow another way they have rationally dismissed a long time ago?

So the answer is not to merge all projects, but to work together where possible, alter common code where needed and code only what is absolutely necessary project-specific from scratch.
Hopefully beunited.org will help with that. I'd really love to sponsor a weekend conference where all the different project leaders can meet and compare notes... but alas, I don't have the money... :

Back-fire

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 17:31:00 GMT

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.

Blind hope? The more doomsayers tell me it can't/won't be done, the more determined I am to do my part to help. While I'm not an active member of any of the 4 projects to clone the OS, I'm still developing software, and doing my part to bring a future to the OS. Mabey this is what the trolls want, mabey they just want to get us fired up and 'prove them wrong' because they really want to see a new BeOS. And mabey I'm just over-analyzing things again... drat this over active imagination.

I'd be happy if a girl broke up with me. That would imply that I had been involved in some sort of relationship to begin with. And that, my friend, would be a welcome change of pace for this geek.

any one else read this

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 17:35:00 GMT

http://www.unstrung.com/document.asp?doc_id=21627

"Palm Has Visions of Sugarplums"

It mentions that Palm's CEO said they may need minority investors for the spinoff of palm os. It also cites a wall st. journal rumor that sony is one of the interested parties. Sounds familiar to the register.co.uk rumor of way back that sony would take over Be.

It is also interesting also because of Sony's vision for the next playstation and proliferation of cell (toshiba, ibm, sony chip) based devices.

now putting these tid bits together to claim that beos could be back is way out there but YC may be right. We might see beos from palmsource yet.

stew, what you wish is already accomplished

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 17:36:00 GMT

Using Linux as a kernel will not draw all the 1337 h4x3uRz to OBOS, it will not give us the X11 toolkit cruft, it will not turn OBOS into YAWM, it will not force you to compile kernels all the time. It will, however, take a huge pile of work off the Kernel and Network teams and let us focus on what made BeOS BeOS.

Why do you use the future tense? B.E. OS is already doing exactly that, they utilize the Linux kernel in theri effort towards a BeOS clone (or so they think). So get your lazy ass over to B.E. OS and contribute to that project. Just leave OpenBeOS to do its thing.

And if you were right (which you certainly believe you are), then B.E. OS will succeed and OpenBeOS will fail, and it will be the icing on your cake of satisfaction.

Re: mario

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 17:43:00 GMT

So get your lazy ass over to B.E. OS and contribute to that project.

I am an application developer, not an OS developer. Give me an alpha copy of B.E.OS so I can write software for it

Questions for Michael Phipps

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 17:46:00 GMT

I posted earl;ier about an evolving process and sicne so many mistake Linux The Kernel for GNU/Linux and are jsut prejudice d against it and X, I have questions abotu a direct approach.

HURD and Fresco (Berlin) are here now, modern, and lack what peiople hate about linux and X. They are just not far enough along for use now, but so are NewOS and your appserver. They are even further behind then HURD and Fresco.

Why use NewOS The Kernel over HURD The Kernel. ive been following OBOS very closely (checking the news page every day) and reading the IRC discussions. You talk about it beong the closest in design to the BeOS kernel. I feel HURD The Kernel takes the BeOS philosophy a bit further with translators. They are a perfect lower level counter part to the kits. The work being done on the port from Mach to L4 would help improve the speed.

Like I noted earlier, for Fresco, you can write to it in any language thanks to Corba. You would be able to accelerate it with a video card like Quartz Extreme. I think someone mentioned X drivers being used within GGI so that would mean you could write a compatible driver API with X for Fresco to get the acceleration and card support. For when those developing Fresco for an X replacement and not a BeOS clone get enough momentum, they can improve the APIs since I bet tehre could be a lot of improvement in the model.

Any comments on why not HURD or Fresco

Note: HURD does not mean having to include the load of GNU. I actually feel that if possible to not even support the Unix like file structure. Instead the APIs come in 3 varieties:
-C Based Unix Port (Virtual File system that provides Unix structure)
-C Base Native API (Native C apps, No Virtual File System)
-C++ Based Native API (For Native apps)

Sony/PalmOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 18:04:00 GMT

Sony is also the fastest growing PC maker now according to C/Net (please note, I said fastest growing, not the top dog - Dell). Sony makes the coolest Palm handhelds. Hmmm.

Re: Any one else read this

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 18:10:00 GMT

Just read the article. (Thanks
Sony makes sense as minority investor.

If you think about it, (The state current OS market, the MSFT case, PalmSoure's current product line, PalmSourse's profitability in the future, the BeOS engineers at Palm, the fact that Palm does not want to sell or license the unfinished DANO to anyone, the viability of a finished BeOS desktop and BeIA on TabletPC like devices in the future etc...) it just make sense to expect BeOS to return.

ciao
yc

ice cream

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 18:15:00 GMT

lichtgestalt: So the answer is not to merge all projects, but to work together where possible, alter common code where needed and code only what is absolutely necessary project-specific from scratch.

mario: So get your lazy ass over to B.E. OS and contribute to that project. Just leave OpenBeOS to do its thing.

And if you were right (which you certainly believe you are), then B.E. OS will succeed and OpenBeOS will fail, and it will be the icing on your cake of satisfaction.

One of the points of this discussion is that if the projects don't unite, there's a good chance that none of them *individually* will be able to get into a usable state in a reasonable amount of time.

Can B.E.OS (or whatever it's to be called) reach critical mass with the current number of devs working on the project? If not, where will new devs come from?

Here's an analogy: When you call Ben & Jerry's to complain that your Cherry Garcia didn't taste right, they make the wise assumption that it probably didn't taste right for a whole bunch of people but that you were the only one motivated enough to actually pick up the phone.

Daniel took the time to pick up the phone.

johnG - the projects won't unite

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 18:25:00 GMT

for the simple reason that the people who think Linux kernel stinks are not working on B.E. OS, as opposed to those who think that Linux kenrel is the cat's ass and so they devote their time to B.E. OS.

And if the fact that OpenBeOS utilizes a kernel they like more, NewOS, attracts more committed and enthusiastic developer and other key people to that project, then OpenBeOS wins, no matter what any smart guy has to say about Linux kernel's readiness or the fact that projects are not united. My experience is that fewer passionate people can achieve more and better results than a larger but unmotivated group. And right now, OpenBeOS is larger and more vibrant than B.E. OS. Could it be the Linux kernel pukeworthiness?

oOo look what i found...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 18:29:00 GMT

http://web.archive.org/web/20000829115512/www.eugenia.co.uk/

Re: oOo look what i found...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 18:34:00 GMT

Some of us have seen this before.
From the good old BeNews days.

ciao
yc

RE: oOo look what i found...

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 18:34:00 GMT

Yeah, what did you find? Big deal.

Testsssssssss

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 18:43:00 GMT

"I am an application developer, not an OS developer. Give me an alpha copy of B.E.OS so I can write software for it"

B.E.OS __ IS __ source compatible with BeOS.
IF you want REALLY to help us, write (under BeOS) test code and don't ask about which class you could test,
2 tests for a class from 2 different is sometimes not enough. We need :
- basic tests
- bounds tests
- stress tests
Your test must be able to diagnostic if it fails
(and explains why).

Regards,
Guillaume

Here is garapheane's thought

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 19:08:00 GMT

A very very refreshing article. Kudos to Daniel.

First of all, while we can still see new apps popping at bebits and newbies actively posting installation problems, BeOS is definitely *not* dead.

IMO OBOS should drop binary compatibility and move on to gcc 3.x . BeOS was meant to be a modern OS, so having unable to harness today's (and future) processing power simply denies the point. My suggestion of a workaround is having BeOS 5 PE on the new OpenBeOS, as some "classic environment" feature (ala MacOS X). And of course, fix the flaws/bugs in BeOS along the way.

And definitely not linux. As said by many, BeOS is about the Be in the OS. And the GPL virus issue too.

I dont think that neither OBOS nor B.E.OS would finally regain most of the BeOS user-base. Having two products that acts the same way, ppl would be tempted to choose based not on what kernel theyre running. They would look on speed, stability and hardware compatibility. I see OBOS will gain on stability, while B.E.OS on hware compatibility.

Come on guys, we need an OS here ... (an OS. Not a myriad of BeOS-like distro ala Linux). BeOS users were always seen as united and friendly. We are a family. Having two competing BeOS will just divide the community. We are sick off standard wars, that's why we stick to BeOS .

i am garapheane.

Responses to last night

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 19:40:00 GMT

stew: "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? "

Hey there! Send me a private mail...

stew: "It (Linux) 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."

Exactly.

stew: "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."

Amen.

C: "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."

Nothing is wrong with protecting your own code. In fact, I like the LGPL license a lot. What I meant by viral, and this is an intentional design point, is the fact that anything which links against GPL'ed code must be GPL'ed itself. For example, we at TEAC wanted to use cdrecord as a library in our project. But that would have required GPL'ing our entire source, which is unreasonable. As a result, we had to use something else, and the community lost out on our contributions (which we would have gladly made under LGPL).

mk: "This is the reality, Be broke binary compatibility when Intel moved from PE to ELF executable format."

Oops, you're right. I forgot about changing from Metrowerks to gcc on Intel. My mistake.

Chris Herborth: "The biggest challenge here would be to re-use the X drivers without requiring X, and allowing things that X has big problems with (direct framebuffer access and OpenGL). I have no idea if this is even possible."

I haven't researched it either, but I agree that would be the goal.

Ores: "The prime example is to not use gpl yet suggest using linux."

I was suggesting drawing a line between things linked into the kernel which you must GPL, and having a different license for the rest of your code. I'd also like to repeat that Linux is not the only possibility here - a BSD flavor could also work. The main thing is to leverage an existing code base to bring hardware support and greatly shrink the size of your task.

axeld: "I would like very much to join with BlueEyedOS to reduce the efforts both of us are trying to achieve."

I agree that a minimum both teams should share all the upper-level code. But it's still a shame to fragment the few remaining users between multiple efforts. Look how tedious it is now to provide net_server and BONE binaries of the same app. It would be ideal (although unrealistic) to have one platform for all users and developers to support.

axeld: "We will switch to 2.95.3, so we will have a much better and bug-free compiler than BeOS ever had."

That's still not a path forward though (does it even get you Pentium 3 optimizations?). At some point you'll have to break binary compatibility and switch to gcc 3, so why not do it now?

Hardware Compatibility

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 19:41:00 GMT

Great article, Daniel. Michael Phipps makes a good response. I wonder though whether he is underestimating the complexity of real world hardware compatibility. Certainly there are indeed a limited number of graphics chipsets and many devices are now USB. You might be able to get a system running with minimal hardware, but that's just the start. There's a whole world of exotic and esoteric devices any one of which would be a show stopper for a user wanting to switch who needs that device. An O/S doesn't live in isolation, it needs to talk to the world. And doubly so for a 'media' O/S.

Firewire. USB 2. Serial ATA. UltraSCSI. FibreChannel. Tape drives (Travan, DDS, 8mm, DLT). Soundcards. Audio I/O boards (MIDI, analog & digital, SPIDF, Dolby digital). Mp3 players. Mice. Graphics tablets. Printers (HP & postscript). Scanners (flatbeds, slides, business card). 3d graphics chips. Video I/O boards (composite, S-video, RGB, firewire, serial digital). PDA cradles (Palm, WinCE, EPOC). NICs (10/100/1000), ATM, 802.11[a|b|g]. Bluetooth. IrDA. CD burners, DVD players, DVD burners (+/-/R/W).

Many of these devices come in consumer, prosumer and professionsal versions. Often several competing manufacturers have different chipsets. Many manufacturers provide application software for their devices as well as windows drivers. And more are being developed all the time.

Leveraging an existing base of device drivers is crucial. Its the only hope for coming close to covering a significant subset of the devices that people need. Perhaps that means Linux kernel, perhaps BSD kernel or perhaps some sort of driver compatibility layer. Whichever approach is taken, the goal should be to free up more developer hours to work on building the best user experience, instead of sinking time into supporting hardware.

Linux, the primary reason I use BeOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 19:43:00 GMT

Though I do agree with most of the points you raise, such as dropping binary compatability and analyzing what works and what needs to be fixed in the BeOS API, I cannot agree to using the Linux kernel for the new system.

First, the Linux kernel is still monolithic, no matter which way you slice it. It was 'obsolete' from an operating system technology standpoint the day it was created. Altho a good number of people and uncounted man hours have been spent trying to overcome some of the inherent problems with a monolithic design, the Linux kernel still has a long way to go to reach the morderness of a true microkernel like Mach, QNX Nutrino, or others.

Second, your drives argument, though it makes sense, neglects one main factor. To use the majority of those drivers which users want (ie sound, video), the project would also have to use some of the worst parts of Linux, like the X server. X is another dated technology whos time has come to discarde. It is one of the technologies that BeOS was trying to do away with in order to modernize personal computing. I think using components such as this would be a huge step backwards.

RE: Responses to last night

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 19:45:00 GMT

> At some point you'll have to break binary compatibility and switch to gcc 3, so why not do it now?

EXACTLY. Gcc 3 should be used NOW. Not "when and if...".

x-server

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 19:55:00 GMT

>j-lo "the project would also have to use some of the worst parts of Linux, like the X server. X is another dated technology whos time has come to discarde

Your post has already been answered on the B.E. OS FAQ sheet. Third question from the bottom, here's a snip "...it means that BlueEyedOS will not use the XServer anymore!"

Just thought you should know.

Put up or shut up

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 20:06:00 GMT

Why do everyone put demands on OpenBeOS. They have put out a very clear and detailed roadmap for the next few months that thay will follow, no matter what you think. Still you demand this and that should be changed (even you Euginia ). If you want to influence the project join it. Be there when decisions are made, back your claims up with proof and maybe they choose your route.

Put up or shut up.

(Wonder if Linus heard the same thing back then?)

Last batch of responses

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 20:08:00 GMT

Bill Davenport: "Reasons why I dislike Linux:"

I agree with every one of these. I think many if not all could be addressed though, and frankly I wouldn't want to use the result if they couldn't.

stew: "I also trust Daniel's opinion on that topic (Linux for multimedia), he should know what a system need for multimedia applications - remember, he works at Tascam."

I have to confess that I have no done any research as to how suitable the current state of Linux is for these applications. All of our audio happens in hardware, not on the host CPU.

obi: "See also "overdesigning", and "worse is better", and "biting off more than you can chew". This also has an effect on mindshare: if your project continues to progress, but at glacial speeds, you will have alot of trouble attracting developers."

This is exactly how I would describe writing an entire OS from scratch. It's too big a task to have a good chance of succeeding, and will take far too long.

Oliver Crow: (listed about a million pieces of hardware)

Right, there's just so much stuff out there. I've spent four years compromising about what hardware I can use to run BeOS, and I'm tired of it (and I think a lot of people are). One friend of mine switched to a Mac because "everything just works". Linux doesn't have quite that level of support, and it would take work to make it automatic and user-friendly, but it's miles better than where a new project from scratch would get you.

Evolution

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 20:16:00 GMT

Hi all,

Why you don't consider of the evolution aspect?

Show me one kernel, which went through more updates than linux for last 5 years ?

The updates for 2.6 are pretty significant (For performance and standards).

What can be improoved:

The BeOS is not fully posix compliant (it's big weakness). Standard LinuxThreads packge is good enough (not perfect). NPTL will be much better. The Kernel kit for B.E.OS or any other replacement of BeOS, should be wrapped from POSIX.
When you wanna do it by reverse, it'll be necessary somehow fix the posix compatibility. And this is much more painfull then wrap BeOS system calls from POSIX.

Drivers:
all drivers should be distributed as modules, I don't see any problem why we can't realease Stable kernel for B.E.OS every half year with full set of modules. It should be good enough for standard users. Non standard users may compile linux kernel kernel and whole system as they want from sources.
(Geeks will be always geeks ) )

The Be Framework must be updated, at least I'm missing parts for distributed computing. One of the best way how to solve it, it's write NSPROXY class with all dependencies from GNUStep in C++ (More transparent solution than CORBA).

Binary compatibility. It's totaly useless !!!!!!!!
Why you wanna keep this, all system are evolving.
What you will do when you will need switch to 64bit architecture ?? (It will be here very soon.)

Martin

Re: Linux, the primary reason I use BeOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 20:39:00 GMT

First, the Linux kernel is still monolithic, no matter which way you slice it. It was 'obsolete' from an operating system technology standpoint the day it was created. Altho a good number of people and uncounted man hours have been spent trying to overcome some of the inherent problems with a monolithic design, the Linux kernel still has a long way to go to reach the morderness of a true microkernel like Mach, QNX Nutrino, or others.

That has got to be the most entertaining comment I've seen in a long time! How do did you come up with that???!! All I can do is: LOL! You and YC should team up and do some sort of stage act. It will be hillarious!

Thanks for the laughs...

-fooks

Monolithic

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 20:50:00 GMT

All this talk and discussion on monolithic has drove me nuts. So I've done some digging. Here are the results.

These quotes are taken from an article from www.openna.com about the differences between monolithic and modular kernels.

This article starts buy stating " to explain a little bit what a Monolithic kernel is and why we recommend you install your Linux Kernel as a Monolithic kernel, instead of the common Modularized Linux Kernel that comes with many Linux distributions.

"Modularized Kernels allow small pieces of compiled code, which reside under the /lib/modules/2.4.x-x/kernel directory to be inserted into or removed from the running kernel and a Monolithic Kernel contains the drivers/features into its compiled code."

So Modular is "dynamic" code and monolithic is static code.

Read for yourself:
http://www.openna.com/community/articles/general/monolithic-kernel-...

�Re: Linux, the primary reason I use BeOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 20:53:00 GMT

You are comparing apples to oranges here. First of all, QNX's kernel is designed for the embedded space, something Linux (and BeOS) weren't. QNX doesn't make a great desktop OS for exactly this reason (tho I like QNX). As for Mach, it is unsutiable as a kernel by itself. It really deals with just very low level stuff. That's why it needs more on top (ala Darwin).

Linux does not require an X Server for it's GUI. BEOS doesn't use one, neither does Cosmoe.

Still, as I've said many times before, BSD would be a better kernel anyway (especially from a commercial point of view).

FYI

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 20:54:00 GMT

FYI, Martin Handl is a B.E.OS member working on the kernel_kernel and is testing it with Gcc3.2 and NPTL.
Results look promising.
Because a BeOS-like is a huge task,on B.E.OS, we choosed to choose what people called the "easy way", in order to not be stuck in front of a kernel crash. To make OpenTracker work, we (OpenBeOS, B.E.OS, ...) need a rock stable low layer (kernel, drivers, app_server...), it takes time.
We are far from an ISO you could boot but I'm convinced that it will appear. Seeing the activity in this 'thread', we could think about binary release of our working binaries.

Regards,
Guillaume

Re: Linux, the primary reason I use BeOS

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 21:31:00 GMT

That has got to be the most entertaining comment I've seen in a long time! How do did you come up with that???!! All I can do is: LOL! You and YC should team up and do some sort of stage act. It will be hillarious!

Thanks for the laughs

And that was really fscking constructive

Bah

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 21:33:00 GMT

Here's an interesting idea: Why not let the obos team work the way they want.
I constantly notice pressure for them to switch over to linux and drop newOs, but havent noticed the same for BlueEyedOs to drop the linux kernel and switch to say... bsd, i almost feel that linux zealots want obos to either fail or switch to their camp.

and PS: the beos kernel is a microkernel.

Linux kernel wants to be like Be's

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 21:37:00 GMT

The Linux kernel is a big mess right now. On the 2.5
task list is a reorganization of the drivers tree;
it's been in the planning stages for over 6 months. Basically, the Linux folks have finally seen the light and realize that modularity is a good thing.
IMHO, Linux 2.5 is the first real efforts at revision of their vision. But, I'll believe it when I see it. And if Linux pulls it off, it still won't be as simple and modular as Be's kernel. That's why I believe in the OBOS approach of using NewOS as a base.

But, IMHO, the real problem with Linux is that
the developers have a complete disconnect between
kernel space and user space. Linux kernel folks seem to think that user-land issues are not their problem.
For example, Audio on Linux is OSS or Alsa at the kernel level, and Arts, ESD, etc. at the user-level. Then their are millions of half finished media players which need to have plugins to support several kernel level and user level drivers. None of the systems works well.

What happens when B.E.OS gets a working BeOS API tacked onto Linux. It's highly likely that the
kernel will need to be patched. I highly doubt that
Linus Torvalds will roll their patches into the main tree. So, basically, the B.E. OS kernel will be a fork. Forks need to be maintained. The Linux kernel is not easy to maintain. Do you see where I'm going?

Anyhow, the BeOS system was not like GNU/Linux. The key to BeOS is that it was a coherent system where the kernel was kept light and clean and provided the necessary interfaces to a single API (OK, Posix API too.) Running the BeOS API on Linux just opens a pandora's box of options and kernel problems. Sure, Linux latency might sometimes be better than BeOS. Sure, Linux has a fancy new threading model. The question at the end of the day is "Can the whole works provide a good user experience a la BeOS?". I think that RedHat 8.0 Beta, Cosmoe, and B.E.O.S. prove how difficult it is.

Think about it this way. Linux may have better latency, but how does it apply to XMMS for example. The Linux scheduler is written with server tasks in mind. Also, the whole priority scheme is a mess. To get real-time priorities, which are needed for low-latency akin to BeOS, one must use esoteric Posix
calls. It's really a kludge. BeOS has a simple 0-120 priority scale that works great!

And what about Posix compliance? While BeOS
had Posix compliance, its design prevented complete compliance (at least easily, as not all was done). That is a good thing. A lot of Posix standards are based on 20+ year old technology. The BeOS' IPC and messaging schemes are much more advanced than Posix's IPC and Signals mechanisms. Although I am not a kernel programer (I wish that I could contribute better to OBOS), at least with OBOS,
kernel development doesn't seem like esoteric rocket science. It's better to have a clean slate and tack on the extra needed stuff like signals and Curses for cross platform compatibility. (This is the beauty of having a highly modular, almost micro,
kernel.)

Just my two cents. Keep the faith OBOS developers!

Anonymous

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 21:45:00 GMT

We would prefer to write or listen to somebody. But since nobody can claim what they wrote then nobody wrote it. I can't see the wind but I can see the effects of the wind.

Take owenership of your words or they will be lost in the wind.

B.E.OS & BSD kernel

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 22:01:00 GMT

Why Linux kernel ??

1 year ago we had good discussion in ML, I suggest to try BSD kernel. There are no bariers, at the end to use a BSD kernel.

It has only two low level condition, and i'm pushhing is as much i can. "all system calls must be a POSIX compatible".

Our kernel server server has not full POSIX compatibility,
because there is no real POSIX implementation of MSG QUEUES for LINUX, I really hope that this problem will solved with NPTL with good performance.

Problem 2: App server must be written on something standard.
Honestly there is only one standard now.(X-Window).
For linux we can also use FB, but from some sorces
it's still slow.

With X & Posix basic B.E.OS can run everywhere.
Later when we will have another capatibility for 2d rendering , we can use FB or something else , something what will be good enough, it will cost just rewrite parts of the APP server. (propably not, when we'll be able smartly put some standard 2d rendering library(Poscript,PDF) depend on X drivers (it's big chalenge))

But it's future.
For now we deside that linux kernel is good (enough drivers & support). And I guess it will be good enogh for long time.

Nobody pushing OBOS Team to change their kernel.
You can try, but i guees the will ingnore you.
It's their choice from beginnig.

But All rendering stuff & App server(partly) can be shared.
As i now we are using same code writenn by Frans Van Nispen.

And for whole comunity: it should be very good to merge all energy to write Be Framework & App server first. (This can be usable for all BeOS clones) and then continue on separare ways with kernel. And time will show who had true.

Martin

POSIX & Maitenance

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 22:15:00 GMT

POSIX can be 20+ years old but it's STANDRAD a lot of peoples using it.

More people than me can say, that not full compliance of POSIX was big fault of Be.

I wrapped a Be kernel API to POSIX , and it was PAIN, becasue documentation is not good enough. And in many ways is not keepeng POSIX (different behavior). Be kernel API is not world class API. And it's not just my thought.

There is one good thing on Be API (TEAMS).

There will be no patches to 2.6 kernel.
Kernel Server is separate thin layer, which is used just for translating BeOS system calls to POSIX. That's all. No big maitenance.

Martin

Re: Bah

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 22:19:00 GMT

and PS: the beos kernel is a microkernel.

It might have been a microkernel once, but it sucked so bad (like most microkernels) they had to resort to moving the whole networking stack inside the kernel, just to get decent TCP/IP performance! And yes, BeOS networking really sucked in the pre-BONE days. To summarize: a kernel which includes a complete networking stack is not a microkernel by my definition!

-fooks

ever say never.

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 22:25:00 GMT

I'm really wondering what is happening with existing original BeOS source code.
As insiders permanently throw out sentences like "It will never happen because it happens never" about opensourcing of any part if BeOS code, i'm going in little paranoia about it.
There are 2.5 possible reasons (in addition of existence third-party licensed code)
1) YC's expectations have some ground about PalmBe.
(personally i don't believe in it)
2) Code is polluted with copyright violations. GPL or sem other stealed code. Sad suspect, but i tend to believe in it more and more
3)2.5. Fearless leaders just wish that world forget about BeOS. Like it wasn't at all. In bussiness world (in difference from engineering world) it is bad bad bad track record for JLG, Sacoman and others VIP's. So they dream about real final BeOS funerals.

gcc 2.95.3

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 22:26:00 GMT

Daniel wrote: "That's still not a path forward though (does it even get you Pentium 3 optimizations?). At some point you'll have to break binary compatibility and switch to gcc 3, so why not do it now?"

Because we won't drop binary compatibility. When we switch to gcc 3, we will still have the possibility to run the old applications - we'll keep the gcc 2.95 libraries around (if you wish to do it).

I would keep b/c if it were just to not to have to install another OS - I want to update to OpenBeOS ;-)

2 Fooks

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 23:04:00 GMT

It might have been a microkernel once, but it sucked so bad (like most microkernels) they had to resort to moving the whole networking stack inside the kernel, just to get decent TCP/IP performance! And yes, BeOS networking really sucked in the pre-BONE days. To summarize: a kernel which includes a complete networking stack is not a microkernel by my definition!

That's really [!censored!], by your definition linux isn't a monolithic kernel either because the graphic sever (X) is outside the kernel!

2 Fooks part II

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 23:11:00 GMT

By the way, BeOs was able to handle several videos streams in realtime (and this actually created a "niche" for BeOS in the market), can Linux????? does the linux kernel have multimedia streaming capabilities???? And what about the multithreading diferences between the two kernels???

Reply to Michael Phipps

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 23:12:00 GMT

MP: 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.

I have to disagree. Consider the Epson line of printers, for example. In recent memory, they have had at least two formulations of four color inks, two of six color dye-based inks, one six color pigment-based set, and one seven color pigment-based set. For each of these six sets of ink, they have a unique color table for each of the Epson papers (full gloss, pearl, matte, plain, etc.). They may even have different color mappings based on dpi or droplet size. That's one reason why Epson printers have such great output. There is no generic USB driver that could possibly account for all this, not to mention borderless printing, roll printing with automatic cutters, and so on.

MP: How many video chipsets are there? You can count them on one hand (by family, not permutation).

Ok, let's say you don't count anyone outside NVidia, ATI, and Matrox. Sure, that narrows it down. But consider what a full-featured driver requires today. Back in the day, you only had to worry about 2D support. On BeOS, that meant four colorspaces (8, 15, 16, 32 bit), accelerated rectangles and screen-to-screen blitting, and maybe overlays if you're lucky. Let me estimate that for one knowledgable person, working full time, with documentation, this is a three month task for production-quality code. That's if the docs are complete and correct, and you have a variety of hardware to test with. (Leo, Trey, or RJS: feel free to correct me here)

Now think about what a modern graphics card can do. It needs a full OpenGL driver (forgetting Direct3D of course) with support for everything from vertex shaders to hardware transform and lighting. It probably has DVD-playback assist in one form or another. Most support dual head, S-Video output, etc. I'm not a video card driver writer, so I can't speak authoritatively on this point, but my gut tells me the task is now far, far greater than it used to be.

MP: 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'll defer to your expertise, as I haven't investigated this. Clearly it's hard, but not impossible.

MP: 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.

I don't doubt the talent and energy of the people on the various teams out there. However, I think that doing it from scratch is so much slower that the end result is just too far away. And it sacrifices any chance of getting support from hardware companies themselves, which is a huge loss. And it puts you in a situation where every command line app you might want has to be ported, rather than recompiled, which means maintaining your changes in the future. It's the difference between being a niche OS (which is fine if that's the goal) and piggybacking on the success and acceptance of a mainstream product.

MP: If we are binary compatible to the BeBook's specs, we should support nearly everything out there.

Maybe, but I'm not convinced. Try running "objdump --syms" on some Be Inc. apps (or even Postmaster), and grep for "_k". That's the standard prefix for undocumented kernel calls, which would be a can of worms to support. Plus the Be Book has many omissions, and doesn't document the edge cases.

MP: 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.

Sure, it works for getting things up and running now. But how can you hand your developers a compiler in 2003 which dates back to 1999? As Eugenia and others have mentioned, why not just jump now if you'll have to eventually?

MP: 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

I can only imagine, and I don't envy you having to choose and defend your position. As I said in a previous post, I personally would work under almost any license. My major concern was trying to find a middle ground with the BlueEyedOS folks.

Again I should repeat that these are only my opinions, and that I'm not choosing sides among the various efforts. If the philosophical differences are too great, then separate projects it is. But I think having multiple incompatible BeOS clones considerably weakens the appeal of the final product. I don't think users want to worry about which flavor or distribution to choose (as in the Linux and BSD cases), whether or not a binary or package is available in their format, etc.

Commenting on the direction

donotreply@osnews.com (Anonymous) — Tue, 24 Sep 2002 23:37:00 GMT

Thank you Daniel for your comments. It takes a lot of thinking and continuous reviewing to navigate a difficult course. This is not a once and done discussion as I see it.

Defining the attractive characteristics of BeOS is important. We don't want to create a stranger.

Using any kernel is fine with me as long as it supports or improves the essential characteristics of the BeOS expenience. My general feeling is that the Linux kernel is a bit off the mark but I am not speaking with much factual support. I find that one of the things I mention frequently is the fast boot time so it is important to me I guess.

Binary compatibility could be important. Losing those hundreds of apps even if smallish ones is a loss. Many will not be replaced or it will take a long time. I think the plan to keep BC is sound but it may not be realistic. I really can't make a call there.

It seems like this will probably boil down to 2 efforts and that may be ok. One would surely be better but that is unlikely based on human nature.

What I would wonder about would be getting Palm to help out along the road. Maybe just the app server could be begged away from them as long as we are doing our own kernel work. There may be possibilities down the road.

Thanks again for the throughtful comments and I hope you can continue your involvement going forward.

My two cents...

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 00:06:00 GMT

What I loved about BeOS was:
a) It seemed to combine the MacOS with Unix. It had a decent user interface and a terminal for running shell scripts and GNU tools.
b) The responive feel of the UI
c) The file system and queries
d) The kits for developers to create great software, they weren't perfect, but that comes with time.
e) Fast boot times

What I didn't like about BeOS:
a) Hardware support
b) Hardware accelerated 3D
c) Lack of applications
d) Complete POSIX compliance

The main competitor for a new BeOS that I see is MacOS X. It has:
a) Hardware support, not hard when you control the platform
b) Accelerated OpenGL
c) Applications, not as many as Windows, but enough for the end user
d) POSIX compliance
e) It looks good
f) Coacoa is supposed to really nice to develop for

What it lacks:
a) Responsive user interface
b) Correct me if I'm wrong, but it doesn't have the journaling file system or queries

Rebuilding BeOS with Linux kernel advantages:
a) Hardware support
b) Development community
c) Name recognition
d) Less time to market
e) More stablilty

Disadvantages of Linux kernel:
a) Possibility of being thought of as just another distribution
b) Maintaining a fork of the main tree

Advantages of not using Linux kernel:
a) More BeOS like kernel
b) Not affiliated with misconceptions about the Linux kernel or the just plain hatred some people have for linux
c) Possible binary compatibility

Disadvantages of not using Linux kernel:
a) Longer time to market
b) Less mature product
c) Little hardware support

This is by no means a complete list but it gets the general point across.

Considering all of the above points, here is my opinion:

1) Use the linux kernel with the new O(1) scheduler and pre-emptive patches as the base.
2) Install the hooks needed for BFS and restructure the file system layout to more human readable i.e.: /Applications, /System, /Users, etc.
3) Rebuild all the BeOS servers to run on top of the linux kernel.

Basically build a new operating system. MacOS X uses Mach and FreeBSD for it's kernel, but it is a lot different then the different BSD distributions. That because it is it's own OS. I think that you could do the same with BeOS and Linux.

Just my two cents.

dead? not dead?

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 00:11:00 GMT

Hey folks, what's this constant whinig about whether BeOS is dead or not? Does it matter at all? What if it's dead, and it has to be resurrected? What if it's just sleeping, and it has to be woken up? What if it's fully alive, just it's stuck at its current state, and needs help to go on? Does it matter how you call the situation, and does it influence how you or me will behave from now on, regarding BeOS?

Holy smoke!

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 00:48:00 GMT

Looks like this article may break the OS news comments record. Proof that BeOS still rules!

ciao
yc

How's this for A Starting Point

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 00:57:00 GMT

Since it's now clear that everyone's not going to go for the common good and accept compermise maybe we could at least agree on a common api based on the BeOS api and the BeBook. This wouldn't do anything for binaries but at least developers could write code to cross compile.

Maybe it could be sorta a media version of POSIX...a standard interface that multiple OSes could aim for.

Is this really asking too much?

Douglas Lockamy

OK .........

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 02:02:00 GMT

what i see here is that some people want a be-like os... wiht a 3d accelrated pdf based "quartz like" thingie ... all on a linux kernel..

well then.. why doesnt someon take initiative and start a project ...

instead of wasting ur time arguing.. do soemthing about it .. time to take initiative i say!

Re: Xtreme

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 02:32:00 GMT

Because there already is, as far as I understand it, such a project? B.E.OS.

using Linux kernel for drivers ?

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 04:39:00 GMT

I think this would be wrong approach.
What drivers are important to start with :
PCI bus, IDE, keyboard, mice, framebuffer - they are already in NewOS (framebuffer may be not complete yet) kernel.
Those huge and complex video drivers that Daniel is talking about are not in the linux kernel. They are in the X server and the best of them are distributed as binary only.
Audio drivers? They were not part of kernel as of 2.2 and only some of them made to 2.4.
Network drivers - that's very important but ethernet chipsets are not as complex as video ones.
PCMCIA - it's the whole separate package, it was modified from Linux version in original BeOS and so it can be ported the same way to OBOS.
What's left ? SCSI (standard - no need Linux to port), USB, Firewire, printer? Some obscure hardware ?
The ultimate goal is to have hardware manufacturers to write drivers for your system. For this you need a good development platform and nice readable API. devfs that BeOS and NewOS have is much easier to work with than ever changing Linux kernel.

RE: Holy smoke!

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 05:18:00 GMT

> Looks like this article may break the OS news comments record.

Very unlikely.
The records are:
1. 300 comments
2. 281 comments
3. 266 comments

re: using Linux kernel for drivers ?

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 05:58:00 GMT

> I think this would be wrong approach.
> What drivers are important to start with :
> PCI bus, IDE, keyboard, mice, framebuffer

This must be part of the kernel , how else you wanna type ??
Except frame buffer these are in kernel form version 1.0

> - they are already in NewOS (framebuffer may be not complete yet) kernel.
Exactly as in Linux.

> Those huge and complex video drivers that Daniel is talking about are not in the linux kernel.
> They are in the X server and the best of them are distributed as binary only.
But they are in now.
Linux Advantage

> Audio drivers? They were not part of kernel as of 2.2 and only some of them made to 2.4.
> everything is in ALSA and it's part of kernel 2.5 (not stable yet , but it'll come).
Linux Advantage

> PCMCIA - it's the whole separate package, it was modified from Linux
> version in original BeOS and so it can be ported the same way to OBOS.
Linux Advantage

> What's left ? SCSI (standard - no need Linux to port), USB, Firewire, printer? Some obscure hardware ?
I guess it's also important.

>The ultimate goal is to have hardware manufacturers to write drivers for your system.
>For this you need a good development platform and nice readable API.
>devfs that BeOS and NewOS have is much easier to work with than ever changing Linux kernel.
---------------------------------------------------------------------- -------------------------

Please don't get me wrong.

But real question is.
What we need first ??.

It's stable Be Framework (2d Window GUI). All of us need it !!!
Then lets talk about low level features. It can be implemented by many ways.
On many kernels.

But for App developer we must provide one perfect thing :
"Hi level Object oriented framework 100% compatible wih BeOS".
Later extended for new stuff.

This framework can be developed on BeOS PE,Linux,BSD or whatever.

None of BeOS clones has this job done.
And from my perpective this is bigest fault.
Because with 2d GUI we could easily got a lot of developers.
And things will go much easier.

A really don't wanna change anybody's mind about Mach, OBOS, Linux kernel,
because as I wrote. At the end APP server + 2GUI should be easily
ported to any platform.

My IDEA was write APP server over Display PDF or DisplayPoscript library.
And this lib is only ONE (i'm saying again only ONE) thing which must be ported to
other platform. Then we can easily share APP server & Frans Controls.

My goal: 2D must be much much faster than any available Desktop.

That is for 2D.

For 3D nobody want use anything else than OpenGL.
Or Anybody aimed for DirectX ???? Really big Challenge :o)

OpenGL code is Standard and how it'll be implemented is on particular clone.
The same with AUDIO.

B.O.OS choosed reuse this stuff from Linux.
OBOS must implement all of them.
But Everybody has a choice.
And no one should ignore shared goals.

I hope that this is ground point now.
And competent persons (project managers) start do some actions
(At least intensive communications). What we can have done together.

Martin

RE: Holy smoke!

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 06:12:00 GMT

>>Very unlikely.
>>The records are:
>>1. 300 comments
>>2. 281 comments
>>3. 266 comments

Hmmm, well, what about the top 5 or the top 10?

ciao
yc

Printers, video drivers, DRI

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 06:37:00 GMT

Consider the Epson line of printers, for example. In recent memory, they have had at least two formulations of four color inks, two of six color dye-based inks, one six color pigment-based set, and one seven color pigment-based set.
Most new color ink-jet printers can connect to a digital camera and print pictures from it. This is possible because the pictures are transfered in sRGB color and translated to the wahtever inks the printer uses internaly.

As for the video drivers - the DRI interface is not tied to the X Windows system. The current implementation is tied to X, but accordingly to DRI FAQ it is posible with some effort to separate the two. The DRI can be used directly by the inbterface kit (ala Windows Longhorn and OSX Jaguar) and this will also give you accelerated 3D. Then it will be a no-brainer to port DRI Linux drivers to OBOS. The only exception are the NVidia drivers which do not use DRI. It might be possible to port the NVidia kernel module and object files from linux - this was recently done with BSD.

Re: 2 Fooks

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 06:51:00 GMT

That's really [!censored!], by your definition linux isn't a monolithic kernel either because the graphic sever (X) is outside the kernel!

You're contradicting yourself! Read the above sentence again, and you'll see that it makes no sense at all. By my definition a microkernel should do only very basic things like memory management and message passing. That's where the "micro" comes from. Networking and graphics are already not considered basic. They are considered essential though, but they do not belong in a microkernel. Putting them there defeats the whole perceived advantage of having a microkernel! It also demonstrates the inherent weakness of microkernel design, namely that message passing becomes awkward and slow very fast.

BeOS was moving towards the monolithic + dynamic extensions (sort of like Linux + modules). BONE, the new networking stack was put inside the kernel. This allowed BeOS to reach network speeds that were considered normal on Linux and BSD. Read that last sentence again. Yes, the sacred microkernel design proved to be horrible in the real world! The "Big Mess" that Andrew Tanenbaum used to describe Linux has proved to be the most pragmatic one in real life. AST believes (believed? I should ask him that monolithic designs have very poor structure and are thus pretty much unmanagable. Linux has proven him wrong! And indeed, the biggest cluster at the VU (where AST lectures) is running: Linux! :-)

-fooks

Re: 2 Fooks part II

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 07:11:00 GMT

By the way, BeOs was able to handle several videos streams in realtime (and this actually created a "niche" for BeOS in the market), can Linux?????

Linux handles multiple simultaneous video streams just fine!
I could start about 30 of those silly BeOS demo movies before my old Athlon box started slowing down (UP system)
Linux also does multiple simultaneous mp3 files just fine! (That other famous benchmark). It even does them in reverse with AlsaPlayer. It is also not crippleware and comes with full source code.

does the linux kernel have multimedia streaming capabilities????

What do you mean by this? I don't think there is such a thing as "multimedia streaming capabalities" inside the BeOS kernel.

And what about the multithreading diferences between the two kernels???

I ported multithreaded applications from BeOS to Linux with little modifications. And in all cases performance even increased on Linux, because the underlying infrastructure (networking, VM/Cache) are much better in Linux. That was 3 years ago. I think the latest Linux absolutely smokes BeOS when it comes to multithreading. Read the NPTL thread? If I remember BeOS could only manage about 4.096 threads systemwide (much less per Team!). Ah yes, now I remember, it was dependant on the amount of RAM you had. We all know BeOS choked at anything above 1GB RAM! In contrast, Linux can do more than 100.000 threads today! There is really no comparison to be made since the BeOS kernel is dead, while the Linux kernel is evolving rapidly.

-fooks

So, there is not such a great need for Linux, after all

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 07:13:00 GMT

Oh yes, I know "Linux 2.5 will have..., Linux 2.6 will certainly be able to..., NPTL will be much better..., this patch, that patch will make Linux really fly...". Sure, sure. Very convincing. Yeah. So, we are to expect that Linux will be, maybeh, a good enough kernel, developed in a haphazard, berzerk way where every moron can stick their shit into it (even Linus Torvalds calls his Linux kernel developer colleagues morons, so I am just quoting Linus), a kernel that has huge problems with large I/O and storage -today-, a kernel that is developed without CVS!? (yep, that's why you can't simply use your browser to navigate the source tree.. cuz there ain't any source tree that can be navigated. Download the whole tarball, unpack it and puke)

In addtion, reading the last 2 posts by two B.E. OS developers makes me wonder in how good of a state B.E. OS really is. Comments like "Nobody pushing OBOS Team to change their kernel." are utterly silly to say the least.
I would not, furthermore, feel that a B.E. OS developer should brag about having "PCI bus, IDE, keyboard, mice, (and no) framebuffer" support, coz' that's really expected from Linux.

Anyway, the driver argument seems to be losing it's edge, and the Linux kernel has still to catch up with NewOS on other fronts. Sure, sure, there are all thoselow latency, high octane, super-duper patches that will certainly make it into Linux by 2005. Or 2006. Either way, I think the B.E. OS people should just leave the OpenBeOS people alone because I don't see them being very helpful. In fact, nobody mentioned that OpenBeOS sourcecode is freely available, so the B.E. OS people can, if they want to, use it freely (collaboration?), but the B.E. OS source is not avaiable at all (no collaboration?). I think this is at least a little bit noteworthy.

I really wanted to respect B.E. OS, I realy wanted to say "let's al get along" and I thought that this would be possible, but the stubborn insistence of the B.E. OS members in this thread is starting to change my miind, and I find myself wishing that they simply fail, as a matter of principle. Of course, an opensource project can never really fail.

Re: Fooks

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 07:44:00 GMT

> By my definition a microkernel should do only very basic
> things like memory management and message passing.
> That's where the "micro" comes from. Networking and
> graphics are already not considered basic. They are
> considered essential though, but they do not belong in
> a microkernel. Putting them there defeats the whole
> perceived advantage of having a microkernel!

Agreed.

> BeOS was moving towards the monolithic + dynamic extensions
> (sort of like Linux + modules). BONE, the new networking
> stack was put inside the kernel.

No.
BONE, and BTW OpenBeOS new network stack follow same design,
is made of one driver (/dev/net/api) and many kernelland modules
(add-ons/kernel/network/*), on-demand loaded by the driver
or the other kernelland modules.

The BeOS "static" kernel don't even know what's a network stack,
a socket, a protocol... nothing.
With the exception of file descriptors select() support, which
is mostly use on socket-kind file descriptors...

> This allowed BeOS to reach network speeds that were
> considered normal on Linux and BSD.

No, it's a far better design, using less inter-processes messaging, less userland kernelland switches and a great iovec-like net data packets handling which increased performance.

Don't confuse putting into KERNELLAND (address space)
and putting into KERNEL. That's not the same.
With monolithic kernels, it's often the same however.
With modular ones, it's not.
With dynamicly modular ones, it's even... well, dynamicly better.

And BeOS kernel is the later.
As will be OBOS kernel. It's already implemented for the kernelland modules support part, but still lack fully dynamic drivers support...)

However, I don't consider BeOS kernel as micro-kernel. Nor did former Be kernel engineers, IIRC.

> The "Big Mess" that Andrew Tanenbaum used to describe Linux
> has proved to be the most pragmatic one in real life.

I'll have said "proved to be pragmatic one".
"Most" implies there no other better way of doing.
As there's always, as History/Evolution tell us.
It just take time... so many time!

> Linux has proven him wrong! And indeed,
> the biggest cluster at the VU (where AST lectures) is
> running: Linux! :-)

That's hardly a point, as I guess the biggest or oldest cluster in the World could be still running on very old OS technologies, but who knows?

-Philippe, OBOS Network team leader.

BeOS kernel vs Linux kernel

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 07:48:00 GMT

fooks wrote:
> There is really no comparison to be made since the BeOS
> kernel is dead, while the Linux kernel is evolving rapidly.

Agreed.
So, why do make/reply to such comparaison yourself?

-Philippe

fail

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 07:49:00 GMT

I wrote everything in good mind.
And it's useless respond to unconstructive posts like Mario wrote.

I can easy proof that Linux Kernel outperformed BeOS kernel in Threading & Memory Manegment. On same hardware.

And anybody can do it. Just try Raise 200 threads with simple memory alocations aka 50 KB, and join them. That should by enough as proof.

Martin

Re: fail

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 08:21:00 GMT

And it's useless respond to unconstructive posts like Mario wrote.

Agreed :-)

-fooks

Re: BeOS kernel vs Linux kernel

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 08:27:00 GMT

So, why do make/reply to such comparaison yourself?

The original author asked comparative questions. I simply answered.

-fooks

Device drivers ought not to be a reason

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 08:30:00 GMT

greetings,

while the reasoning is fine i would like to point out that with OSKit ( http://www.cs.utah.edu/flux/oskit/ ) available it is possible to use Linux device drivers without using Linux.

bengt

Re: Fooks

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 08:51:00 GMT

No, it's a far better design, using less inter-processes messaging, less userland kernelland switches and a great iovec-like net data packets handling which increased performance.

This was assumed yes

Don't confuse putting into KERNELLAND (address space)
and putting into KERNEL. That's not the same.
With monolithic kernels, it's often the same however.
With modular ones, it's not.

See, for me it is the same. When you move something into kernelland (read kernel address space) you create the same structure as in monolithic kernels. True microkernels don't allow this. You can still do message passing between kernel tasks, but that I would consider that syntactic sugar. But ok, we agree that BeOS cannot be considered a (true) microkernel.

I'll have said "proved to be pragmatic one".
"Most" implies there no other better way of doing.

With "most" I mean "most of the two" monolithic or micro.

That's hardly a point, as I guess the biggest or oldest cluster in the World could be still running on very old OS technologies, but who knows?

The point I was trying to make was that AST tried to shoot down, dismiss, Linux 10 years earlier, but today he himself uses it, indirectly. That's kind of ironic no?

http://www.cs.vu.nl/das2/das2-machine.html

-fooks

Application support

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 10:27:00 GMT

If anyone's still reading this thread after 164 msgs...

I've only seen the 'Personal' edition that came on the cover of a CD and booting from a floppy ain't possible now my floppy drive is stuffed...

Anyway, good luck to all the projects. A few points to consider on the "it's the apps stupid" type taunts in an effort to break critics out of the 'hobby OS' mindset. (Assuming any of you give a damn about 'critical acceptance'!!)

(a) The projects mightn't agree on infrastructure due to design philosophies, licensing etc but I think that having source compatibility through a common API/libraries is a must. You might have 4 separate projects, but the ability to port end apps seamlessly should be high on the priorities.

(b) To facilitate this, try to agree on a software delivery mechanism. I think I spied something in the BeOS version I played with. Perhaps portage from gentoo or similar?? At least then apps can be easily maintained between the projects. I've heard it said that the BSD folks (Net/Free/Open) would all have much rather had a common ports tree and let the differences in the 3 be only the plumbing.

(c) Provide support for common toolkits. If not X11 in a window then maybe beg someone to port the Gtk, Qt toolkits.
I think some of these are being ported to non X11 systems such as Quartz (OSX). Otherwise, even having a Windows free machine, the dual boot thing will probably continue for many.

(d) Java. Don't be put off by its detractors. Once a JVM is ported, many additional apps become evident. And if B*OS ever wants a server presence, Java is a key player...

(e) XUL (Mozilla). Possibly leading nowhere, but hear me out. At least you'll have a reasonable browser. Performance of the early versions of XUL reminded me of pre-Hotspot Java (barely bearable). But XUL apps are slowly appearing in a trickle.

(f) Toolkit vs OS/kernel separation. If the "let's base it on Linux kernel" faction makes progress, what's to stop it being available as a module for other unices? i.e. how portable to *BSD could it be supposing a file system was portable?

Re: Device drivers ought not to be a reason (Bengt)

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 10:42:00 GMT

I used to think that the OSkit could be the solution. I even suggested it on the benews forums in late 2000, because the OSkit website claimed it'd be easy to integrate in a existing OS.

But since then I've downloaded the sources once (around march this year) and read some more documentation and I found they didn't support the complete range of drivers (not even close). I'm sure eventually it could be very usefull for beginning OS's, but, for the time being, it isn't the Holy Grail it promises to be(come).

Various thoughts ...

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 11:48:00 GMT

Fellows,

after reading Daniel's excellent comments, I would like to add a few myself. But first let me give you some background information about me. I used to work for Be as well, first in Paris as DTS engineer, later on in Menlo Park as PM. Nowadays I work as PM for a large European PC OEM, which some of you might remember from involvements in BeOS in 1999.

First I would like to congratulate all those who have been involved in the OpenBeOS or other projects with the goal of recreating BeOS. Approximately a year ago, when I first read about these efforts I didn't believe that anybody would get to where they are today! This is really quite an achievemment, considering the discipline and knowledge required. After all it's boring to just recreate as opposed to creating somethingg new and original ...

Just out of pure interest, how other people are doing, who basically started the same effort for AMIGA OS, you might want to take a look at http://www.aros.org and see how far they have come. Judge for yourself. This might give a hint about OBOS future.

I do aggree with Daniel's comments on binary compatibility. I also would prefer thinking ahead instead of recreating R5 from scratch. By the time the R1 hits the street a lot of things will be outdated and in order to survive and stay attractive a little bit more than a dated OS is required, however since the decision is done, I don't like the idea to argue this over again ... but there are quite some chunks of work in R1 which will probably never be used extensively, since a redesign or rewrite will follow in the long run anyway. The media kit comes to my mind ...

Regarding BeIDE, yes I also liked it, but there are a lot of better IDEs around nowadays. If OBOS wants to succeed, thhis is the place where effort should be put. In order to atttract enough developers a good toolchain and a good IDE is needed. Unfortunately this is something, which seems to be missing from everybodys list of to do items. Yes, I know it's really a huge effort, but the benefits are really worth the work. After all, one of the reasons why BeOS failed is the lack of applications (commercial quality applications) ... think about it!

Finally I would like to add, that I'm really scared by Sony! Not because they are the fastest growing PC builder (I didn't even bother to verify this claim), but because of their strategy and the assests at hand ... market leader in consumer electronics, owner of a huge amount of content, willingness to loose big money in order to reach targets ...

But YES, I woould love to see a PS2 port ...

Cheers,
Marcus "rossi" Jacob

IDE

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 13:12:00 GMT

An IDE is a [seasoned Beers cringe :] "third party opportunity". Best candidate would be Codeliege, here: http://www.codeliege.com/index.php

this is total trolling on a big scale

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 13:48:00 GMT

first lets clarify some things.
B.E.OS is a good proof of concept and theyre goal is to implement the beos api (amongst other things) on top of the linux kernel.
I do not see a problem with it.

as for OBOS im all with it.
Its a nice project, a good idea wich goes beyond just compatability with beos r5.

And aside from all the crap these guys have to take here they are doing a good job .

And THEY ARE DOING it for FREE!

and where is Yellowtab in all of this .
Well YT is beta releasing their distro it will also be a great boost for the community and for people who want to try something good fast and different.

I'd like to know what most of the people posting total FUD here are doing. since if they arent helping out why are you complaining.
Sure the tasks that the different teams are facing is no small task . but they are doing it and you .. well you seem to complain.

what am i doing.. what i can ..
im a crypto analyst not a coder...
and I have to second that wich one person said about linus torvalds.

and fooks..

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 13:50:00 GMT

the beos demo video thing, was done on a dual 266 p-pro ...

at running i can on my box have 8 divx movies running at the same time .. without crapping out on a single p3 433 with 392 mb ram.. the movies.. ? 600mb giove or take a few megs..

about FUD

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 14:30:00 GMT

Won't editorialise here, have better to do (like coding, hey you all, just stop buzzing and start coding, on whichever project, but just CODE instead of lamenting yourself).

The linux patch that says runs about 100000 threads I don't think the kernel was running all 100000 at once...
IIRC it had launched and destroyed 100000 threads _in_ the 2 seconds, with _only_ 50 threads running concurently each time.
A whole lot different than launching 100000 threads at once :^)

So stop FUD-ing please.

About the 4096 threads limit in BeOS, well this is _not_ fixed in the kernel, since the max-threads number varies with the amount of RAM, so I guess one could have a boot parameter (though I didn't find any).

Ok, I stop here, as I've lots of code to do and many other things, so buzz if you want, but I'll work.

BeOS threads

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 14:48:00 GMT

not concurrent, as each thread is destroyed before launching another, but still not bad, on my "poor" K6-2 350

#include
#include

int32 mythreadfunc(void *arg)
{
return B_OK;
}

int main(int argc, char **argv)
{
thread_id id;
int count;
status_t st;
if (argc < 2) {
printf("usage: %s nthreadsn", argv[0]);
return 1;
}
count = atoi(argv[1]);
printf ("launching %d threads...n", count);
for (; count; count--) {
id = spawn_thread(mythreadfunc, "a thread", B_LOW_PRIORITY, NULL);
if (id > B_OK) {
resume_thread(id);
kill_thread(id);
wait_for_thread(id, &st);
} else {
printf ("failed to launch a thread: 0x%08lx (left %d)n", id, count);
// return 2;
}
}
}

[revol@patrick /boot/home/devel]$ time ./testthreads 2000
launching 2000 threads...

real 0m1.154s
user 0m0.040s
sys 0m0.641s

All or Nothing?

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 15:11:00 GMT

So the only alternatives for BeOS are to run on all the PC hardware out there, or else be reduced to "hobby OS" status?

No. I disagree, not with Daniel's logic, but with his premise. I see this "all or nothing" thinking as the biggest single problem in the Be community. IMO, we are not destined to be a mass marketing juggernaut . . . and neither are we relegated to the "hobbyist OS" scrap heap.

IMO we are shooting at a moving target . . . as mass marketing is "melting down" all around us (not my original thought) . . . and new integrated motherboards invite us to "point and laugh" at much of the current hardware BeOS never supported. Well, thank goodness for that:-)

Linux? First, thanks to you Linux for the many ways we benefit from open source. Linux as marketing example? No thanks . . . you missed your window . . . and it was an outdated "mass marketing" window anyway . . . now you are being propped up by a some large always-late-to-the-party corporations . . . which gives you some staying power . . . that's about it. Linux as kernel? BeOS right now supports the hardware I need . . . far more than is widely perceived . . . so the driver argument is pretty much bogus for me.

When you get really really old like me you realize often the truth is found in the middle, by people who keep plugging away. Very seldom is the actual outcome one of the "all or nothing" alternatives we romanticize about.

I find BeOS right now runs on a very exciting subset of new x86 hardware . . . and certainly I will migrate to OBOS as it continues to develop.

YC . . . why should I trust PalmSource based on their behavior so far? First they suffocate their hostage . . . now they try to collect a second ransom.

Data-streaming

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 18:34:00 GMT

What do you mean by this? I don't think there is such a thing as "multimedia streaming capabalities" inside the BeOS kernel.

Sorry (damn typos), it was data-streaming capabilities (BStream class in BeOS), although i just noticed that there are other OSes with this (XP):
http://www.extremetech.com/article2/0,3973,12576,00.asp
(at the bottom of the article)

Re: All or Nothing?

donotreply@osnews.com (Anonymous) — Wed, 25 Sep 2002 22:38:00 GMT

I find BeOS right now runs on a very exciting subset of new x86 hardware . . . and certainly I will migrate to OBOS as it
continues to develop.

There's hardware that it runs on, then there's hardware that you plug into it to extend its uses. I think you're forgetting the latter. It's when you start to consider the latter that things begin to look bleak.

Get a life

donotreply@osnews.com (Anonymous) — Thu, 26 Sep 2002 04:44:00 GMT

Why waste your time? Put your skills to use building something people will actually pay for and use. Unless, of course, developing successors to BeOS is your hobby. In that case, more power to you.

Do linux people just not get it at all?

donotreply@osnews.com (Anonymous) — Thu, 26 Sep 2002 08:04:00 GMT

Gnome KDE X all absolutly 100% satisfaction not guaranteed illigal in 43 states, no refund, dead man walking on the green mile SUCK!

the native BeOS GUI is far superior, it makes sense it comes with a nice Posix terminal you boot into it really fast, there is no debate what to use, your apps work nicely. there is no stupid login when you boot up, Remember folks BeOS was built as the Multimedia OS
its primary design, light efficient way to play and design multimedia. The BeBox was designed around this, and it still does a good job even today,

bleah

donotreply@osnews.com (Anonymous) — Thu, 26 Sep 2002 12:27:00 GMT

this idea is shit

Re: All or Nothing?

donotreply@osnews.com (Anonymous) — Thu, 26 Sep 2002 14:03:00 GMT

>>YC . . . why should I trust PalmSource based on their
>>behavior so far? First they suffocate their hostage . . .
>>now they try to collect a second ransom.

Ask yourself one question.
Would it Be a good idea (profitable) for PalmSource to have a finished BeOS in the market at this time?

Consider the market situation.
The MSFT antitrust case etc...
The fact that PalmSource is still part of Palm Inc.
What the core business of Palm Inc. is...

yc

Contributions $

donotreply@osnews.com (Anonymous) — Thu, 26 Sep 2002 14:10:00 GMT

There have been some comments about establishing a non profit corp status in the US. This is nice for contributions but not a requirement if I understand thinks.

I am wondering if there is a method to mail in contributions to either OBEOS or BEUNITED in the US.

PayPal will not work for everyone and I have not been able to find an address for contributions.

There may be a good reason for this but if I am just missing an address please post it.

*** Ben

Remember the past, but live in the future.

donotreply@osnews.com (Anonymous) — Thu, 26 Sep 2002 17:10:00 GMT

BeOS is dead. I love the little operating system. It's an amazing OS, but we need to move on. I agree that when an actual alpha is realized it will be outdated. We should take the best parts of Be and apply them to another operating system like freeBSD. Plus freeBSD has the advantage of not having to mess with the GNU.

Re: Remember the past, but live in the future.

donotreply@osnews.com (Anonymous) — Thu, 26 Sep 2002 21:51:00 GMT

> BeOS is dead.

[revol@patrick /boot/home/devel]$ date
Thu Sep 26 23:52:02 CEST 2002
[revol@patrick /boot/home/devel]$ uptime
BeOS System was booted 14 hours, 24 minutes, 43 seconds ago.

looks to me it's still breathing :^)

btw... FreeBSD has a gnu/ folder AFAIK.
and GNU is not a mess, again stop the FUD please.

re: Remember the past...

donotreply@osnews.com (Anonymous) — Fri, 27 Sep 2002 18:51:00 GMT

Of course BeOS is dead, and we *are* moving on: OpenBeOS, Blue Eyed OS, Cosmoe, Leonardo...
It just so happens that BeOS and BeOS PE are still necessary and useful links to the future that many of us desire.

Working together is the solution

donotreply@osnews.com (Anonymous) — Fri, 27 Sep 2002 21:56:00 GMT

I wished we could win more ex-Be-employes to help us working on a new OS.

Re: Working together is the solution

donotreply@osnews.com (Anonymous) — Sat, 28 Sep 2002 04:55:00 GMT

And the NDA?

OSNews:

Interesting

Hmm ...

Small Addition

use the Linux Kernel

Right on brother

Let's not be like Linux... kind of ....

RE: Right on brother

Intelligent

Yes...but

Thanks for the article

BeOS revival

Hit the nail on the head

excellent article

Beos or another Unix forced on an x86 platform

hrmm interested up to a point

Nothing New...

There is and will always Be only one BeOS!

Very Well Written

RE: There is and will always Be only one BeOS!

What is BeOS?

How about the path of least resistance?

Good article

i favor OBOS

About fonts

RE: There is and will always Be only one BeOS!

OpenBeOs is about something better; not taking over the computer world

Thank you

To use linux defets the point

Re: What is BeOS?

R2

Thanks Daniel

Re: Gscott

more kernel chit-chat

For better or for worse.

More responses...

my thoughts

Please...

BeOS...

To Brad

thoughts

What about the L4 microkernel (the one Hurd will use?

This excellent article...

TO ALEX

Where is JLG?

A (slightly) more protective license...

L4 microkernel

beOS Replacement Evolution

Yet more replies

BeOS

re: bytes256 & Eugenia

re: yc

Linux... *sigh*

Yet Another Linux

OS attracts users because it enables them to accomplish something they want to do.

Be

Linux kernal & BeOS Clone

Linux kernel

When is an OS officially dead?

I heard

Re: Very Well Written

Discredit

Linux, the GPL and the rest

Different BeOS-clones

BeUnited

I don't want Linux to assimilate OpenBeOS

app kit

BeOS

Re: Eike Hein

GPL FUD

GPL2

Chances are nobody will read this, but

let's just do this

Linux

Re: Rumormonger

Re. Chances are nobody will read this, but

Binary compatibility

Re: Linux kernal & BeOS Clone

anything but Linux

*sigh*

Linux... sigh

sigh