526 lines
38 KiB
HTML
526 lines
38 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Be Newsletters - Volume 2: 1997</title><link rel="stylesheet" href="be_newsletter.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
|
||
<link rel="stylesheet" type="text/css" href="be_newsletter_ie.css" />
|
||
<![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Be Newsletters" /><link rel="up" href="volume2.html" title="Volume 2: 1997" /><link rel="prev" href="Issue2-4.html" title="Issue 2-4, January 29, 1997" /><link rel="next" href="Issue2-6.html" title="Issue 2-6, February 12, 1997" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue2-4.html" title="Issue 2-4, January 29, 1997"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume2.html" title="Volume 2: 1997"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue2-6.html" title="Issue 2-6, February 12, 1997"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">Be Newsletters - Volume 2: 1997</div></div><div id="headerB">Prev: <a href="Issue2-4.html">Issue 2-4, January 29, 1997</a> Up: <a href="volume2.html">Volume 2: 1997</a> Next: <a href="Issue2-6.html">Issue 2-6, February 12, 1997</a></div><hr /></div><div class="article"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Issue2-5"></a>Issue 2-5, February 5, 1997</h2></div></div></div><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering2-5"></a>Be Engineering Insights: Dogcows and Goodbyes</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Joe</span> <span class="surname">Palmer</span></span></div></div></div><p>
|
||
On my way home last night I passed under highway 280 on Alpine Road. It
|
||
wasn't a momentous or meaningful occasion—I drive that way home almost
|
||
every night—but you see there is a pothole under the bridge that looks
|
||
a little like Clarus the dogcow (aka "Moof"). Passing over it and
|
||
marveling at the randomness of the universe that would causes a pothole
|
||
in the shape of a famous Page Setup dialog box icon to be created is just
|
||
one of the little things that I'll miss about working at Be. He's been
|
||
there for a while now, and with the erosion of the road surface he's put
|
||
on a little weight.
|
||
</p><p>
|
||
I can't say why that sticks in my mind today, but this afternoon as I
|
||
drove back from Mountain View, where I registered a domain name for my
|
||
new venture, I was reminded of the feelings I had 18 years ago moving out
|
||
of my mother's home in Green Bay, Wisconsin, to make my future in
|
||
California. As I drove my '69 Red VW Van, "Fritz," down Highway 1, I was
|
||
overcome with mixed feelings. When I looked in the rear view mirror I
|
||
felt remorse and loss and felt an urge to drive back and throw out the
|
||
anchor in Green Bay, but the future was there in the windshield. Up there
|
||
I had a wide-screen view of a starkly new world. Warm air caressed my
|
||
arms through the open windows, assailing my nose with sea, dirt, and
|
||
flowers. The roar of the Pacific called to me, "Hey! where have you been
|
||
all your life?"
|
||
</p><p>
|
||
With every corner I felt a flush of life, newness, and anticipation. I
|
||
had this cassette tape that my friend John had made for me. When I passed
|
||
Big Sur I plugged it into the player, having saved it for just that
|
||
moment. The Grateful Dead's Estimated Prophet
|
||
<sup>[<a id="id547021" href="#ftn.id547021" class="footnote">1</a>]</sup>
|
||
came pouring forth. I never felt more alive. I was home.
|
||
</p><p>
|
||
Be is leaving the hardware business, and I am leaving Be, and how do I
|
||
feel? I feel good. I feel good because it's the right thing for Be to do.
|
||
You as developers should feel good about it too, because it means that Be
|
||
is determined to make decisions that will benefit the long-term viability
|
||
of the BeOS, and your BeOS applications. Be has proven that it's willing
|
||
to stop doing something when it stops making sense. As someone personally
|
||
affected by this decision, I think it is my place to say that this is a
|
||
remarkably rare virtue these days. I'm very proud of the work I've done
|
||
for Be and consider it to be the best work I've ever done, but now my job
|
||
here is done. The <span class="trademark">BeBox</span>™ gave the BeOS a safe nursery at a time when
|
||
other platforms were far more hostile to yet another (unproven) OS. The
|
||
BeBox proved to be a pedestal on which to display the capabilities of the
|
||
OS. Those of you who've been frightened
|
||
<sup>[<a id="id547039" href="#ftn.id547039" class="footnote">2</a>]</sup>
|
||
by my demos will remember that
|
||
I've always stressed that the software is the most important thing, and
|
||
that the hardware was only there to run the software. Now the BeOS has
|
||
found its way to the Power Mac, and thousands of new developers can see
|
||
what the shouting is all about. (Hint: It's the OS, stupid.)
|
||
</p><p>
|
||
I like to make up metaphors, as Jean Louis will attest, and this one
|
||
comes to mind today. On a warm summer night in 1969, I stood in my yard
|
||
in northern Minnesota and looked at the moon. There was no traffic that
|
||
night, and every house in view was darkened, but lit from within by the
|
||
bluish glow of televisions tuned to Tranquillity base. A few days earlier
|
||
a Saturn rocket had lifted from the Kennedy space center, a noisy
|
||
necessity to putting man on the moon. The booster did its job and placed
|
||
the rest of the ship in low earth orbit. Then its job was done, and the
|
||
attention of the world turned to the moon. I like to think that the BeBox
|
||
is in some way related to that thunderous booster. Its job of lifting
|
||
both Be and the BeOS safely into orbit is complete, but the focus must
|
||
now be on the OS and applications. While it might be romantic for a
|
||
little company to be in the computer hardware business (let's stretch
|
||
this metaphor till it creaks), think of the odds of success for our hero,
|
||
Mr. Armstrong, should he have elected to bring that booster along with
|
||
him to the Sea of Tranquillity.
|
||
</p><p>
|
||
For those of you wondering what I might be up to next, I'm now dreaming
|
||
the Silicon Valley dream and will be putting together my first start up.
|
||
I'd always planned to start my own company one day when Be was
|
||
successful, but now with Be leaving the hardware business, I guess today
|
||
is a good day to start a new business.
|
||
</p><p>
|
||
I'm not prepared to go public with my product plans, but my new venture
|
||
is called "Video Storage Systems," so you may safely guess it involves
|
||
video hardware, and yes it will work with the BeBox. I haven't gotten
|
||
confirmation on my new domain name yet so I won't reveal it, but those of
|
||
you interested can watch for an announcement on my personal home page
|
||
full of Ranma 1/2 Fan fictions: http://www.best.com/~jpalmer
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering2-5-2"></a>Be Engineering Insights: Graphics Drivers Are Hardware Devices Too</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Scott</span> <span class="surname">Bronson</span></span></div></div></div><p>
|
||
First, an introduction. Consider for a moment the expressive simplicity
|
||
of a file. A wide number of things in this world, both conceptual and
|
||
physical, can be expressed in terms of open, close, read, write, and
|
||
seek. And, of course, ioctl fills in any metaphor imperfections. Eek!
|
||
Maybe I'd better get outside, but not until I explore this further.
|
||
</p><p>
|
||
Device drivers are particularly well suited for a file metaphor. All
|
||
hardware devices need to be opened and closed. Reading, writing, and
|
||
seeking are optional but useful when the metaphor fits. In fact, you can
|
||
see that the BeOS has been tending in this direction for years. In DR8
|
||
and previously, to open serial port 2, you:
|
||
</p><pre class="programlisting">
|
||
<span class="type">int</span> <code class="varname">fd</code> = <code class="function">open</code>( "/dev/serial2", <code class="constant">O_RDWR</code> );
|
||
</pre><p>
|
||
This will be fully realized in DR9. <code class="filename">/dev/serial2</code> will no longer be a
|
||
pseudo-pathname. Finally the <code class="filename">/dev</code> directory will be a complete and
|
||
upstanding member of the DR9 file system. You'll be able to use POSIX
|
||
calls, the BeOS file system API, and even shell commands to manipulate
|
||
devices. For instance, to list all installed serial ports:
|
||
</p><pre class="screen">
|
||
$ ls -l /dev/serial
|
||
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 Modem Port
|
||
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 Printer Port
|
||
</pre><p>
|
||
Even though these aren't files, their charade is very convincing. There
|
||
are only two differences to notice here. In the first column, where 'd'
|
||
normally indicates a directory and '-' a file, 'c' indicates a character
|
||
device and 'b' indicates block. Also, these files appear to be zero bytes
|
||
in size. Were you to open one, however, you would find that reading and
|
||
writing would work as expected and seeking would be ignored.
|
||
</p><p>
|
||
As an example, say it's nighttime, and for now you want your modem to
|
||
operate silently. If your modem or terminal program didn't come with this
|
||
feature (most don't), have no fear. Using the shell to send the modem the
|
||
appropriate AT command is as simple as:
|
||
</p><pre class="screen">
|
||
$ cd /dev/serial
|
||
$ echo "AT &M0" > "Modem Port"
|
||
</pre><p>
|
||
To save typing and memorization, this would fit nicely into an alias or
|
||
shell script. Flexible, simple, standard. I love it.
|
||
</p><p>
|
||
Another great DR9 benefit is that graphics drivers will move back into
|
||
the kernel, rejoining their driver siblings. This allows graphics drivers
|
||
to service and synch to VBLs, perform DMA, respond to drawing-completed
|
||
interrupts, and do just about anything else that would be expected of any
|
||
self- respecting driver. This, of course, means that the boot process
|
||
will be quite different.
|
||
</p><p>
|
||
When the kernel is starting up, it asks each driver in the
|
||
<code class="filename">/system/drivers</code> directory to
|
||
install itself. The driver will interrogate
|
||
the system, installing one entry per hardware device found into the
|
||
<code class="filename">/dev</code>
|
||
directory. All graphics drivers will ask to be installed into
|
||
<code class="filename">/dev/graphics</code>, serial drivers into
|
||
<code class="filename">/dev/serial</code>, and so on.
|
||
</p><p>
|
||
For example, assume a particularly well-equipped system has a TwinTurbo
|
||
128 and two Xclaim VR cards installed. The IMS driver will find its card
|
||
and create its "TwinTurbo 128"
|
||
<code class="filename">/dev/graphics</code> device. The ATI driver will
|
||
find the two Xclaim VR cards and install a unique entry for each. All
|
||
other graphics drivers in <code class="filename">/system/drivers</code> (S3, Cirrus, and so on) won't
|
||
find appropriate hardware and therefore won't install anything into
|
||
<code class="filename">/dev</code>.
|
||
This would be the result:
|
||
</p><pre class="screen">
|
||
$ ls -l /dev/graphics
|
||
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 TwinTurbo 128
|
||
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 Xclaim VR (Slot A1)
|
||
crwxrwxrwx 1 elvis 0 0, 0 Jan 30 16:33 Xclaim VR (Slot B4)
|
||
</pre><p>
|
||
Later in the boot process, the Application Server starts up and opens and
|
||
uses the graphics devices found in <code class="filename">/dev/graphics</code>. It will not, however,
|
||
coddle them as it has in the past. The driver will now (as appropriate)
|
||
have to enable its device's PCI spaces, initialize its hardware, and even
|
||
map its own memory spaces. Don't worry, we'll tell you how.
|
||
</p><p>
|
||
Notice that nowhere in this process has a PCI-centric assumption been
|
||
made. Feel like getting that dusty ISA VGA card working? Remember those
|
||
early PowerBook SCSI displays? The possibilities are wide open.
|
||
</p><p>
|
||
All interaction with a graphics driver will be through ioctl. Read and
|
||
write will do nothing. In addition to the standard <code class="methodname">Get/SetRaster</code>,
|
||
<code class="methodname">Get/SetIndexedColor</code> and <code class="methodname">Get/SetGamma</code> requests, we'll include
|
||
<code class="methodname">Get/SetPowerState</code> for VESA power management and GetSense for Apple Cable
|
||
Sense. VESA's DDC (Display Data Channel) won't make it into DR9, but
|
||
we'll leave room for it.
|
||
</p><p>
|
||
An important distinction: The kernel driver only sets up the frame
|
||
buffer; it doesn't draw. Drawing using hardware acceleration is finicky,
|
||
difficult, and subject to very different requirements than kernel
|
||
graphics drivers. Therefore, another piece of code will be called upon to
|
||
draw. The final acceleration architecture won't be in place when DR9
|
||
ships, so we'll have to continue to put up with the copious synching
|
||
performed by DR8 for now. But don't worry, we won't have to put up with
|
||
it for long.
|
||
</p><p>
|
||
We'll include a compatibility driver that will support all loyal DR8
|
||
drivers, easing DR9 adoption. Don't hesitate to start using that
|
||
Millenium or Trio64V+ card; its driver will continue to work.
|
||
</p><p>
|
||
Is it any wonder I'm excited?
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="News2-5"></a>News From The Front</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">William</span> <span class="surname">Adams</span></span></div></div></div><p>
|
||
My daughter has had this one comfort since birth. It's a multicolored
|
||
segmented snake. Its name is Annie. My daughter likes to hold onto it
|
||
because of the neat colors, and some of the segments make a crinkly
|
||
sounds or have bells in them.
|
||
</p><p>
|
||
We like her to experience new things, though. So we've introduced her to
|
||
new toys which don't have the same features as Annie. Usually she's a bit
|
||
reluctant at the start, but then she really warms up to it and has a good
|
||
time. One of her current favorites is this four-wheel car thing that she
|
||
can ride around the house with the help of some people power... Put your
|
||
feet up... Wheee. By embracing the car, she's found that she can go more
|
||
places and have more fun than she could with Annie alone. Annie still
|
||
serves her purpose but has been relegated to night duty in her crib.
|
||
</p><p>
|
||
And so... This week, as promised, we have new serial support for the
|
||
Power Mac version of the BeOS. When the MacTech CD went out, we didn't
|
||
have support for PPP because we didn't quite get the serial driver
|
||
working by the time the CD needed to be pressed. Since then, many users
|
||
have lamented the fact that they couldn't connect to the Internet from
|
||
their new BeOS Power Mac. Well, now we remedy the situation. The caveats:
|
||
</p><p>
|
||
Truly supported PPP won't really be available until DR9. That's to say,
|
||
we're anxious to hear how things are going for you, but our main work is
|
||
concentrating on DR9, so if there's an obscure problem, it may not be
|
||
fixed until DR9.
|
||
</p><p>
|
||
PPP has been tested with a few modems on a few Macs, but we haven't done
|
||
extensive testing with all configurations. Here you can possibly help us.
|
||
When you have a configuration that works, let us know.
|
||
</p><p>
|
||
You must have a thick skin and patience to use a developer's release, and
|
||
this software is offered in the same spirit.
|
||
</p><p>
|
||
ftp://ftp.be.com/pub/dr8_update/macserial.tgz
|
||
</p><p>
|
||
Before joining Be I did a lot of BeOS software that ended up at my own
|
||
Web site and never at the Be ftp site. One of the pieces that I did was
|
||
called the esoteric library. This was a library of things that are useful
|
||
for programming in C++. I want to use these thingies in some of our
|
||
tutorials, so I'm bringing them into the fold.
|
||
</p><p>
|
||
ftp://ftp.be.com/pub/Samples/bebits.tgz
|
||
</p><p>
|
||
Take a look. Utilities, sorting algorithms, container classes, that sort
|
||
of thing. Of course the standard C++ library will cover some of it, but
|
||
not all of it.
|
||
</p><p>
|
||
Geoff Woodcock is at it again. Geoff has a wild hair to do networking
|
||
stuff, and he wanted to create a tutorial that was fun and showed off
|
||
networking. So he's come up with this multi-user drawing thingy that
|
||
allows you to do drawing over the net. The tutorial will not be available
|
||
until next week some time, but I thought I'd mention it anyway. We'll be
|
||
working on three or four more DR8-specific tutorials before we move on to
|
||
preparing for DR9.
|
||
</p><p>
|
||
And how do we get to DR9? Well, last week I sort of hinted at wanting get
|
||
apps up and running before DR9 actually ships out the door. What I'm
|
||
thinking is that we want to have a porting lab. That is, an opportunity
|
||
for developers to come to Be a little before DR9 ships to port their
|
||
wares. I think we can benefit from having apps ported before DR9 shows
|
||
up, so we don't have to send out a disk with only our demos available. We
|
||
want to highlight the work of our third-party developers and give them
|
||
early exposure, and I see this as an excellent opportunity.
|
||
</p><p>
|
||
So if you think you would want to participate in such an event, please
|
||
send me e-mail (wadams@be.com). It promises to be an exciting time, and
|
||
no doubt you'll have a lot of fun being the first on the block. No dates
|
||
or other details have been set yet, but we want to know whether it's
|
||
worth pursuing. Of course space will be extremely limited, so only think
|
||
about coming if you absolutely want to get early exposure.
|
||
</p><p>
|
||
As DR9 approaches, we'll see some of our developers turn toward seriously
|
||
commercializing their products. One thing that the Be platform has
|
||
offered is extremely high exposure for the smaller developer. But there's
|
||
one thing missing. Small developers want to code. Some of them want to
|
||
run companies and become big developers. For those who don't want to make
|
||
the big time, but want to be rewarded for their efforts, shareware is
|
||
often an option. Others will want to go with a more traditional
|
||
publishing route, with advertising and the like.
|
||
</p><p>
|
||
One of the things that Be Developer Services can do is help developers
|
||
bring their products to fruition. That is, helping with suggestions on
|
||
commercialization, helping put developers in contact with publishers, and
|
||
helping put together partners that make sense.
|
||
</p><p>
|
||
So you can look forward to our getting more into your business if that's
|
||
what you desire. Our mission isn't only to help you program but to make
|
||
sure that the fruits of your labors bring you commercial success.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id547484"></a>Mailing List Mumbo Jumbo</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Michael</span> <span class="surname">Alderete</span></span></div></div></div><p>
|
||
Be runs six e-mail mailing lists. You can learn about the nuts and bolts
|
||
of what they are, how to subscribe and unsubscribe, and other information
|
||
on the Be Web site:
|
||
</p><p>
|
||
http://www.be.com/aboutbe/mailinglists.html
|
||
</p><p>
|
||
The recent publicity surrounding Be in the wake of Macworld Expo at the
|
||
beginning of the year has lead to a significant increase in the number of
|
||
people subscribed to our various mailing lists. With this increase in
|
||
subscribers, we've started receiving a larger number of questions about
|
||
the lists that aren't necessarily covered by the Web page.
|
||
</p><p>
|
||
I'm the guy who gets to answer all those questions.
|
||
</p><p>
|
||
So I'd like to tell you a bit about the lists, some recent history, why
|
||
certain things happen, and what's going to change in the coming month or
|
||
two.
|
||
</p><p>
|
||
First of all, the server itself is a PowerMac 7100/80 running ListSTAR
|
||
1.1, from Star*Nine/QuarterDeck. Under normal circumstances, this
|
||
combination is more than capable of handling the dozens to hundreds of
|
||
messages that go out to several hundred subscribers every day.
|
||
</p><p>
|
||
Over the holidays and through Macworld, the server developed some disk
|
||
and preferences problems and was crashing on a very regular basis,
|
||
resulting in delayed mail to list subscribers. This was, to say the
|
||
least, very irritating, but a complete rebuild of the server three weeks
|
||
ago has greatly improved stability.
|
||
</p><p>
|
||
Also during Macworld, Be sent four press releases to the BeInfo list from
|
||
a machine in our booth on the show floor. Some quirk in the show network
|
||
apparently resulted in each of the messages being sent multiple times. It
|
||
wasn't the list server's fault, it actually received the messages
|
||
multiple times and faithfully sent them on.
|
||
</p><p>
|
||
More recently, and probably due to the bombardment that happened during
|
||
Macworld, people have been noticing and commenting that they receive more
|
||
than one copy of the Be Newsletter each week. These comments generally
|
||
come to Valerie Peyre, the Newsletter's editor, and it was she that
|
||
dragooned, er, suggested I write an article explaining the phenomenon.
|
||
</p><p>
|
||
When a person receives multiple copies of the Be Newsletter, it's
|
||
generally for a simple reason: They're subscribed to more than one Be
|
||
mailing list, and each list was sent a copy of the Newsletter. The person
|
||
receives one copy from each list (I receive four copies of the Newsletter
|
||
each week!).
|
||
</p><p>
|
||
You can see that this is happening by examining the "To:" field of each
|
||
message. The four lists to which the Newsletter is sent each week should
|
||
have unique "To:" field entries:
|
||
</p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><thead><tr><th>List Name</th><th>"To:" Field</th></tr></thead><tbody><tr><td>BeInfo</td><td>beinfo@be.com</td></tr><tr><td>BeDevNews</td><td>bedevnews@be.com</td></tr><tr><td>BeUserGroup</td><td>beusergroup@be.com</td></tr><tr><td>BeResellerNews</td><td>beresellernews@be.com</td></tr></tbody></table></div><p>
|
||
Of course, a reasonable person might suggest that there's no reason to
|
||
receive multiple copies of the Newsletter, even if subscribed to multiple
|
||
lists. Indeed, I agree! Later this month I will test and implement a
|
||
separate, hidden list just for sending out the Be Newsletter.
|
||
</p><p>
|
||
Once this solution is working you should receive one copy of the Be
|
||
Newsletter—no more, no less. Then hopefully people won't feel as
|
||
though Be is mail bombing them. At least, not until this fall's Macworld
|
||
Expo in Boston.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Gassee2-5"></a>Exiting the Hardware Business</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Jean-Louis</span> <span class="surname">Gassée</span></span></div></div></div><p>
|
||
Let me start with an apology. When we stated we'd provide software
|
||
support for BeBoxes for at least 12 months, we got our just desserts, a
|
||
swift e-mail lashing. We saw the errors of our ways and will provide
|
||
software support for at least 3 years. I apologize for the frustration we
|
||
created, and I am grateful for the feedback and for the opportunity to
|
||
quickly correct the situation.
|
||
</p><p>
|
||
Now, why do we exit the hardware business? When we started Be,
|
||
multiprocessing didn't exist on desktop PCs, only on servers. Once you've
|
||
paid for the entire infrastructure of a personal computer, we thought,
|
||
the cost of one or a small number of processors is but a modest addition
|
||
to the whole bill of materials. More important, perhaps, we thought
|
||
symmetric multiprocessing, SMP, a type of architecture where all
|
||
processors are used in the same fashion, couldn't be felicitously
|
||
retrofitted on a design. To work well, to offer all the benefits it
|
||
promised, SMP had to be designed in from the very beginning.
|
||
</p><p>
|
||
So, we designed SMP hardware. With the AT&T Hobbit at first; the PowerPC
|
||
didn't exist then, and AT&T's processor was fast and inexpensive. Fast,
|
||
but not exceedingly fast. This started us on healthy habits of getting
|
||
good performance from less than turbo-compressed hardware. When the
|
||
PowerPC appeared and AT&T helped us move to our new target, we enjoyed
|
||
the sudden boost, even on the slowest member of the PowerPC family, the
|
||
66 MHz 603.
|
||
</p><p>
|
||
Later, a strange idea came to us: Porting our software to the
|
||
highest-volume PowerPC design, the family of Power Macs and clones. As a
|
||
result, Be developers gained a broader playing field, and we started a
|
||
happy partnership with Power Computing. Not only did our young OS shine
|
||
on a larger number of machines, but multiprocessor Power Macs moved out
|
||
of the system software orphanage. Previously, they were condemned to
|
||
hacked applications. Neither the OS nor standard applications could use
|
||
the extra hardware. On the Be platform, all software automatically
|
||
benefits from more processors. A four-processor DayStar machine draws
|
||
strong reactions from the audience, achieving more impressive performance
|
||
than much costlier workstations.
|
||
</p><p>
|
||
We were watching two trends. First, the total value of our software to
|
||
all participants, developers, users, hardware partners, and ourselves
|
||
increases with the number of users. Not really a surprise, but our
|
||
migrating to the Power Mac family accomplished such an increase. Second,
|
||
and speaking of the Power Mac family, there is now a healthy Mac clone
|
||
community. To wit, a MacWeek story
|
||
(http://www.macweek.com/mw_1105/nw_sales.html), in which Pieter Hartsook,
|
||
Apple vice president of marketing analysis and research, estimated that
|
||
clone vendors shipped 100,000 to 120,000 machines during the fourth
|
||
quarter. We came to feel there was little we brought to the PowerPC camp
|
||
now that MP machines were available and more accepted.
|
||
</p><p>
|
||
So we decided to focus on software and on doing whatever we could to help
|
||
the PowerPC build momentum. Of course, we're aware of our minuscule size;
|
||
a 55-person company in Menlo Park can't influence the PowerPC platform as
|
||
much as its largest player, Apple. But we feel we can do the most good by
|
||
focusing our resources on adding value to the largest possible number of
|
||
PowerPC machines.
|
||
</p><p>
|
||
Unfortunately, it's not that simple. On the human side, we're losing Joe
|
||
Palmer, our Director of Hardware Engineering. Joe's fine work put us in
|
||
orbit. He himself uses the booster rocket metaphor to describe the role
|
||
the BeBox played for the Be community. We'll miss Joe's presence, his
|
||
work, his endless supply of metaphors, especially ones that require
|
||
lengthy explanations for this immigrant, his demonstrations. We get to
|
||
keep the memories and the good feeling of being in the debt of such a
|
||
classy man.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="BeDevTalk2-5"></a>BeDevTalk Summary</h2></div></div></div><p>
|
||
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.
|
||
</p><p>
|
||
To subscribe to BeDevTalk, visit the mailing list page on our web site:
|
||
http://www.be.com/aboutbe/mailinglists.html.
|
||
</p><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id547800"></a>WEEK 2</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id547806"></a>Subject: GUI (in)consistency</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: Applications without windows</h5></div></div></div><p>
|
||
More desktop UI talk:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
Should all app menus be collected into a centralized location so
|
||
you can, for example, switch among them quickly? What if there are
|
||
tens or hundreds of apps running?
|
||
</p></li><li><p>
|
||
Should the method for making a running (and possibly idle)
|
||
application be the active application be different from launching the
|
||
application in the first place?
|
||
</p></li><li><p>
|
||
Certain GUI functions could be split between separate handler and
|
||
"displayer" apps. For example, a Web browser could be divided into a
|
||
net-crawling, image-caching back end, and an HTML-displaying front
|
||
end. Fronts and backs could be mixed and matched.
|
||
</p></li><li><p>
|
||
The BeOS should have "zoomable" process control. You could zoom
|
||
out to see all apps, zoom in to see just user apps, zoom in more to
|
||
see the threads of a certain team, and so on.
|
||
</p></li></ul><p>
|
||
The GUI discussions spilled into mutli-user land. Specifically, the
|
||
evilness of root (or "administrator") was debated. But, some folks
|
||
wondered, how do you create a secure multi-user system without a root
|
||
permission level? Delegating permission seems to be popular: Power is
|
||
distributed among (as Loren Wilton put it)...
|
||
</p><p>
|
||
“<span class="quote">...a pantheon of small local gods... [who] don't have the power on
|
||
their own or communitively to erase the trails of their actions.</span>”
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id547876"></a>Subject: Tracker suggestion</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: A Better name for Tracker?</h5></div></div></div><p>
|
||
Practical Tracker suggestions have pretty much bottomed out. The name
|
||
mail continues.
|
||
</p></div></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id547894"></a>NEW</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id547900"></a>Subject: Be's hardware plans</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">
|
||
AKA: Very, very, very Bad Be...<br />
|
||
AKA: No more BeBox HW - whence MIDI?<br />
|
||
AKA: Good Audio<br />
|
||
[and others]
|
||
</h5></div></div></div><p>
|
||
The hot topic of the week was the announcement that Be is getting out
|
||
of the hardware business. A number of developers were understandably
|
||
agitated by this move; some characterized it as a betrayal. Others
|
||
mourned the passing of the BeBox but saw it as an economic
|
||
inevitability. And there was even some scattered applause to commend
|
||
the decision.
|
||
</p><p>
|
||
Some specific (and relatively unemotional) topics:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
Hardware Abstraction Layer (HAL)<br />
|
||
Be's platform support will naturally need to be more generic. Will
|
||
this make Be see that hard-wiring parts of the kernel to support
|
||
specific platforms is a bad idea? Dominic Giampaolo briefly described
|
||
Be's plan to move platform-specific components (file systems and
|
||
CPUs in particular) out of the kernel—it's not a full-fledged HAL
|
||
(yet), but it's headed in the right direction.
|
||
</p></li><li><p>
|
||
MIDI<br />
|
||
Are built-in MIDI ports necessary? It was pointed out that (A) the
|
||
Mac is the platform of choice for MIDI applications, and it doesn't
|
||
have built-in ports, (B) a professional studio setup needs more than
|
||
two ports anyway, and (C) PIOS will offer plenty of "music-friendly"
|
||
IO hardware.
|
||
</p></li><li><p>
|
||
"CD-Quality" Audio<br />
|
||
The loss of quality audio hardware was lamented. This was countered
|
||
by the claim that Macintosh audio hardware is pretty much the same as
|
||
what you get with a BeBox; none of it lives up to professional studio
|
||
standards, but it's more than good enough for general-purpose use.
|
||
</p></li></ul></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id547975"></a>Subject: let's talk about cursors</h4></div></div></div><p>
|
||
Performing context-sensitive cursor switching is difficult because
|
||
there's no "the mouse has left the building" message. It was proposed
|
||
that Be provide a <code class="methodname">MouseExited()</code> call back
|
||
(plus a <code class="methodname">GetCursor()</code> so the
|
||
old cursor image can be remembered and restored when the mouse exits).
|
||
Two primary objections:
|
||
</p><p>
|
||
Objection #1: Every Exit is complemented by an Enter in some other
|
||
window (the Tracker if you exit to the desktop)—why not just let the
|
||
Enter do the work? This means that every window or view should set the
|
||
cursor to the image that it needs; if there's no handler in a view, the
|
||
default image is used.
|
||
</p><p>
|
||
Objection #2: There's no way to guarantee that the <code class="methodname">MouseExit()</code> will run
|
||
before the concomittant <code class="methodname">MouseEntered()</code>
|
||
so the user may end up with the wrong cursor.
|
||
</p><p>
|
||
Another proposal: Provide cursor regsitration and let the Application
|
||
Server change the cursor as the mouse moves around.
|
||
</p><p>
|
||
Objection: You can't (easily) perform cursor image processing or other
|
||
dynamic cursor updating.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548032"></a>Subject: BitMap storage format: PNG?</h4></div></div></div><p>
|
||
There is no "official" Be bitmap data format; Jon Ragnarsson wrote in
|
||
to propose that PNG (Portable Network Graphics) be sanctioned as such.
|
||
This was met with general acceptance, although there were some
|
||
questions about the speed of compression and decompression.
|
||
</p><p>
|
||
For more on PNG, see http://www.wco.com/~png or
|
||
http://www.boutell.com/boutell/png/png.html.
|
||
</p><p>
|
||
The status quo Be screen dump format and the DATA_BITMAP datatype were
|
||
also proposed as possible standards.
|
||
</p><p>
|
||
More philosophically the question was raised, "what's a standard for?"
|
||
It was suggested that a standard is meaningful only when data crosses
|
||
application boundaries; within an app, you can do whatever you want.
|
||
</p></div></div></div><div class="footnotes"><hr /><div class="footnote"><p><sup>[<a id="ftn.id547021" href="#id547021" class="para">1</a>] </sup>
|
||
You can find Estimated Prophet on Terrapin Station. Or see the lyrics
|
||
at http://cyclone.weather.net/zarg/dead.htmls/EstimatedProfit.html
|
||
</p></div><div class="footnote"><p><sup>[<a id="ftn.id547039" href="#id547039" class="para">2</a>] </sup>
|
||
From comp.sys.be, where I was once accused of giving demos that scared
|
||
small children.
|
||
</p></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue2-4.html">Issue 2-4, January 29, 1997</a> Up: <a href="volume2.html">Volume 2: 1997</a> Next: <a href="Issue2-6.html">Issue 2-6, February 12, 1997</a> </div><div id="footerB"><div id="footerBL"><a href="Issue2-4.html" title="Issue 2-4, January 29, 1997"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume2.html" title="Volume 2: 1997"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue2-6.html" title="Issue 2-6, February 12, 1997"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
|
||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
|
||
Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>
|