Casady & Greene Shuts Down — Casady & Greene, one of the oldest companies in the Macintosh market, is shutting down after 19 years, according to Bonnie Mitchell, Casady & Greene’s VP of Public Relations. Full details weren’t available at press time, but it appears as though Casady & Greene simply couldn’t remain financially viable. Although the company had released a number of Mac OS X products this year, including Spell Catcher X, Tri-Catalog, Clone X, and iData Pro (see "The Digital Shoebox: iData Pro X 1.0.5 in TidBITS-675), revenues weren’t sufficient to keep the doors open or to pay some of its contract programmers. None of Casady & Greene’s current products have the same broad appeal as Conflict Catcher (which never made it to Mac OS X) or SoundJam, which became the basis for Apple’s iTunes, and the transition to Mac OS X proved particularly problematic for the company. [ACE]

<http://www.casadyg.com/>

<https://tidbits.com/getbits.acgi?tbart=07145>

Extensis Buys DiamondSoft — Just a few days after Apple revealed that Mac OS X 10.3 Panther would feature a font-management utility called Font Book, Extensis (makers of Suitcase) announced that it was buying DiamondSoft (makers of Font Reserve). Coincidence? Yes, actually, since corporate acquisitions take more than a few days to arrange. Nicole Andergard of Extensis confirmed that the acquisition had been in the works for some time, and the announcement of Font Book had come as a surprise to both companies. She also said the point behind the acquisition was eventually to combine Suitcase’s strengths on the client side with Font Reserve’s server-side capabilities to create the most powerful font-management solution for publishing professionals. Also, although Apple hasn’t provided many details about Font Book, Nicole said they had been led to believe that it was more of an entry-level font-management program that would be unlikely to cannibalize professional users from Suitcase. [ACE]

<http://www.extensis.com/press/releases/063003_ fr.html>

<https://tidbits.com/getbits.acgi?tbart=06751>

<https://tidbits.com/getbits.acgi?tbart=06797>

Remember? Not Forgotten — Dave Warker’s Remember?, a superbly simple calendar and reminder application that got its start as a desk accessory, has at last migrated to Mac OS X with version 4. Although Remember? doesn’t show banners in its calendar for multi-day events, its superb and original interface and flexible reminders make it a welcome alternative to iCal, and at $20 shareware, it’s a bargain. [MAN]

<http://www.warker.com/remember.html>

Another Take on Jaguar Upgrade Percentages — Last week, I commented that I’d heard from a developer at MacHack that a non-trivial percentage of Mac OS X users had not upgraded from Mac OS X 10.1 to Jaguar, a fact I found surprising. It turns out I had reason to be surprised – it had simply been reported to me incorrectly (as the developer said, it’s never safe to believe anything that’s said after 48 hours of sleeplessness at MacHack). Here’s the real deal. About 75 percent of this developer’s users are running Mac OS X, and only about 1 percent are still using Mac OS X 10.1. A second developer whose software also reports operating system version also shared his numbers, which were almost identical, so I think it’s safe to say that the number of users running Mac OS X 10.1 is vanishingly small.

Now, these numbers come with several caveats. First, although they’re automatically collected, sending the information is optional, so it’s conceivable that people running earlier versions of Mac OS X may not be volunteering the information as readily. Second and more likely to skew the results, these numbers come from people registering current software products, and that is a behavior that likely trends with continually upgrading the operating system. To put it another way, those who didn’t pay for the upgrade to Jaguar may also be less likely to register shareware. [ACE]

Apple Announces Design Awards 2003 — Wrapping up the Worldwide Developer Conference (WWDC) last week, Apple announced the winners of its annual Apple Design Awards. As with last year, the awards recognize Mac OS X software that excel in seven categories. Topping the list with two awards was Salling Clicker 1.5 from Salling Software, taking Best Mac OS X Product (Best of Show) and Most Innovative Mac OS X Product. Using Bluetooth networking, owners of select Sony-Ericsson cellular phones can control scriptable applications such as iTunes or Keynote on their Macs (especially cool is the capability to run “proximity sensor” scripts that activate when the phone comes into the Mac’s Bluetooth range).

<http://developer.apple.com/wwdc/ designawards.html>
<https://tidbits.com/getbits.acgi?tbart=06818>
<http://homepage.mac.com/jonassalling/Shareware/ Clicker/>

In the Best Mac OS X User Experience category was Starry Night Backyard 4.0 from Space Holdings (see “Up, Up, and Away with Starry Night Backyard” in TidBITS-542). The Best Mac OS X Technology Adoption award went to World Book 2003 Jaguar Edition from Software MacKiev. Appropriately working together on a truly collaborative tool, Martin Ott, Martin Pittenauer, Dominik Wagner, and Ulrich Bauer of Technische Universitat Munchen won the Best Mac OS X Student Project for Hydra 1.0.1, a Rendezvous-based text editor that enables multiple people to contribute to a shared document. (Adam and about ten other attendees at MacHack used Hydra to take notes during this year’s Hack Contest.) This year’s Best Mac OS X Use of Open Source was the University of Michigan’s Fugu 1.0, a graphical front end for SFTP (Secure File Transfer). And, in a new category this year, the Best Mac OS X Server Solution award was accepted by BioTeam for iNquiry 1.0, software that can be loaded onto multiple Mac OS X Server machines to create processing clusters for analyzing biological data (see “Bioinformatics and the Mac” in TidBITS-622). Congratulations to the winners, as well as the runner-up applications in each category, which are listed at Apple’s Web site. [JLC]

<http://www.starrynight.com/>
<https://tidbits.com/getbits.acgi?tbart=06069>
<http://www.mackiev.com/>
<http://hydra.globalse.org/>
<https://tidbits.com/getbits.acgi?tbart=07244>
<http://rsug.itd.umich.edu/software/fugu/>
<http://www.bioteam.net/>
<https://tidbits.com/getbits.acgi?tbart=06764>

German Translators Needed! Our German translation team has dwindled in size and available time, so much so that they haven’t been able to translate TidBITS for a while now. (Our Japanese, Dutch, and French translations are still going strong; Spanish and Russian are in need of new translation teams.) If you can spend a little time each week helping to translate TidBITS into German, or helping put together and distribute the finished product (for those who are fluent German editors but aren’t as comfortable with translation), the German-speaking Macintosh community will thank you. For more information, please contact Heinz Gnehm <[email protected]>. Thanks for helping out! [ACE]

Normally after Macintosh conferences I like to draw some conclusions about what we can learn about the overall world of the Macintosh from the attendees, the discussions, the attendance, and so on. After this year’s MacHack, there simply wasn’t much to say, thanks to Apple rescheduling the Worldwide Developer Conference (WWDC) for one day after MacHack ended. That meant the developers at MacHack could merely speculate about what would be announced at WWDC, and worse, it meant there was no Apple Feedback session and that only a handful Apple employees came to MacHack, instead of the usual contingent of 15 or so. (Overall attendance was down less than 20 percent, a surprisingly strong showing given the WWDC conflict.) Sure, almost all the hacks used Mac OS X, and it took some looking to find anyone even still running Mac OS 9, but that’s not particularly telling any more. In the end, MacHack this year had a bit less of a Macintosh focus, and my impression from overheard comments was that the sessions and papers were particularly good this year. Especially enjoyable (if not representative) was Keith Stattenfield’s reprise of last year’s "Mac OS 9 is dead!" session, in which he spoke movingly about how much Mac OS 9 means to people still and how many people are still using it before emphasizing that "Mac OS 9 is STILL dead!" and launching into four or five slides of euphemisms for "dead."

In fact, the conference organizers have decided to acknowledge the expanded scope of the conference next year, renaming it the Advanced Developers Hands On Conference (ADHOC) and adding more sessions on Unix, Palm, and other platforms. The hack contest will also be changing somewhat, as the people who have run it for the last 17 years move on to other interests. But despite the name change and the expanded focus, I’m confident the basic experience won’t change much. That’s because unlike every other industry conference, the people organizing the sessions, papers, and other events are themselves long-time attendees. First and foremost, it’s a conference of the developers, for the developers, and by the developers, to paraphrase the Gettysburg Address. Look for ADHOC next year, tentatively scheduled for July 21st through 24th, 2004, but subject to change as necessary to avoid other trade shows.

<http://www.adhocconf.com/>

So rather than attempt to draw any far-reaching lessons, I’d like to pass on a few vignettes of what it’s like for me to be at MacHack, along with a few behind-the scenes pictures from each.

<http://www.tidbits.com/resources/686/machack- 2003.html>

Jumpsuit Week — Ever since he delivered the keynote at MacHack a few years back, Andy Ihnatko has become as addicted as I have to MacHack, and he returns every year. But last year he missed hearing about the informal oldest t-shirt contest, so in a fit of geek pique, he declared MacHack "Jumpsuit Week" and appeared stylishly attired each day in a jumpsuit. He started with a Wingz jumpsuit, an homage to the early days of the Mac when the Wingz spreadsheet made a huge splash at Macworld Expo. The next day was a jumpsuit worn by technicians at the Yankee Point 3 nuclear plant (bought at a salvage store and checked with a friend to make sure it wasn’t actually radioactive). And the third day brought an authentic pre-Challenger-era Space Shuttle flight suit, complete with NASA and shuttle patches.

<http://www.cwob.com/>

News! Cell Phones Too Small! Shortly after arriving at MacHack, Greg Robbins, who works on RealOne Player at Real Networks, and who used to live only a few miles from us in Issaquah, Washington, couldn’t find his cell phone in his bag. Once he’d searched for a few minutes, I called it from my cell phone, and the ringing confirmed that it was indeed in the vicinity of his bag. Despite more searching, Greg still couldn’t find it, and a second call showed that it had in fact fallen out of his bag and into the hotel lobby’s indoor planter. Any smaller, and we’ll have to attach these silly phones to our bodies instead of just to our belts.

<http://www.real.com/>

When You Come to a Fork — As the famous saying from Yogi Berra goes, when you come to a fork in the road, take it. Yogi obviously never thought about where forks spend much of their time (other people’s mouths), but since this was one of the few times Geoff Canyon, who works on Runtime Revolution, and I had seen an actual fork in an actual road, we took it. Well, its picture anyway. And then we wondered if its proximity to MacHack might mean that it was actually a code fork.

<http://www.inspiredlogic.com/>

<http://www.runrev.com/>

Late Night Quips — Following Scott Knaster’s second keynote, filled with numerous stories from Apple and General Magic I’d never heard before, a number of people took over one of the conference rooms for an informal port and scotch tasting. (Note to self: Don’t assume you can buy decent port within driving distance of the hotel in Dearborn, Michigan.) Chris Page, who works on Palm Desktop for the Mac, brought some snacks as well. His Almond Tartlets generated a few risque jokes (keep in mind that it’s about 3 AM at this point), so when Chris pulled the next item from the bag, he said dryly, "And here we have a box of double entendres." I don’t think anyone actually inhaled their drink, but a few people came pretty close while laughing themselves silly.

<http://www.chris-page.org/>

<http://www.palm.com/us/software/desktop/ mac.html>

The Family that Hacks Together… Default Folder author Jon Gotow and his 15-year-old son Ben were nearly inseparable for much of MacHack as they were working on their winning hack, Unstoppable Progress (see "The MacHax Best Hack Contest 2003" in TidBITS-685). At MacHack, technology is not only highly social, it even makes teenagers want to hang out with their parents. Well, some teenagers anyway, although I have to say, the students I’ve met at MacHack over the years have seemed far more well adjusted than the norm.

<http://www.stclairsoftware.com/DefaultFolderX/>

<https://tidbits.com/getbits.acgi?tbart=07244>

MacHack Food — After years of attending MacHack, I finally came up with a great way of dealing with the wacky eating schedule and programmer junk food that permeates the conference. On my way to the airport, I stopped at a grocery store and bought eight excellent Braeburn apples. That way, I was able to eat an apple every day for "breakfast" before the hotel-catered "lunch" that usually ends up being the first meal of the day otherwise. I don’t know about you, but I can’t quite face a full-fledged hot lunch after waking up, but the apple fooled my stomach into thinking it had moved on to the second meal of the day. Then, after a bunch of snack food and rectangular pizza at midnight, a second apple offered a great way to consume some healthy food. Evidence I was onto something? Every time I pulled an apple out of my bag, a different person looked longingly at it and asked where I’d gotten it. This may be a hint that we’re all getting older.

Actually, the food was a step up from standard hotel fare this year, since the conference organizers convinced the hotel chefs that MacHack attendees were adventurous eaters. The first lunch had a Mexican theme, and while it may not have been haute cuisine (or authentic Mexican), it was a darn sight better than the "please, not again!" rice pilaf with your choice of chicken or salmon. The second lunch danced around a Russian or at least Northern European theme, and again, while not exactly what I would have chosen to eat an hour after waking up, at least it wasn’t dull.

One of the chefs even got into the swing of things, carving an apple into a watermelon fruit salad bowl and helping bake a cookie that looked like the Spinning Pizza of Death. Maurita Plouff, who collaborated on the cookie, was soliciting experts to help the chef put together a multimedia business card to use in applying to chef competitions.

File Sharing Still Annoying — Amazingly, despite all the advances of the past decade, moving a file from one computer to another still proved to be more difficult than it should be. The internal MacHack network was plagued by what may have been a bad switch, and as a result, Rendezvous, as helpful as it is for displaying TCP/IP network resources, didn’t always show shared computers. And then there were the user mistakes – people who hadn’t turned on file sharing, or who, for some reason, had incorrect permissions on their Drop Box folders, or other problems. In some cases, switching to a Computer to Computer Network (Apple’s name for ad hoc networking, appropriately enough for the future name of this conference) solved the problem. The moral of the story is that even though file sharing is getting better all the time, there’s still room for improvement.

Smash Hulk — Lastly, we all went to see The Hulk movie after the awards banquet and, wow, was that a bad movie. Not even a good bad movie, where you enjoy yourself but feel slightly guilty that you haven’t yet seen A Mighty Wind (Spinal Tap for folk music, though almost nothing is as funny as Spinal Tap) or Bend It Like Beckham (an extremely enjoyable movie about an Indian girl playing soccer in England). No, The Hulk was just a bad movie that irritated all the comic book fans and confused everyone else, presumably thanks in part to the damage that was done when the Hulk was allowed to look at the script. "Hulk smash plot. Puny humans write stupid movie." During the traditional "Keith Explains" group attempt to understand what had really gone on in the movie (in which Apple’s Keith Stattenfield and the rest of us examine every little detail to extract more humor than was actually present in the movie), there was a bit of a discussion as to whether the best scene in The Hulk was the cameo appearance of Marvel Comics’ Stan Lee and Lou Ferrigno (who played the Hulk on TV years ago) as security guards early in the movie, or if it was actually the trailer for Tomb Raider II, which promises to be a much more enjoyable bad movie.

<http://keithexplains.com/>

<http://www.thehulk.com/>

<http://amightywindonline.warnerbros.com/>

<http://www.foxsearchlight.com/bendit/>

<http://www.tombraidermovie.com/>

Optimizing disks is a waste of time. There, I said it. The horse is out of the bag, the cat is out of the barn. So why do so many people believe that an optimizer is an essential part of any Mac user’s tool kit? And what does it mean to optimize a disk, anyway?

Background Fragments — When you save a file to disk, the file system looks for an empty space to write the data. If there isn’t a single space large enough, it divides the file among several smaller spaces. When a file is stored in more than one piece, we say it’s fragmented. Each piece is called a fragment, or an extent.

A file may be broken into two fragments, or 20 fragments, or 200 fragments. The file system doesn’t care; it can handle any number of fragments equally well. However, reading a fragmented file takes longer than reading an unfragmented one. The more fragments in the file, the longer it takes to read. That’s because the hard disk’s head must move to each fragment and read each one separately. Reading a single chunk of data sequentially is fast, even when the chunk is rather large. But moving the head from track to track for each fragment is comparatively slow. (And I mean "comparatively" – we’re talking about additional milliseconds here.)

The solution to this slowdown? Defragmenting or optimizing. Some programs claim to defragment a disk, others claim to optimize it, and a few offer both functions. What’s the difference?

Defragmenting combines files that are broken up across multiple fragments into a single fragment. But defragmenting files is only part of the problem, since the free space on a disk is often split into many pieces, a little here, and a little there. In effect, the free space is fragmented. You may have 5 GB of free space, but it could be in 5,000 chunks of 1 MB each. The next file saved may be fragmented, simply because there isn’t enough unfragmented free space. That’s where optimizing comes in – it defragments all the fragmented files and the free space.

Some optimizers also position similar files, such as all the operating system files, physically next to one another. The claim is that this speeds up the computer even more, because operating system files are likely to be accessed together, which prevents the disk head from needing to move long distances to read the next file. Although the concept sounds good at first blush, I’m dubious that this technique creates any perceptible speed increase. Beyond a few simple cases, it’s very difficult to divine in advance which file the computer will want next.

So optimizing the disk should make your Mac run faster, right? Well, maybe. If a file you use all the time is fragmented, such as a key part of the operating system, then defragmenting that file could really help. But the operating system is usually written to the disk right after it has been freshly formatted. The disk is empty, so the operating system is rarely fragmented. If a file you rarely use is fragmented, such as that QuickTime movie from Aunt Ethel’s birthday party, it doesn’t matter as long as you can access the file – play the movie, in this case – normally. In short, avoiding fragmentation is helpful only on files that are accessed constantly.

So where did this cult of disk optimization come from? Back in the early days of Windows, and DOS before that, PCs used the FAT (File Allocation Table) file system. Legend has it that the FAT file system was pretty bad about fragmenting files, so disks quickly became badly fragmented. Back then, disks – and computers in general – were extremely slow, especially by today’s standards. With those painfully slow disks and computers, optimizing a disk could provide noticeable performance improvements. Modern computers and disks are of course much faster, and they also have much larger and more sophisticated disk caches, all of which significantly reduces the impact of a fragmented disk.

When Apple designed the HFS (Hierarchical File System) file system for the Mac, and later when they replaced HFS with HFS+, they took special care to try to minimize fragmentation. All hard disks store data in 512 byte chunks called sectors. FAT, HFS, and HFS+ use larger chunks, called clusters on FAT and allocation blocks on HFS. One purpose of clusters and allocation blocks is to try to reduce fragmentation, by storing files in larger pieces. But HFS goes one step further. When saving a file to disk, the Mac file system allocates space in even larger chunks, called clumps, in a further effort to reduce fragmentation.

When the Mac file system saves a file, it looks for a free space large enough to hold the entire file. If there aren’t any, it finds the largest free space available, then the next largest, and so on, in an effort to reduce fragmentation as much as possible. HFS will never fragment a file if it can be avoided.

Real World Fragmentation — There are two things that lead to disk fragmentation for most people: full disks and email.

Overall, the Mac’s HFS+ file system does a good job of keeping fragmentation to a minimum, assuming a reasonable amount of free space remains on the disk to use when laying down files in contiguous chunks. How much free space should you maintain? There is no set answer, but leaving 20 to 25 percent of a disk free is a good rule of thumb.

If your 60 GB hard disk has only 5 GB free, that doesn’t mean that you have a single empty space on the disk where the entire 5 GB is available. Rather, there are dozens, if not hundreds, of smaller free areas. The largest single chunk of free space may be only 500 MB. When a disk is very full, not only is there less total free space, but the size of the largest free area becomes much smaller. Thus the likelihood of fragmentation goes way up.

What kind of files tend to be fragmented? The most likely candidates are files that grow regularly, with little bits of data added to them over time. Each time the file system extends the file, it looks for another piece of free space, and the file fragments a little more. Various types of files fit this profile, but the prime candidate is email.

My email program’s In box file has been fragmented into more than 100 pieces. Does this matter? No, it still functions perfectly. Doesn’t it slow down my email program? Certainly, but not enough for me to notice. The main reason people optimize their disk is to make their Mac run faster. Doubtless it does make using the Mac somewhat faster, but I’ve rarely seen a perceptible speed increase in real world usage.

Pros and Cons — So increasing the speed of your Mac, even if the improvement is nearly imperceptible, is one reason to optimize your hard disk. There is a second reason to consider defragmenting files. If you suffer a disk crash, disk recovery software has a harder time recovering badly fragmented files than unfragmented files, simply because there are more pieces to track down. And which files are most likely to be fragmented? Email files, which are also the most likely to have changed recently, and thus the least likely to be in your last backup. (Obligatory reminder – if you don’t have a recent backup, make one right after you finish reading this article. Really.)

There are also some good reasons not to optimize, and ironically, one of them is speed. Optimizers are slow. It takes many hours to optimize a disk. Does it make sense to tie up your Mac for hours just to make it respond a second faster when you’re opening a mailbox?

More worrying is the fact that if the optimizer crashes, the disk could be, to use the technical term, "horked." That’s because an optimizer must move nearly every piece of data on the disk. The best optimizers use algorithms that make it nearly impossible to lose data, even if the power goes out in the middle of a long optimization, but there’s always a slim chance of something bad happening when you let a program move everything on your disk.

The problem is that no program is perfect. Earlier versions of some optimizers have had bugs that resulted in lost data or damaged disks. I don’t know of any currently shipping optimizers with these types of catastrophic bugs. But that’s not to say that some future version may not contain a bug, or that a current version won’t have trouble when combined with a new version of the Mac OS. Be careful when you’re using optimization software!

Optimization Advice — If you’re going to optimize your disk, be sure to check the disk first with a program like Apple’s Disk First Aid or Disk Utility. A damaged disk could cause even the best optimizer to crash when it runs across corrupted data or data in a completely unexpected place.

It’s also a good idea to back up your entire disk (or at least your most important data) first. But once you have a backup, you could just erase the disk, and restore from your backup. Doing this optimizes the disk as effectively as running any optimizer. Plus, reformatting a hard disk ensures you have clean directory structures, and if you reformat it with the option of writing zeroes to every sector (which takes a long time and isn’t worthwhile unless you’ve been experiencing odd disk problems), you’ll also make the drive map out any bad blocks it may have developed. That’s why I say my favorite optimizer is Retrospect – with it you can both protect your data and optimize your disk.

<http://www.dantz.com/products/mac_express/>

Speed Disk, the optimizer in Symantec’s Norton Utilities, has some useful features for analyzing a disk. It rates the overall disk fragmentation as light, moderate, or severe. It’s almost certainly not worth optimizing a disk unless the fragmentation is severe, and often not even then. That’s because Speed Disk considers a disk severely fragmented based on a combination of how many files are fragmented, how fragmented they are, and how fragmented the b-trees (disk directory structures) are. The last item is what can make it seem alarmist, because the b-trees act as triggers: if they’re fragmented a certain amount, Speed Disk can automatically assign the whole disk a severe rating, even if the other files on the disk wouldn’t otherwise generate that rating.

<http://www.symantec.com/nu/nu_mac/>

Speed Disk shows a graph of the files and free space on the disk, letting you see how badly the free space is fragmented. It also lists the size of the largest free block, a useful piece of information to keep in mind because any file larger than that will, by necessity, be fragmented when it is saved. If you routinely work with files larger than your largest free block, optimizing the disk would be advisable.

Lastly, Speed Disk lists all fragmented files and the number of fragments per file, and it lets you defragment individual files. Why would you want to do this? HFS+ can track up to eight fragments in a file’s catalog record. If a file has more than eight fragments, HFS+ creates additional records, called extent records, to track the extra fragments. Since files with more than eight fragments require accessing these additional records each time they are opened, a file with more than eight fragments is certainly a reasonable candidate to be defragmented, assuming of course that you access it frequently enough for defragmenting to make a real difference.

There’s usually no need for Speed Disk’s capability to defragment individual files. That’s because you can usually defragment a file yourself, by simply duplicating it in the Finder. When the file system creates the duplicate file, it automatically uses only a single fragment for the file, assuming there is enough contiguous free space on the disk. Then you can delete the original and rename the copy with the original file’s name.

Alsoft’s DiskWarrior 3 offers the unique feature of showing a graph of a disk’s directory, using a color gradient to show items that are out of order. DiskWarrior’s "rebuild" function is usually used to repair damaged disks, but when used on healthy disks, it "optimizes" their directories. Although Alsoft calls this feature "optimization," it’s quite different from what all other disk optimizers do. Other disk optimizers defragment the files on a disk. DiskWarrior puts the disk’s catalog in order.

<http://www.alsoft.com/DiskWarrior/>

The catalog is composed of nodes, which contain records that correspond to files. The nodes form a tree structure, with all the nodes linked together in a specific order. The file system tends to keep the nodes in order. But as files are added to and deleted from the disk, nodes are likewise created, deleted, and shuffled around, and they can end up out of order. This is not dangerous, or even wrong, just not optimal.

DiskWarrior reorders the nodes. In theory, this should make a disk faster for the same reason defragmenting a file makes it faster, namely that related information is stored together, so the disk’s head doesn’t have to seek to distant sectors when retrieving it. In the real world, I doubt the speed increase is noticeable, especially since the file system caches key pieces of the catalog in memory, making access much faster than when the information is stored only on the hard disk. Disk Warrior is excellent at recovering disks with damaged directories, but optimizing a properly functioning catalog is gratuitous.

Bottom Line — To sum up then, for most people, most of the time, there’s simply not enough to gain by optimizing your disk to bother doing it. There’s nothing wrong with optimizing a disk, and for a severely fragmented disk that is responding slowly when reading regularly accessed files, it may even be worthwhile. But in general, it’s not necessary and carries a small risk. If you really want to optimize your disk, the best approach is to make a backup (with a second backup for safety’s sake), reformat your hard disk, and restore from the backup.

[David Shayer was a senior engineer on Norton Utilities for Macintosh 3.0, 4.0, and 5.0. Before that he worked on Public Utilities, a disk repair program that won the MacUser Editor’s Choice Award, and on Sedit, a low level disk editor.]

PayBITS: Glad to learn that you don’t need to waste time or

money on optimizing your disk? Thank David via PayBITS!

<http://www.amazon.com/paypage/P12NE4WQ7K8ODD>

Read more about PayBITS: <http://www.tidbits.com/paybits/>

Power Mac G5 specs — Serial ATA bus speeds, swapping hard drives, heat dissipation, maximum RAM, and more in this Power Mac G5 examination. (27 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=1981>

Older Power Macs still available — In the wake of the Power Mac G5 announcement, Apple is still selling a Power Mac G4 model – that can even boot into Mac OS 9! (4 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=1982>

The "Outlook" for Mail — Apple’s Mail application will use the Safari engine to render HTML messages in Mac OS X 10.3 Panther. What controls will exist to limit the HTML rendering to thwart malicious spammers? (5 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=1983>

Motorola’s PowerPC future — With the PowerPC G5 announced, what happens to Motorola’s PowerPC G4 processor? (2 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=1984>

G5-based PowerBooks — Will PowerBooks using the new PowerPC G5 chip appear soon… or at all? (6 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=1985>

Text Clippings to the Palm — What’s the easiest way to get simple text snippets onto a Palm handheld? Readers post a few options. (4 messages)

<https://tidbits.com/getbits.acgi?tlkthrd=1988>