January 2008
Mon Tue Wed Thu Fri Sat Sun
« Dec   Feb »
 123456
78910111213
14151617181920
21222324252627
28293031  

Month January 2008

Entries 3 Total

An Expo-timed update

Jan 14, ’08 2:05 AM

It was about a week ago that we noted that our production machine had stopped working.

At the time, we did not know that the local Apple Store’s “diagnosis in 24-48 hours” would take five days—and end with “we can’t find anything else wrong so it must be the logic board; please mortgage all your property to buy a new one.”

We’re investigating other options, including last week’s new machines. (Even if we’d purchased AppleCare on the sytem, it would have expired six months ago.) We started limping along on a secondary machine by Thursday morning, and as of Sunday night, we’re fully up and running on it, although as usual we have to re-enter a bunch of serial numbers, fix some aliases, and so forth.

Since we purchased our production Power Mac G5 in late 2004, we’ve had no need to replace it, so the temporary machine we’ll be using marks the first time that MDJ and MWJ shall be produced on Intel machines. It also marks the first production under Leopard, and the first production using Microsoft Word 2008. We haven’t seen much of Word yet, since our first and primary task was to convert the handful of Visual Basic macros we use in production to AppleScripts, and some very subtle changes made that more complicated than we’d thought. We’ll talk more about that, either here or in MDJ and MWJ, later in the week.

We’d prefer to tear through a ton of material and publish around 8:00 AM CST, but unfortunately, the publisher is bugging out because he has an important doctor’s appointment at noon today that was scheduled months ago (and has been drafted to run other important errands as long as he’s out). We did take the first week of the year off, instead of Christmas week, because that’s just how it worked out for us. We were busy at work a week ago, until the machine died. Now we’re back on a smaller machine, an Intel iMac. It seems to work fine, but with some Rosetta programs still in our production flow, we wish it had a bit more RAM.

We had been working on some philosophical articles about issues that have been raised online in the past few weeks as if each was some kind of crisis, but in fact, none of them were any kind of crisis. Ironically, one of those was about obtaining repairs, so we’re a bit more up-to-date on that one now.

Those are not time-critical, so we’ll likely put them on hold and go straight into all the news from the Expo, and provide our pre-keynote gloss on some of the more prevalent rumors. If there’s not much news on Monday (hey, it could happen, right after President Gore cuts all funding to the EPA), we’ll finish up the stuff in the pipeline.

Either way, the plan is to publish that Tuesday morning, and take that plus the previous “Think Secret” coverage and put it in MWJ for Tuesday morning, then head straight into whatever happens at Moscone Center on Tuesday afternoon (our time). If the doctors find something wrong or there’s nuclear war or something, the schedule may get pushed out again, in which case we’ll likely go straight to keynote coverage to get that out Wednesday morning.

We had also planned to spend time last week on Apple’s Q4 FY2006 financial results, which happened before the publisher got his strength back. We’ll now postpone that until the coming weekend or early next week, to try to get all the financial news contained in a couple of issues for those of you who prefer to skip it (and to keep it isolated for those of you who pore over it in great detail).

That’s the current set of plans, since a few of you asked how the machine is doing. The machine is not doing well at all, but we’re now managing with a substitute while eagerly awaiting something bigger to run all our tools at once. It’s really quite astonishing how much RAM and disk space all these things take. Why, we remember when code segments couldn’t be larger than 32KB, and the whole system and applications loaded in 512KB, and…

OK, we’ll stop now. We’re old.

Comments (0)

Voodoo, by definition, does not work

Jan 9, ’08 2:43 AM

Our production machine is still out of commission, so we’re doing this by hand; please forgive any typos or formatting errors.

More than two months after we were compelled to call out MacFixIt’s despicable fear-mongering, the site has continued to fight back by picking even the most ludicrous and remote justifications for its ridiculous rituals and passing them off as “evidence” that everyone who knows how Mac OS X works is wrong, and only MacFixIt’s “do it this way or suffer the consequences” advice can keep you from certain doom.

As before, the true sentiments seem hidden in the RSS summaries rather than presented on the main page. Such is the case with Tuesday’s entry, “Cannot copy and paste in Leopard: repair permissions.” The RSS summary for this item is just two words:

Voodoo works.

Well, no, it doesn’t. Here’s the text in question:

If repairing permissions with Disk Utility (located in /Applications/Utilities) is a useless ritual, don’t tell the group of users who have been able to reverse an inability to cut/copy and paste under Mac OS X 10.5.x (Leopard) via the process.

For some users, installation of the software for Logitech’s Harmony universal remote has broken the ability to cut/copy and paste under Leopard. Repairing permissions resoles [sic] the issue.

Guess what? Repairing permissions is a “useless ritual” when it’s a ritual. We have pointed out repeatedly in MDJ and MWJ that repairing permissions is a completely valid troubleshooting technique. These people had trouble, they wanted to fix it, and they tried an easy troubleshooting step that resolved the problem. Hooray! The system works!

What’s “useless” is to repair permissions as if it were some form of necessary system maintenance. It’s not, or Apple would have set up the daily, weekly, or monthly automatic launchd tasks to do it for you. In fact, Panther and Tiger both had to add extra code to undo the damage caused by people repairing permissions frequently for no reason at all. Nothing in the Mac OS X rules required that installer receipts have the correct and final permissions for all files installed—a post-installation script could have, and sometimes did, set permissions depending on the configuration of your system. But if you “repair permissions” every day (or hourly) “just to be safe,” you undo that work and leave permissions incorrect. Apple had to add mechanisms in the Installer and Disk Utility to work around this unanticipated problem.

No one, except maybe Artie MacStrawman, argued that you should never repair disk permissions. If you’re having trouble, especially if you suspect it’s permissions related, you should by all means repair permissions and see if that fixes the problem. You just shouldn’t imagine that performing this task at other times is doing you any good, because it’s not.

You do not need to repair permissions regularly.

You do not need to avoid repairing permissions if you’re troubleshooting.

What a happy day it will be for us, and for all the Mac users in the land, when whoever is writing MacFixIt these days stops trying to mend a bruised ego by repeatedly misconstruing the words of critics. Since being called out for fear-mongering, the site seems obsessed with proving the criticisms wrong, no matter how many facts it has to twist in the process.

Another egregious example: when the site discovered that using Mac OS X 10.4′s “repair permissions” functionality causes problems on Mac OS X 10.5 startup disks (because the installer receipts are stored in a different way on Leopard than on Tiger), MacFixIt twisted the story to imply that Alsoft, makers of DiskWarrior, had somehow hidden this from customers.

The clearer version of the article? “Repairing permissions when started from Mac OS X 10.4 causes problems on Mac OS X 10.5 startup disks, even if you boot 10.4 from something like the DiskWarrior CD, and even though that’s exactly what Alsoft just said, we’re going to pretend otherwise so we can pretend that our October fear-mongering about DiskWarrior 4, whose main ‘rebuild directory’ functions does absolutely no damage to Leopard disks, is somehow dangerous because we said so and everyone who says otherwise is a poopy-head.”

To the MacFixIt writers:

You were wrong, and you libeled a long-time and dedicated Mac developer in the process. Now, rather than admitting it, apologizing, and moving on, you’re bound and determined to flush your entire site down the crapper by pretending that your obvious mistakes were somehow correct. Stop it. Apologize and move on. You can do important work if you’ll get your bruised egos out of the way and focus on troubleshooting, and supporting every word you write with solid factual evidence. Not “a reader saw it so we think it works this way,” not “it worked for us so it probably works for everyone,” but facts.

If you don’t understand what’s going on with a particular issue, say so. Say what you know and what you don’t know clearly and precisely. Stop guessing. Last month, you said that when people see a QuickTime logo with a question mark in it instead of a Flash movie in a Web browser window:

In most cases the issue has to do with a conflict between QuickTime Player attempting to playback Flash content, and Adobe’s own Flash plug-in attempting to playback the same content.

This is not true. This was never true. More than one browser plug-in can register for the same MIME type, but the browser only calls on one of them to play it. It makes absolutely no sense for a browser to call upon multiple plug-ins to draw the same content, and that’s why no browser has ever done that. The problem is that QuickTime is attempting to play Flash content and it’s not very good at it. The “note” on your “Fix #1″:

(Note: Before going through the process below, try simply deleting the file ~/Library/com.apple.quicktime.plugin.preferences.plist then restarting your browser).

…would be the simplest correct solution if you had gotten the pathname right. It’s ~/Library/Preferences/com.apple.quicktime.plugin.preferences.plist. You have this habit of leaving Preferences/ out of that path in lots of articles.

The point is, you said something that could not possibly be true. You didn’t know the true cause of the conflict so you guessed at it. Stop doing that. Stop trying to rehabilitate your mistakes. Stop writing for your egos. If you get something wrong, fix it and move on. Write what you’re sure of, and let people know what you don’t know.

You don’t have to try to scare people into following your superstitions. Make MacFixIt a must-read again: don’t write a single word you can’t support with documentation. When you don’t know, say “we don’t know.” Be honest and the world will be patient. You do lots of good work, and coordinate lots of information, and yet none of that’s going to matter. Keep making stuff up to salve your egos and your days are numbered, and we’re not talking triple-digit numbers. Focus on the facts and the good work and you’ll have a devoted audience for as long as you want them, without even trying.

We’re just sayin’. You’re MacFixIt, for cryin’ out loud. Fix it.

Comments (0)

Out of service for a day or two

Jan 7, ’08 9:39 PM

In an unwanted display of irony, our production machine (a dual-2.5GHz Power Mac G5) has gone dark in the midst of our preparation of an article about how to best take in your Macintosh for service. (Don’t worry—we removed the internal hard drive before taking it in for service, and verified with the local Apple Store that this was fine.)

We even stopped by a going-out-of-business CompUSA store to pick up an external Serial ATA drive enclosure, in the hopes of getting the drive up and running on another computer and continuing at less than full speed. Alas, when the drive enclosure box said “cables included,” they meant the USB cables to connect it to the computer—not the cables you need to connect the drive to the enclosure. Those are not included, and we don’t have any, since in most Macintosh models, they’re rather firmly attached to the case or logic board at several places. It’s now long past closing time at any store that might have them, and most of them are a good 45 minutes away, anyway.

This is why no one liked CompUSA and why they’re going out of business.

So while we’re without the main machine or main storage drive for a day or so, we’ll be out of commission—we’re here, but without the properly licensed installations of all our tools. E-mail responses will therefore be delayed as well. And it’s still better that it happened this week instead of next week.

Just in case you worried, we’re still here. We hope to be back at full speed within a day or two, and certainly by the end of the week.

Comments (0)