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