Be Newsletters - Volume 1: 1995–1996
Life was good from Winter to Spring and Summer to Fall. I was the lone escapee from the weekly newsletter article. I wore pocket protectors, kept a messy office, walked zigzag and backwards, and hid in small corners for days just so I couldn't be found. I anticipated... I planned... I executed.
But I forgot to turn off BeMail. "You have 1 new message." I didn't have to look twice to know it was a message from Her. I tried to delete the message, but I stumbled and deleted the apps folder instead. Panicking, I hit the reset button and forced a rebuild of the database... just as She was walking into my office. With my database nuked, I was sure I had covered my tracks. But when my machine came up, the mail_deamon told a different story: "There is 1 unread message." I was red-faced and caught with the e-mail in my BeBox. I had no choice; I uncapped my pen and pulled out my checkbook. But I didn't have enough in my checking account to cover what She wanted.
So now it's time to do some writing on managing your source files on the BeBox.
With the DR7 release, we started shipping the GNU source code control utilities, called Revision Control System (RCS). We use these tools at Be as a back-end for our source code control. The RCS tools let you store, retrieve, merge, log changes, and identify revisions to your source files. The commands to check out a file from RCS and to check it back in again are as simple as
ci filename
and
co filename
This method works well, but it can become cumbersome if you have multiple directories or nested subdirectories. And beyond the usability issue, there's also the fact that your working directory will be cluttered with an equal number of RCS ",v" files.
The easiest way to get around these problems is to write a few Bash shell scripts that can:
Pass the appropriate options to ci and co
Descend subdirectories to look for files to check in or out
Redirect the target RCS from current working directory to a "mirrored" RCS repository directory
Create "missing" directories when you ask to check out a file that's far down the RCS tree
Through these scripts, you can tailor and reduce the complexity of creating a simple source code control system on the BeBox.
There are a couple of gotchas currently in the BeBox that will make writing and using these scripts not as straightforward as they could be. One is that scripts are executed very slowly on the BeBox. This problem, which is targeted to be fixed for DR9, can be traced to the way fork and exec work.
The other major gotcha is that the file system doesn't check the write permissions of a file. The danger in this is that you can check out a file as read-only, yet still edit the file. Furthermore, while you will be able to edit the file, RCS will not let you check it in as a revision. The simple solution for this may be to just set up all files in RCS as nonstrict, allowing check-in of files without locking.
At Be, we use many scripts and programs that cover the basic RCS tools.
I hope that this brief introduction to the RCS system, combined with the RCS documentation in the /documentation/Shell Tools directory, will help you create and tailor a source code control system for your project.
I'm a third year student at Cal Poly, San Luis Obispo, in Computer Engineering. I first saw the BeBox while on an Internship with InterNex Information Services in Santa Clara (practically neighbors!). I liked it when I first saw it, and I still like it now. The idea of a computer that's trying to learn from the mistakes of all the current platforms sounded very interesting.
My two main interests have always been music and computers. It wasn't until recently that I started to get into mixing the two, and even now I see that the publicly available music software sucks—I hope to change that. In addition to music, I'm also interested in networking. (Networking and sound, now there's a combination.) The BeBox looks good for the sound side of things: Real-time mixing, sampling, and sequencing.
When I look for a new computer, I first look at what's cheap. (Hey... I'm a student. What can I say?) The BeBox looks like an excellent platform for its price. It's also got the I/O that I want for my projects. The GeekPort™ will make interfacing to drum pads a breeze, the MIDI ports will make an obvious impact, and the 16-bit I/O is also a huge advantage. And it all comes standard!!
From my one-person company, Halibut Computers, I run a bulletin board service (Citadel UX). I'm thinking of porting it to the BeOS™. I'm also working on some sound remixing software for Linux. In general, I'm interested in developing public domain software in the spirit of GNU. I'd also like to share ideas with other Be developers that have interests similar to mine. Anyone else willing (read: crazy enough) to shell out the $1K to work on public domain sound and DSP stuff? If there are other developers that are willing, I'd like see if we can't start working on things together. It's better to not have to reinvent the wheel, brakes, suspension, steering, and all the other standard options when trying to build a sports car.
My column on the war of two browsers last week triggered the highest volume of e-mail responses yet to my weekly essays. I must have underestimated the heat of the browser war and the interest it generates. Several readers pointed to an apparent omission: Microsoft has been shipping a Mac version of Explorer 2.0 for a while and I failed to mention it. This is true, the omission was intentional and poorly presented. What I should have said is: At the 2.0 level, on the Mac or on Windows, Internet Explorer could not compete with Navigator, its much more complete feature set (news, mail, multiple simultaneous downloads...), and much better execution. I appreciate the feedback and the opportunity to clarify my position.
Speaking of clarity and position, I have to deal with the two "Wall Street Journal" stories of August 29 and September 3. These stories report rumors of conversations between Apple and our little company and raise various possibilities, including an acquisition. I could pretend the stories aren't there, but that wouldn't make them go away.
For the record, I can but confirm what I told "MacWeek" when they asked about secret meetings at Macworld in Boston, following our presentation of the BeOS port on a Power Computing Mac clone. Nothing of the sort took place. The only conversation I had with an Apple executive, Heidi Roizen, was about wines and lazy afternoons on barges floating down canals in Burgundy. I shook hands with Ike Nassi when he passed by our booth and took pictures of an Apple Fellow, Guy Kawasaki.
I also confirmed to "MacWeek" that I discussed technical cooperation with Michael Spindler. I felt both parties might benefit, being part of the PowerPC alliance. The first conversation took place in the Spring of 1994, as we were porting our system from the Hobbit to the PowerPC. The second happened in February 1995. At the time, I was looking at the whites of the repo man's eyes, we were running out of money, and I offered Michael Spindler a financial transaction that would keep our company afloat and provide Apple some insurance against delays or other problems with Copland. Nothing came out of these discussions and, with the usual but unfair 20/20 hindsight, it's probably for the best.
Instead of receiving assistance from Apple, we were helped by friendly investors. My associate Jean Calmon and I lent funds to the company for a while and, in April 1996, we raised $14 million (see our web site for details), thus giving us the financial viability needed to develop our business. When I write "for the best," I mean we enjoy a situation where agendas are nicely aligned: Developers, investors, the team, everyone agrees on what needs to be done. None of our investors, this includes all Be employees, is in any hurry to unload shares. With alliances, different cultures and goals are often hard to align, efficiency and agility tend to suffer, and motivation can be hard to maintain. This seems to be the sentiment on the net. Most people who comment on newsgroups advise us to stay independent, for fear of losing the agility and focus that got us where we are today.
We agree. We still have a lot to do and a lot to prove. DR8 is in duplication and we're now focusing on DR9, the port to PowerMacs, and the CD we'd like to sell out of our booth at the San Francisco Macworld in January 1997.
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.
A reminiscence on Amiga turned into a discussion of what machine would make the best multimedia kiosk box. Unsurprisingly, a number of Be proponents were in the audience. The MM kiosk idea begat talk of the advantages of built-in sound (versus sound cards).
Some discussion of how hard and soft links should be implemented in the Be file system (and a bit of a UNIX and shell link tutorial). The implied necessity of links was questioned: Some folks think that record_refs obviate the need for links; others think that links are needed, and the sooner the better.
Polling and redrawing; if you want smooth game animation, does the application's redraw frequency need to exceed (or even equal) the monitor's vertical blank rate? A short introduction to gaming terms ("physics rate,Ó "gfx rate") culminated in the blessing of 15 Hz as a "good enough" redraw rate. Others differed, citing low rates as a cause of "VR sickness;" some folks think that 15 Hz is simply too low given that the brain can process 100 images a second.
Relatedly, should polling the user's input be faster than the redraw? It was offered, not without objection, that it's pointless to poll faster than you draw.
Anticipation of the 133 MHz 603e spawned talk of performance improvement; Dominic Giampaolo (of Be) posted some benchmarks. The lack of an L2 cache was lamented, but, as one writer pointed out, the 66 MHz 603 doesn't have an L2, but it's zippy, nonetheless.
Should Be support X? The X champions say "Why not?" The thread then veered into a discussion of whether inter- application drawing should be allowed, and how it should be implemented. Sending "draw it like this" info in a BMessage to the remote app was suggested.
This thread carries the file representation torch that proved too scorching in previous incarnations (notably, the filename case-insensitivity thread). Given here were theories on how the GUI and the shell should display filenames, and how the two should interact. For example, it was proposed that if you drop a file icon into a shell window, the shell should display (as text) the file's name.
