|
Be Newsletter
Issue 54, December 18, 1996
Table of Contents
Editorial Note
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!
BE ENGINEERING INSIGHTS: FCC Wonderland
By Guillaume Desmarets
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(TM)
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.
BE DEVELOPER TALK: Good Be Citizens
By Carlin Wiegner and Michael Klingbeil
StarCode Software, Inc.
E-mail: cew@starcode.com
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.
PackageBuilder and Beyond
Our PackageBuilder product will soon be in its third
preliminary release. Aside from the usual bug fixes, this
version finally sees the addition of binary patching
capabilities. Following this release, we'll begin planning
for the release of version 1.0, which should be available at
about the same time as DR9 of the BeOS. For file-system
intensive programs like our installer, the changeover to DR9
will likely involve considerable work. Our hope is that
early planning can make this as smooth a transition as
possible, both for us and for developers using our product.
In addition, with the release of 1.0 we finally hope to have
a preliminary software uninstaller. The uninstaller will
capitalize on the new and improved database, thus providing
a quick and foolproof way to track installed software.
As usual we welcome feedback and product suggestions from
fellow users and developers. The more feedback we see, the
better we can make PackageBuilder 2.0. Additionally, if you
have a specific installation need for your software, we'd
love to come up with a speedy and effective solution for
you. Let us know.
StarCode Software and Macworld San Francisco
StarCode Software will be demoing at Be's booth at Macworld
San Francisco. We'll be showing the software, including
binary patching (which we demoed at the December developer
kitchen), and announcing our pricing. Come by and see us.
News from the Front
By William Adams
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/interface_kit/obsolete/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.
FOR THE LAST TIME
Since this is the last newsletter of the year, for one last
time I want to say BOOOM BOOOM BOOOM! That's the last
thumping of the drum to get developers to polish up their
applications if they want them to be shown at Macworld on
January 7. I'm speaking primarily to the crowd of developers
who will not actually be in attendance, but who want their
applications to be shown in some way. Get them uploaded to
the ftp site as soon as you can, so that we can become
familiar enough with them to show them with pride.
I bought my first BeBox about a year ago. I spent that first
holiday vacation porting as many apps from all over the
place as I could. Three releases of the OS later, I came to
realize that I liked what I was playing with enough to
actually join the company that was giving it to me. I don't
regret my decision for a moment, and I'm having the time of
my life in this venture. I hope we're spreading the same
amount of excitement to the rest of our development
community.
Clear-cutting
By Jean-Louis Gassée
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 Summary
BeDevTalk is an unmoderated discussion group that's a forum
for the exchange of technical information, suggestions,
questions, mythology, and suspicions. In this column, we
summarize some of the active threads, listed by their subject
lines as they appear, verbatim, in the group.
To subscribe to BeDevTalk, visit the mailing list page on
our Web site: http://www.be.com/aboutbe/mailinglists.html.
- -----WEEK 3---------------------------
Subject: Better thread control
AKA: Thoughts
More discussion of threads, semaphores, and (somehow)
sockets. The primary topic was the efficiency of semaphores
(which, in this debate, means multithreadedness) in the
light of the context-switch overhead: At what point does
multithreading lose its appeal because of the overhead
incurred by hitting the controlling semaphores? No clear
answers, here, but some numbers were thrown around.
- -----WEEK 3---------------------------
Subject: Preferences and version numbers
Where should version information go, and how should it be
accessed? Is a binary version (of the version) necessary so
installation tools can operate properly? Also, what do you
have to do to satisfy copyright requirements? According to
one of our listeners, copyright info must be presented to
the user when the app is launched, and a human-readable (and
so hexdump-displayable) version must be embedded in the
binary. But is this so? Another listener claimed that the
"must be presented to the user" rule refers to license
agreements, not copyrights.
- -----WEEK 2---------------------------
Subject: Accessing Preferences
More talk about where preferences info should be stored in a
multi-user system. Various existing methods were described
and considered (but mostly dismissed). The database as a
compendium of preference values keyed to individual users is
the popular choice, although there are still some
"preference directory" holdouts.
- -----WEEK 2---------------------------
Subject: BWindowScreen
AKA: Multiple Monitors
This thread became a discussion of multiple displays. The
app server doesn't support multiple heads yet, but once it
does, how should they be used? Should each monitor be a
separate workspace? There was some speculation that
splitting a single workspace over multiple displays would be
inefficient. Others argued that you could (theoretically)
split a single window between monitors with no significant
overhead, so one-monitor/one-workspace isn't a necessary
restriction.
THE BE LINE: Note that you *can* plug in multiple gfx cards
and monitors to develop a video driver, but the app server
will only talk to the first card that it finds. For more
info on video driver development, see William Adams' column
in last week's Newsletter (#53).
- -----NEW---------------------------
Subject: Mail system design.
An initial query, "why is there a mail_daemon?" elicited a
number of quick (and well-tuned) responses: So you can
easily plug in your own mail application. As Jake Hamby put
it:
"With mail_daemon, I just make the BMailMessage and then it
takes on whatever user prefs have been set: connection
frequency, POP/SMTP options, whatever. And as Jon Ragnarsson
commented, it was frighteningly simple."
This led some readers to ask for even more "pluggable"
servers, for http, sockets, ftp, etc.
- -----NEW---------------------------
Subject: access exception in __ptr_glue
This one's worth repeating (and committing to memory):
Q: Any ideas as to what a "data access exception" in
"__ptr_glue" means?
A: [quoting Jon Watte's reply] "__ptr_glue is the place all
calls through function pointers and calls through virtual
methods go. You've either called a bad function pointer, or
a virtual function of a bad object."
- -----NEW---------------------------
Subject: Messaging speed and efficiency.
AKA: Async I/O via BMessages
What's the best way to handle hundreds of messages a second?
Can the BMessage system keep up? Also, what does the kernel
use for sending messages? Ports (according to one listener)
don't seem fast enough to explain the responsiveness of the
machine.
THE BE LINE: (from Dominic Giampaolo) "I believe we can send
around 7,000 or so 64 byte messages per second on a 66 MHz
BeBox and even more on the 133s. Try to make your messages a
power of 2 in size: It's actually faster to send 64 bytes
than to send 62." (Dominic off)
The kernel indeed uses ports, which are faster than the
current suspicion.
|
