|
Be Newsletter
Issue 48, November 6, 1996
Table of Contents
Be Demo Tour: BeBox Demos in Ithaca, NY and Boston, MA
- Monday, November 18, 1996, 2:30 pm to 4:30 pm
BeBox General Demo Meeting
100 Caldwell Hall on the Ag Quad
Cornell University
Ithaca, NY 14853
Directions: http://www.cornell.edu/bin/MapMove.x/M1-1-1?200,300
- Tuesday, November 19, 1996, 6:30 pm
BeBox General Demo Meeting / Boston Be User Group
MIT E51-345
Lecture Hall at the Sloan School (The Business School at
MIT)
Cambridge, MA
- Wednesday November 20, 1996, 4:00 pm
BeBox General Demo Meeting
Dartmouth College Computer Center
(Location details (room #) are still being worked out.
Please check the Be web site in a few days.)
Dartmouth College
Hanover, NH 03755-3523
- Thursday, November 21, 1996
BeBox General Demo Meeting / Harvard Computer Society
(Location details (room #) are still being worked out.
Please check the Be web site in a few days.)
Harvard University
Cambridge, MA
BE ENGINEERING INSIGHTS: The Evil Empire?
By Erich Ringewald
Much has been written, and even more said, about those dark
forces from the Northwest, the evil willies of Redmond. Why
does one little software company evoke such harsh sentiment
from almost everyone in the industry (not to mention the
occasional investigation from the Department of Justice)?
The subject came up again at dinner last night, and I was
unsurprised by the unanimity and depth of feeling.
"Unscrupulous bastards," "criminals," "lunatics." Round the
table we went (myself included), in a game of "top the
epithet." I started to feel sorry for Bill Gates.
But... I've witnessed my share of Microsoft's "interesting
behavior." Is it coincidence that Microsoft announced
PenWindows just one day before Go Corporation announced its
PenPoint operating system for portable pen computers?
Microsoft was a key PenPoint developer -- Go had even
invited Microsoft to demonstrate their application at the
PenPoint rollout. Yet, somehow, the other half of Microsoft
(the system software folks) chose to repay this kindness by
scooping Go with their own PenWindows intro. This
"coincidence" took a little of the steam out of Go's
announcement.
Criminal behavior? I wouldn't like it if they did it to my
little sister, but... probably not illegal. Besides, wasn't
Go asking for trouble by inviting the fox into the
preproduct introduction henhouse?
I see Microsoft as a remarkably persistent company whose
business tactics are extremely aggressive, bordering on
ruthless. They push the limits, but as any adolescent can
tell you: That's What Limits Are There For. Microsoft has a
position of power in this industry that's unparalleled, and
they sometimes abuse it. But it wasn't always this way...
[WAVY LINES ACROSS THE SCREEN; HARP ARPEGGIOS ON THE
SOUNDTRACK]
I first worked with Microsoft when they had a single
product, a BASIC interpreter. Not the stuff the world's
largest personal fortune is made of, but it was a good
product. It actually worked. Then they made their second
product, a FORTRAN compiler for CP/M. It too was a good
product. It also worked. And it was documented. Again, this
may not sound like much, but it did serve to distinguish the
product from its competition. Microsoft was a scrappy little
company (about the size of Be), but it was just one of a
number of scrappy little companies in the microcomputer
language market. In the years before their big break with
DOS for the IBM PC, Microsoft slowly but steadily increased
their product line, their quality and support, and their
revenues.
Microsoft first showed a version of Windows in 1983. It was
miserable. Nobody bought it. They regrouped and refined and
launched Windows 2.0. It too was miserable. Nobody bought
it. They regrouped and refined and launched Windows 3.0 in
1990. Better. People started to actually use it. Refinements
known as Windows 3.1 made it a highly successful product.
Once again the traditions of persistence and refinement paid
off.
There is a bumper sticker about Macintosh that really bugs
me: "Windows '95 = Macintosh '89."
It's not the logic that bugs me -- yes, of course Windows
'95 is no better than Macintosh in 1989. But I want the
companion bumper sticker, which is just as true: "Macintosh
'95 = Macintosh '89."
So next time people start complaining about the tactics of
Microsoft, I might be compelled to point out that while Bill
Gates is our only modern example of the robber baron, his
company's drive and persistence in continuously improving
their products might also be part of their success.
News from the Front
By William Adams
What is a Technical Evangelist anyway? Well, it's a name
that I made up so that I could fit into this awesome
company. A Technical Evangelist is a person with a lot of
engineering experience who has a fire in the belly to become
a marketing type person. The evangelism aspect of the job is
to spread the gospel of the BeOS(TM) as far and wide as
possible.
The BeOS provides a platform upon which developers can "do
the right thing." As a company that's interested in
longevity, and ready market acceptance, we're interested in
getting software from well-established companies, but that's
not the exciting stuff. What's really exciting are the
offerings of the small developers who take a risk on a new
platform and dare to create something a little bit different
from the past -- and often a few levels better.
So, how can a Technical Evangelist help this process?
Well... the Technical Evangelist can write code. A lot of
code. The Evangelist can show developers how easy (or hard)
it is to use the system in a particular way for maximum
effect.
In working with NeXT and Taligent, I always pressed hard for
good documentation and sample apps. So I believe this is the
best thing for the BeOS as well.
This week finds us looking at how to support something like
Photoshop. We have a modest application, Rraster! The
primary function of this application is as a replacement for
the ImageViewer application, which comes with the BeOS. I
took a look at the ImageViewer code and thought, "This could
be made into a lot better and more useful example."
Rraster! is like ImageViewer in that it lets you drag and
drop images on it to view them. The twist is that it allows
you to drag and drop images of any type! It achieves this by
use of add-ons. The interface is easy, and a GIF and PCX
add-on are included. There is a simple add-on manager that
shows how add-ons can be easily supported in any
application. I don't want to spoil all the fun, because this
was also the basis for an upcoming magazine article, but
there's a lot of good stuff in here.
The other things you'll see in this sample are how to
properly launch an application and deal with parameters,
whether you dragged and dropped onto the icon, double-
clicked a file, or launched it from the command line. These
are mundane issues, but they can be maddening if you can't
do them right.
You can get the code from:
ftp://ftp.be.com/pub/samples/translation_kit/obsolete/Rraster.tgz
The add-on support is very basic, and is meant to give you a
good idea of how easy it is to use add-ons. As far as data
translation in general is concerned, you should probably
take a look at the DataTypes library by Jon Watte.
TOOLS FOR YOU
Writing graphics device drivers is a black art on a good
day. If you have been trying to do this of late, you know
what a pain it can be. Well, our graphics driver person has
given me a tool that anyone writing graphics drivers will
probably find useful. The tool allows you to test your
driver like a normal app by hooking it up to an app_server
dummy. You can do source-level debugging without having to
reboot all the time, and when you're done, you can make it a
full-blown driver. This is the very tool that we use
ourselves, so you have it as good as we do. If you really
want to get your hands on it, please send e-mail to me
(wadams@be.com) and ask for it. I won't make a general
public release, because the code is not very... pretty. But
we'll give it to those who are really interested in
exploring the heart of darkness.
RALLYING THE TROOPS
The BeOS is a fun and exciting operating system to write
applications for. The proof is in the number of applications
that show up on our ftp site every day. Developers at this
stage are sharing and cooperating with each other. This is a
good thing and will only serve to make applications better
in the near term rather than later. We're currently creating
a sample CD that will go out to all our demo teams, and
thanks to everyone who sent in code to get on this disk!
More opportunities abound! Comdex is coming, Macworld is
coming, and many more opportunities will give our developers
exposure. Keep those apps coming! The more we can replace
our own apps with yours, the better the BeOS demonstrates.
We're in a much better position if we can show developer
applications instead of our own. So keep them coming, we'll
put you in front people's faces.
BE DEVELOPER TALK: Richard Deken
E-mail: rad@teclink.edu
My primary occupation is as a VLSI design engineer. My
responsibilies are a combination of circuit design and CAD
software design and modification. I've been fascinated with
electronics since I was a kid. As I dabbled in computer
programming a few years later, I developed interests in
scientific software tools developement. What I've enjoyed
most is the continuous challenge and the constantly
expanding base of knowledge from which I could learn
exciting new ideas.
In the late 80s I closely watched the development of the
Amiga computer system. It was a novel system with many
features unmatched in other systems of the time. A group of
friends and I decided that it would be cool to develop
software for this system. We formed a small group that
collaborated on a few small projects. Unfortunately the
Amiga entered a long period of stagnation, and there was no
attractive alternative platform for our varied projects.
Last year we started hearing rumors of the upcoming BeBox.
At first we cautiously stood back and watched Be, Inc. The
BeBox and BeOS seemed to be well thought out. Designed from
the ground up, not just for multitasking, but for
multiprocessing. The BeBox also had many nice standard
features, such as SCSI and IDE, PCI and ISA, PowerPC CPUs,
and the GeekPort(TM). (Clearly more than the cheapest common
denominator sold by many other companies.) However, a good
product alone is not sufficient.
We wanted to make sure that the company was going to be
committed to developing a strong and unique product, and
most important, that it was willing to commit to helping
developers and to pushing the development of products on the
new platform. Be seems to be doing precisely that. They seem
to be willing to accept and support small-time developers.
It's always been my experience that the majority of software
used on systems is not the major applications, but the small
additions, utilities, and tools developed by small
developers. It's also these small things that give a system
the general functionality (if not the feel) that makes a
system so great. They also seem to be very open with
information about their system. The major manuals and
information about the BeBox and BeOS all seem to be freely
accessible via the Internet.
I feel that developing for the BeBox is a unique
oppurtunity. The user base is clearly a cut above average,
for being willing and able to work with a new system such as
this. Further, the market is probably going to be much more
open to new software, users aren't likely to be limiting
themselves to the "I've got the same software as everyone
else" attitude. This will hopefully give not only software
my friends and I develop a better chance of making it off
the ground, but should also provide us with a more diverse
set of software and tools for us to choose from to aid our
work.
The BeBox also provides a lower-cost route to parallel
processing. I look forward to investigating parallelizing
software algorithms, and integrating these techniques in
more responsive applications. The BeOS seems much friendlier
to multithreaded applications than any other OS I've worked
with.
The BeOS also seems to provide several other unique features
that it would be cool to use. Some of these include the
object-oriented approach used throughout the OS and the
integrated file system and database.
Having only been accepted as a Be developer in the last few
weeks, I'm still investigating my options as far what
products I (and probably several of my friends) decide to
work on. Numerous ideas I've been considering include:
- Schematic entry utilities
- Circuit board layout tools
- Circuit analysis programs (both digital and analog)
- Mathematic analysis or spreadsheet software
- And the old classic... games development
Most likely none of these will be available before the
middle of next year. Most of these are targeted at
electrical engineers and hobbyists. They would probably be
released as low-cost commercial packages.
BE MARKETING MUTTERINGS: Recruiting
By Alex Osadzinski
I like bananas. In fact, I like them a lot. I bring a few of
these wonderful fruits to the office every day and my
colleagues have probably noticed that I munch on one
sometimes as I wander from cube to cube. I hope that they
don't mind when I absentmindedly drop banana skins into
their waste baskets. I guess I should retain my banana
detritus and dispose of it in the Be kitchen, where it could
aid in the evolution of the strange lifeform that is
beginning to write code with pseudopods as it grows in the
refrigerator.
Whether or not my Be colleagues have noted my passion for
bananas, I know someone who definitely has: The management
of a hotel in Hong Kong.
Last year, I had the pleasure of visiting Hong Kong eight
times, to work at the Asian HQ of my then employer. On each
occasion, having survived the truly unique final approach
and landing to Hong Kong's tired, overloaded airport, I
would present myself at the same hotel's checkin somewhat
worse for wear and ready for bed. The first time I stayed
there, I was greeted professionally and quickly checked in,
and my room featured a little bowl of fruit. During the next
48 hours, I consumed, of course, the two available bananas
but eschewed the kiwi fruit and apples. During the next
seven stays, the level of greeting escalated from the
regular checkin staff through to the manager herself and the
bowl of fruit (and room) grew bigger and, on my last stay,
included no less than eight bananas and a note indicating
that more of them were available on request.
Imagine what kind of customer service system notes guests'
banana eating patterns and adjusts the room inventory
accordingly. And, although I have my peculiarities, they
pretty much limited themselves in Hong Kong to unusually
high banana consumption. Imagine, if you will, how this
hotel's customer service system adjusts to a much wider
range of guests' preferences and idiosyncracies. Impressive,
and not a little scary.
Be's first distribution channel is direct sales of our
products through the web and other methods involving direct
contact between the customer and Be. When you order a BeBox,
send in a check, ask for the shipping date, deal with
warranty issues, or have general product and logistical
questions, you're working with Customer Service. Right now,
that usually means working with Lilia Simbe, who's built a
reputation with our customers for quick, pleasant, useful
responses. We're building our customer service function to
enable us to deal personally and efficiently with our
growing customer base while not losing that personal contact
between the customer and someone who knows Be and its
products and cares that customers are satisfied. Early next
year, when we ship our BeOS for PowerMac product, we expect
(and hope!) that our unit volume grows by two orders of
magnitude, and we very much want to keep direct contact with
as many customers as possible. That's why we'll continue to
focus on direct sales while simultaneously building other
channels for our products.
Direct customer contact is not, by the way, a way to make
more margin on products. Life being what it is, and the "no
free lunch" law continuing to apply, all channels tend
towards generating the same bottom-line profit for a
company. The main purpose of direct customer contact is to
see, hear, and feel what customers think about Be and our
products.
So if you get in touch with Be next year to order the BeOS
for PowerMac and someone asks you if you like bananas, don't
be too surprised.
Apple Rumors
By Jean-Louis Gassée
I receive many e-mail messages asking me to comment on
rumored conversations between Apple and Be. No, no comment,
maybe, yes -- there are many possible responses. Rather than
picking one, I'll direct you to two URLs:
http://biz.yahoo.com/finance/96/11/05/aapl_3.html
http://www.infoworld.com/cgi-bin/displayStory.pl?96115.eamel.htm
BeDevTalk Summary
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.
- -----NEW---------------------------
Subject: Architecture <-> Legacy
AKA: Are files really what you want?
The Be philosophy calls for a break from "legacy" software.
But is Be true to the call? This long-winded thread was a
thoughtful (if somewhat abstract) look at certain
appropriations that, perhaps, shouldn't have been made. The
centerpiece was the concept of files: Are files (containers
of "sequential bytes of data") obsolete? Does Be pledge a
misguided allegiance to "unstylized" ASCII?
- -----NEW---------------------------
Subject: Filesystem/database thoughts
Re: iozone results
In anticipation of the DR9 filesystem rewrite, many
developers are offering proposals of their own (and hoping
out loud that Be is listening). Too many ideas here to
summarize -- many of the messages were quite detailed --
but the gist of most of the offerings hinged on whether the
filesystem should be "natively" hierarchical or "databased."
In a related thread, a contributor posted the results of the
IOZone benchmark (which measures disk I/O speed). The
results were not glorious, but judgement is being withheld
until the new filesystem appears.
- -----NEW---------------------------
Subject: Database thoughts (not filesystem related)
Some general questions about the database lead to
observations and theories of query performance as the
database swells with records. The highest number of records
reported was 60,000 (with no appreciable performance loss).
Good, as far as it goes, but some folks think billions of
records (2^31) would be a reasonable and practical test.
- -----NEW---------------------------
Subject: Exponential Rolls out X704, etc etc
Some thoughts on the recent announcement of chips that run
at N zillion MHz. Will they fry the user? What will the cost
be after you've added in the requisite memory? Does the
average user even need that much speed?
- -----NEW---------------------------
Subject: caches & CPUs
This thread was spawned from the "Why aren't two threads
better..." affair that started a couple of weeks ago. Here,
we concentrated on how multiple CPUs share the contents of
the individual caches, whether one big cache is better than
many small ones (yes), and, somewhat unrelatedly, whether a
thread can (or should) pass a pointer into its stack to
another thread (not a great idea).
- -----NEW---------------------------
Subject: GUI
This highly speculative thread discussed the
possibility/advantage of a 3D user interface. Would it be
fast enough? Would the user intuitively understand how to
fly around 3D objects? Would it just be a toy? (The answer
to this last question: Yes... but what GUI isn't?)
- -----NEW---------------------------
Subject: Injecting input into the app_server stream
William Adams (the Be Evangelist) solicited specs for event
data that developers would like to "inject" into (and so be
able to detect from) the app_server. Developers responded
and also debated different approaches to various event
detection techniques.
- -----NEW---------------------------
Subject: Fresh Programs
Should programmers concentrate on porting existing programs,
or, instead, take the ideas of the old and rewrite them to
take advantage of Be's "fresh" software? Many folks wrote in
to point out that you have to start somewhere -- porting is
important if you want to get a set of basic utilities up and
running quickly. The thread then veered into scripting.
- -----NEW---------------------------
Subject: A software License Manager Library
AKA: bankruptcy and the keymaster
Some words about protecting your product from piracy, the
desirability of source code escrow, and the pains of
hardware-specific software. This lead to some difference of
opionion regarding the merits of free software. Does "free"
mean "not good enough to pay for?"
- -----NEW---------------------------
Subject: 603e vs DSP
AKA: DSP Performance Comparison
AKA: DSP on the BeBox
The performance of PPC chips was compared to that of
dedicated DSP chips. While it was admitted (in theory) that
DSPs are faster than the PPC, it was generally agreed that
programming a DSP is a pain. Also, one contributor found
that the PPC is actually faster than most (15 out of 19) DSP
chips (see http://www.bdti.com/articles/bench.html).
- -----NEW---------------------------
Subject: Sockets
The thread started with a simple question about select():
Are you limited to 32 sockets because of the 32-bit fd_set
mask? (No.) This led to a discussion of whether Be should
abandon the BSD socket API in favor of an object-oriented
interface (or similar high-level layer). Opinions were
divided: Some folks find the BSD calls clunky and limited,
others think that these calls are here to stay -- why accept
the overhead of a cosmetic layer?
THE BE LINE: The BSD approach was taken to make it easier to
port existing socket code. A higher-level interface is being
consider (time permitting).
|
