Issue 1-34, July 31, 1996

Be Engineering Insights: Bugs!

By Melissa Rogers

Let's say you witness odd behavior in your application. And let's further assume that you suspect that the culprit isn't in your own code. Moreover, you prove to yourself that it is, indeed, a bug in the BeOS™. You can work around the bug—perhaps at the expense of performance—but you sure would sleep better at night if you had a clean version of the OS. How do you get us (Be) to fix one of our own bugs and release the improved OS? I'll tell you how. But first, let's look at the Be release process.

We follow Metrowerks' release strategy of delivering new software four times a year. That's a release every three months, which gives us just enough time to make an appreciable improvement in the OS. In an ideal world a release every other month—an almost constant, on-demand release system—would be great. We actually tried it once, but found that a monthly release schedule didn't leave much (any) time for testing —and you thought DR7 was unstable. So for now, anyway, we'll try to keep up with a three-month release cycle. This is pertinent to the developer because as a rule, we only distribute bug fixes as part of new releases.

Of course, bugs don't fix themselves; and within a single release cycle, we many not even have time to fix all the bugs we can identify and understand. So we have to do some filtering: We decide which bugs are most important and which ones we (and you) can live with until the next go-round.

We have a reasonably simple strategy for release content. In the first part of the release cycle, we make a list of the features that we really want to include—without regard for the time it would take to implement them. The feature list is always longer than a novel. Then we look at each feature, figure out how long it will take, and try to fit it into the schedule of the appropriate programmer. This goes a long way in cutting down the list. When we think we have a list of features that can be managed in three months—given the talents and temperaments of our engineers—we look at the list once more and lop off one feature from each assignation. This is the sacrificial feature—the time that this feature would have taken is devoted to fixing bugs. That's the theory.

Once a week we pull down the bug reports from the Be web site and separate the good bugs (feature requests) from the bad bugs. We try to reproduce each bad bug and to figure out the scope of its malfeasance -- does this bug merely hang a window, or does it kill an entire app? Does it wedge the app server, crash the entire machine, crash all machines in the same room, shut off the electricity to the building, or run around the parking lot letting air out of car tires?

Having gauged a bug's severity, we argue over which ones we'll try to fix. Once a week, seven of us enter a room and, a few hours later, at least three of us are still talking to each other (it's astonishing how much heat can be generated when you sit in a room and discuss bugs with the programmers who imposed them). We mark bugs with four different priorities: A priority 1 bug is important enough to hold up a release -- we won't ship until the bug is fixed. Priorities 2 and 3 mean we'll live with the bug if we have to, but we'll be ashamed (priority 2) or merely chagrined (priority 3). Priority 4 means the bug is deferred until next time. On average we fix 180 bugs each release. That's pretty good for 13 engineers.

So now that you know where the ballpark is, here's how you play the game:

Be Developer Talk: Piotr Pytlik of Double P Software

By Piotr Pytlik

By day, I work as a software developer for Switchview Inc., a Canadian telecommunications business. But at night, I become Double P Software, developing programs for several clients in Canada and for developers on PC and BeBox platforms. I've developed games, such as Dragon's Lair, Space Ace, Brain Dead 13 (Readysoft Inc), written problem-solving applications (Waterloo Engineering Software), and built custom, real-time control systems for high-resolution projection systems (Electrohome Ltd.).

I started in electronics when my uncle introduced me to "Electronic-Logic," used for controllers of sorts. We built an entire railway station: Tracks, trains, lights—all controlled in real time. Then came the first microcomputers, Z80, ZX Spectrum, Commodore64/128, Amiga, Pcs... and now the BeBox. Progressing from one to another I have loved the possibility to be creative as a programmer, to create something completely new. At school I was already programming on contracts for the Academy of Art in Poland and then created special effects for the SFI movie "Snake Valley."

I love the power of creativity that computers give me; but I need a powerful, flexible programming environment that's driven by an easy-to-use and powerful OS. I also need a system that allows various peripherals for direct hardware control, that provides communications via network or modem access to the Internet, and that's FUN to program and use, intuitive and smooth (not like some "windows" are).

When a friend introduced me to the BeBox, I saw an opportunity to be a part of a growing community and to be able to contribute to the new OS, which is not a hog like some other systems. And the machine itself has exactly what I need: Power, graphics, the GeekPort™, and for now at least, relatively small competition.

I love the responsiveness of the GUI, the flexibility in using PC peripherals, and the great ideas in the OS, such as the database. On the other hand, I would like to see a few things change: For example, I prefer an Explorer-like browser, rather than Mac-style folder windows. Also, some parts of the window design are less than ideal: I would like to be able to resize a window by grabbing any edge, for instance.

As for products that I'm thinking of producing: I would like to address other software developers so the software base for BeBox can be much bigger. I would also like to address the needs of Musicians by working on MIDI software for controlling MIDI equipment (patch editors...) and sound (accompaniment).

Other plans I have include porting the Timex Data Link communication protocol, creating an add-on for a universal HTML parser/browser that could be used for Web browsing and pop-up (balloon) help boxes for all applications. I'd also like to integrate a web browser, mail client, FTP, and user groups (Internet news) into a single shared package, so anyone can take advantage of those facilities.

But in general, I'd like to share my experience in software development and tools for programmers. I believe that the wheel should not be re-invented so many times. Every single invention should be available to everyone for immediate use and every developer could then concentrate on new tools and inventions, allowing everyone to grow much faster.

Be Marketing Mutterings

By Alex Osadzinski

Last time, I wrote about hardware unbundling and how it seemed to be working just fine for our customers and for us. I also promised, or threatened, to address the much thornier topic of software bundling in my next mutterings. Alas, my two weeks are up and there is no escape; our newsletter editor is a person not to be trifled with, and she combines this with an elephantine memory, truly a formidable combination of attributes. Resistance is futile.

Whereas hardware bundling stimulates powerful emotions, these pale into insignificance compared to the reactions generated by software bundling. In particular, application developers become very upset (and with good cause) when hardware vendors begin to invade their turf by bundling applications that compete directly with third-party products. Users may like the idea of getting "free" software but, of course, it isn't really free and it restricts competition in the long run.

Let's deal first with "shovelware." Shovelware is simply the practice of including mostly tired old CD-ROMs, a few restricted apps, and the obligatory free samplers for CompuServe and America Online with a hardware platform, advertising it as "up to or more than $1000 worth of free software." Unless you have a burning desire to browse the full text of 1991's "Time" magazines or to play the first two levels of a 70-level adventure game, you may find shovelware a little disappointing. If you believe that it's worth $1000, please call me to discuss some real estate opportunities I happen to have available for your investment dollars.

Needless to say, you won't be able to buy a BeBox with "up to $1000 or more" of free software anytime soon. We ARE planning CD and on-line software samplers, but we won't pretend that they take the place of real applications.

A less common but more significant form of software bundling involves a hardware vendor preloading usable, useful applications. Be's philosophy on this is simple: Avoid competing with our application developers and avoid giving one developer an unfair advantage over another. In practice, this means that we'll include with our hardware all the basic software required to provide a comfortable environment for developers and users alike, but no more. Based on input from developers, we have included, or will include, items such as standard graphics and networking APIs, a simple text editor, and sound players. It can always be argued that by including, for example, a MIDI player, we're competing with a developer who could offer a better one if only we weren't unfairly excluding him or her. Here we apply the "reasonable person" test and, yes, there are always gray areas. Nobody would argue that we shouldn't "bundle" an API for reading and writing files, nor would anybody argue that we should bundle a full-featured video editing suite. There are many less clear-cut examples, such as a web browser. This has become a requisite on all computer platforms, particularly on the BeOS as all our on-line documentation is, well, on-line, and in HTML format. In situations such as this, we'll provide a "good enough" solution, leaving the field open for developers with better, more extensive, or more innovative solutions. It will be hard to please everybody all of the time, but we'll optimize our approach to come as close to this as possible.

Built-In or Bundled?

By Jean-Louis Gassée

Before I jump into this week's topic, a correction. Two weeks ago I discussed the opportunities for more interesting audio afforded by DVD, referring to these opportunities as the A behind the V of the Digital Video Disc. It turns out I was mistaken, not about the potential for better audio, but about the V: It doesn't stand for video, but for versatile. We agree. Others even find it a little too versatile. Hollywood and other contents owners haven't yet reached an agreement with DVD manufacturers on ways to protect their intellectual property from DVD's versatility. We might have to wait a little longer for DVD sales to take off, even if Toshiba bravely claims to be going ahead with an October 96 release.

This week I'll discuss our e-mail client, included in the upcoming Developer Release 8 of the BeOS. I expect we'll get questions or even criticism for "bundling" an e-mail client, and I'd like to take this opportunity to clarify our position on the matter. You might also want to refer to my related article, "Bungling Bundling," in Issue 1-9 of this newsletter (it's on our web site at

E-mail is so nice and useful we can't conceive of a personal computer without it anymore. Windows 95 includes a mail client, the Macintosh had the ill-fated PowerTalk, one of our engineers, Robert Polic, also an avid and prolific contributor to this newsletter, wrote BeMail for the BeBox. A question immediately comes to mind: Is this the first of many third-party opportunities Be will take away from application developers as the BeOS expands its capabilities? On the surface, yes, but a look under the hood will convince you we're actually creating opportunities.

First, Robert wrote BeMail as an application. The mail client can easily be replaced by a third-party application. Unlike what we've seen on another platform, no hidden hooks, no hard-to-delete web client icon. One might object it'll be hard to sell a third-party mail client while Be's is "free," included with the BeOS. Eudora is a good counter example. They offer a base level version for free and charge for the "Pro" client. Exchange, included in Windows, doesn't prevent Eudora from selling well on that platform. It's simply a much better, richer, nicer product—at least I think so, I love it and I use it on my Pentium system as well as on my Macs.

Second, to make e-mail matters more hospitable to developers, Robert has built an e-mail API into our system, and anyone can use it to write something better than BeMail, or more suited to particular needs, or integrated into another application. Third, we'll go even further and release the source code of our mail client as an example, illustrating system features such as the database, the network, and drag-and-drop.

Hopefully, someone will shame us and write the next Eudora, or the next Claris E-Mailer. That would make Robert proud, and he stands ready to change his e-mail API to suit your creative drive.

BeDevTalk Summary

Tons of mail this last week, yet barely a word about GUI. Miracolo.

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. To subscribe to BeDevTalk, visit the mailing list page on our web site:


Subject: Speaking of Postscript...

This thread, originally about file types (such as MIME) and later about e-mail filters, swerved back into the file type lane. The logic behind a hierarchical file type (as in MIME's "major/minor" typing scheme) was described.

Subject: First Experiences

Should a CPU's idle thread go into "snooze" mode (instead of a busy wait)? Would this degrade context switch performance when the CPU has to wake up? It was agreed (sort of) that, yes, there would be a performance hit, but some folks think that the hit could be acceptable, given proper management.


Subject: First Experiences

A/K/A: Root Dir Proposal

The what-goes-into-root controversy narrowed this week to volumes (should they be allowed to be mounted anywhere?) and then turned into a discussion of OpenBoot. The proposal that OpenBoot might solve a number of file system issues (specifically) as it allows a solution to the more general problem of identifying and mounting arbitrary devices was rebutted by the observation that OpenBoot is "beneath" the file system layer. RDB ("Rigid Disk Boot"?) was proposed as an alternative solution, or as a layer that would sit on top of OpenBoot. But is RDB prone to viruses?

Subject: Internet-Based Updating System

A/K/A: Application Messaging

"Is it possible to have the BeOS automatically upgrade itself over the internet?"

A lot of traffic in this thread: Some off-the-shelf solutions were proposed (and objected to). The debate ranged between philosophy and practice: Would daily updates (from Be) lead to daily bugs? Are existing non-T1 lines fast enough to download an entire clean-slate release? Can you download a kernel while you're running? And so on.

Uninstalling was also debated. The hottest question here, boiled to its pith, was: Who should be responsible for keeping track of the apps that share a common resource such that when all sharers are deleted the resource is also deleted? Should the shared resource be deleted by default or should it be a preference? How does an app declare the resources (shared libraries most importantly) that it needs?


Subject: Standard Installer Application?

This thread started to address some of the same issues as the "Internet-Based Updating System" thread, but then turned into a discussion of how preferences should be stored and how apps should apply them. Some folks want human-editable preference settings. Should there be a standard format (X11 was suggested).

Subject: X11 Apps on Be

A call for X11 support.

Subject: Generic Settings Wanted

A proposal for a "Settings Manager" was made. In it, user-by-user preferences-like settings would be stored and managed (through add-ons, optionally) as a system service. Each setting would be stored in the database, keyed by the thing that's being described ("mouse speed," for example) and user name. Looking up a setting, therefore, would only require that you know the name of the "thing"; it wouldn't require a specific C function.

The objection was made that such a system would be better implemented as an ORB rather than as a manager.

Subject: BAudioFile

Should the sound file format allow loop points (or AIFF marks)? Some folks think that loop points are essential to playing "samples." Others see it as a higher-level construct that would open the door to other "essential" sound manipulations.

Subject: Telling Browser to Launch Items??????

What happens when you report a bug? How do you track your report?

THE BE LINE (and I quote):

"You now get a bug tracking number for your bug... [The] bug number is indeed a date-based YYMMDD-HHMMSS, because we wanted unique numbers (and it gives us and you an idea of when it was filed).

...[B]ug reports definitely do not get sent into a Bottomless Pit, they get placed in a bug-tracking database and every single one is evaluated. Every [Be] engineer knows how many bugs they have..."

Also, see the "BE ENGINEERING INSIGHTS" article in this issue.

Subject: How Are We Supposed To Do This?

A/K/A: Stylus Pressure

The question of how to get near-constant keyboard status was raised -- should you poll the keyboard? Some folks think that polling is always bad; that if the resource that you want to monitor requires polling, then the system is poorly designed. Others think polling has its place, given that the "normal" solution (call-back functions) carries an overhead of its own.

Subject: Game/3-D Kits: Good Job!

Most folks are pleased by the Game Kit and 3D Kit announcements and the decision to support OpenGL. Some folks wondered that perhaps QuickDraw should also be supported; and one lone voice wanted Be to create a brand new format (which was countered by the argument that the 3D Kit IS a brand new format).

Subject: Dependencies and Installers and Shared Libraries and Stuff

A/K/A: Microkernels and Context Switch Time

This thread was an attempt to induce the Installer discussions from (at least) two other threads. Instead, it became a discussion of microkernels: Are they good? Is Be *really* a microkernel OS? What are device drivers doing in there? Stayed tuned.

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.