|
Be Newsletter
Issue 78, June 18, 1997
Table of Contents
- BE EVENTS: Be Demo Tour: LAMG in Santa Monica, CA, MacHack '97 in Detroit, MI, European Events in Paris, London, Frankfurt
- BE ENGINEERING INSIGHTS: What I did On My Summer Vacation, By Robert Chinn
- Please State the Nature of the Emergency, By Michael Alderete
- News From the Front, By William Adams
- Be Developer Funding, By Jean-Louis Gassée
- BeDevTalk Summary
BE EVENTS: Be Demo Tour: LAMG in Santa Monica, CA, MacHack '97 in Detroit, MI, European Events in Paris, London, Frankfurt
- European Be Developers' Conferences in London and Frankfurt:
- Wednesday, June 25, 1997
Be Developers' Conference in London, UK
- Sunday, June 28, 1997
Be Developers' Conference in Frankfurt/Main, Germany
For more information, please see:
http://www.beeurope.com/Developers/index.html#Meetings
- June 26, 1997: Santa Monica, California
BeOS Demo at the LA Macintosh Group General Meeting
When: Thursday June 26 at 7:30pm
Where:
Santa Monica High School
Barnum Hall
601 Pico Boulevard
Santa Monica, CA
- June 26-28, 1997: Detroit, Michigan
MacHack '97
When: June 26 12:01am to June 28 11:30pm
Where:
Holiday Inn Fairlane
5801 Southfield Service Drive
Detroit, MI 48228
(313) 336-3340
The hotel is located at the intersection of the
Southfield Freeway and Ford Road in Dearborn, Michigan.
For more information, please see:
http://www.machack.com/97/
BE ENGINEERING INSIGHTS: What I did On My Summer Vacation
By Pierre Robert Chinn
My first day at Be happened to coincide with the start days
of two interns, William Bull and John Standerfer, both gone
now but with a lasting impression left in their wakes. For
some time I was viewed by others as just another intern with
a finite time-span in the company. Maybe it's because of how
I look or carry myself or the inane questions I ask. Perhaps
it's because I feel comfortable just sitting behind a
computer and trudging through header files. Now, as the
interns leave and new ones enter our doors I have often been
stopped by other Be employees who ask how much longer I will
be around. I think to myself, "Do they want to get rid of me
so soon?"
Playing with software or hardware in development (that
"Bleeding Edge" stuff) has often been called living life
dangerously, working on the high wire without a net. One
might get a shock from a piece of hardware (yes, I've done
that many times); one might fry a new board or hard drive
(yup, made that happen); or, you might start a little fire
(well, it was little before I left the room!).
It really isn't dangerous, though. Have you ever thought
what a test pilot thinks before he takes a new plane up?
"Well, gee, it's not preventing me from doing this, so I
guess I'll just have to try it." Ever heard of a test pilot,
after crashing, ask the engineers where the reset button is?
Okay, so I will admit that corrupting an OS or losing lots
of data is a real pain and can get quite tedious day after
day, but it is kind of amusing in a masochistic sense.
When I arrived, we were in the middle of Mac compatibility
testing, for DR8 that is. Often times someone would come in
and ask, "Where's the 8500?", "Is that computer a
Tanzania?", "Have you tried, 'such and such' on Power
Computing 'foo'?" Then I started to realize that there are a
lot of configurations to deal with nowadays. So, we started
to build a lab, of sorts. We acquired many different models
of Macs (still only a small subset of what exists), wired
them all up, and turned the switch. "Damn! Why'd the power
go out!", I heard from next door. Hmmm, I thought, "Why'd
the stereo just go off in the lab?" Oops, I guess I really
shouldn't have daisy chained four power strips from one
outlet. The office -- now getting quite full with equipment
and, often times, engineers -- is at a constant 75-80
degrees, and is looking forward to a nice wading pool with
flamingos and palm trees.
Black Box testing on a system or an application is always
quite amusing. You get to try the most stupid, ridiculous
things, wallow through incredibly tedious processes, and
perform some quite natural actions. Then, of course, you get
to answer the question from the engineer, "Now why would you
ever do that?," almost always with the simple practiced
reply, "Because I could."
To effectively test it would appear that you simply need to
poke into regions of the brain of the engineers who created
the stuff you worked on. After a period of probing you begin
to discover when they got tired or when the caffeine wore
off, and the effects that had on their creations. But, after
this stage you have to discover or invent new ways to break
their creations. Often times, by asking leading questions,
one can find where they did not "bullet-proof" their code or
skimped on the robustness of a feature. On the other hand,
by simply getting to know who the engineer is you can
discover how to not just break their work, but also possibly
enhance and help create a robust and working piece of
software or hardware. Okay, maybe it's a bit idealistic, but
sometimes it actually works.
When writing tools, I often think about what a doctor once
told me after I injured my back, "When I do this it hurts,"
"Well, then don't do that!" Writing test tools has a balance
between being an amusing task and one that is extremely
tedious. While one has the opportunity to play around with
the API of some system and create tools or applications with
wild abandon, a test tools writer also has to break down and
trudge through the multitude of classes and methods and
address such issues as performance and compliance. The
results of this are applications that simply and efficiently
go out and fragment your disk, or ones that become a robust
but totally copyright-infringing reproduction of a well
known game.
Tools are also created that test the sanity of some
engineers and test the assumptions and patience of the use
of things like void*. It is always amusing to look over some
API and to find a method or function that allows a pointer
to be passed in. Hmmm, I think, "What happens when NULL is
passed as that parameter?" Of course, the reply from the
engineer goes something like, "Well, don't do that! Do you
really think I should be checking for that? No one would
ever pass that in...", and the rant goes on.
So, here I sit in a lab with 20 computers, a multitude of
monitors, keyboards, boxes of cables, stacks of hard drives,
dead equipment and the air conditioning system wondering why
it didn't just become that neat little fan for an RV. We
play with the stuff as it comes out, come up with new
scenarios in hopes that some user will never have to deal
with what we come up with, and arrive upon amusing uses for
technology. Working here never gets boring; new tasks and
ideas appear every day. Somehow I guess, the tasks and
problems that we overcome define a role that I play here. I
just wish I knew what that was.
Please State the Nature of the Emergency
By Michael Alderete
When I had been working at Be for about a week, William
Adams came to my cube and asked me to say "Please state the
nature of the emergency." I did it, and he laughed his
inimitable laugh and walked away. It wasn't until a few days
went by, and I saw that week's episode of Star Trek:Voyager,
that I got the joke.
It would seem William thinks I resemble Robert Picardo, the
Holographic Doctor on Voyager.
I kind of like that. When people come to the Holographic
Doctor he asks them, in a very formal way, what the problem
is. Since I read and respond to a lot of the electronic mail
that comes in to the Be offices, including a fair number of
requests for technical help, I frequently find myself saying
the e-mail equivalent of "please state the nature of the
emergency."
What makes a really good request for technical assistance is
a formal declaration of what is going wrong. When we get a
request for help here at Be, we love it when you tell us
four things:
- what you were doing, and where you were doing it
- what actually happened
- what you think *should* have happened
- detailed information about your BeOS system, including:
- computer make and model
- BeOS system version (and Mac OS system,
if you're on a Mac)
- amount of RAM and hard drive size(s)
- graphics/video interface and monitor type
- *everything* plugged into internal expansion slots
- anything else that's interesting about your computer
When we get this kind of information, one of two things
generally happens. Frequently, we instantly know what's
wrong, and can answer immediately. People seem to like this.
Failing that, we're at least in the position to try to
replicate the problem, and figure out what the solution
might be, instead of having to ask for more information.
Either way, BeOS users get help a lot faster than they might
otherwise.
Of course, in the heat of an emergency, most people don't
want to write a lot of stuff in a help request, or sometimes
skip items on the above check list. Or sometimes the problem
is fairly trivial, and it seems like a bother to write all
the details out into an e-mail message.
Ed Romson, our Director of Support, wrote in Newsletter #72
about one of our solutions to this. We've created a Help
Request web form, which we are testing internally right now,
that should make the process easier. It will make it simple
to remember to enter all of the information our technical
support group needs to solve the problem, and it will make it
easier to actually enter that information, by simply choosing
items from pop-up menus and checking radio buttons.
The Help Request form will make its debut around the same
time as the Preview Release, or a little before. When the
form appears, you'll find it in the Support section of the
Be web site: http://www.be.com/support/index.html.
Of course, some problems are so catastrophic that using a
web form is not possible. We will, as Ed wrote, continue to
handle support requests via e-mail and, soon, our support
telephone number.
All of our available support resources are described on our
web site: http://www.be.com/support/index.html, which is
updated constantly as we add resources. If you have ideas
for information or other resources to add, that will help
you to use the BeOS better, I'm eager to hear them. Please
write me at alderete@be.com. Formality not required. ;-)
News from the Front
By William Adams
A funny thing happened on the way to releasing the mkimghdr
code from last week. I tested with 8-bit GIF images and
reawoke to the fact that you can't make any app_server calls
unless you have a connection to the app_server, and that
only happens if you have instantiated a BApplication object,
and preferably created a window object as well.
In particular, you can't call index_for_color(), or now
BScreen::IndexForColor(), unless you have met these
criteria. Well, it's actually out now, just in time to be
revisited by discussion of why you actually shouldn't do
things this way in the first place. This just goes to show
you, you're never too good a programmer to slap your
forehead and say "Doh!"
Also last week, I mentioned the Wacom tablet code. Well
after a similarly delayed release, I did manage to put out
the fiddling code. Why fiddling? Because, you can open up
the tablet and get all the information you want, but it's
not exactly "integrated" into the system. As has long been
known in the US, separate is not exactly equal. The current
system may allow you to talk to a graphics tablet, but it
does not really view it as a mouse! What can you do? You
want to integrate your tablet in such a way that the tablet
can both be used as your primary system mouse as well as get
at the tilt, pressure and other information specific to a
tablet.
The answer lies in a couple of places. First of all, there
should be a /dev/tablet device that you can talk to. This
driver, if it were ideal, would allow you to do a few simple
things:
- Allow you to setup various parameters like resolution,
sensitivity and the like.
- Allow you to read the current settings
- Allow you to get the current position information
Generally the tablet position information should look
something like:
struct tablet_position
{
bool proximity;
bool stylus;
bool buttonflag;
int32 x;
int32 y;
uint32 buttons;
bool pressuresign;
int32 pressuredata;
bool xtiltsign;
int32 xtiltdata;
bool ytiltsign;
int32 ytiltdata;
};
If you want to get the current position, you should be able
to do something like this:
ioctl(fd, TABLET_GETPOS, &position);
That would be nice, but how does that make it look like a
mouse? Well, it doesn't directly, unless the kb_mouse driver
knew to open up this device and get positional information
from it instead of from the serial mouse. Well, with a
little fiddling about, you can create a new kb_mouse driver
that can recognize a serial mouse, a PS/2 mouse, or a
tablet:
ftp://ftp.be.com/pub/samples/drivers/obsolete/wacom2.tgz
In your application, you will still have to query the tablet
driver yourself to find out about the tablet specific
information, but at least you'll have your tablet acting
like a mouse. It shouldn't be too long before some
industrious soul creates a paint program that takes
advantage of the tablet specific features, specifically
pressure, and the switch between the nib and the eraser.
Should be fun!
Clean Up
I'm headed to MacHack along with Benoît Schillings and Mark
Gonzales. Hopefully we'll be able to entice some more of the
Macintosh faithful to step into the light and generate some
tractor-driving killers. Geoff Woodcock is done fiddling
with iso9660, and that's going to be great fun. Now he's off
to Europe.
And one last thing. In the past we have always distributed
our samples and whatnot using gzipped tar files, the
familiar .tgz file extension. Well, a new day is upon us. In
the next release of the BeOS, the unzip utility that Chris
Herborth worked so hard on will be a standard part of the
system. What's so great about this? Well, the zip/unzip
combo is a little more flexible than the tar/gzip combo in
that it preserves the attributes associated with a file, and
allows you to create self-extracting archives rather easily.
Thus, in the future, our samples will be packed with zip
instead of tar/gzip. We won't start yet, since we don't want
to deliver samples that require you to go outside the box,
but this will be our future direction.
So, it was my second Father's Day. When you're with a 2 year
old, there is never a moment of their life in which they
think someone else might be the center of the universe.
Despite this, they do a fairly good job of making you feel
happy to be called daddy. Yasmin's not old enough to buy me
ugly ties, so she took me to the Monterey Bay Aquarium.
Groovy, man. She was so wonderful and I had a really good
time. And the best part was, she was so exhausted when we
got home, she was asleep within the hour. As I kissed her
good night, and shut the light, I had one last wish for this
Father's Day night... One more compile!
Be Developer Funding
By Jean-Louis Gassée
One question keeps coming back with increasing frequency:
why don't we invest in promising start-ups developing Be
software? After all, without application software we are
nothing.
Such a move would make more likely availability of exciting
applications and it would leverage our own investment in the
BeOS. (Let's quickly note the "increasing frequency" is good
news.) On the surface of things, our investing in Be
developers looks helpful. Yet, after careful consideration,
we found that, on balance, such a move wouldn't be helpful
to the commonwealth.
A first objection is easily defeated but leads to a more
serious one. Too much money involved. Indeed, we would have
no trouble identifying one hundred exciting projects, each
one easily justifying one million dollars apiece in mere
seed money. We don't have that kind of money and we don't
think we should or could raise it. This company was started
on the more than ever valid premise that we operate on
different metrics. By this we mean we don't need the
hundreds of millions of dollars larger companies have to
spend to write a new OS, more often than not ending up with
an unwieldy product.
Well, then, let's pick carefully a very small numbers of
projects, thus keeping our outside investments consistent
with our philosophy. This makes a partly hidden assumption:
in fact, we'd be saying to ourselves we're smarter, more
experienced, and better connected than professional
investors, a.k.a. venture capitalists. This, I'm not
prepared to assume.
It is one thing to trade criticisms sublimated into
epigrams: VCs think entrepreneurs are too stubborn,
entrepreneurs think VCs are too greedy, all is well. It is
another to miss the essential point that investing is a
profession, a craft, or an art -- I'm sucking up -- very
different from our trade. Anointing or improvising ourselves
investors could cause great harm. Still, some companies have
"internal" venture funds. To the best of my knowledge, they
rarely compare favorably with purely profit driven funds.
Admittedly, I'm influenced by having watched one such
example from the inside. I observed frequent abuse of the
word "strategic" in order to cover for politics and other
human factors unrelated to shareholder value. Admittedly
again, there are good counter-examples, they often happen
with the help of a real venture fund running the show for
the company. These are big and smart companies; we'll review
the situation when we can call ourselves that.
Another objection is our investing in one company would
create tension with other developers. Perhaps paradoxically,
I could find a defense for that one. If we make the Be
platform more successful, everyone benefits, not just Be
shareholders and employees. Mangling metaphors: the tractor
app will raise all boats. Still, it would be a difficult
balancing act, it would create controversy and, as a result,
absorb energy better spent elsewhere. In the end, the
overriding reasons are I'd rather not assume we are smarter
than the free market and the professionals accustomed to
swimming in it.
BeDevTalk Summary
BeDevTalk is an unmoderated discussion group that's a forum
for the exchange of technical information, suggestions,
questions, mythology, and suspicions. In this column, we
summarize some of the active threads, listed by their
subject lines as they appear, verbatim, in the group.
To subscribe to BeDevTalk, visit the mailing list page on
our Web site: http://www.be.com/aboutbe/mailinglists.html.
- ----NEW---------------------------
Subject: How to port software
Is it better to port, or should the scrupulous developer
re-write from the ground up? Obviously, a re-write can show
off more of a new OS's native talents, but is it worth the
extra effort and time? The "port or not" threshold, for many
folks, falls between developer tools (port 'em) and end-user
apps (which should be all fresh and slippery). Rollin Weeks:
"Fred Fish and others are performing a tremendous service to
developers in providing ports of things we already know how
to use, even if we have to use them from the shell in the
beginning. If we were to adopt a BeOS purist attitude, our
development capabilities would be greatly handicapped."
There was some frustration over the lack of Be-native apps
-- where are the brave? -- but a number of folks pointed out
that a) There *are* apps in development b) It's difficult to
maintain steady forward progress on a platform that's young
and constantly changing its API c) Working without UI
guidelines is less than comforting d) Working on a platform
that doesn't have a huge built-in audience requires a lot of
faith. The general feeling was that there is a sufficient
number of people with sufficient faith, and porting is a
great way to solidify the indoctrination.
Another notion, somewhat orthogonal to the port/don't port
question, is that a new OS has to find itself a niche. Jake
Hamby offers the following niche possibilities:
- The embedded arena (...think set-top boxes...).
- Hard-core gamers (think 3D acceleration and "bang for the
buck").
- Scientific and engineering applications: a market that has
yet to be tapped...
- New Internet technologies.
- ----NEW---------------------------
Subject: Be Newsletter Issue #77, June 11, 1997
Rraster vs. the Datatypes lib. Which plug-in format does Be
officially support? Is it foolish to write Rraster codecs,
or is this exactly what the savvy Be developer should be
doing?
THE BE LINE: Rraster codecs will work with the Datatypes
library. William Adams' continued work on the Rraster codecs
shouldn't be taken as an assault on the Datatypes beachhead.
The bottom line: If you're writing a codec, heed the
Datatypes format.
- ----NEW---------------------------
Subject: Prefs: Lowest Common Denominator is *NOT* C...
What's the best language/mechanism for designing a
preferences "server"? The major candidates:
- Straight C: It's easy, portable, and ubiquitous.
- C++ BMessage subclass: More in keeping with the Be
lifestyle.
- BMessage-like protocol: Similar to the above.
It was admitted that C is much more portable, but is porting
preferences code useful or even desirable? Mixed feelings,
here.
- ----NEW---------------------------
Subject: Anyone interested in GLUT (OpenGL®)?
Will the GLUT library be on the DR9 CD?
THE BE LINE: No -- sorry about that. But keep your eyes on
the Web site; we hope to have the library ported and posted
sometime soon.
- ----NEW---------------------------
Subject: Pictures in BeWare list
Here we read a number of requests for the BeWare catalogue:
- Include a screen shot of each app.
- Provide a topical search function, and by-app
keywords database.
- Organize the entries for easier cross-referencing.
THE BE LINE: Ron Theis, Be's Web site Maitre and BeWare
fiddler, is hard at work improving the catalogue's look and
taste. He sez:
"...here are some interesting things you'll be able to do
with [the BeWare database] soon--look for my Newsletter
article next month..."
|
