Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

Issue 13    November 1, 2000 Be in the News October 19, 2000 BeIA Product Review, techtv Be Press Releases 24-October-2000 Be Announces Sun Microsystems' Certification of Internet Appliance Software Platform return to top Streaming Media: The Future of the Internet by Brennan Spies, Sr. Market Analyst Without high penetration of broadband technology among Internet users, the possibilities that are enabled by streaming media over the Web seem like a distant rather than present reality. But there is no denying that broadband is the wave of the future and that it will shape the future of the Web in terms of what Web sites can offer to their viewers. In this future "broadband world," streaming media has a key role to play in enhancing Web content and allowing new methods of communication and e-commerce. In a recent study done by Gene Munster, senior technology research analyst at U.S. Bancorp Piper Jaffray, streaming media was identified as the next "macro-growth driver" on the Internet. Mr. Munster further identified six key drivers for the growth of streaming media on the Net: Demand for Interactivity Streaming media technologies will enable the delivery of enhanced and interactive content that new media users demand. More Effective Advertising Streaming media enables an advertiser to place targeted ads within a media experience that is one click away from commerce. The report says that consumers may be more likely to conduct transactions due to the improved convenience and timing offered. B-to-B Broadcasting B-to-B broadcasting includes events such as earnings calls, annual meetings, sales and training seminars, product launches, trade shows, industry seminars, telemedicine, and distance learning. Improved Content Distribution Streaming media would enable content owners to electronically distribute this digital content at a much lower cost compared with traditional distribution methods. Availability of Content Using streaming media, content owners can re-purpose content into a form that could be streamed in order to generate incremental revenue from that content. Innovative Applications The report found that streaming media will lead to innovative and exciting applications, which will improve the way people interact with commerce, content, and advertising. Mr. Munster further predicts that the Internet in 2-5 years will resemble the television in terms of audio and video quality while "enabling users to control the media viewing experience." Web streaming media spending, currently at about $9.7 million will grow to $21.6 million by 2004. As I've noted before, the BeIA software platform has been built from the ground up to handle media in a fast and responsive fashion, allowing the playback, for example, of MP3 or video files while performing other tasks. In a world of "fat pipes" the BeIA client ensures the smoothest and most reliable means of playing back streaming media from the Internet. BeIA also supports the latest in Internet media technologies, allowing the viewing of those formats in the first place -- unlike other Internet appliance clients which support HTML and little else. return to top Watching the Pendulum by Jean-Louis Gassée, CEO and Chairman It's more fun to watch a pendulum than an hour hand. Not just because there's more movement. With a little exercise of memory, there's also more merriment. I don't mean ancient bloopers such as a Business Week cover story in April 1980 titled "Exxon's Next Prey, IBM or Xerox?" No, what I have in mind is the current swing towards "The Death of The New Economy." What we told you is no longer "operative," as they said in an earlier White House. We're buying back your file copies of our magazine. No need to rehash this week's jeremiad -- the e-sky is falling. Perhaps. There are no tall buildings to jump from in Silicon Valley and I haven't noticed an increase in other forms of self-termination either. Having nothing to add to commentary on the stock markets, I'll focus on New Economy questions instead. First, is there one? If so, what does it mean and what does it amount to? Let's look at the automobile. It's more than 100 years old, but is there an automobile economy? Certainly there's a huge auto industry, but no one ever said it created a New Economy, or an Auto Economy. The main reason is that the automobile became pervasive in our lives, part of the fabric. The telephone lends itself to similar analysis. The Internet too is destined to be woven in our lives. At some point, the New vs. Old, Internet vs. non-Internet question will become moot. It will seem bizarre that it was ever asked. Note that I've exchanged "Internet" for "New," because when one writes "New Economy," one really means "Internet Economy." The next implied thought behind "New" is new laws -- of physics and economics. Read that way, what the pendulum swing to "The Death of the New Economy" actually means is, some misguided people, not us, hyped new laws of physics and now we're letting you know there aren't any. If only it were that simple. Nothing should ever be done for the first time. Let's not even mention the hype and exaggerations. Yes, there were rediscoveries of old business models, such as the phone company model of large investments and zero variable costs. But there are also some new laws. The law of accumulating choice real estate locations for one's business and raising prices once the oligopoly is established only applies in the real world where there is a physical limit to the length of Rodeo Drive, not so on the Net. Hence the misplaced expectations and empty dot.com coffers. The Internet, the Web, is more important, more profound than the telephone. It carries more data types and also a special type of active information known as programs. More than the telephone, the Internet will influence our actions, our thoughts, our emotions. Bill Gates once dismissed the notion of creating an Internet division at Microsoft because it would be like creating an electricity division; everything uses electricity. He was right and, incidentally, started an Internet division at Microsoft. Now Microsoft doesn't breathe a line of code disconnected from the Web. That should answer the "what does it amount to" question. There is, I think, a possible explanation for the pendulum swings, for the hype and the pessimism. Going back to the automobile and the telephone, neither appeared to impact us with the speed and magnitude that the Internet has. Hence the exaggerated expectations and reactions, the frenzy of buzzwords, the grasping for concepts. I choose to see this as good news. Chaos means there is more room for new players. return to top Tips for Debugging Add-ons and Optimized Code by John Dance, Engineering Director, Development Tools A recent discussion on BeDevTalk helped me realize that there is some misunderstanding about the power of bdb for debugging add-ons. This same discussion works for replicants also, so continue reading if you're concerned about them. Suppose you're writing a Tracker, bdb, or Opera add-on that doesn't work the first time you run it (surprise). How do you debug it? Simple "printf debugging" doesn't help since you can't see the output, but there are other ways to solve the problem. I'll mention two in passing and a third one at length. First, there are debugging helper tools available on BeBits that support a debugging window that you can use. Second, you can kill whatever application your add-on works with and start it again from a Terminal window. This allows you to see diagnostic output. For example, in Tracker, open a Terminal window, then use the Team Monitor to kill Tracker. In your Terminal window, start Tracker running again with "/system/Tracker &". Tracker will start up with standard error and output directed to the Terminal window. People often mistakenly think that the "host application" must be built with debugging information in order to debug an add-on in it. This isn't true. Debugging an add-on is not so different from debugging an entire application. You just need to set your breakpoint after the add-on has loaded. First, make sure your add-on is built with debugging information and installed in the correct location, then start bdb. bdb opens a window listing all the running applications on your machine. Double-click on the desired application and bdb shows you all threads currently running in it. (You can try this with Tracker if you like.) Since there's no debugging information, there isn't much to look at, but you can poke around in the different threads. What you want to do though, is have bdb stop once your add-on is loaded. Select Debug->Break after load_add_on (this menu item was added in BeOS 5.0). Now go to your application and perform the action that causes the add-on to be loaded. bdb will open a new window showing the "Add-on" thread. At this point, the bdb Team window displays the files from your add-on. You can then select a file and set a breakpoint before continuing execution. That's all there is to it. Now you can debug the add-on using bdb as you normally would. In fact, the next time you debug your add-on, you don't even have to stop after loading because your breakpoint is persistent and will be set automatically as the add-on is loaded. So, you might be saying... "What if I don't launch bdb and my add-on crashes? I don't want to deal with assembly-level debugging." More on assembly-level debugging later, but when you see "The application has encountered an error" dialog box, all you need to do is press "Details" and then "Debugger". When the terminal debugger appears, type "bdb" to launch it. bdb displays the location of the crash with a dialog describing the reason the application crashed. As much as we'd rather not worry about assembly-level debugging, there are times in life when you have to do it. I've seen crashes that occur when an application is optimized. Sometimes the crashes are caused by bugs in the compiler optimizer. (It's always fun to work with a compiler under development.) More often the bug is timing dependent and is exhibited only rarely and perhaps only in the optimized code. My rule is never to dismiss the dialog that tells you the application has terminated. I always go ahead and open the debugger and do a stack crawl (sc), look at the registers (regs), and then look at the instruction that caused the problem. If the instruction is trying to read or write to a register, (and the register isn't zero), I look at the memory at that register (if the register in question was eax, the command would be: dm eax). I also write down what I think I did to cause the problem. Sometimes timing-related bugs are impossible to reproduce on command. However, if you keep this crash log, patterns often become apparent after a few seemingly random crashes. While the optimized code is often very different from the unoptimized code with debugging information, I build the crashing application with debugging information and then debug the application. I stop at the function that crashed in the optimized version, and become comfortable with the function in assembly by using the Window->Show Assembly menu option. This opens a window with the source and assembly mixed. You can step through the code and look at the assembly listing and the Registers window to become more familiar with assembly-level debugging. The next time the timing-dependent bug in optimized code gets you, you'll have better information to dig around with the Terminal debugger and find out what's wrong. Good luck finding those bugs. 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!