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.
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.
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).
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 firstname.lastname@example.org.