In the beginning, the BeBox was the way, so we developed applications for it. Geekport peripherals and all. I can't quite swallow the "it was never intended to be permanent" idea. Why would you make a custom device like the Geekport if the box was just a development platform?

Then we were the MediaOS. So we developed media apps. The media kit was designed and redesigned. The 3d kit was new. The BFS was designed to maximize disk throughput for streaming media. Etc.

Then our Focus Shifted and some of us animals were less equal than others. Those who wanted to work on the desktop were ... not as welcome as others. But I am not bitter.

Finally, chaos decended on our happy little realm. The King has abdicated. His ministers are scattered to the winds of fortune. The citizens look this way and that for peace and order and a return to the way that things were or, at least, should be.

In many ways, we (OpenBeOS) are like the military. The keeper of the Operating System is really the place of power in the country of Be. We aspire to that goal. As many small countries have found, however, a military does not make a very good government. It tends to be harsh and direct -- a father figure, if you will. A military needs a diplomatic and legislative counterpart. In the same way, the Be community needs a sales/marketing/planning/etc. group.

OBOS is not all things to everyone. For one reason, I am only one person. I lead the kernel team, I am the point person for any and all communications to the group, I write these editorials and newsletter articles, I monitor the openbeos mailing list, the new BeDevTalk, and the BeUnited mailing lists. Oh, yeah, and sometimes I actually have time to code, too. For me to take on oversight, if not an active hand in the other organizational issues that need to occur to replace the vacuum that Be has left behind would be *far* more than I can handle. Additionaly, there is a purity issue. OBOS is an opensource project. The politics and such of trying to be both Linus AND RedHat would mean doing neither justice.

I receive all sorts of interesting emails. One that I received in the last week was a long missive on just this issue. Another was a rumour of a new PowerPC box that may well be coming out. The third was a company that is interested in distributing OpenBeOS in certain markets, when it is complete.

I picked up a few books on Extreme Programming several months ago. There are far more useful tidbits of knowledge in there than I can explain in a short article, but one of the most simple and useful is to take what you *hate* and do it *more*. The premise to this unusual practice is that the more you perform this task, the more you choose to automate it, because you loathe to spend so much time on it. This dove-tails nicely with the old axiom that programmers are among the world's laziest people.

Having said that, my current assignment is ATAPI. That is the CD-ROM interface. For those who are interested, it is basically an implementation of the SCSI protocols over an IDE interface. I started to investigate this topic from three sides:

1) What did Be do? Since there was no documented API, I read the CDButton sample source code.

2) What does the standard say? I downloaded the MMC-3 standard and read through it.

3) What does OBOS/NewOS require for drivers?

As I started to understand the scope of the driver a bit more, I started building a set of tests. I decided that I would test Be's driver. That would give me several advantages -- chief among them that I would have a working set of regression tests that I could run against my code. I would also have practice in using the API, so I would *know* the API, because I had *used* the API.

I dove into the CDButton example and realized that user level apps were calling ioctl. For those not so initiated, this is the command to send a command that is not open, close, read, write or create. It is the "and all other stuff goes in here" command. It is also a UNIXism, and in my opinion did/does not belong in a user level API. I know that all of the UNIX folks out there are groaning. Sorry.

So I wrote a simple helper wrapper class. I call it BAudioCD. It's definition looks like this:

class BAudioCD
{
    public:
        BAudioCD (char *device);
        ~BAudioCD();
        bool Eject(void);
        bool Load(void);
        bool Close(void);
        bool Play(uint32 trackNo,uint32 endTrack=99);
        bool Pause(void);
        bool Resume(void);
        bool Stop(void);
        BCDRomPosition  GetPosition(void);
        status_t  GetMediaStatus(void);
        BList *GetTOC(BList *storage);
        bool ScanForward(void);
        bool ScanBackward(void);
        bool StopScanning(void);
        bool SetVolume(uint32 volume);
        uint32 GetVolume(void);
        uint32 getCDDBID(int []);
        uint32 getTracks(void);
        uint32 getLength(void);
};                          

This is a preliminary -- it should be cleaned up a bit more and become an "official" part of the API. However, this abstraction allowed me to write my test harness for CD-ROM access. It is included at the end of this article. The test harness is very simple. You pass in the device and one command. A BAudioCD is instantiated, that one command is called, then the BAudioCD is detroyed and the application ends. The "parser" is nothing more than a long string of

if (!strcmp(argv[2],"Pause")
    ...
else if ...

commands. Efficiency is *not* an issue here. This is easy to write and easy to expand with new commands.

With this test tool complete, we can actually write a test script that calls the test tool. The test script will invoke the test tool repeatedly, trying different commands each time. It should capture the results to a "current run" and diff those results against the "known good", allowing the tester to replace the "known good" if the results are acceptable.

I hope that this gives everyone some insight into how to design unit tests. There are certainly a good number of additional tests that could be created here. These are the "it works once, under ideal conditions" tests.

Many of you know me, in one way or another, as someone that has been 120% dedicated to BeOS for a very long time. For those of you that don't know me, I've been using BeOS as my primary OS since R4 first came out, and my sole OS since Genki (R4.5), up until recently. I've created websites about BeOS, written articles for magazines, and have been involved in countless other projects dealing with BeOS for many years. I even was honored to work with some really great people on BeOS/BeIA projects in a real life job, making real money doing it.

All good things must come to an end, some say. I disagree, in a sense. While BeOS as we know it has come to an end, and Be, Inc. has definitely played its final role, BeOS is very much still alive in the hearts of its users and in the community.

Ah, the community. The BeOS community has been revered the world over in many publications as one of the friendliest online places around. And it is. It still is. And it is this community that has all focused their efforts right here, and right now. Here we are, working together more than we ever did before. Can you imagine if everyone here had gotten together like this three years ago on something as simple as BeZilla? Where would BeOS be now? But, that's history. We are looking ahead now, towards the future.

Many have asked why is it that I have joined in the OpenBeOS project. Has BeUnited's effort failed? Is this a sign that there will be no more BeOS derived from BeOS itself? Have I given up on BeUnited?

Absolutely not. While there hasn't been any word from Palm to date, and it is increasingly likely that there we will not hear anything at all from Palm, there is still a faint bit of hope there. But instead of sitting idle and waiting, I have been hedging my bets -- the obviously smart thing to do. We all put all of our eggs in the Be, Inc. basket at one point, and now we are all scrambling for that pleasant BeOS user experience from somewhere... anywhere.

And even though BeUnited may not succeed in licensing the source code from Palm, there is still great hope. BeUnited has been and is still working on other things as well, with OpenBeOS. What many people do not understand is that BeUnited is part of OpenBeOS, and OpenBeOS is part of BeUnited. We are all one in the same. This also follows for Glass Elevator. All of these groups have been together since day one after the announcement of Be's closure, they've only split up into distinctly separate groups for organizational sense. It is not fragmentation that you are seeing, it's a collective group that is more organized than ever before. It is one effort, one by the entire community, and it will succeed, one way or another.

So here I am, and here are you. I am honored to still be joined with many others in the hopes that we will all once again run an OS that is so "fun" to use, so ahead of its time. One that we've grown to love and will never get by without. I hope you all will forgive my taking up article space this week for my little introduction. I only wanted to let you know that I am happy to assume the newsletter editor duties here at OpenBeOS, and that I am still a proud member of the BeOS community. Most importantly, I wanted to let everyone know that there is no fragmentation of efforts, and we are more organized now than many people realize.