|
Be Newsletter
Issue 62, February 26, 1997
Table of Contents
Be EuroTour: Milano
- Friday, February 28, 1997
11h30 to 13h30
Universita degli Studi di Milano, aula Alfa,
Via Comelico, 39, Milano
For details, please have a look at
http://www.crema.unimi.it/scrivania.html in the "Seminari &
Conferenze" section.
Be Demo Tour: Chicago, Champaign, and Springfield, Illinois
- Tuesday, March 4, 1997
4:30pm to 6:00pm
BeOS General Demo Meeting
Northwestern University
New Media Center
Annenberg (School of Education and Social Policy) on
Evanston campus
Room: G-21
- Wednesday, March 5, 1997
5:30pm
Private Be Developer and Be User Group Meeting
7:15pm
BeOS General Demo Meeting Hosted by the NorthWest of Us
Macintosh Computer User Group
Arlington Park Hilton Hotel
Chicago Room
3400 West Euclid Ave. (1 block east of Route 53)
Arlington Heights
- Thursday, March 6, 1997
3:45pm to 5:30pm
BeOS General Demo Meeting
University of Chicago
The Biological Sciences Learning Center (BSLC)
924 East 57th Street
Room 001
- Friday, March 7, 1997
4:30pm to 6:30pm
Be Users Group and Association for Computing Machinery at
the University of Illinois at Urbana-Champaign
BeOS General Demo Meeting
1320 Digital Computer Laboratory
University of Illinois at Urbana-Champaign
1304 W. Springfield, Urbana
- Saturday, March 8, 1997
9:00am to 5:00pm
ComputerFest 97
Illinois Building
Springfield, Illinois
See the BeOS at the Be booth, #211, between the UNIX and Mac
users groups. BeOS demos all day long.
11:15am to 12:15pm
Be Conference -- Large BeOS Demo Meeting
BE ENGINEERING INSIGHTS: Java Junkies
By Erich Ringewald
Early every year, the industry elite and their paparazzi
buzzard friends circle the oasis of Palm Springs in a three-
day elbow-shining schmooze fiesta. During this invitation-
only conference (code name: "Demo"), top execs -- your
bosses and the people they envy -- witness demos of new and
important technologies selected by the show's curator, Chris
Shipley, while reporters from the New York Times and Wall
Street Journal watch them watch.
Always looking for a theme, this year Ms. Shipley turned
Demo '97 into a coffee klatch: Gallons of Java, plenty of
sugar. A great opportunity, I thought, to deepen my
understanding of the potential and benefits of the Java
language. Don't get me wrong -- I may roll my eyes and slap
my forehead, but I still understand that the reason the Java
jihad has engendered such excitement is the promise of a
hogshead of compelling platform-independent applications.
And since I'm associated with a platform that has even less
market share than Windows '95, platform independence is
enticing. But I also believe that end users, in the end, are
unwilling to give up performance, responsiveness, and other
creature comforts in exchange for something as abstract,
high-minded, and Good For You as Platform Independence. It's
like talking about the environmental benefits of car pooling
while driving your V8 to work.
Stuffing my lathered attitude back down my throat, wiping my
mind free of reasoned opinion, and sewing my lips shut, I
knelt at the altar beside the other over-paid techno-
acolytes in anticipation of serious, professionally written
Java applications. One after another, bright-eyed young CEOs
and VPs of Marketing demonstrated their applications, the
most impressive feature of most (and the *only* feature of
many) being that they were "written 100 percent in Java!" Of
course, not one of the demos showed a level of performance
you'd expect from a "native" app. Despite a healthy dose of
the best of JITC (and not a moment too soon) technology,
they suffered noticeable delays in redraw speed and user
interface responsiveness.
Slightly fazed, but still looking for that sunny day, I
realized that performance isn't always the point: Freedom
from Wintel oppression, the chance to pry the Redmond talons
from the throats of the... (hum, excuse me)... I realized
that Platform Independence! is the real benefit. I wanted to
see the second half of the show, where these "written 100
percent in Java" apps would smash the platform barrier -- I
wanted to see a venerable Mac next to a BeOS machine next to
Linux X, an UltraSparc, a thundering Alpha workstation, an
Amiga or two, VAXen... even some sexy little itty bitty
thing from Larry "Lemme buy yez a Porsh [sic]" Ellison...
and I wanted them all to run the same app and exhibit the
same behaviour.
Imagine my surprise when every last demo was conducted from
the warmth and safety of Internet Explorer 3.01 running on a
200 MHz Pentium Pro. So much for platform independence.
Don't get me wronger -- my noggin is bruised and I can't
focus any more, but I still think Java has a great deal of
potential. Be's working with a number of partners and
developers to make sure that the multithreaded BeOS is
second to none as an environment to run Java applets and
applications.
But I think it's going to take more than Platform
Independence! to justify a new programming language,
especially when up till now it's been more "freedom to
choose" than the actual exercise of that freedom. Luckily, I
think Java, a modern, object-oriented programming language,
has a lot more than platform independence going for it.
News from the Front
By William Adams
Bonjour mes amis!
Je m'appelle "William Adams"
C'est moi, et c'est tout!
I was an American in Paris this past week, attending the
European developers' conference. This was my first time
outside the North American continent, so I sure did see a
different perspective on the world. At the conference itself
I met quite a few of the prolific European developers, and I
saw demos I haven't seen before. There were a couple of
games, one space shoot-em-up, and one French board game.
There was a demo of the Beat Box application. I would
mention another well known game, but its origins were
dubious. And at last, there was a real-time ray-tracing
program that one teenager ran on the quad DayStar machine.
Boy is that gigabyte of RAM useful!
I would say the conference was a success: I was able to meet
developers, they were able to meet each other, we
disseminated information on DR9, answered questions, wrote
code, and generally had a good time. The myBrowser product
will be better in the future, due to some changes in DR9.
Also, one developer had good ideas on writing
internationalization support.
There were of course some questions about how we will
support media like video in the short and long term, and
their patience is amazing. I believe the BeOS will be
greatly enhanced when we can turn some of their code into
commercial products.
So I left San Francisco at 3:30pm on Wednesday and arrived
in Paris at 11:00am Thursday. Where did the day go? Then
immediately into the Be office to work out the details, off
to a Parisian dinner, and to bed. Next day up at 7:30am, do
the setup for the conference, which started at 2:00pm and
went to 11:00pm. The DayStar machine showed up at 10:00pm,
and it had an Imagine 128 graphics card in it. We went out
and got an ATI board and had it up and running by 10:45. The
crowd was making sounds that led me to believe they needed
to get out a bit more often.
Next day up at 7:30am. The conference started by 9:00am and
was over by 1:30pm. Took the machines back to the Be office
and started the tourist thing. With the help of George-
Edouard, I saw quite a lot of Paris in just a few short
hours. We managed to run into a protest, which left us down
by the river and not moving too much. We saw the Eiffel
tower all lit up at night and a number of other spots.
Then Christian Marchandise was nice enough to invite us to
his 'farm' out in the country where we dutifully oggled at
the nice swimming pool, tennis courts, and helipad. Did a
nice dinner, planned the rise of the BeOS, and had a good
night's sleep.
Up at 10:30am for our 'breakfast,' you know, one of those
continental affairs. Not quite ham and eggs and pancakes,
but it's a good start for the day. Then, off to Notre Dame,
a number of squares and back alleys, a few more French
sounding places, and finish the night at a 'Mexican'
restaurant. George-Edouard was sure the waitress spoke
French too perfectly to be anything other than French, I
guessed she was English. She turned out to be British and
Italian.
Seeing all this French stuff gave me some perspective into
the minds that created the BeOS and guide its future. The
thing is, Paris is a very old city by American standards.
But even in its age it presents a mix of modernity that
leaves Americans thinking, "Hmm, that's odd and different,
yet refreshing." Take driving, for instance. Parisians don't
so much drive as they flow. Imagine one of those wide
boulevards going around one of the monuments in a circle.
There are no real lines on the road, and you just kind of
flow into the traffic, and amazingly, not very many
accidents happen. This speaks of a people that are in tune
with one another. Americans would be honking and shaking
fists, and the traffic would not run very smoothly. We would
stay within the lines and not break the rules, but sometimes
you have to for efficiency's sake.
Then there's the use of color. I saw a billboard advertising
the Papamobile, and in the price every number was a
different color. Same thing for chimneys and clothing. Very
odd, but again, fun and refreshing.
All in all, it was a good trip and they even asked me to
come back. So I guess I didn't mess up. By the last night, I
called home to check with the family and learn about the
latest Yasmin tricks. When she got on the phone, the
conversation we were having was sounding clear and normal.
This child who had just one week earlier been speaking in
broken sentences was suddenly speaking in complete sentences
that made sense to me. I thought, "Oh boy, I better rush
home before she makes it to college." It was fun, and I look
forward to the conference that will be in Germany.
I can't say too much about what else has happened at Be in
the last week. You undoubtedly know of the new partnering
announcements. So until next week, adieu.
Back from Tokyo
By Jean-Louis Gassée
We spent a week in Japan, around Tokyo Macworld, an
opportunity to strengthen ties with our existing partners
and to start developing new partnerships -- not to speak of
improving our limited understanding of this market.
Tokyo prices used to be out of sight. A few years ago, when
the exchange rate was about the same as it is today, the
joke was you bought a Nikon in Palo Alto for a friend in
Japan. It cost 20 to 25 percent less in the US. This
phenomenon gave rise to accusations of dumping; Japanese
companies were charged with selling goods in the US below
cost in order to gain market share, put their competition
out of business, and ultimately raise prices again once they
had established a monopoly.
I can't make a blanket statement, but the price differential
often came from Japan's very inefficient, multitiered
distribution systems, costing much more than the ruthlessly
streamlined network we have in the US. In a way, it was a
form of welfare, maintaining many jobs, some of which indeed
engendered a better service experience.
This has changed to some extent. Tokyo no longer feels
inordinately expensive, especially when compared to London
or Paris, and we found hotel rooms for $90, next door to the
Makuhari convention hall where Macworld was held. Checking
computer prices, we found many instances of Power Macs
selling for less than in Silicon Valley. Several Performa
configurations were advertised below $1,000, upper middle
class brand name modems sold for less than $50, and Kodak
DC50 Zoom digital cameras sold for about half what retailers
charge here. Perhaps Fuji will cheekily accuse Kodak of
dumping, or perhaps the Rochester firm is clearing inventory
before introducing new models.
Speaking of digital still cameras, they're more prevalent
than in the US. Every brand was represented at Macworld:
Olympus, Epson, Minolta, Fuji, Kodak, Sega, Panasonic,
Nikon, Canon, and Apple. You'd think this actually was a
digital imaging show, with Epson and Sony offering real good
hands-on tutorials and digital cameras at most other booths,
such as Motorola's, where your digitized likeness could be
transferred onto a T-shirt. Not as sophisticated as the Mac-
driven embroidering machine, with very nice jacket-
publishing software, but a lot faster and less expensive.
Speaking of Motorola, we made a joint announcement of a
bundling partnership very similar to the one we reached with
Power Computing in November of 1996. The idea is to put the
BeOS CD "in the box" with Motorola's StarMax Mac-compatible
machines. This again enlarges the playing field for BeOS
developers and gives users an inexpensive and easy
opportunity to test-drive the emerging platform and
applications. With Motorola's VP, Dennis Schneider, in town,
we had the opportunity to meet the local press, and our
association received abundant and favorable coverage. Other
Mac-compatible manufacturers present at Tokyo Macworld
expressed interest, with UMAX leading the way.
To the various audiences we addressed, we stressed our
commitment to carefully adapting our product to the Japanese
market and to developing the kind of partnerships needed to
earn the trust of Japanese customers. We were always kindly
received and, in a culture interested in innovation and in a
country where so much of the digital media originates, we
were impressed by the variety and size of the opportunities
open to us -- if we execute. That's a big if, especially
with the added challenges of the writing system, but we
ought to be able to get there faster than our noble and
worthy elders, benefiting from their experience. And unlike
traditional office automation applications, A Japanese word
processor or other traditional office automation application
isn't easy to export. But as Japanese developers deal with
more universal data types, they're likely to discover that a
sound synthesizer or an image editor offer better
opportunities for export on the Web.
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.
- ----WEEK 2---------------------------
Subject: file-caching and programming style
A discussion of file I/O techniques. Under what
circumstances should you mmap() as opposed to a simple
fopen()? Size can be a consideration, but access style
(sequential vs. random) is just as important.
From Jake Hamby:
"mmap() is designed primarily for RANDOM access to files.
When you're doing sequential file access... you won't gain
anything from mmap(), and you can potentially lose big in VM
paging."
What's the best size for a buffered read? Joanne Dow:
"...buffer sizes in the 16K range seem to work best for
me... [L]arger sizes can 'page' too easily which results in
a performance loss. The object is to make the buffers large
enough that the system 'just about' pages you out before you
are done with the current load in the buffers."
Further recommendations from Jon Watte:
"...you really should look into double-buffering, and having
a separate thread that reads the data, for overlapping I/O
and computation."
- ----NEW---------------------------
Subject: More kernel & memory stuff...
Topic #1
Is it possible to pass a function pointer (that lives in the
app's address space) to a driver (which lives in the
kernel's address space) by passing the pointer as an
argument to an ioctl() call?
Yes. But is this a good idea? Be's Dominic Giampaolo sez...
"I strongly recommend that you do not do this... you are
forcing the kernel to depend on the correctness of some
arbitrary piece of user code. In the land of kernel
programming this is the ultimate evil."
Topic #2
How do you send data from a driver back to the app? A couple
of suggestions were offered: Create a shared area that the
driver fills with data; when the data is ready to be read,
the driver sends a signal or releases a semaphore on which
an app thread is acquire-blocked. Or spawn an app thread
that loops over a buffered read(). In any case, unbuffered
reads (that is, single-byte data transfers) were strongly
discouraged.
Topic #2a
What about a driver that spits out LOTS of data really fast?
Solutions and objections: A single synchronous read() thread
could miss data; multiple read() threads require
synchronization; kernel-managed buffering could be too
memory consumptive.
The thread veered into a discussion of speed and price of
various wires and flavors of RAM.
- ----NEW---------------------------
Subject: Fonts, fonts, fonts!
The new font system prompted speculation and requests.
Chris Herborth:
"Could we get a real bitmap font format? By 'real' I mean
something that free tools can convert to/from."
There was also a call for anti-aliasing and Unicode.
- ----NEW---------------------------
Subject: Shared Locks
Can anyone think of a clever Benaphore-like way to create a
many-reader/one-writer lock? Everyone agreed that it can't
be done with a single Ben/semaphore. And even then there are
some questions that need to be answered; for example (from
Eric Berdahl):
"...if a bunch of entities hold read locks and someone tries
to acquire a write lock, the write lock must block (natch).
If another read lock is attempted, should it block or
succeed?"
- ----NEW---------------------------
Subject: Debug Server
Luc Andre wrote in to request that Be provide a version of
the system that performs memory checks. The "debuggable
memory manager" would check for memory leaks, invalid
writes, redundant free()'ing, and so on. Many folks
applauded the notion.
|
