Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

Issue 15    December 6, 2000 Be in the News December 4, 2000 Be's Founder Looks at Life and Work in Silicon Valley, San Jose Mercury News November 28, 2000 Taking the Appliance Reins, PC Magazine November 25, 2000 It's Raining Net Appliances, But Where?, PCWorld.com November 17, 2000 Comdex 2000: Picks and Pans, PCWorld.com November 14, 2000 Be Takes New Slant on Net Appliance Biz, The Register Be Press Releases November 28, 2000 Be Inc. Appoints Chief Operating Officer Steve Sakoman to Board of Directors return to top One Step Closer by Jean-Louis Gassée, CEO and Chairman Tempting as it might be, the title is not a reference to age-related dysfunctions in Florida, such as stochastic voting machines and 19th century electoral statutes. Someone did suggest, however, that we could generate publicity by offering free BeIA licenses for the purpose of building robust, unambiguous, citizen-friendly voting appliances. But legal counsel would never let us do that. Instead, I'll focus on the BlueTooth conference this week (12/4 to 12/7) in San Jose, CA. There's an excellent Web site, www.bluetooth.com, with a wealth of information on protocols, devices, piconets, scatternets, industry groups, hardware, software, interoperability with IrDA -- everything you need or don't want to know about BlueTooth. For an optimist such as yours truly, the importance of this week's event is that it gets us closer to a world of affordable connected devices. But critics now charge that we have a surfeit of wireless protocols. In their mind, we're in great danger of babelizing this new frontier. Other naysayers feel that we're too optimistic. They say that it took nearly ten years for USB to gain some kind of mainstream acceptance and many implementations still leave much to be desired. So who's right? Critics are right to suggest moderation. You can't really buy BlueTooth devices at Fry's today, and therefore, BlueTooth doesn't exist, yet. And, yes, the great thing about standards is there are so many to choose from, as Larry Tesler, a former Apple Fellow once joked. Consumers will be turned off by the confusion: RangeLan, Wi-Fi and, now, BlueTooth. Do they work together? Which one(s) will be Betamaxed? The news is mixed. Wi-Fi, a.k.a. 802.11b, and RangeLan compete for the same application space, wireless LANs, WLANs, connecting PC and peripherals, most of the time as an extension of an existing "conventional" wired Local Area Network, itself connected to the Net. If you read the specs, one calls itself 802.11, the other 802.11b. Today, they don't work together, but that could (should?) happen in Future Releases. Let's hope it does. BlueTooth belongs to another category -- WPANs, Wireless Personal Area Networks, with a 802.15 Working Group (see http://grouper.ieee.org/groups/802/11/ for more details. Personal Area Networks are supposed to mean an area of a few feet around one's person, as opposed to hundreds of feet for WLANs. For example, your PDA or your cell phone will offer a wireless earphone/microphone. No more unseemly wire between the two -- you can take notes while talking. Another application is wireless PC keyboards and mice. These exist today using ad hoc protocols, but they'll be more economical and easier to connect when BlueTooth becomes pervasive and also includes printer connections. In some ways, we're looking at a fairly normal network topology, with small capillary pipes feeding bigger ones and so on. In this view, BlueTooth feeds into 802.11 WLANs, rather than compete with them. Over time, we'll see if one or more of these standards get "perverted" to currently unforeseen uses, through performance tweaks or otherwise. After all, the floppy disk was initially designed for IPLs (Initial Program Loads), feeding code and micro-code updates into mainframes, remotely like BIOS updates, if you will. IBM had no idea it was inventing something that would last more than three decades, used on more than a hundred million computers. The question of speed of adoption remains, however, with bad memories of USB lingering. I submit, though, that BlueTooth is different. USB replaced a messy system of serial and parallel ports; it didn't unlock many new applications. Today it's mainly used for connecting printers, scanners, keyboards and mice, and the occasional floppy or CD-RW drive. There is still a wire and, contrary to our hopes, the connections are not as executive-proof as promised. Try putting this notebook to sleep with a USB mini-hub attached. With BlueTooth, wires disappear, something mobile users of computing and communication devices value. Now, as stated earlier, this is the promise, the standard is still "de facto," meaning unofficial. I doubt that we'll see any real (purchased at your favorite retailer) product before the second half of 2001. Hopefully, we'll have learned the lessons from USB. Tart-tongued miscreants say that BlueTooth will work because it doesn't need a stack from one half of Wintel and an OSR (OEM Service Release) from the other half. Let's hope they're right. I enjoy a WLAN as I write this. I'm ready for the next step in freedom and friendliness. return to top The Co-Development Conundrum by Lee Williams, Director, Product Development and Delivery Be and the community of developers, fans, and shareholders around us are in the middle of an interesting dilemma. Since we began targeting our efforts toward developing an Internet appliance platform many people have expressed concern about the changes they've seen. Questions arise, such as, "Why haven't you announced your product line?" "When can I buy a BeIA Device?" "How are you going to compete with Palm?" "Does this mean there will be a new BeBox?" The answer to these questions lies in understanding the process by which products are developed for the consumer marketplace. I hope to shed some light on the reasons for our actions by giving you a high-level perspective of the product development process. Let's start by looking at some typical consumer electronics products -- TV, VCR, and cable/satellite/DSL unit (what I call a signal box). Have you ever wondered exactly what went into creating these devices? At first glance the product looks like a basic item that comes from one company. You can glance at your TV and imagine an assembly line with naked tube chassis rolling along and workers assembling and testing electronics components and wiring assemblies. This part of the development process often referred to as the "manufacturing line." However, it's just one piece of the overall development process -- in some cases a relatively simple phase of the total product effort. In fact, that TV, VCR, or signal box comprises products from a collection of companies and individuals. An individual device contains embedded components from companies whose sole focus may be signal processing, power modulation, sound filtering, picture fidelity, or protocol support. Now throw in industrial design for the case materials, faceplates, and button and input arrangements. Also, consider the intellectual property inherent in firmware. For example, the Dolby Digital and Digital DTS trademarks that you see on these devices indicate corporate property that's been embedded in these products to provide additional features and functions. Now let's continue this exploded view of the contents of an electronics product by considering the business practices that go into a development effort as well. Think about what it took to collect the market research that determined the proper price point for the product. That would include concepts like competitive analysis, user testing, and other marketing focused efforts. Think about the program management practices as well, and what's required to coordinate a development effort that involves multiple companies spread around the world, whose employees live in different time zones, speak different languages, and have different value considerations. Another significant part of the development process concerns the levels of testing involved. Any good, high-quality product has been through a series of tests that would surprise most consumers. Have you ever wondered how a device can take a direct lightning strike and still be in one piece? Have you ever questioned why very few consumers and their curious children get shocked, electrocuted, burned, or hurt by doing some very awkward things with these devices? It's because these devices have been tested for a great variety of contingencies. Unit testing, integration testing, user testing, and other types of validation take the proposed products to extremes that replicate the most bizarre situations in which the product might be used. This testing often significantly alters the work that companies do. It necessitates effective communication, planning, and coordination throughout the entire product development process. As with many things, if the right type of planning, testing, and design have been implemented by the time a product gets to the manufacturing line phase, the apparently simple assembly process reaps the benefit of all the effort that has preceded it. The size, number, and complexity of consumer markets make competition a critical factor in the success of any product. Maintaining a competitive edge necessitates a secretive development process, with controlled methods of communication and disclosure that benefit the parent company or the company primarily responsible for launching the product. Seemingly small advantages that a company may realize with component transportation costs, case material savings, firmware license fees, and labor-based wages each can have a dramatic impact on the success or failure of the final product in the marketplace. Consider for a moment what's happening in the PC, Internet services, entertainment, and consumer electronics marketplaces. They are converging. It's not a matter of whether they are colliding -- it's a matter of when, based on how quickly companies can tailor their development process to accommodate consumer demand for devices that are pervasive, connected, and compelling to use. We often think that the difficulty with convergence lies in the concept of what will converge, and we make the mistake of disregarding what it takes behind the scenes to actually realize the benefit of this convergence. The markets that will realize the benefits of this convergence are larger than the PC market, the enterprise sector, and the consumer electronics markets. They are bigger than the service industry and they dwarf the entertainment business. The marketplace for pervasive and seamless computing and communication is defined by all these markets combined. We are a small company that has taken the fantastic intellectual property that we have developed over the last eight years and thrust it into the middle of this maelstrom of change. We are interacting with all levels of companies and processes that are engaged in product development in this space. For the first time in our history as a company, the response to our contribution is material and in some cases overwhelming. This is why you have seen a different face on Be. Our co-development partners guide our ability to disclose information. The licensing options are one of many in a cauldron of choices that span industries. The markets themselves are new, converging rapidly, and changing at such a pace that the competitive advantages and distractions are still unknown. All of this makes it seem that we may be silent or struggling when in fact quite the opposite is true. Like all the community members with an interest in Be, we are along for the thrilling ride that is the next revolution in the communication and computing industries. Hang in there. Don't misinterpret the changes you've seen in our efforts. Look for the subtle signs of progress that define our opportunity. We can't be as open and footloose as we've been in the past about demonstrating our capabilities and our successes, but that doesn't mean they aren't happening -- and that is our dilemma. return to top News from the Media Front by Jon Watte, Engineering Director, Media Technology It seems like yesterday, but it's actually a year since I wrote a newsletter article entitled "Do You Have 24 Ears." In it I talked about the multichannel audio device driver model that we had developed for BeOS, which shipped as part of BeOS R5. Several developers have e-mailed me about getting the specs to write drivers for new and interesting sound cards, and we appreciate that. However, what about cards that don't fit the multi-audio model? Multi-audio excels at describing and dealing with professional studio recording cards, where there are roughly as many DMA streams (interleaved or not) as there are input/output codecs, and not too much other processing going on. These days, though, most sound cards seem to be simple "stereo in/out" cards or "game cards" where the card can run 192 different "sounds" through an internal mixer and then render the result to stereo, quad, or 5.1 output. Up to now, we've had no good way of expressing these cards' capabilities in the BeOS audio driver model, because we've been fettered by the "old" model, as originally implemented on BeBox hardware. When we started cutting down memory footprint and leveraging the BeOS media capabilities on BeIA-style devices, we saw that the current audio driver model, while minimally capable, was actually going to get in the way. First, it typically introduces extra copying in the audio stream, which consumes precious memory bandwidth; second, it does not allow us to properly express the capabilities found on most modern analog sound card mixers (AC-97 based or otherwise); and third, it does not allow us to take advantage of hardware capabilities such as built-in digital mixing to off-load the CPU. We thus set out to create a new driver API that borrows from multi_audio where it makes sense, and abstracts and describes the capabilities of current and near-future "typical sound cards." We call this API game_audio. The API we designed allows a sound driver to describe the resources available to the system in terms of three units: A number of codecs (typically, there will be one input codec and one output codec in this parlance) which determine "master" audio characteristics such as sampling rate, sampleword bit width and number of output channels. A number of mixers (typically, there will be one mixer for input and one for output) which consist of a number of controls that are either sliders, enables, or muxes. A number of streams which can transfer data between buffers allocated by the driver and provided to the application, and the actual hardware; such streams may have their own bit width, number of channels, sampling rate and other parameters as separate from the codecs and the hardware is responsible for doing the conversion. In the cases where hardware cannot provide a specific service (say, sampling rate conversion) it will not describe that capability, and client software (on the desktop, the System Mixer, or the Node that talks to the card) will have to cope. We are working on making both multi_audio, with a sample driver, and game_audio, also with a sample driver, available on our developer Web site, along with documentation. While it's not quite frozen yet, we're getting very close, and should have it up by the new year. Feel free to bug us at info@be.com if you notice that it's no longer the year 2000 and you still can't find the files. return to top Statements contained in this Newsletter that are not historical facts are "forward-looking statements" including without limitation statements regarding the demand for, future market penetration and market acceptance of BeIA and BeOS, the shipment dates of Be's products, and the future operating results of Be Incorporated. Actual events or results may differ materially as a result of risks facing Be Incorporated or actual results differing from the assumptions underlying such statements. Such risks and assumptions include, but are not limited to, risks related to competition, market acceptance and market penetration of Be's products, ability to establish and maintain strategic relationships, the benefit of Be's products to OEM and Internet appliance manufacturers. the continued availability of third party BeOS applications and drivers, and the ability to establish and maintain strategic publishing relationships. All forward-looking statements are expressly qualified in their entirety by the "Risk Factors" and other cautionary statements included in Be Incorporated's Annual Report on Form 10-K for the year ended December 31, 1999, and other public filings with the Securities and Exchange Commission. The BMessage Copyright (c) 2001 by Be, Inc. All rights reserved. Be, Inc. 800 El Camino Real, Suite 400 Menlo Park, CA 94025 Tel: (650) 462-4100 Fax: (650) 462-4129 Web: http://www.be.com/ Be, BeOS and BeIA are trademarks or registered trademarks of Be Incorporated in the United States and other countries. Other brand product names are registered trademarks or trademarks of their respective holders. All rights reserved. The BMessage is sent to subscribers of one or more of the Be mailing lists. For more information about subscribing/unsubscribing, see the Be web site: http://www.be.com/world/mailinglists.html. The Be web site also offers a complete set of current and back issues of Be Newsletters: If you have any comments about The BMessage, please e-mail them to:newsletter@be.com.

About Be, Inc. | Be Products | World of Be | BeOS Support | Jobs | Developers | Press | Partners | Investors

Copyright © 2001 by Be, Inc. All rights reserved. (Legal Info)
Comments, questions, or confessions about our site? Please write the Webmaster!