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.
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.
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 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.
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.”
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.
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.
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?”