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™. 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.
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.
"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 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.
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.
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)?
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.
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?
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.