|
Be Newsletter
Issue 34, July 31, 1996
Table of Contents
BE AT MACWORLD BOSTON: See You
There!
Be will have a booth at MacWorld Boston in the World
Trade Center.
The Be booth number is #5068.
Exhibits are open from:
10:00am - 6:00pm: Wednesday, August 7
Thursday, August 8
Friday, August 9
10:00am - 4:00pm: Saturday, August 10
We will also have a press hospitality suite at the Boston
Marriott Long Warf on Thursday, August 9, from 10:00 am to
4:00 pm, in the Commonwealth Ballroom, located on the Lobby
level.
See you there!
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(TM). 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:
- Submit your bugs and feature requests on our web site
(http://www.be.com/developers/bugform.html).
As a rule of thumb, bugs reported after the first four
weeks of a release cycle must wait until the next
release.
- Submit one bug per report. If it looks like there
might be more than one bug on a report, then someone over
here (me) has to figure out how many bugs are really
there, which takes time and makes me grouchy.
- If you're reporting a "bad bug" (as opposed to a
feature request), give us an easily reproducible case. We
love it when there are steps to follow or example source
code.
- If you're sending us a feature request or UI
enhancement, please be clear and precise about what you
want. We have plenty of bugs that are long-winded
philosophical tracts (then again, if you're looking for
an essay for your Computer Interface Design 101 term
paper, maybe we can work a deal).
- Bugs that crash apps (or, gasp, the machine) are
pretty easy to peg. But if a bug doesn't crash your app,
try to tell us exactly what adverse effect it does have.
Sometimes we have a hard time assigning a priority to a
bug because we don't know why or how the bug affects you.
And the number one secret to getting your bug fixed,
(drum roll please...):
- Send us your bug in the first place! If we don't know
about it we can't fix it. We really, really want to fix
any and all bugs that keep you from easily developing
your application on the BeBox.
BE DEVELOPER TALK: Piotr
Pytlik of Double P Software
E-mail:
ppytlik@doublep.com
URL: http://www.doublep.com
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(TM), 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 9 of this
newsletter (it's on our web site at
http://www.be.com/about_be/benewsletters/Issue09.html).
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:
http://www.be.com/about_be/mailinglists.html.
- ---- WEEK 3 ----------
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.
- ---- WEEK 3 ----------
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.
- ---- WEEK 2 ----------
Subject: Root Directories
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?
- ---- NEW ----------
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?
- ---- NEW ----------
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).
- ---- NEW ----------
Subject: X11 Apps on Be
A call for X11 support.
- ---- NEW ----------
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.
- ---- NEW ----------
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.
- ---- NEW ----------
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.
- ---- NEW ----------
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.
- ---- NEW ----------
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).
- ---- NEW ----------
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.
|
