|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In this ChapterWhence from Here? New Architectures Converging on the Media
The term "final code" is an oxymoron. No software is ever finished, and there's always something that can be done better. When you're talking about the 1.5 million lines of code in BeOS (actually an incredibly small codebase, compared to, say, the 30+ million lines of code in Windows NT), it's inevitable that there will always be improvements that can be made. Improving BeOS is the reason dozens of Be engineers get up in the morning. It's all about the future--how to meet it, how to beat it, and how to build the best possible operating system for the hardware that consumers can get their hands on easily. This chapter is all about the future of BeOS: what new capabilities, software, hardware, and OS concepts you can expect to see in the coming years.
Whence from Here?Time doesn't stand still, and the world's technology evolves more quickly than any single company can keep up with (witness Microsoft missing out on the Internet boat for a few years). Making sure that BeOS continues to be the ultimate fine-tuned desktop and workstation operating system is a constant challenge for Be's engineers. Fortunately, the rapid development cycles possible on BeOS mean that new releases can be offered frequently, accommodating not just new ideas and concepts, but hot new hardware as well. To date, BeOS users have had access to major updates roughly twice a year, with interim releases and bug fixes being made available at sporadic intervals in between. These updates aren't just a matter of a nip and tuck here or a new I/O card driver there, either. In most cases, they've represented major, quantifiable leaps forward in speed, usability, and "feature completeness." This book made it out the door just after the endof the R4 beta cycle, and by the time you read this, Release 5 should be just around the corner. We'll be posting updates to some of the material in this book at www.peachpit.com/xxxx, where we'll keep you abreast of any significant changes that affect the material you read here. Because Be was completely "nose to the grindstone" working on R4, they didn't yet have a concrete road map to projected features for releases 6 or 7. However, based on what we know of the system today and early statements Be has made about R5, there are a few areas around which we can speculate and project with various degrees of certainty. Table 1
Planned BeOS R5 features as of November, 1998. Release 5 should expand significantly on support for laptops, peripheral devices, multimedia formats, and more.
Release 5 RoadmapRelease 5 of BeOS is scheduled for shipment in early summer of 1999. Table 1 lists the features that were scheduled for inclusion as of November, 1998. Again, nothing in this list represents a commitment to ship specific features. New ArchitecturesIf BeOS is so portable, can we expect to see it running on other types of computers soon? Mostly no ... and a little bit of yes. When Will BeOS Run on Platform X?A question frequently asked in Be-related newsgroups and mailing lists is whether BeOS will be ported to run on <insert your favorite architecture here>. For example, many people would like to see BeOS running on Alpha-based workstations, Sun SparcStations, or Silicon Graphics O2 graphics machines. The question is a natural one, since BeOS has run on four different computer architectures already (Hobbit, BeBox, PowerMac, and Intel), amply demonstrating how portable the system is. However, there are a couple of important things to keep in mind here. For one, just because BeOS is easy to port doesn't mean that such a project would be a piece of cake. Yes, the initial port from the BeBox to the PowerMac practically occurred over the course of a weekend, but that was just the initial port--making everything work properly was another matter altogether. Then there was the small matter of critical differences between various Macintosh motherboards. While the CPUs remained pretty much the same from model to model within a given class of machine, custom chips on the motherboard were different for almost every single model, which meant that Be had to do a ton of work to get BeOS working on as many PowerMacs as they could. Of course, the Intel port presented similar challenges. While the x86 boot sequence is publicly documented and pretty much identical from one machine to the next, Be had to deal instead with the huge array of video cards, CD-ROM drives, sound cards, network cards, etcetera. To undertake similar challenges on yet another platform would be suicide--Be isn't Microsoft or Apple, and doesn't have the kind of resources it takes to dedicate a team to facing these or similar hardware hurdles on other platforms. Secondly, BeOS was a lot younger and simpler when those early ports were taking shape. BeOS may contain only a small fraction of the system code found in MacOS or Windows, but if you compared the codebase in DR7 or DR9 to the codebase in R5, you'd find that the system has grown immensely. Not that the Be engineers have waned in their commitment to keeping the system light on its feet, but in order to deliver the features that users demand, the system's complexity must grow almost by definition. You want to boot from SCSI drives on the Intel side? You have to add code to the kernel. You want task-switching with hotkeys? Add a few more lines to the application server. You want spatialized audio? Grow the Media Kit. Finding a balance between the contradictory demands of staying clean and simple on one hand and offering everything the other systems do (and then some) on the other is a continual battle. Sure enough, the codebase grows in size and complexity as time passes. It's unavoidable, and makes the prospect of a port all the more daunting with every passing release. Third, managing the codebase for multiple platforms is a major operation, requiring sophisticated tracking systems and painstaking documentation of every little change to ensure that the platform remains identical regardless of the machine you're running it on. As anyone watching Be throughout 1998 could tell you, just supporting PowerPC and Intel at the same time was a herculean task for Be; adding a third or fourth platform to the source tree would likely break the camel's back. While it's true that the codebase stays the same between various platforms and that only the boot code, kernel, and drivers change significantly from one platform to the next, the reality of the situation is that maintaining a cross-platform source tree is a somewhat messy job. But the fourth--and most important--reason why you're not likely to see BeOS running on other architectures in the foreseeable future is one of simple economics, and involves the requirements of running a sane business. You don't need a scientific calculator to figur> out what percentage of potential users out there are running Alpha-based machines compared to the percentage of users who are running stock Intel or x86 clone hardware. Granted, the proportion of unique platforms in Be's target high-end graphics and multimedia markets is higher than that in the office suite computing space, but it's still not nearly high enough to make a sound business case for another port. And in the high-end CAD, 3D modeling, animation, and design fields, Windows NT has encroached strongly onto territory once owned by the likes of Sun and Silicon Graphics, so there are a lot more stock Intel machines in Hollywood and Silicon Alley graphics studios than there once were. These machines are perfect candidates for BeOS partitions. It simply doesn't make sense for Be to move toward obscure architectures when the world's most popular architecture is doing such a great job of coming to Be. Bastard Child All of that said, the possibility for a port to another hardware architecture is certainly there. It's easy to imagine someone like SGI hypothetically wanting Be to bring the OS to their hardware and Be hypothetically responding, "You give us a check and we'll give you the source code--you port it." Unfortunately, a scenario like that would mean a splintering of the sacred cross-platform solidarity of BeOS code--a bastard child, if you will. On the other hand, it would also mean you'd be seeing BeOS-generated special effects in more summer blockbusters, and that can't be a bad thing. Evolutionary Designs I think it's safe to say that Be will endeavor to keep up with the latest and greatest chip designs and motherboard revisions appearing in the consumer market. Intel's 1,000 MHz "Merced" chip promises a brand-new branch in the x86 family tree. You've probably heard for years that the CISC architecture is "on its last legs," "gasping for breath," "can't possibly go any faster." Well, they've been saying that for five years, and x86 chips are ten times faster than they were then. Nevertheless, there are a number of fundamental problems with the basic CISC architecture that do limit its growth potential. Without going into a chip design discussion, suffice it to say that Merced throws most of those problems away and gears up for the truly high-bandwidth future--just as BeOS has done. It's a marriage made in heaven.
Like most new high-end chip releases, Merced CPUs will appear first in the server market (probably around summer 2000), then trickle slowly but surely down into consumer machines when the price comes down to the mortal realm. Be hasn't made any announcements about Merced chips (how could they? No one but Intel engineers has played with them), but I'll wager that Be will be enthusiastically Merced-compatible. Meanwhile, transistors keep getting faster and more efficient. IBM recently announced plans to build chips wired with copper, rather than the traditional aluminum. Copper is a better conductor than aluminum and can be molded into thinner wires, which in turn lets chip manufacturers pack more transistors onto a single chip. Soon after IBM's announcement, several other chip vendors--including Intel--announced plans to release similar chips. As clock cycles continue to rise, current memory and bus speeds will become major bottlenecks, so we can expect fundamental rethinking of those architectures at the same time. Peripheral connection standards like FireWire will go a long way toward keeping your external devices and storage media humming along in step, and BFS has already shown itself to be excellent at milking as much performance out of hard drives as possible. More than Eight is Enough The original logic of the BeBox design--that it makes more sense to have a bunch of cheaper processors working in concert than it does to put all your clock cycles in one expensive basket--still makes a lot of sense. Do the math: At this writing, you can get 200 MHz CPUs for around $100 each. Four of those running in a system that knows how to distribute the workload efficiently would give you practically 800 MHz of desktop power for $400, when you can't buy an 800 MHz processor today at any price. However, the vast majority of operating systems installed on the world's desktops don't know how to communicate very well with multiple processors. Windows 98 and MacOS 8.5, in fact, completely ignore extra processors (though applications can be specifically coded to take advantage of them). That pretty much leaves Windows NT and Linux to carry the multiproc market, and both of them suffer from serious impediments to efficient symmetric multiprocessing (SMP): NT wastes too many clock cycles in multiprocessor configurations, and Linux's SMP implementation is rather coarse (not to mention the fact that most Linux software isn't as finely multithreaded as similar BeOS software).
Of course, you know that BeOS handles SMP elegantly and automatically. When and if BeOS becomes popular enough to drive the multiprocessor market by itself, we'll all cheer. Until then, it's up to Windows NT 5, MacOS X, and future versions of Linux to improve their SMP behavior. Of course they ultimately will, because one processor per person isn't enough. And when they get really good at it, the multiproc market will explode and we'll all have to install seatbelts in our computers. Using two or four processors is one thing, but the question is, when will consumer machines begin to ship with eight or more CPUs? As you recall from Chapter 1, BeOS can theoretically work its magic on any number of processors, but an upper limit of eight is in place for now. That limit can be removed by Be simply by uncommenting a few lines of system code, but motherboard and bus designs will have to take another form (the overhead required to juggle instructions between that many processors becomes hideously complex). In any case, BeOS will likely be more ready for that day than any other operating system in the mainstream market.
While Wired magazine speculates about the future of chemical-based computers and lightning-fast RAM made of blue-green algae, you might want to chase more humble pursuits, like stuffing pennies into a piggy bank for your first quad-Merced machine.
|
The Future of BeOS on the PowerPCSince the introduction of BeOS for Intel Architecture, speculation in the BeOS community has run high regarding Be's plans for continued support of BeOS on the PowerPC side. Initially, however, this speculation was based solely on numbers--everyone knows how much more potential revenue can be garnered from the Intel market, not to mention the additional management work required to maintain the codebase for multiple versions of the system simultaneously. It wasn't until months later, when Apple declined to release technical specifications for the motherboards shipping with their new G3 processors, that this kind of speculation started to gain serious traction. The equation, it appeared, was quite simple: If Apple owns the entire PowerPC market and also refuses to work with OS vendors such as Be to add value to Apple hardware, all roads are blocked; there's simply nowhere for BeOS on PowerPC to turn. Intel had come to Be, sending in a team of engineers to assist in the port of BeOS to their hardware, while Apple was curling up into a solipsistic little ball and refusing to dance. Many members of the Be community were up in arms about this turn of events. After all, they argued, PPC is where BeOS got its start in the public sphere (the original Hobbit processor design was never made public). The original BeBox had been PowerPC-based. Be had previously put all of their eggs in the PowerPC basket, and were now turning their backs on this market--the same market many associated with the creativity crowd (Be's target). In addition, all of BeOS's early adopters were about to be left high and dry. The only thing keeping BeOS running on PowerPC Architecture at all, it seemed, was a promise made by CEO Jean-Louis Gassee after the death of the BeBox: He had publicly declared that the BeBox would be supported by Be, Inc. for a period of three years. As long as the BeBox was supported, PowerMacs would be supported along with it. To complicate matters further, astute users noted that the Linux community had already succeeded in making their operating system run on G3-based PowerMacs by reverse-engineering the new motherboards. If Linux could run on G3s, why not BeOS? The answer given by other users was that Linux users are hackers. With no corporate representation, you can get away with reverse-engineering specs, but a company cannot base a business on the hacker's ethic. Be, curiously enough, was silent on the matter, saying nothing in favor of nor against these speculations. While all of this was going down, an almost predictable phenomenon appeared on the horizon: Significant BeOS developers were choosing not to compile PPC versions of their applications. The first company to go public with this information was RoDesign, who make the popular BackRow and RoColor applications for Web developers (see page 372 in Chapter 13, Graphics Applications). While disappointing, none of this came as a total shock to anyone. Given that Be had sold more copies of BeOS for Intel in its first week of release than it ever had sold copies for PowerPC, the numbers had told the story long before these announcements were made. On the other hand, more in>eresting news began to arise from the Apple camp. After years of steady decline and virtual acknowledgement by all but the staunchest PPC supporters that their platform was indeed doomed for good, Steve Jobs' closed-door policies were beginning to have an apparently positive effect on the Macintosh purse. Profits were up, the iMac appeared, and the usual gloom and doom over Apple's situation did yet another about-face in the press. Be remained (and as of this writing, remains) diplomatically silent on the whole issue. Never once have they publicly stated that days are numbered for BeOS on PPC. Perhaps that will change by the time you read this, but for now, BeOS is still officially a cross-platform operating system. Personally, I support and encourage the notion of an operating system that doesn't care what hardware it's running on--biological diversity is good for all ecosystems--but I also fully understand that Be has a business to run. Back to Earth on PIOS OneIf prospects seem glum for BeOS on PowerPC, there's another architecture waiting in the wings that may just see the light of day by the time you read this. Since the death of the BeBox in April, 1997, the Be community has buzzed over what many have hoped could become its replacement: a PowerPC-based machine called the PIOS One from German manufacturer PIOS (http://www.pios.de). This unique company staunchly refused to roll over and play dead when all hopes for the long-awaited PowerPC Platform (or PPCP) spec (formerly known as CHRP, which in turn was formerly known as PReP) were dashed on the rocks by the companies behind it (the Apple/IBM/Motorola alliance, or AIM). CHRP had been intended to merge the technical superiority of the RISC CPU with the operating-system agnosticism and easy upgradeability the Intel community enjoys. Later, Apple came back to the table with an amended spec including some Mac-specific technology such as ADB, and called the new spec PPCP. PPCP machines would have supported MacOS while simultaneously loosening Apple's stranglehold on the RISC market with a nonproprietary design capable of multibooting MacOS, BeOS, Linux, and potentially other systems, without the boot ROM headaches facing alternative operating systems under Apple's then-current hardware design. PIOS's project manager Dave Haynie had this to say about this period in CHRP's history: "Everyone had considered MacOS vital to the launch of CHRP. We didn't. The original PIOS One was launched as something of a next-generation BeBox. I came to it with ten years of experience designing the high-end Amiga systems at Commodore, and I studied what Joe Palmer did on the BeBox, which oddly enough was very much the direction I was trying to move Commodore to, before they bought the farm. In early '97, I met with Apple, and they convinced me to support CHRP, the MacOS, motherhood, and apple pie. If this were a classic tragedy, that would have been the mistake that has the whole castle dead by the end of Act III. I did the second redesign last fall and winter, based on where we had to point things (multiplatform, even) with the loss of MacOS as a possible market. [PIOS] got a better system out of the deal, but we've since been plagued with little things like 'how do we pay for all of this with the MacClone business going away Real Soon Now.' "CHRP was clearly too good to succeed. A market 'standard' is supposed to be someone's proprietary design, usually a crappy one, never intended for the greater life it enjoys as an industry standard. I won't claim CHRP was perfect, but it's way beyond the PowerMac and PCs in basic architecture. Which means very little the first time around, but over time, it has a great impact on what designers like me can put under the hood without the kind of kludges you find in the PC industry. The real promise of CHRP was that it made a better, much more flexible kind of personal computer, naturally centered around PowerPC, a better, more flexible kind of CPU. We're still going at it, jaws locked on the thing like some kind of pit bull terrier." Like the BeBox and the BeOS itself, the PIOS One takes the best from the PPC and Intel worlds--its CPUs are RISC, but its I/O cards (sound, video, networking) all come from the Intel space. Uniquely, though, these machines can also utilize a few hardware standards from the Mac world, such as ADB mice and keyboards and LocalTalk networking. Users get more choices, more competitive prices, more expandability, and more performance. But best of all, the PIOS One is designed to rock as a BeOS workstation. If you've ever heard an ex- (or current) Amiga-head ranting about how great that platform was in its time, you'll appreciate the fact that PIOS is run almost exclusively by former Amiga movers and shakers. At one point in time, some people called the BeBox "the next Amiga." Now they give the PIOS One the same accolades. The icing on the cake? This machine--if it ever sees the light of day--should only cost around a grand. See www.url.to.come.url.t/K for technical specs. Unfortunately, after a year of construction and community buzz, PIOS One machines haven't yet shipped to the public. As the PIOS One was finally approaching readiness, PPC support in BeOS seemed to have question marks circling its head. In addition, the unusual hardware design of the PIOS One will require some close QA work with Be to ensure compatibility, primarily in the boot code arena. PIOS expects to be shipping BeOS-ready machines by the time you read this, but the company has faced an uphill battle gaining traction in the quickly changing PowerPC market. As you'll discover in the sidebar Interview with Dave Haynie, PIOS's brief history has been tumultuous, though the company has held tenaciously to its vision. In an ideal world, a radically successful PIOS could be the factor that ensures continued support for PowerPC chips under BeOS. Only time and consumer spending patterns will tell. Epilogue In August of 1998, PIOS apparently came under the umbrella of another German company and/or product, called MetaBox (www.metabox.de). However, MetaBox's pages are not offered in both German and English, as were the pages on PIOS's original site. If you'd like to try and determine the status of the PIOS or MetaBox projects, you might want to try running the MetaBox pages through AltaVista's BabelFish translator (babelfish.altavista.com). At this writing, the future of the PIOS line appeared fuzzy, and inquiring e-mail was not returned.
With Be completely removed from the hardware scene and Apple having completely disconnected the once-thriving PowerPC clone market, the business argument for continued support of PowerPC chips under BeOS is threatened. Furthermore, the BeBox represented something cool and seemingly unreplaceable: The combination of superior RISC CPU technology with cheap, standard, and often superior I/O cards from the x86 world. PIOS represents a sort of "last hope" for a continuation of many of the ideas that drove the original BeBox. I recently discussed the origins of and prospects for PIOS with Dave Haynie, hardware project manager of PIOS and one of the "godfathers" of the Amiga architecture. A few weeks later, I get a call from a Mr. Stefan Domeyer at Amiga Technologies, the new Amiga arm of ESCOM GmbH. He would like to fly me and my good friend Andy Finkel to Germany to talk about The Future of the Amiga. In Germany, I learn they're planning to do it right. They want to hire Andy's 20-30 person software team and build a new PowerPC-based Amiga system, targeting the $500 price point that most Amigas sold around. Back in the States, we each write up formal proposals, and before I know it, I'm the head of hardware development for Amiga Technologies. In my copious spare time (I'm still working for Scala, Inc. at the time), I fly to Austin and Phoenix to meet with Motorola, I fly to Germany again, etc. Life isn't perfect. The PowerAmiga architecture I describe (look at today's MedixGX from Cyrix, put in PowerPC and Rambus, and you'll have a first-order approximation of what I was trying to do for AT) is too aggressive: Motorola doesn't even have a Rambus license; IBM does, but neither has PPC cores flexible enough to be reworked in short order (the goal was to finish in a year). But it was still possible to make low-cost systems using PPC602s, PPC603s, or some of the embedded chips, coupled with a "media processor" Motorola had in super-secret development with a partner in California, VM Labs, some kind of startup. I went to the '96 CeBIT show and gave a talk to selected developers on the Power Amiga architecture. While the $500 machine was not CHRP, we had plans from the get-go to build a new AmigaOS based on an OS-level HAL (see Windows NT for an example), so this could run not only on our $500 machine, but on any possible PowerPC machine one would care to support, including PReP, CHRP, and even old Amigas with PowerPC cards in them. This was all well received, but by the end of March, ESCOM wasn't paying their bills. In April, it became clear there were big problems with ESCOM, mainly from private mail from Stefan to me. He was looking for money to keep the project going. Later in April, Amiga Technologies dumped most of its technical staff. In May, I met with Mr. Domeyer, Andy, and another partner from Germany, Geerd Ebeling, and we formed PIOS. With the total collapse of ESCOM (which had been the second largest PC vendor in Germany), the Amiga technologies were being kicked loose, and the front-runner to buy them was apparently VIScorp. We met with VIScorp to discuss the idea of an Open Amiga platform. VIScorp, it seems, was a Chicago-based company, with some ex-Amiga/C [Commodore?] personnel, working on a kind of WebTV-style browser box, which would extract dedicated or Internet content embedded in analog TV signals. They used the AmigaOS to do this, and did not care about desktop systems. We formed an agreement with their technical people to develop a sort of co-op, where various pieces of the OS could be developed by interested parties, under the direction of a small intercompany council. So we could work on desktops, they could work on set-tops, others on maybe handhelds or whatever interested them. A month later, VIScorp, who had still not actually purchased the Amiga assets, was talking about making desktop Amiga systems. It got weirder and weirder, as they threatened legal action against anyone working on Amiga or Amiga clone systems. Ultimately, they went away, and the Amiga technology was once again homeless. By late summer, we had had our fill of this nonsense. Mr. Domeyer was out at the MacWorld Expo--PIOS was reselling Mac clones in the German market as a way to establish a presence and get into the PowerPC market at the time. He met with the Be, Inc. folks, not knowing I was already into BeOS myself. He called me, asking about BeOS, I immediately gave it the green light, and that become the new target. BeOS wasn't the AmigaOS in the sense that it would be good on a $500 machine, but it was also much more likely to enable the markets I was familiar with from the Amiga high end. That high end had been good for 50K-100K machines/year during most of Commodore's life; not great for Commodore, but plenty large enough for our purposes. That fall, I started working on the design.... I started working on the PIOS One in my garage, with about 1/3 of the development costs out of my own pocket. I had a very basic "midnight engineer"-type in-the-PC combination logic analyzer and slow-scan oscilloscope. I was shut down most of the summer of '97 due to our lack of higher-level equipment. While the computer revolution was founded in the garage, there's a big difference between working on an 8-bit computer at 1 MHz and a 64-bit (external) computer at 66+ MHz. Until last fall it was only me, but we managed to hire Thomas Rudloff, formerly of Phase V, who's working in Germany on additional PowerPC things, including our four-processor board and CPU modules for some of the PowerMac systems. My take on the whole cancellation was, as you can view most things in the PPC market, as a reaction to Apple. Now, Be's structure was clearly pro-software, as it had to be. You basically had Joe on the hardware side, everyone else on the software side (they may have gotten someone else for hardware before the end, I know they were looking). The discussions about the end of the BeBox ranged from "too costly to make" to "not our focus," but I suspect it was the whole notion of noncompetition. Apple has always had the problem of being in competition with its hardware vendors. Commodore had that too; even if we didn't have Amiga clones, the add-in pieces were always a bit risky for developers, because Commodore or Apple could come out with the same thing any time, on a much larger scale. If Be was in direct competition with Power or Motorola or any of the other supposed big licensees, it would be a problem. Another footnote: At this time, PIOS was the BeBox reseller in Germany, and while it wasn't a monstrous business, we were selling them faster than Be could deliver. We tried to negotiate for the rights to make the BeBox and all the leftover pieces at Be, but they apparently wanted too much money for this. If Motorola were to really push the architecture, I would favor something like the Alpha 21264 bus, rather than heading in Intel's direction. This is a 64-bit point-to-point bus (there's only two devices ever on the bus), which can run at 350 MHz today, a good 3.5 times faster than any Intel or PowerPC bus. SMP systems are managed with a system chip using an internal cross-point switch to main memory, rather than the traditional shared, arbitrated bus of Intel and Motorola today. The cool thing about the PIOS One is that, the way I did the CPU cards, if they did support this, or even the new "Max" bus (the first "Max" processors will run in old PPC-bus mode, but also offer a more advanced bus mode, yet to be supported by a Motorola system chip), I can offer an upgrade CPU module for the PIOS One that takes full advantage of this new bus. You don't get this in any other machine currently announced. For that matter, we could deliver a Pentium or Alpha module, if that seemed like a reasonable direction at some point. The CPU module is being presented as a free and open spec for anyone else to use, too. It's based mainly on PCI technology; it's not all that hard for anyone to duplicate anyway, but with 10+ years of experience doing CPU slots (since the Amiga 2000, in which some people today stick PowerPC boards, 11 years after the 2000 first shipped), I might have an idea or two others would miss. Converging on the MediaMuch has been made over the past few years of the confluence of our most common media delivery mechanisms. Every year, another study indicates that people are spending more time in front of computer screens and less time in front of televisions. One may make the argument that this is a good thing for our culture, as television viewing is generally a more passive activity than Web surfing or game playing. Interestingly, though, it's slowly becoming more difficult to tell television and the Web apart. The Web struggles to deliver an advertising model as successful as television's, TV adopts Web-like interfaces in sports coverage, cable channels specialize in niche topics as obscure as some Web sites, TVs acquire increasingly sophisticated onscreen menus that resemble point-and-click Web pages, flat-screen TVs borrow technology from laptop displays, digital broadcasting becomes mandatory in some areas ... the list goes on. According to Sony, it won't be long before televisions begin to break their display and computation functions into separate boxes, for independent upgradeability. Set-top boxes such as the WebTV system exemplify this crossover between old media delivery systems and new. It won't be long before televisions come preenabled with voice-recognition technology, displays in billions of colors, surround-sound stereo and Dolby noise reduction, and immersive, three-dimensional virtual reality. All of this causes pundits to ask questions like "Are computers becoming more like TVs, or vice versa?" The answer, of course, is yes. Both are true, and one can envision a point in the future when the distinction becomes negligible. Currently, most computer users lack a connection to the outside world capable of delivering a 3GB movie in 90 minutes, and even if they had that kind of throughput, most of the hardware/OS combinations out there would not be capable of presenting "download on demand" copies of The Terminator full-screen at 30 fps anyway. At the same time, non-Internet-enabled televisions don't offer the scope of choice users find online, and don't let users toggle over to work on a spreadsheet during the commercials . The first decade of the next millennium will likely bring high-bandwidth Internet to millions of homes, and faster processors inside high-definition televisions (HDTVs) will enable TVs to perform more computer-like tasks. Nor can we leave music distribution out of the picture. Just as you'll soon be able to log into blockbuster.com to download a midnight movie, you'll also be able to log into record labels' Web sites to rent or purchase audio tracks. The custom cassette tape from days of yore will give way to custom CDs burned on the home network server. Tracks will be paid for with virtual credit cards meting out micropayments measured in hundredths of a cent. One of the first "bridges" between computers, television, and hi-fi systems is the DVD, or Digital Versatile Disc, format. While DVD is getting off to a rocky start with standards wars that eclipse those waged between Betamax and VHS in the '70s, we'll eventually be able to swap DVD disks containing custom combinations of computer data, audio tracks, and video information effortlessly between the TV, stereo, and computer--which may, in turn, become a single device. Tying it all together will be the home network, which will finally rise above its current "geeks only" status and become the norm in modern households. The living room server will dish up movies, data, and audio to terminals scattered throughout the house, make your house look occupied while you're on vacation, relay images of your kids from the preschool to your work PC, answer your phone, take and deliver voice notes for other family members, auto-download this week's programming guide into your TV's memory, find a cure for gingivitis, and give you a pedicure every Tuesday at 3:00. You get the picture. Okay, a lot of that sounds like hype, but the writing's on the wall--all of our most important technologies are converging on a point, and all of them come back ultimately to the thing BeOS does best: juggling media. Every one of these technologies feeds perfectly into the realms Be has so carefully targeted. Of course, certain other operating system vendors have their eyes on the convergence prize as well, so it should be an interesting decade. But even if Bill somehow finds his way into your DVD player and set-top box, you'll still get to pick the OS your home network runs on. Embedded ChipsWhile we think of an operating system almost exclusively as an environment for the desktop or laptop computer, computing doesn't stop at the desktop. The physical world is getting "smarter," and it seems that the computer industry is hell-bent on installing a little CPU in every greeting card, movie theater seat, "one-time-use" camera, and wristwatch around. Not all of these devices require an operating system (in any traditional sense) to function, but many of them do. How do you think they synchronize the stoplights to make them turn red right before you get to them? A team of evil monkeys programming in some Transportation Department basement? Nope--embedded chips. Be has never announced plans to work with embedded chip makers to have a variant of BeOS implanted in circuit boards or ASICs (custom chips); that's not Be's media target, several companies already excel at this, and Be is nose-to-the-grindstone perfecting the MediaOS for desktop computers. On the other hand, BeOS has something going for it that the other mainstream OSs don't--it's incredibly compact and efficient. Though it's never been released to the public, Be once successfully squashed the OS down to its bare essentials and fit it onto a single bootable floppy, similar to the famed QNX demo disk (QNX is the maker of a compact operating system intended for customized, vertical applications). Be is too focused on their stated target right now to compete in the embedded chip market. Then again, play CEO for a moment and think about the sheer size and scope of the following industries. Ask yourself which of these would benefit from a stripped-down version of BeOS running behind the scenes:
Chapter Summary
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Please direct technical questions about this site to webmaster@peachpit.com.
Copyright © 1999 Peachpit Press and the respective authors.