On my way home last night I passed under highway 280 on Alpine Road. It wasn't a momentous or meaningful occasion—I drive that way home almost every night—but you see there is a pothole under the bridge that looks a little like Clarus the dogcow (aka "Moof"). Passing over it and marveling at the randomness of the universe that would causes a pothole in the shape of a famous Page Setup dialog box icon to be created is just one of the little things that I'll miss about working at Be. He's been there for a while now, and with the erosion of the road surface he's put on a little weight.

I can't say why that sticks in my mind today, but this afternoon as I drove back from Mountain View, where I registered a domain name for my new venture, I was reminded of the feelings I had 18 years ago moving out of my mother's home in Green Bay, Wisconsin, to make my future in California. As I drove my '69 Red VW Van, "Fritz," down Highway 1, I was overcome with mixed feelings. When I looked in the rear view mirror I felt remorse and loss and felt an urge to drive back and throw out the anchor in Green Bay, but the future was there in the windshield. Up there I had a wide-screen view of a starkly new world. Warm air caressed my arms through the open windows, assailing my nose with sea, dirt, and flowers. The roar of the Pacific called to me, "Hey! where have you been all your life?"

With every corner I felt a flush of life, newness, and anticipation. I had this cassette tape that my friend John had made for me. When I passed Big Sur I plugged it into the player, having saved it for just that moment. The Grateful Dead's Estimated Prophet ^[1] came pouring forth. I never felt more alive. I was home.

Be is leaving the hardware business, and I am leaving Be, and how do I feel? I feel good. I feel good because it's the right thing for Be to do. You as developers should feel good about it too, because it means that Be is determined to make decisions that will benefit the long-term viability of the BeOS, and your BeOS applications. Be has proven that it's willing to stop doing something when it stops making sense. As someone personally affected by this decision, I think it is my place to say that this is a remarkably rare virtue these days. I'm very proud of the work I've done for Be and consider it to be the best work I've ever done, but now my job here is done. The BeBox™ gave the BeOS a safe nursery at a time when other platforms were far more hostile to yet another (unproven) OS. The BeBox proved to be a pedestal on which to display the capabilities of the OS. Those of you who've been frightened ^[2] by my demos will remember that I've always stressed that the software is the most important thing, and that the hardware was only there to run the software. Now the BeOS has found its way to the Power Mac, and thousands of new developers can see what the shouting is all about. (Hint: It's the OS, stupid.)

I like to make up metaphors, as Jean Louis will attest, and this one comes to mind today. On a warm summer night in 1969, I stood in my yard in northern Minnesota and looked at the moon. There was no traffic that night, and every house in view was darkened, but lit from within by the bluish glow of televisions tuned to Tranquillity base. A few days earlier a Saturn rocket had lifted from the Kennedy space center, a noisy necessity to putting man on the moon. The booster did its job and placed the rest of the ship in low earth orbit. Then its job was done, and the attention of the world turned to the moon. I like to think that the BeBox is in some way related to that thunderous booster. Its job of lifting both Be and the BeOS safely into orbit is complete, but the focus must now be on the OS and applications. While it might be romantic for a little company to be in the computer hardware business (let's stretch this metaphor till it creaks), think of the odds of success for our hero, Mr. Armstrong, should he have elected to bring that booster along with him to the Sea of Tranquillity.

For those of you wondering what I might be up to next, I'm now dreaming the Silicon Valley dream and will be putting together my first start up. I'd always planned to start my own company one day when Be was successful, but now with Be leaving the hardware business, I guess today is a good day to start a new business.

I'm not prepared to go public with my product plans, but my new venture is called "Video Storage Systems," so you may safely guess it involves video hardware, and yes it will work with the BeBox. I haven't gotten confirmation on my new domain name yet so I won't reveal it, but those of you interested can watch for an announcement on my personal home page full of Ranma 1/2 Fan fictions: http://www.best.com/~jpalmer

First, an introduction. Consider for a moment the expressive simplicity of a file. A wide number of things in this world, both conceptual and physical, can be expressed in terms of open, close, read, write, and seek. And, of course, ioctl fills in any metaphor imperfections. Eek! Maybe I'd better get outside, but not until I explore this further.

Device drivers are particularly well suited for a file metaphor. All hardware devices need to be opened and closed. Reading, writing, and seeking are optional but useful when the metaphor fits. In fact, you can see that the BeOS has been tending in this direction for years. In DR8 and previously, to open serial port 2, you:

int fd = open( "/dev/serial2", O_RDWR );

This will be fully realized in DR9. /dev/serial2 will no longer be a pseudo-pathname. Finally the /dev directory will be a complete and upstanding member of the DR9 file system. You'll be able to use POSIX calls, the BeOS file system API, and even shell commands to manipulate devices. For instance, to list all installed serial ports:

$ ls -l /dev/serial
  crwxrwxrwx  1 elvis  0  0,  0  Jan 30 16:33  Modem Port
  crwxrwxrwx  1 elvis  0  0,  0  Jan 30 16:33  Printer Port

Even though these aren't files, their charade is very convincing. There are only two differences to notice here. In the first column, where 'd' normally indicates a directory and '-' a file, 'c' indicates a character device and 'b' indicates block. Also, these files appear to be zero bytes in size. Were you to open one, however, you would find that reading and writing would work as expected and seeking would be ignored.

As an example, say it's nighttime, and for now you want your modem to operate silently. If your modem or terminal program didn't come with this feature (most don't), have no fear. Using the shell to send the modem the appropriate AT command is as simple as:

$ cd /dev/serial
$ echo "AT &M0" > "Modem Port"

To save typing and memorization, this would fit nicely into an alias or shell script. Flexible, simple, standard. I love it.

Another great DR9 benefit is that graphics drivers will move back into the kernel, rejoining their driver siblings. This allows graphics drivers to service and synch to VBLs, perform DMA, respond to drawing-completed interrupts, and do just about anything else that would be expected of any self- respecting driver. This, of course, means that the boot process will be quite different.

When the kernel is starting up, it asks each driver in the /system/drivers directory to install itself. The driver will interrogate the system, installing one entry per hardware device found into the /dev directory. All graphics drivers will ask to be installed into /dev/graphics, serial drivers into /dev/serial, and so on.

For example, assume a particularly well-equipped system has a TwinTurbo 128 and two Xclaim VR cards installed. The IMS driver will find its card and create its "TwinTurbo 128" /dev/graphics device. The ATI driver will find the two Xclaim VR cards and install a unique entry for each. All other graphics drivers in /system/drivers (S3, Cirrus, and so on) won't find appropriate hardware and therefore won't install anything into /dev. This would be the result:

$ ls -l /dev/graphics
  crwxrwxrwx  1 elvis  0  0,  0  Jan 30 16:33  TwinTurbo 128
  crwxrwxrwx  1 elvis  0  0,  0  Jan 30 16:33  Xclaim VR (Slot A1)
  crwxrwxrwx  1 elvis  0  0,  0  Jan 30 16:33  Xclaim VR (Slot B4)

Later in the boot process, the Application Server starts up and opens and uses the graphics devices found in /dev/graphics. It will not, however, coddle them as it has in the past. The driver will now (as appropriate) have to enable its device's PCI spaces, initialize its hardware, and even map its own memory spaces. Don't worry, we'll tell you how.

Notice that nowhere in this process has a PCI-centric assumption been made. Feel like getting that dusty ISA VGA card working? Remember those early PowerBook SCSI displays? The possibilities are wide open.

All interaction with a graphics driver will be through ioctl. Read and write will do nothing. In addition to the standard Get/SetRaster, Get/SetIndexedColor and Get/SetGamma requests, we'll include Get/SetPowerState for VESA power management and GetSense for Apple Cable Sense. VESA's DDC (Display Data Channel) won't make it into DR9, but we'll leave room for it.

An important distinction: The kernel driver only sets up the frame buffer; it doesn't draw. Drawing using hardware acceleration is finicky, difficult, and subject to very different requirements than kernel graphics drivers. Therefore, another piece of code will be called upon to draw. The final acceleration architecture won't be in place when DR9 ships, so we'll have to continue to put up with the copious synching performed by DR8 for now. But don't worry, we won't have to put up with it for long.

We'll include a compatibility driver that will support all loyal DR8 drivers, easing DR9 adoption. Don't hesitate to start using that Millenium or Trio64V+ card; its driver will continue to work.

Is it any wonder I'm excited?

My daughter has had this one comfort since birth. It's a multicolored segmented snake. Its name is Annie. My daughter likes to hold onto it because of the neat colors, and some of the segments make a crinkly sounds or have bells in them.

We like her to experience new things, though. So we've introduced her to new toys which don't have the same features as Annie. Usually she's a bit reluctant at the start, but then she really warms up to it and has a good time. One of her current favorites is this four-wheel car thing that she can ride around the house with the help of some people power... Put your feet up... Wheee. By embracing the car, she's found that she can go more places and have more fun than she could with Annie alone. Annie still serves her purpose but has been relegated to night duty in her crib.

And so... This week, as promised, we have new serial support for the Power Mac version of the BeOS. When the MacTech CD went out, we didn't have support for PPP because we didn't quite get the serial driver working by the time the CD needed to be pressed. Since then, many users have lamented the fact that they couldn't connect to the Internet from their new BeOS Power Mac. Well, now we remedy the situation. The caveats:

Truly supported PPP won't really be available until DR9. That's to say, we're anxious to hear how things are going for you, but our main work is concentrating on DR9, so if there's an obscure problem, it may not be fixed until DR9.

PPP has been tested with a few modems on a few Macs, but we haven't done extensive testing with all configurations. Here you can possibly help us. When you have a configuration that works, let us know.

You must have a thick skin and patience to use a developer's release, and this software is offered in the same spirit.

ftp://ftp.be.com/pub/dr8_update/macserial.tgz

Before joining Be I did a lot of BeOS software that ended up at my own Web site and never at the Be ftp site. One of the pieces that I did was called the esoteric library. This was a library of things that are useful for programming in C++. I want to use these thingies in some of our tutorials, so I'm bringing them into the fold.

ftp://ftp.be.com/pub/Samples/bebits.tgz

Take a look. Utilities, sorting algorithms, container classes, that sort of thing. Of course the standard C++ library will cover some of it, but not all of it.

Geoff Woodcock is at it again. Geoff has a wild hair to do networking stuff, and he wanted to create a tutorial that was fun and showed off networking. So he's come up with this multi-user drawing thingy that allows you to do drawing over the net. The tutorial will not be available until next week some time, but I thought I'd mention it anyway. We'll be working on three or four more DR8-specific tutorials before we move on to preparing for DR9.

And how do we get to DR9? Well, last week I sort of hinted at wanting get apps up and running before DR9 actually ships out the door. What I'm thinking is that we want to have a porting lab. That is, an opportunity for developers to come to Be a little before DR9 ships to port their wares. I think we can benefit from having apps ported before DR9 shows up, so we don't have to send out a disk with only our demos available. We want to highlight the work of our third-party developers and give them early exposure, and I see this as an excellent opportunity.

So if you think you would want to participate in such an event, please send me e-mail (wadams@be.com). It promises to be an exciting time, and no doubt you'll have a lot of fun being the first on the block. No dates or other details have been set yet, but we want to know whether it's worth pursuing. Of course space will be extremely limited, so only think about coming if you absolutely want to get early exposure.

As DR9 approaches, we'll see some of our developers turn toward seriously commercializing their products. One thing that the Be platform has offered is extremely high exposure for the smaller developer. But there's one thing missing. Small developers want to code. Some of them want to run companies and become big developers. For those who don't want to make the big time, but want to be rewarded for their efforts, shareware is often an option. Others will want to go with a more traditional publishing route, with advertising and the like.

One of the things that Be Developer Services can do is help developers bring their products to fruition. That is, helping with suggestions on commercialization, helping put developers in contact with publishers, and helping put together partners that make sense.

So you can look forward to our getting more into your business if that's what you desire. Our mission isn't only to help you program but to make sure that the fruits of your labors bring you commercial success.

Be runs six e-mail mailing lists. You can learn about the nuts and bolts of what they are, how to subscribe and unsubscribe, and other information on the Be Web site:

http://www.be.com/aboutbe/mailinglists.html

The recent publicity surrounding Be in the wake of Macworld Expo at the beginning of the year has lead to a significant increase in the number of people subscribed to our various mailing lists. With this increase in subscribers, we've started receiving a larger number of questions about the lists that aren't necessarily covered by the Web page.

I'm the guy who gets to answer all those questions.

So I'd like to tell you a bit about the lists, some recent history, why certain things happen, and what's going to change in the coming month or two.

First of all, the server itself is a PowerMac 7100/80 running ListSTAR 1.1, from Star*Nine/QuarterDeck. Under normal circumstances, this combination is more than capable of handling the dozens to hundreds of messages that go out to several hundred subscribers every day.

Over the holidays and through Macworld, the server developed some disk and preferences problems and was crashing on a very regular basis, resulting in delayed mail to list subscribers. This was, to say the least, very irritating, but a complete rebuild of the server three weeks ago has greatly improved stability.

Also during Macworld, Be sent four press releases to the BeInfo list from a machine in our booth on the show floor. Some quirk in the show network apparently resulted in each of the messages being sent multiple times. It wasn't the list server's fault, it actually received the messages multiple times and faithfully sent them on.

More recently, and probably due to the bombardment that happened during Macworld, people have been noticing and commenting that they receive more than one copy of the Be Newsletter each week. These comments generally come to Valerie Peyre, the Newsletter's editor, and it was she that dragooned, er, suggested I write an article explaining the phenomenon.

When a person receives multiple copies of the Be Newsletter, it's generally for a simple reason: They're subscribed to more than one Be mailing list, and each list was sent a copy of the Newsletter. The person receives one copy from each list (I receive four copies of the Newsletter each week!).

You can see that this is happening by examining the "To:" field of each message. The four lists to which the Newsletter is sent each week should have unique "To:" field entries:

Of course, a reasonable person might suggest that there's no reason to receive multiple copies of the Newsletter, even if subscribed to multiple lists. Indeed, I agree! Later this month I will test and implement a separate, hidden list just for sending out the Be Newsletter.

Once this solution is working you should receive one copy of the Be Newsletter—no more, no less. Then hopefully people won't feel as though Be is mail bombing them. At least, not until this fall's Macworld Expo in Boston.

Let me start with an apology. When we stated we'd provide software support for BeBoxes for at least 12 months, we got our just desserts, a swift e-mail lashing. We saw the errors of our ways and will provide software support for at least 3 years. I apologize for the frustration we created, and I am grateful for the feedback and for the opportunity to quickly correct the situation.

Now, why do we exit the hardware business? When we started Be, multiprocessing didn't exist on desktop PCs, only on servers. Once you've paid for the entire infrastructure of a personal computer, we thought, the cost of one or a small number of processors is but a modest addition to the whole bill of materials. More important, perhaps, we thought symmetric multiprocessing, SMP, a type of architecture where all processors are used in the same fashion, couldn't be felicitously retrofitted on a design. To work well, to offer all the benefits it promised, SMP had to be designed in from the very beginning.

So, we designed SMP hardware. With the AT&T Hobbit at first; the PowerPC didn't exist then, and AT&T's processor was fast and inexpensive. Fast, but not exceedingly fast. This started us on healthy habits of getting good performance from less than turbo-compressed hardware. When the PowerPC appeared and AT&T helped us move to our new target, we enjoyed the sudden boost, even on the slowest member of the PowerPC family, the 66 MHz 603.

Later, a strange idea came to us: Porting our software to the highest-volume PowerPC design, the family of Power Macs and clones. As a result, Be developers gained a broader playing field, and we started a happy partnership with Power Computing. Not only did our young OS shine on a larger number of machines, but multiprocessor Power Macs moved out of the system software orphanage. Previously, they were condemned to hacked applications. Neither the OS nor standard applications could use the extra hardware. On the Be platform, all software automatically benefits from more processors. A four-processor DayStar machine draws strong reactions from the audience, achieving more impressive performance than much costlier workstations.

We were watching two trends. First, the total value of our software to all participants, developers, users, hardware partners, and ourselves increases with the number of users. Not really a surprise, but our migrating to the Power Mac family accomplished such an increase. Second, and speaking of the Power Mac family, there is now a healthy Mac clone community. To wit, a MacWeek story (http://www.macweek.com/mw_1105/nw_sales.html), in which Pieter Hartsook, Apple vice president of marketing analysis and research, estimated that clone vendors shipped 100,000 to 120,000 machines during the fourth quarter. We came to feel there was little we brought to the PowerPC camp now that MP machines were available and more accepted.

So we decided to focus on software and on doing whatever we could to help the PowerPC build momentum. Of course, we're aware of our minuscule size; a 55-person company in Menlo Park can't influence the PowerPC platform as much as its largest player, Apple. But we feel we can do the most good by focusing our resources on adding value to the largest possible number of PowerPC machines.

Unfortunately, it's not that simple. On the human side, we're losing Joe Palmer, our Director of Hardware Engineering. Joe's fine work put us in orbit. He himself uses the booster rocket metaphor to describe the role the BeBox played for the Be community. We'll miss Joe's presence, his work, his endless supply of metaphors, especially ones that require lengthy explanations for this immigrant, his demonstrations. We get to keep the memories and the good feeling of being in the debt of such a classy man.

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail.

To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.