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.
- "Part I"
- "Part II"
