Be Newsletters - Volume 2: 1997
Some of the changes in the DR9 BeOS will be immediately obvious: Faster boot times, a new Tracker, foreign file system support. But other new features won't be quite so visible. One of the "invisible" features is support for IDE on O'Hare-based Macintosh platforms (this includes, most notably, the Motorola StarMax).
Most Mac motherboards include two IDE controllers. Because the DR9 BeOS recognizes both master and slave IDE drives, these two controllers can support four IDE drives. The Mac OS, by contrast, doesn't recognize slaves, so it can only support two IDE drives. This means, of course, that if you do add a third or fourth drive to your Mac, these drives will be "BeOS-only" volumes. When launching the BeOS, you'll be able to boot from any IDE devices, including the slaves - - if it's a BeOS volume, you can boot from it.
Another new feature in DR9 is Direct Memory Access (DMA) for IDE hard drives. With DMA, data transfers (mostly between main memory and a memory-laden device) occur with as little intervention from the processor(s) as possible. When a CPU is about to transfer a big chunk of data, it tells the DMA controller how much data to transfer, where to get it from, and where to put it. It also sends a DMA instruction to the target device. The transfer is then performed independently by the controller; when it's done, the CPU is signaled by an interrupt. Thanks to Be's multithreaded OS, huge memory transfers don't tie up your entire machine.
DMA transfers are doubly efficient in that not only are they asynchronous, they're also not tied to the clock speed of the CPU. Since the DMA controller takes care of the transfer, a slower CPU can actually see its IDE access speed increase. File system operations and the programming of the DMA transfer itself will be no faster than the CPU, but at least the data copy will depend only on the bus speed.
I tested DMA versus non-DMA performance on a 66 MHz and 133 MHz BeBox™. The access time was rated with iozone, writing and reading a 64 MB file on a blank Quantum Bigfoot 5.25 (1 GB) drive mounted as a Be file system. The DMA transfers used DMA mode 2.
The results are summarized in the following table. Note that in each set of (a/b) measurements, "a" is the transfer rate for a lightly loaded CPU, and "b" is a machine with a heavily loaded CPU.
Transfer Rates
Test (MB per Second)
-------------------------------------
66 MHz Read
With DMA: (4.2 / 2.7)
Without DMA: (1.0 / 0.13)
66 MHz Write
With DMA: (2.8 / 1.7)
Without DMA: (1.2 / 0.14 )
133 MHz Read
With DMA: (4.2 / 3.7)
Without DMA: (1.4 / 0.35)
133 MHz Write
With DMA: (2.9 / 2.7)
Without DMA: (1.5 / 0.45)
Taken as absolute measurements, the non-DMA numbers are a little bit misleading: We could have used fast PIO modes, which would have made the non-DMA transfers faster. But what IS relevant is the drop in access speed between a (nearly) idle system and a very active system. There's a 60 to 85 percent drop in performance for non-DMA transfers, but DMA transfers suffer only a 10 to 40 percent hit.
To best use your IDE drives you should be aware of a few things:
First of all, be wise selecting your IDE cable. IDE specs recommend a maximum length of 18 inches (total), but the rule is the shorter the better. IDE cables aren't shielded and have fewer ground lines than a SCSI cable.
If you're using only one drive on a bus, configure the drive as a master (or single), not a slave, or it won't be detected.
If you have more than one drive, it's better to keep slow drives on one bus and fast drives on another bus. The driver adapts the bus speed to the slowest drive present, so it won't take full advantage of your fast device if it's daisy- chained to a slow one.
Think your brand new drive is dead? Turn the cable over. Many IDE cables aren't keyed.
As always, take the NEWER!!! FASTER!!! claims that you get from drive manufacturers with a grain of salt. The other day I got a brand new ATA 32.1 GB hard drive that claimed a 16.6 MB per second data rate. If you look REALLY close, next to that gigantic red and green "16.6!!!" you can see a teeny little "instantaneous." The "sustained" (or, shall we way, "real") data rate was 4.4 to 6.9 MB/s. Add to this the seek time (unless you're used to having one file per hard drive), and you get the picture.
You use text in many places in an application's user interface. But for style purposes, these can be divided into three kinds: Titles and labels, lists, and explanatory text. This article provides guidelines for consistent capitalization and punctuation of these three kinds of text in your Be applications.
Titles and labels include menu items; labels for icons, buttons, check boxes, text fields, and other objects; the titles of windows and panels; and the titles of groups of controls in panels.
Use "title style" capitalization for titles and labels: Capitalize the first letter of the first and last word in a title; also capitalize the first letter of all others words in a title, except for prepositions, articles, and coordinate conjunctions (words such as "and," "or," "but," and "for").
Don't end a title with a period, but if the title asks a question or announces an emergency, it's OK to end the title with a question mark or exclamation point (use exclamation points sparingly; use them often and risk crying "wolf" or appearing shrill).
If a menu item or button opens a panel the user must work with to complete an action started by the menu item or button, append ellipsis points to its label. Ellipsis points—often mistakenly called "ellipses"—are a single character that looks like three periods ( ... ). You produce ellipsis points by typing Option-period. Don't emulate ellipsis points by typing three periods.
For menu items and button labels that take an action (rather than showing the state of a selection, for example), use verbs that clearly and succinctly identify the action. For example, in a panel that asks users whether they want to save changes to a document, it's better to label the default button "Save" than "OK".
Lists are usually lists of options in panels, with each item in a list accompanying a radio button, check box, or other control.
Use "sentence-style" punctuation for lists: Capitalize the first letter only of the first word in each item in the list. Don't end list items with a period, colon, or other punctuation.
Explanatory text explains options or situations in windows and panels, such as the larger text in an alert panel that summarizes the situation that caused the alert panel to open, as well as any smaller text that gives details. Use "sentence-style" punctuation for explanatory text: Capitalize the first letter only of the first word in each sentence in the text. Use complete sentences for explanatory text, and punctuate each sentence as you would a normal sentence: End each sentence with a period, question mark, or other terminal punctuation.
To brush up on your spelling and capitalization rules, see The Chicago Manual of Style (any edition will do) or Words into Type.
Tractors, killers, mission-critical, personal productivity. How about cool, exciting, fun, thrilling, raise your hair? These are all words that are used in the software industry to describe... software. Such strong words for such a soft thing.
We're always in a perpetual state of one-upmanship. Pushing the envelopes of productivity, practicality, and hyperbole. Well, sometimes you get into it, and sometimes you just want to do some calculations.
These week we feature on our Web site a spreadsheet program.
http://www.be.com/beware/highlights/sumit.html
Maarten L. Hekkelman produced it, and he did a fine job. A spreadsheet by any other name would still have revolutionized the computer industry oh so many years ago. I know we're looking for killers, who drive tractors, but someone has to keep the tally. It's not glamorous, but without it, we can't be taken seriously as a solid computing platform. Even DVD production schedules need some simple computing every once in a while.
Spring really does seem to bring out the best in people. A little sunshine, a little music, and people are bouncing off the walls, programming their hearts. Our porting lab is in progress. A small but enthusiastic group, they're already giving us feedback. When I explained our OpenDoc-lite features, I received excited gasps and promises to recast the world's problems into archivable components. Maybe it's Spring, maybe it's the CEO next door with the Listerine on his desk. I don't know, but people do tend to get excited.
But Spring is about renewal. New things coming all the time. In the case of an OS, rebirth and renewal are synonyms for new API, and lost programming time. So to help make the DR9 transition as quick and painless as possible, we're already releasing some DR9 sample code:
ftp://ftp.be.com/pub/Samples/calendar_dr9.tgz
This is the good old January sample code migrated to DR9. The code is
simple enough and exhibits few enough DR9 concepts that you should be
able to get something out of it. In particular it shows how to deal with
fonts in a view. Most of the rest of it is unchanged. Among the primary
differences with fonts in DR9 is that we have UTF8 support. And you don't
have to be attached to a view to get the width of a string. There's a new
BFont object that does some of this for you. Take a look, you'll be
surprised how easy it is. Also note that DR9 is still not shipping, so
this sample may change a little bit before it's all said and done.
I don't remember if it has been six weeks or not, but Yasmin was sick for one day. As a friend with three children explained it, they are totally wasted, clingy, and demanding, just long enough to wear you out, then they recover and are bouncing off the walls, while you lie wasted on the couch. Well, Spring's recuperative powers are extraordinary, so being sick won't keep her from walking a mile back from the grocery store. She'll be 2 in 9 days. And oddly enough, the BeOS will be nearing its release at the same time. Maybe there's something there. In the mean time, we're tearing up cement, laying down sod, and getting ready for a cool and exciting summer at home. What a perfect environment to write applications. Poolside, near the swing set, with the BeOS dancing under your fingers running on a Quad DayStar machine!
We have another anointed word: Push.
Instead of explicitly logging on to a server, we designate locations, channels, information sources, whatever—a URL in any event—and the broadcaster pushes the agreed-upon content to my computer. PointCast was probably the earliest entrant in the field. Their receiver, a browser plug-in, can be tuned to a number of customizable channels: The stock market, sports, and so on. It became so successful, corporate IS managers complained: The update traffic to the legions of in-house desktops clogged their networks.
From Netscape to Marimba, Microsoft and a legion of followers, everyone is pushing today or Real Soon Now. The rush to push has already triggered a rash of negative comments, either blaming the hype, as usual, or stating no one needs it, another original reaction. The idea of "tuning" my desktop to information channels is an attractive one. I have a choice. I can feel lazy and flip through my usual channels, or I can navigate the Web, with or without a precise destination. And I can see the old dream of corporate executives: Up-to-the-minute financial data. Tune to the secret channel from anywhere in the world, even from your cellular phone. It will soon get an HTML interpreter, courtesy of Unwired Planet, a Redwood City start-up developing a dialect of HTML for small wireless devices. When you look at IP packets and URLs, push isn't very complicated to implement or simulate.
Of course, there are issues with push other than bandwidth utilization and littering our desktops. Security is a big one. It's not hard to design experiments where programs get pushed and activated on my machine. Upon close examination, the border between data and programs only exists as a word. Spreadsheet data are in fact programs for an interpreter, as is HTML. An innocent text file can become a batch program, a rogue word processor macro, or a script for dial-up networking. Java has been designed with these issues in mind and avoids many of the more hazardous situations. Still, as long as a remote computer can deposit data on your hard disk, with or without your explicit consent, with or without trust certificates, there's the theoretical possibility of damage, intentional or not. In practice (not in the media accounts) not much damage has occurred. We seem to strike a collective balance between security and ease of use. Just as in credit card use. We no longer hesitate typing credit card numbers in a field on a Web page. The servers offer decent security, actually better than the chits we sign in restaurants. More damage has been caused by innocent program crashes than by malicious viruses, but they don't make great stories.
Before I leave the subtopic of security, following my Bill Gates quote of last week, and in order to provide additional perspective on Microsoft and Java, I can't resist quoting from the addendum to the software licensing agreement for Windows 95:
“Java technology is not fault tolerant and is not designed, manufactured, or intended for use or resale as on-line control equipment in hazardous environments requiring fail- safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines, or weapon systems, in which the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage.”
The above applies to most software in existence today, and I'm sure lawyers have good reason to suggest such a cautionary note—in general. But why specifically for Java?
For us, push technology is another step in building the net as an infrastructure for the electronic distribution of software. Tuned on a developer's channel, I'll get notified of bugs and updates. At my option, the updates will download or even install themselves. This might be going a little far, but the potential is there for an individual to reach as many potential users as a large corporation, once again making the Internet a great equalizer.
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.
What's the best format for (A) general text markup exchange and (B) placing styled text on the clipboard?
RTF. Provides a good deal of control, and the general spec is well known and settled. However, it's not great for markup, it provides "personalizations" (known as "styles") that aren't part of the commonly defined spec, and it seems that no two implementations are the same.
HTML. It's ubiquitous and friendly, but it's not very flexible.
SGML. Too flexible, say some.
PDF. The best of breed for layout. But it's big and not well supported.
XML and DSSSL (Document Style Semantics and Specification Language). Between these two (which describe content and layout, respectively) almost any page can be described. But it's new, complicated, and the spec is massive.
There was some squabbling over how and when text "richness" can and should be used. For example, does text format richness help the readability of e-mail? Probably not—the difference between <bold>Groovy</bold> and GROOVY! may not be worth the time spent encoding the HTML.
Meanwhile, do questions (A) and (B) require the same solution? Possibly
not; the clipboard solution can be much "lighter" than the
all-the-bells-and-ponies solution. It was generally accepted that STE
(part of DR9 BTextView) is the proper format for placing enriched text
on the clipboard.
One of our favorite topics: Why does an MP machine sometimes work better with one of the CPUs turned off? Cache coherency problems, no doubt.
From Mimir Reynisson:
“How do I increase the stack size allocated to an application?”
You can't. The stack is limited to 64K; this fact o' life was lamented, but is a more flexible setting necessary? An infinitely growable stack may not be a toy you want everyone to get their hands on; it could lead to tailspinning recursion. The next thing you know, the missiles have been launched by accident and Nebraska is a smoking ruin. (My cousins live in Nebraska. Nuke 'em.)
On the other hand, it was posited that recursion isn't necessarily a bad thing: In some circles, recursion is actually considered GOOD programming. This point bordered on the religious, but it was mercifully dropped.
The thread also discussed what an app should do to recover from bumping into the stack size limit, and how (or if) it should inform the user of the error.
Let's say document A (text) imports document B (a picture). When saving A, you don't want to copy B's data, you simply want a reference to join the two. How should A refer to B?
It was suggested that if A contained a known, commonly used (system-defined?) attribute that took a "pointer to" B as its value, then not only would this solve the reference question, but you could query on the attribute to find all files that import some other file. In other words, A would know how to find B, and B would be able to query for all such A's.
This led to a discussion of what the "pointer to" data should be: Should it be symbolic (pathname) or "hard" (such as you get with the pre-DR9 record ref)? If you use a pathname reference, then you break the link (from A to B) if you move the file. Hard references let you maintain the link no matter where the referred-to file goes—but do you really want to refer to B after it's been moved to the trash?
THE BE LINE: There was some confusion about what a "node_ref" is; a node_ref is NOT a record_ref. There is no DR9 analog for the record_ref —persistent, unique, "hard" identification just isn't possible in a foreign file system world.
