The Be Newsletter will take a well-deserved holiday on the next two Wednesdays: December 25 and January 1. Look for a new edition of the newsletter in the new year: January 8, 1997!

Each profession has a set of criteria by which you can sort good work from, well... other work. Take software: Most programmers are able to write a piece of code that will compile (I can do this). Others can track down the tiniest bug and fix it (I'm borderline, here). And the gods can get it right the first time while keeping their code clean, small, and fast (forget it).

Hardware also has its benchmarks. Designing something that can be manufactured, that won't set your house on fire, and that's cheap is the hardware Parnassus. Unlike software, however, some of the hardware criteria are not just advisable—they're legally enforced: If you plan to sell your product to end users, you first have to get a gold star from the FCC.

FCC regulations establish physical limits within which your hardware is supposed to run. Just think about it: What if such rules were applied to software? What if you programmers had a government agency checking the quality and compactness of your code? Imagine sitting before a Federal Software Agency review board to explain why you're polling so much. Or who want you to translate your comments into an actual human language. Or who want you to... (Well, maybe I should stop this little fantasy right here. Just remember: Seg fault and you go to jail.)

Of course, out-of-date comments and lazy error-checking aren't going to reprogram your VCR or scramble your neighbor's cell-phone call.

One of the most important FCC regulations limits the amount of electromagnetic noise your computer can produce. All active electronic equipment produces such noise: Signals propagate through your board, which acts as an antenna. Some frequency bands—the lowest ones—are pretty easy to control because they need a big antenna to radiate any significant amount of energy. But high frequencies are pernicious; they sneak through any available electrical path, spill out any gap in a chassis, and spread all over the place. And unfortunately for the hardware engineer, computer components aren't getting any slower; as CPU clocks and bus rates get faster, the task of eliminating excess noise gets tougher.

There are different ways to bring a product within FCC guidelines once you have a prototype to play with, but nothing replaces good intuition in the design stage. After you've drawn a (hopefully) noise-free schematic, you can simulate your hardware in software. Unfortunately, good simulation tools are expensive and require a lot of time to learn and use.

At some point, you have to put your pencil down and send your schematic to a fabrication shop (or build it yourself). This, obviously, can be the most expensive step, and not one you want to have to re-do. When you get your toy back, it's time for the real test: You have to "scan" your product for noise.

The process of scanning is quite simple. You reproduce a potential working environment by plugging devices into each of the I/O ports of the system you're testing. The BeBox™ has 24 connectors, plus the graphic card, plus the CD headphones... The system has to run software that can exercise the computer as well as the various external devices (which, to get a realistic measurement, should be commercially available products). Then you put the computer on a stand that spins in front of an antenna that measures the noise. And your humble construction starts to spin...

Have you ever had this dream where you're a kid again, and you've arrived at school only to realize that you've forgotten to put your clothes on?

When the scan is over and you get the results, in which every imperfection in your work is magnified, you have the choice of fighting with the machine to lower the noise (inserting ferrites, playing with the mess of cables coming out of the box, adding gaskets to the chassis), going back to the (virtual) drawing board to rework your design—or you can hit the bars in an attempt to find your pants.

The 133 MHz BeBox complies with the FCC and European class B requirements; therefore, it can be sold to end users.

Apple's original announcement that they were shopping around for an OS was the start to an open discussion about Apple's ability to actually deliver a modern OS. The Copland project has ended with little doubt that it was a failure. As the January Macworld Expo approaches, so too does Apple's announcement about its future plans for the MacOS. Considerable discussion about Apple choices and which OS would be best have taken place in the trade press, inside software vendors, and in the general population.

At StarCode, we just want the issue to be settled one way or another. If the Apple deal goes through, great! We can step up our development efforts and support a larger team.

Of a great deal more importance to us is to be able to use the BeOS full-time for all the things that we have come to expect PCs to do. We don't think we're alone in our desire to have a fast, stable, modern OS to work and play on. So, in our desire to be good Be citizens, what to do?

Well, the first step is to pick our five favorite apps that we'd like to see on the BeOS. These could be Photoshop, Eudora, or even Doom. Second, we must e-mail at least one person at the respective companies, whether it's the webmaster, or the person who answers info@whatever.com, or the CEO—it doesn't matter. Third, make sure five friends do this as well with their favorite apps.

This has probably been the most noble cause ever to mail bomb a company. If we can get just a thousand Be aficionados to send e-mails by Christmas, we're guaranteed of changing some companies minds around the time of Macworld in San Francisco.

Whooo weee! Time sure does fly when you're having fun! This past year has been quite an exciting and tumultuous one. Be, Inc. as a company has gone from obscurity to limelight in a few short months. But all the hoopla surrounding the BeOS hasn't just been in the applications that we've shown at demos. Our developers have done quite a fine job of coming up with real applications for real-world use.

There are a number of notables, and we've highlighted a few in this newsletter. The bottom line is, you simply must take a look at the Be ftp site and the BeWare pages to get a good feel for what people have worked on and will continue to work on in the near future.

For once though, I'm not going to be long winded and give a big long story about what's gone by. Suffice it to say that a lot of time has passed, and many good things have been done. As a holiday gift, we have the source to the Clock application.

ftp://ftp.be.com/pub/Samples/clock.tgz

This is the last newsletter for the year, but it's not the last time you'll get sources. There are still a couple more things that will squeak out before Macworld, so keep an eye on the ftp site. Hopefully we'll be using this down time to catch up with actual tutorials.

The last Developer's kitchen was well attended, and a few developers were helped along to finish their efforts. We finished the year with a strong PowerMac port, and a promising future at Macworld. Speaking of which, there will be a Be Developer's Conference after the Macworld event on January 11th at the Hyatt Embarcadero in San Francisco. The general details are that the event will be held from 10 am to 6 pm or until we are kicked out. Look for more detailed information on our Web site soon.

I wonder if the era of the "free" Internet is coming to an end. For a couple of decades, the Internet grew in the relative obscurity of a community of UNIX users in university research laboratories. In the spirit of academic freedom, most everything was accessible, shared, and virtually free. For proficient users, the feeling of power and reach was exhilarating. More than five years ago, companies such as NetCom in San Jose started selling dial-up Internet access for what passed then for ridiculously low fixed fees. Mosaic appeared and the Net started to become accessible to normal, or at least less geeky people. We know what happened: Tens of millions of people (I leave the exact number to the professional sages) are now connected, and companies such as America Online and Compuserve have been forced to drastically alter their business models—to say nothing of their accounting methodologies.

But now we start hearing a different tune. Users complain about pesky servers, interrupted connections, slow or frozen downloads, cranky DNS servers, and the worldwide wait.

In many respects, we found an infrastructure and we clear- cut it. At least, that's the way the phone companies will describe it. Local calls are free or almost free. They're subsidized by long distance conversations. For these the local company gets an access fee, a cut of the long distance toll paid by the user to AT&T, MCI, and their competitors. Voice calls are measured in minutes, not hours. Now comes the friendly neighborhood ISP. The call to the access point is a local one, and once you hop on the Net, there's no more long distance toll rebated to the local phone companies. The Internet calls measure in hours, not minutes, and eat capacity at the local phone company. The development of the Net forces these companies to bring profit-free new capacity on line. Whatever we otherwise think of the phone companies, if they install another line at your home because you spend hours on the Web, they'll not get the same return for their investment. They feel ISPs and Net users have clear-cut the infrastructure without providing funds for replanting.

Turning to the potential for highly interactive, high- bandwidth multimedia on the Net, we must underline the word potential. Nowhere is the infrastructure capable of sustaining the peak bandwidth these data types require. What about the cable network and cable modems? This is another case of a tired infrastructure stretched well beyond its carrying capacity. It's so easy to add new users, new taps on a cable, at least in the theory of a broadcast model. We know what consumers think of the signal quality and service "enjoyed" on cable. When asked what he thought of the competition that cable operators might create for the local phone companies, one executive asked in return: "Would you trust these guys to carry your 911 call?" And in addition to the problematic quality of today's cable infrastructure, clear-cut as it is already, the Internet with all its problems still lies beyond the head end of the cable system.

Back to the Net, then. If the potential is to become reality, someone will have to pay for replanting, for creating more carrying capacity, or the navigators will discover that the trees have run out. Who will pay to create new capacity? Users, advertisers, content providers, the taxpayer? Are we going to have several classes of service for IP packets, as we have for letters and parcels? I hope the answer to the latter question is yes, so taxpayers don't have to pay for services they may or may not use. It might be feasible. After all, this is the country where the Postal Service seems to balance its budget. Let's hope the IP Service does the same for basic net services and that we'll see a range of faster IP courier services emerge as well.

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.