|
Be Newsletter
Issue 58, January 29, 1997
Table of Contents
Be Demo Tour: Canada and the Comdex / IT Forum in Paris
- February 3-7, 1997
Comdex / IT Forum, Paris
February 3-7
Paris Expos
Hall 1, Booth T93
Porte de Versailles
75015 Paris, FRANCE
Come with your friends and see the latest demos running on
the BeOS!
For more information on this event, please contact
Christophe Droulers at droulers@beeurope.com.
- February 5-6, 1997
General BeOS Demo Meetings in Ontario, Canada
University of Waterloo, Ontario, Canada
Hosted by the Canadian Be Users' Group, "Be Yourself."
The William G. Davis Computer Research Center building at
the University of Waterloo, Ontario, Canada
Rooms 1301 and 1302 in the center of the building on the
main floor.
February 5
2:30 pm -5:30 pm
Private meeting for registered Be Developers in the area.
Room 1301
6:30 pm - 9:00 pm
General BeOS Demo Meeting. Open to general public. Time for
technical and general questions.
February 6
2:30 pm - 6:00 pm
General BeOS Demo Meeting. Open to general public (for those
who can't make it on Wednesday or who want to see the demo
again). Time for technical and general questions.
For more information, visit
http://www.doublep.com/events/be/
European Be Developers' Conference '97 in Paris
On February 21-22, 1997 the Be Europe team is happy to
invite you to the European Be Developers' Conference '97 in
Paris. All developers are welcome to attend this event. The
meeting will be held at:
Palais des Congres de Paris
2 place de la Porte Maillot
75017 Paris, France
Doors open at 2:00 pm on Friday and remain open until
Saturday afternoon. The agenda is still under construction,
but the goal of this conference is to:
- meet the Be Europe team
- meet some Be US engineers
- discuss upcoming DR9 features
- see the latest demos running under the BeOS
- chat with other Be developers
- show off your latest code
- learn about our goals for 1997
If you can come, please confirm your attendance by sending
e-mail to Christophe Droulers (droulers@beeurope.com) before
February 14.
We look forward to seeing you there!
BE ENGINEERING INSIGHTS: Fastmath and fastmem are in a boat.
Libmoto falls into the water... Who's left?
By Pierre Raynaud-Richard
By now most of you have an idea of the main points of the
huge DR9 feature list. But I'll not write about the new file
system, the new Tracker, or any of the other big subjects.
Today, I want to add my 5 cents to a topic that's a tenured
member of the list of release features: Improving
performance.
One of the performance-enhancing tonics that, until now, had
to be applied as an "extra" was libmoto. Available from
Motorola, libmoto is an extremely optimized library of
memory, math, and string functions, written in PowerPC
assembly language. In DR9 we'll integrate libmoto into the
standard package, at which point everybody should be able to
use it.
Libmoto is good -- but is it really as fast as possible?
Does it give you precisely what you need? Is it overkill,
particularly with regard to floating-point precision? In
short, can we do better?
At Be, these questions posed themselves as we worked on two
specific problems: Basic 3D calculations for the 3D Kit and
the compatibility between our drivers and the set of memory
functions (memset(), memcpy(), and so on). The result: New
"fastmath" and "fastmem" libraries.
FASTMATH
The idea behind fastmath is that many programs don't need
the high precision and full-range definition provided by
standard math libraries such as libmoto.
Controlling precision in a general way is a difficult
problem. At the high end, you have people doing scientific
calculations: For them, the utmost precision is necessary.
They know that even a tiny round-off error propagated
through a system can render a calculation meaningless. To
avoid excluding such scientists, math packages are all
defined in double precision and go to great lengths to
maintain accuracy.
On the other hand, if you're processing audio samples or
performing 3D computation for image rendering, you don't
require scientific precision. An error of, for example, less
than 1 in 10,000 will be lost in the noise of the
pixelization process. And an error of less than 1 in 100,000
means nothing to a 16-bit audio sample. In many cases,
programmers could easily use math functions with an error of
1/1,000,000 (within the range [ -1 ; +1 ]). It's clear that
double-precision, floating-point calculations are
unnecessary for such operations.
If you find yourself in this bargain basement -- where, for
example, a sine or square root that's accurate to within +/-
.000001 is good enough -- then you should use the fastmath
library. Therein you'll find the following math functions
(the ">" mark designates the "most optimized" function(s)
within a group):
- Cosine and Sine
> float b_cos_90(float radians)
float b_cos(float radians)
float b_sin(float radians),
void b_get_cos_sin(float radians, float *cosine, float
*sine)
b_cos_90() is the fastest trig function: It achieves much of
its speed by restricting the input range to [ 0.0 ; PI/2 ].
In other words, it's only defined for angles up to 90
degrees. Using the symmetries of the cosine curve, you can
translate the returned value for any angle, or you can use
one of the other functions, which are based on b_cos_90()
but don't carry the input range restriction.
- Tangent and Arctangent
> float b_tan_45(float radians)
float b_tan(float radians)
> float b_atan_1(float value)
float b_atan(float value)
b_tan_45() is defined for angles in the range
[ 0.0 ; PI/4 ].
Actually, you *can* go further -- as far as PI/2 -- but the
relative error becomes quite significant as you approach
this limit.
b_tan() doesn't restrict the sign of the input, but it
doesn't fix the growing error problem -- its effective range
is [ -PI/4 ; PI/4 ].
Analogously, b_atan_1() and b_atan() retrieve arctangents
for the range [ 0.0 ; 1.0 ] and for unbounded values,
respectively.
- Square Root and Inverse Square Root
> float b_sqrt(float value)
> float b_sqrt_inv(float value)
The square root functions are defined for any value > 0.0.
I've listed some benchmarks and error approximations for
these functions at the end of this article.
One big advantage of the fastmath library is that all
functions are short C-code functions, and so can easily be
inlined for even better performance.
If you're interested in getting a preview version of
fastmath (the header file only; this includes the code for
the inline functions), or if you want to help us extend our
support or optimize our code even more, contact
pierre@be.com.
FASTMEM
The motivating force behind fastmem is the existence of the
"data cache block" (DCB) instruction set provided by the
PowerPC architecture. The DCB instructions give you greater
control over the data cache, so you can optimize the way the
cache is loaded and fetched. In particular, these
instructions let you preload data and fetch a cache line
without reading it first.
But to use this advanced control, you need to work with
cacheable memory. Unfortunately, not all memory can be
stuffed into the data cache; for example, you can't take the
frame buffer of a graphic card and load it into the cache.
The standard memory functions (memcpy(), memmove(), and
memset()) use the DCB instructions, thus they can't be used
for noncacheable memory.
The fastmem functions provide "cache-specific" memory
operations. Within the library you'll find that the
standard functions work as usual (they copy, move, and
initialize memory), but they *only* work for cacheable
memory.
The "nonstandard" fastmem functions work on noncacheable
memory:
memcpy_nc2c() copies data from noncacheable to cacheable
memory
memcpy_c2nc() copies from cacheable to noncacheable
memcpy_nc2nc() copies from noncacheable to noncacheable
memmove_nc() copies between interleaved buffers in
noncacheable memory
memset_nc() initializes a buffer in noncacheable memory
One restriction of fastmem is that you *must* choose the
proper function; the standard memset() call, for example,
won't work on noncacheable memory. (Actually, the functions
memcpy_nc2nc(), memmove_nc(), and memset_nc() will always do
the right thing, even if the targeted area is in cacheable
memory -- but they will be quite a bit slower than the
analogous memcpy(), memmove(), or memset() call.)
This might sound a bit complicated -- how do you know if
your memory is cacheable? In general, only drivers need to
access noncacheable memory; "normal" applications only
manipulate cacheable memory. (In the BeOS, an exception to
this is applications that use the Game Kit to access the
screen.) If you don't know if you're using noncacheable
memory, then you're not.
With regard to the characteristics of the memory buffers
themselves:
- Buffer sizes. Although the overhead for copying small
buffers should be reasonable, you may want to copy small
buffers (up to 64 bytes) by hand.
- Alignment. The fastmem functions can handle any alignment
of data, but you should try to get your buffers aligned to
8-byte or, at the least, 4-byte boundaries.
The fastmem implementations are designed for speed, but we
could probably squeeze a few more cycles out of them if we
really needed to, particularly for nonaligned buffers.
FASTMATH BENCHMARKS
The following tests were performed on the five main
functions only. The input set was a random suite of
10,000,000 samples within the functions' defined ranges.
[Note: You may want to use a fixed-width font to view the
table in this section.]
We ran the tests on four different machines using four
different processors:
Machine CPU Speed
BeBox(TM) 66 603 66 MHz
BeBox 133 603e 133 MHz
PowerCenter 120 604 120 MHz
PowerTower 225 604e 225 MHz
Legends:
L = libmoto
F = fastmath
I = inlined fastmath
The score x.xxx is a measure of the operations per
microsecond
BeBox 66 BeBox 133 Power 120 Power 225
b_cos_90 VS cos:
L: 0.668 1.188 2.036 3.939
F: 2.219 3.721 5.398 10.161
I: 3.613 5.371 6.612 12.331
b_sqrt VS sqrt:
L: 0.490 0.873 1.324 2.518
F: 1.130 2.243 2.192 4.178
I: 1.262 2.481 2.349 4.516
b_sqrt_inv VS (1.0/sqrt):
L: 0.384 0.689 0.952 1.807
F: 1.129 2.239 2.184 4.188
I: 1.263 2.487 2.345 4.502
b_atan_1 VS atan:
L: 0.542 0.972 1.890 3.652
F: 1.686 2.936 3.244 6.173
I: 2.002 3.273 3.601 6.858
b_tan_45 VS tan:
L: 0.278 0.528 0.659 1.250
F: 1.008 1.811 2.351 4.481
I: 1.150 1.936 2.532 4.864
FASTMATH ERRORS
Here are reasonable estimates (not the theoretical values)
of the maximum, average, and average absolute errors for the
5 "most-optimized" fastmath functions, within their usable
ranges.
Notes:
- e-6 stands for 0.000001
- "error in absolute value" means the error is relative to a
restricted range that's peculiar to the function; for
example, for cosine the range is [ -1.0 ; 1.0 ]. Any
be_cos() call will return a result that's within 0.000000536
of the "real" answer.
- "error in relative value" means the error is relative to
the result of the computation. Consider the call
b_sqrt(1e12) // square root of 1000 billion
The real answer is, of course, 1,000,000. But the
result will be in the range
[ 999,998.314 ; 1,000,001.686 ]
Now consider this call:
b_sqrt(1e-12) // square root of 1/1000 billion
The answer is .000001, and the result will be in the range
[ 0.000000999998314 ; 0.000001000001686 ]
b_cos_90 (error in absolute value):
- maximum: 0.536 e-6
- average: 0.046 e-6
- average absolute: 0.125 e-6
b_sqrt (error in relative value):
- maximum: 1.686 e-6
- average: -0.160 e-6
- average absolute: 0.184 e-6
b_sqrt_inv (error in relative value):
- maximum: 1.686 e-6
- average: 0.160 e-6
- average absolute: 0.183 e-6
b_atan_1 (error in absolute value):
- maximum: 0.656 e-6
- average: 0.030 e-6
- average absolute: 0.123 e-6
b_tan_45 (error in absolute value):
- maximum: 1.013 e-6
- average: 0.052 e-6
- average absolute: 0.159 e-6
FASTMEM BENCHMARKS
We compared the fastmem functions to our old code as well as
to the latest version of libmoto (where possible; libmoto
doesn't handle writing into noncacheable memory).
The tests played by these rules:
- We set up a 4 MB cacheable area and a 512 KB noncacheable
area as the source and/or destination.
- The tests were run on buffers ranging in size from 8 bytes
up to 256 KB.
- We tested aligned and unaligned buffers. For aligned
buffers, we stuck to 8-byte alignments, but we used all four
such alignments within 32 bytes (keep in mind that a cache
line is 32 bytes long).
- So that we wouldn't be affected by a warm cache, we
trashed both L1 and L2 after each test.
- We also tested a mix of
memmove() offsets, from
-(buffer_size-1) to +(buffer_size-1). Each size was tested
for a total of 10 MB, in standard operating conditions
(restart from scratch and then run only the test program).
The machines and their characteristics:
Machine CPU Speed Bus Graphic Card
BeBox 66 603 66 MHz 33 MHz fast PCI
BeBox 133 603e 133 MHz 33 MHz standard PCI
PowerCenter 120 604 120 MHz 40 MHz on-board
PowerTower 225 604e 225 MHz 50 MHz fast PCI
The numbers presented come from the average for buffers
between 2 KB and 128 KB, removing the best and the worst
measure. Everything is mixed with a noise of +/-1 percent.
Legends:
O = old library
L = libmoto
F = fastmem
The score aa.a (uu.u) is the bandwidth in MB/second for:
aligned case (unaligned case).
BeBox 66 BeBox 133 Power 120 Power 225
memcpy:
O: 15.3 (10.0) 17.6 (15.8) 19.8 (14.8) 27.6 (21.3)
L: 16.2 (13.6) 20.5 (17.7) 31.6 (25.9) 37.2 (35.0)
F: 20.8 (17.3) 27.0 (25.6) 30.5 (29.3) 37.1 (36.7)
memcpy_nc2c:
O: 5.8 ( 0.9) 4.4 ( 0.9) 16.8 ( 3.5) 8.0 ( 1.2)
L: 3.5 ( 1.9) 3.8 ( 1.9) 13.6 ( 8.7) 5.0 ( 2.9)
F: 6.3 ( 5.2) 4.7 ( 4.5) 27.5 (19.3) 11.1 ( 8.7)
memcpy_c2nc:
O: 16.1 ( 3.0) 19.1 ( 3.4) 25.1 ( 5.3) 29.6 ( 4.3)
F: 17.1 (15.9) 19.1 (18.3) 25.1 (23.8) 29.7 (29.4)
memcpy_nc2nc:
O: 5.7 ( 0.7) 3.9 ( 0.7) 15.5 ( 1.9) 7.6 ( 1.0)
F: 5.9 ( 4.8) 4.2 ( 3.8) 16.8 (13.5) 8.5 ( 7.7)
memmove:
O: 18.7 (17.5) 20.7 (20.7) 29.6 (29.3) 37.8 (36.5)
L: 17.7 (15.0) 22.4 (20.6) 31.4 (29.3) 38.2 (37.5)
F: 21.7 (17.8) 27.4 (26.6) 32.3 (31.9) 40.1 (39.5)
memmove_nc:
O: 3.0 ( 2.9) 2.8 ( 2.8) 8.7 ( 8.7) 4.2 ( 4.2)
F: 5.8 ( 4.8) 4.3 ( 3.8) 19.4 (14.6) 8.5 ( 7.5)
memset:
O: 21.3 (21.2) 25.0 (24.7) 32.1 (32.1) 41.1 (41.1)
L: 35.6 (35.3) 39.4 (39.3) 75.9 (75.7) 86.3 (86.2)
F: 35.7 (35.4) 39.4 (39.2) 76.2 (75.8) 86.5 (86.1)
memset_nc:
O: 6.5 ( 6.5) 7.0 ( 6.9) 11.8 (11.8) 8.7 ( 8.7)
F: 25.8 (25.6) 25.1 (25.1) 47.3 (47.2) 30.4 (30.2)
Comments:
- libmoto has been optimized especially for the 604 and
604e; fastmem isn't dedicated to a particular CPU. We
compromised to get good performance on every processor.
Perhaps later we'll have processor-specific libraries: With
604-dedicated code, we'll be able to get the same
performance as libmoto for the
memcpy() on the PowerCenter
120 (the only case where libmoto really outperforms the new
library).
- The test for
memmove() used interlaced buffers only, while
memcpy() used noninterlaced buffers. Because of this,
memmove() always appears to be faster than memcpy().
For all remarks, contact: pierre@be.com
News from the Front
By William Adams
So I was sitting around trying to think of an appropriate
irrelevancy to satisfy George's funny bone this week, and I
came up with the following.
My wife and I are pretty cheap, I guess. We bought a book to
show us how to make things like silly putty so we wouldn't
have to go out to the store and buy silly putty. The
commercial version of silly putty is a nice, evenly textured
smooshable plaything that provides countless hours of fun
for the little ones.
The home-brew variety consists of flour, salt, and tartar
sauce of all things. Who would think that such a strange mix
of ordinary ingredients could provide so many countless
hours of fun for the tots.
Putting together an operating system is much like putting
together silly putty. You have a bunch of boring ingredients
like device drivers, interface kits, memory management, and
schedulers, but properly combined, they can create a product
that's loads of fun.
The BeOS is like silly putty to me. I'm telling you, it
makes me giddy with excitement just seeing the amount of
work that developers are putting into their applications. It
is a sure indication that they love what they're doing and
probably laughing while they're doing it.
Now that quite a few new developers have received the
MacTech CD and made it through the installation filter, we
receive mail every day to the effect of: "Now that I've
tried the BeOS, going back to the Mac OS seems silly."
More than a couple of developers I know are moving to
California from parts unknown so that they can be closer to
the action. I like to imagine it's because they want to be
closer to the person who provides them with interesting
stories and code samples, but I think not.
One developer I know was invited to show their wares before
5 broadcasters, that is, people who own broadcast stations.
They were sufficiently impressed that the developer was
invited to a certain ranch of a space-faring family.
I also see that our ftp site is continually chock full of
new entries and updates to old ones. One of the more amusing
and powerful ones I think is myBrowser. This is a browser a
la NEXTSTEP and it works quite well. It even does some nifty
things that our Browser doesn't. Additionally there's a new
Python 1.4 port for those in the know, and we've put out our
latest version of NetPositive. There's even great progress
on a native X server of all things!
Well, that's a mouthful for any platform, and even more so
for this particular one, considering we haven't hit our 1.0
release yet. Speaking of which. Before getting to 1.0, we
have to go through the DR9 transition. Our general plan from
a Developer Services perspective is to get ourselves boned
up on the new stuff and have plenty of samples and porting
guides in place such that a developer's transition will go
as quickly and smoothly as possible.
For this release, we still won't be able to do much of a
prerelease before the general release goes out, so you won't
be able to compile your apps before DR9 hits the streets.
But I'm wondering if it would be beneficial to port a couple
of the apps ourselves before DR9 goes out so there's at
least something to play with in the first couple of weeks,
before everyone in the world recompiles.
At this point I'm really just taking a poll, but if you
would like to have us recompile your app for DR9 before DR9
shows up, send me a message and we'll see how much interest
there is. Besides, our new Developer Services staff needs
some way of coming up to speed, don't they?
Well, after much code wrangling last week, the 3dmov and
Bt848 binaries made it out the door. They seem to have made
quite a splash with the general community and have plenty of
people taunting their friends with "Can your OS do this!" So
to continue, we have two pieces to release this week. One is
a new Storage Server that Benoit put together to solve a
startup indexing problem, it can be found at:
ftp://ftp.be.com/pub/dr8_update/storage.tgz
The other is the source to the CDPlayer application:
ftp://ftp.be.com/pub/samples/media_kit/obsolete/cdplayer.tgz
The source for the CDPlayer will show you how your
application can interact with the CD-ROM drive to play
music. It will not allow you to create a driver to support
any new CD-ROM devices, that driver is compiled into the
kernel. But it will show you how to control the CD for your
own purposes.
Additionally, Geoff Woodcock has produced the first fruit of
his Be labors. There is a new tutorial on-line for the
January application. For those who don't know, this little
application is like a HelloWorld for graphics applications
on the BeOS. Geoff was a bit concerned that all he has done
in the three weeks since he joined Be was staff the Macworld
booth, help customers, and write a tutorial. I'd say he's
doing all right so far.
Well, enough rambling. I can't wait for the arrival of DR9
so that I can start pounding my drum again telling people to
port because there are so many neat new things to play with.
BE MARKETING MUTTERINGS: Goals, Goals, Goals
By Alex Osadzinski
In what passes for my career, I've worked for tiny companies
and intergalactic companies; it's been interesting to
examine the similarities and differences between them.
Something that all companies share is a planning process,
albeit with varying degrees of effort. At one company I
worked at, I had the honor of being the VP in charge of
planning one year; the process took three months and
involved a full-time team of around 20 people. Come to think
of it, maybe it was a punishment rather than an honor. The
outcome of the planning process was, of course, a plan,
resplendent in its three-ring binder and sets of goals for
everyone in the company. At the lofty VP level, the
combination of corporate, business unit, functional,
geographic, and personal goals created a list of around 150
things to do that year, ranging from gargantuan tasks on the
order of "Conquer Asia and dominate the market there" to
smaller, although truly horrendous tasks like "Attend group
sensitivity training (3 days, off-site, ropes course
included)." One fervent planner published books entitled
"Goals, Goals, Goals" listing individuals' goal lists. This
wasn't a joke. And of course the last three months of the
year were spent collating, justifying, and groveling, to
ensure credit for as many of the 150 or so goals as
possible, in order to receive A Very Large Check.
We don't do planning this way at Be.
Given that much of planning is numerology and internal
discussions are typically increasers of entropy, we don't
waste a whole lot of time on microanalysis. Rather, we try
to listen to what our customers (currently mostly
developers) say and to react accordingly. Also, as a small
company with limited resources, we have to stay very
focused: There are many more things that we could do than we
have the ability to do.
So, what's our plan for 1997?
We have three goals, and they're known to, and shared by,
everyone in the company. The first two goals are:
- Deliver the first "user-ready" version of the BeOS
- Get the BeOS into the hands of as many potential users as
possible
However, the real meat, and what the first two goals are
designed to support, is:
- Encourage and help the development of BeOS applications
Sure, there are numeric goals associated with these and, of
course, we have budgets to live within. But those three
goals are what we're focusing on this year.
There are two virtuous circles embodied in these three
goals: One is that a great BeOS product enables great
applications, which in turn provide the impetus to improve
the BeOS. The other is that great applications result in
more seats for the BeOS, which creates even greater momentum
for more applications. We're very aware that virtuous
circles can oh so easily become death spirals, and we know
that our job is far from done.
What are the implications of our goals for our customers,
particularly for our developers?
First, we'll be rolling out the Preview Edition of the BeOS
in a few short months. This will be the first generally
available public release of the product and will pave the
way for the first "user-ready" release later this year.
Vague dates, eh? Yes, but we try hard to underpromise and
overdeliver and, when we don't know the exact answer, not to
make one up.
Second, we'll be making it really easy and painless for
people to get their hands on the BeOS Preview Edition. As
you may know, Power Computing will be bundling this release
with most of their machines; that's one of the very easiest
ways to get the BeOS. We'll try to make it almost as easy
for buyers and existing owners of other Power Macs.
Third, we're continuing to beef up our developer services
(aka developer support) and evangelism teams, whose mission
in life is to help developers get their apps shipped.
1997 is a very important year for us and our developers. In
1996, thanks to the kindness of the media and the enthusiasm
of our many supporters, we made a lot of people aware of our
existence and what we're trying to do. We also saw the first
BeOS apps emerge, and that was a very exciting set of
events. In 1997, we're relying on that continued support to
get us to the point where users begin to do real work on the
BeOS, running some of the existing and forthcoming
applications. We'll definitely do our best to play our part,
and we're all pretty excited about what can happen this
year.
Why Do We Pay Attention to Japan?
By Jean-Louis Gassée
Why do we pay attention to Japan?
Coincidence or not, I was asked this question several times
in the past few days. As we make preparations for Tokyo
Macworld, I'll use this opportunity to offer our perspective
on Be's involvement with Japan.
There are many aspects to it. Let's start with customers. Go
to the Laox Computer store in the Akihabara (all things
electronic) district of Tokyo. There's a magazine section on
the ground floor. At 5 pm, high-school and college students
are standing four deep at the racks, reading the US and
Japanese computer magazines. There's a large, active techno-
nerd, geek, propeller-head population in Japan, just as in
the US and Europe. And contrary to a persistent legend,
there's an appetite for US hardware and software products in
Japan. The Macintosh sells well, the Amiga still has a
following, PC makers such as Compaq enjoy very good business
there and, of course, Bill Gates receives the immense,
somewhat fearful respect accorded to quasi-divine creatures.
The BeBox and the BeOS have been granted an initial warm
reception, many magazine articles have been published, web
sites are dedicated to our products, and Fumihiko Shibata,
noted magazine editor, just published the first BeBox Guide
Book in Japanese (ISBN 4- 89369-490-1).
We're very happy, and we're concerned. Many Western
companies have floundered because they took the Japanese
customer for granted, failing to pay the local custom, the
local ways of doing business, the respect that generates a
trusting relationship necessary for any business to grow
beyond the novelty stage. Beyond the early adopters who read
enough English and accept the US version of a product, a
great deal of detailed work is required for us to offer a
product fit for broader consumption in Japan. And we need to
find the right partnerships that would guarantee the
Japanese customer the continuity, the level of service, the
overall comfort they are entitled to.
With 400,000 to 500,000 PowerPC machines sold yearly in
Japan, the market more than justifies the extra effort. But
there's more than market size. It seems that Japanese
customers are, on the average, more interested in multimedia
applications than are customers in other Western markets,
where personal computers are predominantly office automation
machines. Our product, focused on creative digital media
applications, fits nicely with the multimedia bias in the
Japanese market. And where do the new DV cameras or the DVD
units come from?
This leads me to developers. There has been a tendency to
stereotype Japan as less individualistic than, say, Silicon
Valley and therefore less creative. Large bureaucratic
keiretsus leave no room for entrepreneurs. Add a different
writing system and the sum is: No Japanese PC software
developer success stories. As for the lack of creativity,
this is absurd. Look at the arts. Same for the lack of
entrepreneurs. Small businesses flourish everywhere, their
styles are different. Actually, less and less so. To the
more worldly Japanese software entrepreneurs we offer a
"born on the Web" distribution model yielding instant access
to the rest of the world. And when we have a properly
localized and supported product, our platform will play well
to the natural trends of the Japanese market. Speaking of
success stories, we'd love to be part of one relating how a
programmer in Kobe sells his digital video editor to BeOS
users worldwide.
We can't help it, we like Japan. We would immensely enjoy
doing a decent job in this very different, very attractive
market. This might not be the most rational of motives, but
liking one's customers can't hurt.
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.
CORRECTION: In last week's BeDevTalk summary, Marco
Nelissen's name was given as "Marc". We apologize to Mr.
Nelissen for the mistake.
- -----WEEK 2---------------------------
Subject: Thoughts on Fragile Base Class problem.
AKA: The FBC
AKA: FBC problem
AKA: Be's FBC hack won't work
[and others...]
Here we pat Be's fragile base class solution (reserved
functions and library versioning) on the head and cuff it
about the ears. The pro and con philosophies go something
like this (con first):
- Some folks think that since a real solution will be needed
someday anyway, it's better to suffer the pain of the
adoption now (and everyone admits that the pain will be
substantial) rather than after the first commercial release
of the OS.
- Proponents of Be's "hack" solution point out that the
problem may be more theoretical than practical: A
theoretically pure and elegant FBC solution provides more
backward compatibility than anyone needs; better to have a
lightweight, if homely, solution (intramajor release
compatibility) since advances in feature set alone will
necessitate a rewrite every couple of years.
There's also a middle position: It would be nice to have an
elegant FBC solution, but there's no such thing for C++. You
can have the language or you can have robust base classes,
you can't have both. This argument spawned
COM/SOM/Objective-C comparisons.
Some technical questions and observations:
- -----NEW---------------------------
Subject: GUI (in)consistency
AKA: Applications without windows
AKA: Let's move out the main menu f
AKA: Application start-up and take-down time
Various opinions about matters GUI: Menus, menu bars, the
dock, (potentially) windowless apps, and so on. Some
specific topics:
- Should ALL of an app's menu items appear in the same place
-- that is, either in a menu bar *or* in the main menu (or
both)?
- Where should an app's main menu be displayed? According to
many, the top of the dock isn't intuitive.
- Should closing an app's last window kill the app?
- Window miniaturization should show an icon, not a title
bar.
- Let the user decide where the dock will be displayed (left
or right side of the screen).
- Please, Be, give us window-management conventions
(cycling, tiling, backgrounding, foregrounding, and so on).
- Should a new window always grab focus? Even if you're
still typing in the old window?
Many opinions and a LOT of traffic. The need for UI
guidelines is clear, and the hope that the guidelines will
be adhered to (once they're published) was voiced explicitly
(by Mike Coleman, in particular) and could also be felt in
the many arguments that hypothesized the naive user's
experience.
THE BE LINE: General user interface guidelines for Be
applications were published in an article in Issue 51 of The
Be Newsletter. That article is the introduction to the Be
User Interface Guidelines chapter of the DR9 edition of The
Be Book, which is being written now.
- -----NEW---------------------------
Subject: Tracker
AKA: Tracker suggestion
AKA: A Better name for Tracker?
AKA: Be Newsletter Issue # 57, January 22, 1997
A number of folks wrote in to comment on Steve Horowitz'
column (in Issue 57) about Tracker, the DR9-generation
browser. Among the suggestions:
- Allow MIME mapping based on arbitrary attributes (not just
filename extension), particularly for nonnative systems. For
example, HFS could use a type/creator -> MIME mapper.
- Integrate HTML support.
- Allow multiple handlers per file; for example, you may
want an HTML file's primary handler to be NetPositive, and
its secondary handler (through Command-click, perhaps) to be
an editor.
- Provide a means for add-ons to announce the types that
they can handle.
- "Live icons" should be semitransparent.
- A lot of name suggestions, too many to list here.
THE BE LINE: There was some confusion over the phrase "live
icon dragging." It means (as several contributors correctly
surmised) that when you drag an icon, you'll see the icon
picture being dragged, not just the outline of the icon's
frame. It doesn't refer to animation running in an icon. We
apologize for the muddle.
Regarding add-ons being able to announce the types they can
handle: This will be done, although not necessarily in DR9.
We appreciate the name suggestions, but for now we'll stick
with "Tractor"... uh, excuse me, "Tracker."
- -----NEW---------------------------
Subject: /boot/system/ voes
This thread, which took off from the FBC discussion,
branched into system folder talk: Where should it be, what
should be in it, should there be more than one (one for Be,
another for third parties, a third for the user, and so on).
- -----NEW---------------------------
Subject: BView updates flickering?
A new listener wondered why BView blanks to white before
redrawing. Many folks wrote in with suggestions: Use a
transparent background color, draw to an off-screen buffer
first. The best result can be gotten from this bit of
advice: Don't Invalidate() the view; instead, call Draw()
directly.
A smarter double-buffering scheme was requested.
- -----NEW---------------------------
Subject: NetPositive & Datatypes
Listeners yearn for the ability to script URL requests. For
example, it would be nice to be able to send NetPositive a
message telling it to open a requested URL.
- -----NEW---------------------------
Subject: Soft reboot after crash
An idea (paraphrased from Daniel Lakeland):
Why not have a key stroke combination that kills the
Application Server (and client programs). You would then
drop into a terminal from which you could "hack and slash
away at the currently running programs."
The point, here, is to more gracefully bring down a crashing
machine. The initial idea spurred other suggestions:
- Ctrl-Alt-Del should shut down, not just reboot.
- Tracker and the Application Server should relaunch after a
crash.
- -----NEW---------------------------
Subject: Be public FTP archive on OS CD
A feature request for Be: How about copying the contributed
code from the ftp site onto the DR9 CD? It would have to be
recompiled, and some of it probably wouldn't work in DR9,
but is that so bad? How about a commercially released
version of the site -- would anyone pay for a CD of ftp
contributions?
It was pointed out that such a CD is already available, from
Adamation (see www.adamation.com for information).
THE BE LINE: Sorry, but Be probably won't burn the ftp site
onto the CD. As William Adams put it:
"Yes, it would be good to [distribute] the sources, but I
don't think it would make us look very good to release a
bunch of stuff that doesn't work with our brand spanking new
release."
|
