|
Be Newsletter
Issue 32, July 17, 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
See you there!
This week: The Be Demo Tour rolls into Austin
for meetings on July 16th and 17th, then moves to the
University of Houston at Clear Lake on July 18th, and
finished up in Dallas on July 20th. For more
information, see our
events
page.
BE ENGINEERING INSIGHTS: The
Brain Explained
By Doug Fulton
The other day a deputy from the Santa Clara county
sheriff's office called and offered to let me help pay for
their effort to keep kids off drugs. A commendable pursuit,
to be sure, but I wondered aloud that is it not in the
*development* of a robust drug habit that the expense is
incurred? "Seems to me..." (I continued, making a fool of
myself to an audience that knew my name and had the
authority to radically curtail the freedoms that were
granted me by the divinity of my choice) ...it seemed to me
that *not* taking drugs -- much like not buying a plane, not
undergoing elective cosmetic surgery, and not travelling
across Europe for a year and a half -- is a leisure activity
that actually makes very little demand on one's disposable
income (or the county's coffers). Had he asked me to help
buy Johnny some crack -- now *that* would make sense.
I didn't take the deputy's unresponsiveness as an
indication that he was necessarily unconvinced by my
confutation; actually, I think he couldn't hear me -- there
was a lot of noise in the background. It sounded like the
hubbub of kids not taking drugs. So I made a suggestion to
him that was presented to me in simile many years ago and
miles away in the Sunday School of a church that has since
burned down:
If you're talking on the phone in such a noisy room that
you can't hear your correspondent, don't stick a finger from
your free hand into your free ear in an attempt to hear
better. Instead, cover the mouthpiece while listening,
uncovering it only to speak.
(The moral side of the simile, easy enough to conjecture
from this description, was something along the lines of, "If
you want to hear what God has to say, shut up." Frankly, I
wasn't all that keen on the ex cathedra angle, but the phone
trick itself I have kept with me to this day. The burned
down church was called First Federated. It sounded like a
bank: "First Federated, where Jesus Saves.")
This method of "room noise rejection" works incredibly
well; the shocking thing is that very few people know about
it. Less shocking (or more, as we shall see) is how it
works. First, the biology:
- The brain is divided into two halves, left and right
(or back and front if you're standing sideways).
- The brain works by firing teeny electrical charges
across the synaptic gap between adjacent neurons.
- Thus, your head is -- almost literally -- a battery
with two chambers, just like in your car. (Except a car
battery has more chambers. That's because your car is
smarter than you.)
What happens when your car battery starts to run down?
You pour water into the little chambers; the higher the
water level, the more electricity the battery can generate.
If it runs dry, it loses its charge. In biology, we call
people who've lost their brain water "airheads."
Back to the phone trick: When you stick your finger in
your ear, you temporarily increase the water level on one
side of your brain -- but it's the wrong side. Furthermore,
while the heightened level actually does improve your
ability to hear, this increase in acuity is tempered by the
fact that, well, you've got a finger in your ear.
Alternatively, by covering the mouthpiece you don't get
any smarter, but you do reduce the amount of ambient noise
that's picked up by the transducer. Remember: Anything that
goes into the mouthpiece ends up in your ear (please don't
quote this out of context). By shutting the room noise out
of the mouthpiece, you improve the listening environment for
your phone ear. The other ear is still assaulted, but your
brain is marvelously adept at listening to one ear while
almost completely ignoring the other, with slight personal
variations due to age, sex, and whether you live in Santa
Clara.
If you want to perform further experiments on your brain
you can use the GeekPort(TM). In Developer Release 8 of the
BeOS, we will introduce new classes that let you access the
GeekPort's eight channels of analog-to-digital and digital-
to-analog conversion (four channels each way) and the two
digital data ports. The classes, which are part of the
Device Kit, are called BA2D, BD2A,
and BDigitalPort. The methodology (and API) for
objects of these classes is quite simple: You open a
specific channel or port, sit in a loop that reads (or
writes) a series of values (one access per device per loop
turn), and then, when you're through, you close the object.
It's fast, simple, and inexpensive. Of course, if you
want customized documentation (with your name and those of
your children worked into the code examples), you may have
to pay a bit more. You see, I'm thinking of not taking a
mistress and not keeping her in a pied-a-terre overlooking
San Marino, which I would then not visit a couple of times a
month. I'm not sure how much it's going to cost to keep
myself from doing it, but the meter is running.
BE DEVELOPER TALK: Hugo
Fiennes of The Serial Port
By Hugo Fiennes
E-mail:
altman@cryton.demon.co.uk
I started my company, The Serial Port, in 1988 to sell my
first communications package, ARCterm 6. This was one of the
first such packages for the Acorn machine. It had all the
usual things: x/y/zmodem, scripting, vt100/ansi/viewdata
(videotex), and so on. Although it never caught on in
America, the Acorn machine is used all over Europe (and
beyond). It's mostly for educators and enthusiasts, so the
market isn't big, but it's devoted, and for a software
developer that isn't in it just for the money, the size is
nearly ideal -- it's large enough to support a small
company, but still small enough that an individual developer
can change the way the machine is used.
In developing for the Acorn I've seen ARCterm and my
other products -- terminal-emulation and file-transfer
packages, telnet and rlogin clients, fast serial cards --
used in universities from Germany to New Zealand. They've
even found their ways into companies such as Sony, Eidos,
and others. Nowadays, I just develop products that other
companies (currently ANT Ltd. and Atomwide Ltd.) resell.
I was delighted when I heard about Be. This is a concept
that took some nerve, going out on a limb and making a dream
machine -- companies ruled by accountants don't do that.
Technically, the machine is nearly perfect for
communications applications; it's a multiprocessor machine
with oodles of I/O. And it supports a familiar programming
environment: Metrowerks' IDE and the bash shell -- in other
words, both GUI and the command line!
I've only had my BeBox for a short time, but hopefully a
beta version of my ANTterm will be out soon. The actual
terminal works fine, but the dialogs are far from pretty. As
soon as a UI-building tool appears for the BeBox...
As soon as I have time, I plan on putting in some serious
play time on the BeBox. Then I'll see what's needed and,
with luck, help move the machine into markets that I'm
familiar with.
BE MARKETING MUTTERINGS
By Alex Osadzinski
"Bundling" is one of the most emotive words in the
computer business. During what passes for my career, I've
seen grown men, and even a few grown women, reduced to
incoherent anger by the topic, and I've witnessed a CEO
become so impassioned by the subject that he climbed onto a
conference room table to be able to better shake his finger
in somebody's face (mine). Fortunately, Be's fearless CEO is not
prone to table-climbing (at least not yet), so we can have
rational discussions about bundling.
There are two aspects to bundling: Software and hardware.
I'll cover software in my next mutterings (thus relieving me
of the agony of deciding what to write about in two weeks'
time). Software bundling is even more emotive than hardware,
so let's work up to it gradually.
Bundling is a popular technique because it allows a
vendor to combine high- and low-margin products into a
package in which it's very hard for the customer to
determine how much he or she is paying for each component.
When bundling is coupled with manufacturers' dire warnings
of the consequences of using "unapproved" third-party
components, resulting in voided warranties, the customer may
justifiably feel manipulated and, worse, ripped off. The bad
old days of paying five times the market price for, say, a
disk drive or a memory board in order to obtain the
manufacturer's seal of approval are (almost) over, but
bundling continues to be a common industry practice.
The strongest theme at Be is "break with the past"; this
theme extends beyond writing a new o/s and creating a new
desktop platform, into business models. We offer our
hardware as unbundled as we can make it: Developers, and
soon end-users, can buy BeBoxes with no peripherals at all.
We offer only two configurations today: Bare bones and fully
configured. Although we plan to add a small number of memory
and disk size variations later this year, we're trying to
avoid, for now, multiple disk/memory/CD/graphics/networking
permutations because they make manufacturing and logistics
complicated, which translates into higher costs and higher
prices. In unbundling our hardware this way, our customers
can easily figure out how much profit we're trying to make
on memory, disks, and other peripherals. The answer, not
surprisingly, is very little. The result has been that most
of our customers to date have ordered fully configured
machines.
A paradox, perhaps? By unbundling hardware we have
created a situation where most people prefer the bundled
solution. I prefer to think of it as freedom of choice at
work. The hardware unbundling scheme seems to be working
fine for us and for our customers. An additional observation
is that we have observed few, if any, problems resulting
from customers configuring their machines with parts that
they've obtained on the open market. Whether this is because
of tolerant hardware design on our part or increasing
standardization and quality of widely available components
is irrelevant. The point is that it works just fine.
The A behind the V
By Jean-Louis Gassée
The V of DVD, that is. For us at Be, DVD (Digital
Versatile Disc) holds much promise. As it breaks
strangleholds and suggests new applications, it represents a
good vehicle for a new entrant such as ourselves. As usual,
glowing predictions are made for the new medium and, as
usual, the grand new applications will need more time than
expected. Still, technical difficulties and confusion over
standards notwithstanding, the promise of 8 or 16 times the
capacity of today's CDs backed by the best high-tech and
entertainment conglomerates in the world is guaranteed to
succeed. Most of the salivating is over video applications
-- a movie on a CD. The stamping cost is less than
duplicating a tape, the format is more convenient, pirating
is difficult, and it sells new consumer electronics devices.
Life is good. (Or will be -- the manna hasn't fallen from
the heavens yet.)
If DVD is a vehicle for Be, on what bahn will we do our
driving? Shovelware, sometimes politely referred to as
"repurposing," holds little opportunity for us. We've seen
it on CD-ROM, we'll see it on DVD as well. We're more
interested in two arenas: Games and audio.
Ask fanatical MYST players if they'd like richer imagery
and plot. Ask Sony and Sega if they'd like to take a nice
bite out of Nintendo's business. Nintendo has made a
"courageous" (some say imprudent) bet on cartridges. Sony
and Sega might use DVD in versions of their game consoles as
a way to further the momentum they've gained as the
cartridge-based Nintendo Ultra 64 is delayed. We already
intend to cultivate game-authoring applications, a genre our
product serves well. DVD, when it becomes a game medium,
will make the opportunity better as it will demand more
bandwidth and better programming tools.
And then there's audio. Somehow CDs failed to deliver the
promised nirvana of audio. Far from a fixative, the crisp
clean CD experience generated a whole audiophile industry
bent on fixing the aural blasphemies of digital sound. And
so we had hilarious discussions of the audio artifacts of
cables, oxygen-free copper, and propagation-enhancing
crystalline microstructure for better resolution. Or the
mellower sound of tubes, with a Chino-based company, Vacuum
Tube Logic, charging a premium for esoteric triode-tetrode
switching.
Behind this excess there's opportunity: Higher resolution
and multitrack sound. Today's home theater sound is simply
tarted-up stereo using decades-old gimmicks that extract
spatial information that's fed to a third, a fourth, or even
a fifth speaker. Higher resolution (20-bit) sound will make
the discerning listener happy (or at least happier). Three
(or more) real, independent audio channels will yield novel
sound experiences in movies and concerts. Of course we'll
have to sit through the "mind blowing" dog and pony demos at
first, but just as with stereo 40 years ago, the gimmicks
will yield to comfortable and intelligent uses, and the
phenomena will stabilize to become a fact of life in homes
and cars.
Audio applications are already friendly to the BeBox.
Higher resolution and more channels will help us
differentiate ourselves against aging platforms. Demand
won't be small: Video may stand at the forefront of the new
medium, but we spend more time listening to music than
watching videos.
A final word of caution: These new audio applications
won't be settled in the next 18 months. In the meantime,
we'll happily help make music for today's CDs, with or
without vacuum tubes and monster cables.
BeDevTalk Summary
Most of the old threads died last week, probably because
nobody did anything except post to the "App names" and
"First experiences" threads. An astonishing amount of mail
passed through these two threads in the last ten days or so.
To subscribe to BeDevTalk, visit the mailing list page on
our web site:
http://www.be.com/about_be/mailinglists.html.
- ---WEEK
3-------------------------------------
Subject: Write a mailer!
This thread came back last week to flirt with the
subject of drag-and-drop. It was contended that Be's
d'n'd facility could be better; for example, the source
(app) for a drag isn't informed where the dragged icon
was dropped.
- ----WEEK
2-------------------------------------
Subject: What about the desktop?
More suggestions for organizing and storing icons
in/on/under the desktop.
- ----NEW----------------------------------
Subject: Packaging App
Strategies for installing and uninstalling apps that
bring a multitude of collateral files. Should the
dispersal of such files be limited? Should there be an
Amiga-like "Assign" approach (in which an application
modifies system variables in order to tell the system
where its resources are)?
- ----NEW----------------------------------
Subject: App names
The "App names" thread began with a simple and
seemingly innocuous question: What are the four-byte
application signatures for? The quick and easy answer (so
apps can be identified -- in order to receive messages,
for example -- by the Browser and other apps) raised some
new questions (and unburied a number of gnawed-on
tibiae):
- Is the type/creator identification "good" enough?
It's numerically sufficient, but should it be human
readable? Should Be use MIME types instead?
- Should there be an explicit versioning system?
- Given an imported file, how should its type be
determined? Should the user have to drag the icon onto
an app in order to set the creator info?
- Given an existing recognized file, should there be
tools for setting the application that will open it by
default? Should the user be able to specify an
alternate opener? Should these tools be part of the
Browser? Preferences?
Everyone seems to have a strongly held opinion, here.
Some people have two or three conflicting opinions, no
less strongly held for that.
- ----NEW ----------------------------------
Subject: First experiences
Second only to the "App names" thread in volume of
participants, this thread wasn't about how to use the
box, but how to turn it off. Specifically, should Be
provide ephemeral disk synchronization and database
integrity assurance in order to obviate the "shut down"
process, and would this make everything else slower?
Horizontally, should the user be prompted to save "dirty"
files, or should, perhaps, the unsaved data be stored and
retrieved at the next session?
- ----NEW----------------------------------
Subject: Speaking of PostScript...
A/K/A: File Format
Document-type identification and translation. It was
suggested that Be provide a system-level data translation
mechanism. This way, if you receive data (in e-mail, for
example) that has a recognized type, but for which you
don't have a reader, you can ask the system to translate
the data into a type that you can read.
- ----NEW----------------------------------
Subject: Help me argue for the BeBox
Why should anyone choose Be over WinNT 4.0? A number
of flattering reasons.
|
