Categories
Apple bugs

sh: /usr/bin/lockfile: No such file or directory

Q.

Mysterious error message after updating to El Capitan: sh: /usr/bin/lockfile: No such file or directory

A.

[I]n El Capitan B4, Apple decided to stop shipping Procmail, and with it, lockfile. It wasn’t deprecated and then removed… it was unceremoniously sent to the bit bucket. So, as of B4, scheduling in El Capitan broke.

Shirt Pocket Watch: Oh yeah? Well, lock *this*!

Categories
Apple bugs Design glamorous OSX software The Essentials This never happens to Gruber User Experience UX

Zen & The Art of iTunes Failure 

REBUILDING iTunes library from scratch over two days got app working again. Fine use of lazy weekend.

Had to sacrifice all custom playlists dating back to 2002, including An Event Apart playlists and delivery room mix from Ava’s birth.

Playlists still exist on old iPod but can’t be copied from it back to iTunes. (All software I’ve tried freezes & fails.)

Playlists still exist as code snippets inside .itl file in old iTunes folder, but numerous trials prove iTunes can’t launch from that folder any more. Thus I can’t temporarily launch from old folder, export playlists, switch back to safe new folder, and import them, thereby saving them.

And iTunes can’t import old .itl files. I Googled. I tried anyway.

13 years of custom playlists. From before, during, and after my marriage. Including one my daughter called “princess music” and danced to when she was three. Gone.

But, really, so what? Over time we lose everything. This loss is nothing. Attachment is futile. Always move forward, until you stop moving.

Categories
Browsers bugs Code CSS CSS3 Design HTML interface javascript launches Layout maturity Standards State of the Web Tools

Finally, cross-browser visual control over forms.

Now we have something else to be thankful for. Nathan Smith of Sonspring has created a library that gives designers and developers “some measure of control over form elements, without changing them so drastically as to appear foreign in a user’s operating system.” Smith calls his new library Formalize CSS:

I’ve attempted to bridge the gap between various browsers and OS’s, taking the best ideas from each, and implementing what is possible across the board. For the most part, this means most textual form elements have a slight inset, and all buttons look consistent, including the button tag.

For more, including demos, options, screenshots, thanks, and the library itself, read Smith’s write-up at SonSpring | Formalize CSS. Hat tip and happy Thanksgiving to my good friend Aaron Gustafson for sharing this gem.

Categories
Browsers bugs Code Compatibility CSS CSS3 development Free Happy Cog™ HTML HTML5 Ideas industry links Standards State of the Web The Essentials The Profession Tools Web Design Web Design History Web Standards

HTML5, CSS3 default templates

Free for use in all web projects, professional or personal, HTML5 Reset by Monkey Do! is a set of HTML5 and CSS templates that jumpstart web development by removing the styling native to each browser, establishing basic HTML structures (title, header, footer, etc.), clearing floats, correcting for IE problems, and more.

Most of us who design websites begin every project with bits and pieces of this kind of code, but developer Tim Murtaugh, who created these files and who modestly thanks everyone in the universe, has struck a near-ideal balance. In these lean, simple files, without fuss or clutter, he manages to give us the best-practices equivalent of everything but the kitchen sink.

Tim Murtaugh sits beside me at Happy Cog, so I’ve seen him use these very files (and earlier versions of them) to quickly code advanced websites. If you’re up to speed on all the new hotness, these files will help you stay that way and work faster. If you’re still learning (and who isn’t?) about HTML5, CSS3, and browser workarounds, studying these files and Tim’s notes about them will help you become a more knowledgeable web designer slash developer. (We need a better name for what we do.)

My daughter calls Mr Murtaugh “Tim the giant.” With the release of this little package, he earns the moniker. Highly recommended.

Categories
Advertising bugs Google Images industry Microblogging war, peace, and justice

When Ads by Google Go Wrong

When Ads By Google Go Wrong

When Ads by Google Go Wrong


Categories
Accessibility Advocacy Apple Applications apps art direction Browsers bugs Code Compatibility CSS Design HTML ipad iphone Layout Real type on the web Standards State of the Web The Essentials Tools W3C Web Design Web Standards webfonts webkit webtype zeldman.com

Opera loves my web font

And so do my iPhone and your iPad. All it took was a bit o’ the old Richard Fink syntax and a quick drive through the Font Squirrel @Font-Face Kit Generator (featuring Base 64 encoding and SVG generation) to bring the joy and wonder of fast, optimized, semi-bulletproof web fonts to Safari, Firefox, Opera, Chrome, iPhone, and Apple’s latest religious device.

Haven’t checked IE7, IE8, IE9, or iPad yet; photos welcome. (Post on Flickr and link here.)

What I learned:

? Even if manufacturer supplies “web font” versions with web license purchase, it’s better to roll your own web font files as long as this doesn’t violate the license.


Categories
Browsers bugs State of the Web The Essentials Web Design Web Design History Web Standards webfonts webkit webtype

Opera hates my web font

Opera hates my web font.

So I’ve wanted to use a condensed, bold Franklin typeface for my site’s headlines since, well, forever. So I bought Fontspring’s fine Franklin Gothic FS Demi Condensed and licensed it for @font-face use for a mere $2.99, an incomparable value.

It looks great in Safari, Chrome, and Firefox, but not so nice in the latest version of Opera, where it resembles the inside-out test monkey in Cronenberg’s “The Fly.” (Okay, okay, it looks like a ransom note, but the monkey simile was more picturesque.)

And this, my friends, is why Typekit exists. Because even when you find a great font that’s optimized for screen display and can be licensed for CSS @font-face use, guess what? There is almost always some glitch or bug somewhere. And Typekit almost always seems to find and work around these bugs. It’s the kind of grueling task designers hate dealing with, and Typekit’s team loves solving.

If this were a client site, I’d switch to Typekit, or try licensing a different vendor’s Franklin, or (if neither of those options proved satisfactory) dump web fonts altogether and use Helvetica backed by Arial instead. But as this is zeldman.com, I’d rather nudge my friends at Opera to look into the problem and fix it. This will make browsing zeldman.com in Opera a somewhat weird experience, but hopefully it will help all Opera users in the long run.

Implementation Notes and Details

  • I haven’t made an SVG version yet, so the web fonts don’t work in iPhone or iPad.
  • iPhone and iPad see normal weight Helvetica instead of bold Helvetica, because if I leave “font-weight: bold” in the CSS declaration, Firefox double-bolds the font. This is not smart of Firefox. Fixed via technique below.
  • In order to match the impact of the previous Helvetica/Arial bold, I boosted the font-size from 25px to 32px. (This also helps smooth the font. Web fonts need more help in this regard than system fonts.)
  • Camino ignores @font-face and supports the first system font in the font stack, Helvetica Neue (correctly styled bold).

Update: Problem solved. See Opera Loves My Web Font.


Categories
Apple Browsers bugs glamorous MobileMe This never happens to Gruber

The dog ate my bookmarks

Disappearing bookmarks bug.

It’s been years (or is it weeks?) since something odd, implausible, and inexplicable happened to one or more of my Apple computers that doesn’t happen to anyone else’s. You know you want to hear this.

So yesterday morning I’m in my hotel, finishing some work on my laptop before leaving for the airport, when MobileMe alerts me that in order to sync the bookmarks on my laptop, it will need to delete some and add some. I click OK. A few seconds later, I have no bookmarks in Safari.

That’s strange, but it’s a bit liberating, too. I feel lighter. That kink in my neck is gone.

Heck, I can re-create the few bookmarks I really need and do without the rest, right? (Besides, I imported my Safari bookmarks into Chrome a few weeks ago, and I sync Chrome bookmarks via Google, so the bookmarks aren’t really gone, they’re just gone from Safari.)

I re-create five or six bookmarks in my laptop’s Safari bookmarks bar, close my laptop, and fly home.

Here’s where it gets weird.

At home, after midnight, sleepless, jetlagged, I turn on my iMac. MobileMe wants to sync my bookmarks. It says it will delete quite a few of them and create a handful of new ones. There is no option to send my iMac’s bookmarks to MobileMe instead. There is no option not to sync. I can skip sync for now, but eventually I’ll have to sync, and that means I’ll have to let MobileMe wipe my many old Safari bookmarks off all my computers. No sense delaying the inevitable.

I click OK.

My old bookmarks are gone, but the new ones I created on my laptop have not been sync’d. I have no bookmarks.

I start re-creating them from scratch, and as I create them, they disappear.

I create a Flickr bookmark. It works. I create a zeldman.com admin bookmark. When I look up, the Flickr bookmark has disappeared. I create a Twitter bookmark. When I look up, the zeldman.com admin bookmark has disappeared. A moment later, the Twitter bookmark has disappeared.

I begin quitting Safari immediately after creating a bookmark (in order to force Safari to save it). This seems to work. When I re-start Safari, the bookmark I just created has been saved. I do this six times in order to create and save the few bookmarks I really need in order to work.

I don’t bother re-creating the dozens of JavaScript bookmarklets I use daily. I figure I can do those in the morning. I verify that Safari now contains six bookmarks. I run a backup via SuperDuper and go to bed.

In the morning, my bookmarks bar is blank again. Overnight, all my bookmarks have disappeared.

It can’t be from syncing via MobileMe, because the computer should have gone to sleep as soon as the backup finished (and it was asleep when I woke up this morning).

At this point all I can figure is that Apple wants me to switch to Chrome.


Categories
Browsers bugs Compatibility CSS Design Fonts OSX

Last Tangle in Firefox

Incorrect Helvetica in Firefox rendition of zeldman.com

Snow Leopard plus FontExplorer X equals screwed-up fonts in Firefox (especially Helvetica).

  • Google Search on “Snow Leopard Firefox FontExplorer X” reveals numerous incidents of CSS displaying incorrectly in Firefox (wrong font weight, wrong font style) when Font Explorer X is on Snow Leopard Macs.
  • My Flickr thread contains a screenshot demonstrating the problem plus a useful discussion of causes and possible workarounds.
  • Disabling FontExplorer X solves the problem.

Update: Buying FontExplorer X Pro and clearing font caches also solves the problem. (The problem is with Apple’s fonts, not with Firefox or FontExplorer X, but it takes mediation to fix it.)

Categories
A List Apart An Event Apart Appearances architecture art direction Authoring Browsers bugs Career Chicago cities Code Community Compatibility conferences content content strategy creativity CSS Design development DOM downloads editorial Education engagement eric meyer events flickr Fonts Formats glamorous Happy Cog™ HTML HTML5 industry Information architecture Jason Santa Maria javascript Markup photography Real type on the web Scripting Search social networking speaking spec Standards State of the Web

Chicago Deep Dish

Dan Cederholm and Eric Meyer at An Event Apart Chicago 2009. Photo by John Morrison.

For those who couldn’t be there, and for those who were there and seek to savor the memories, here is An Event Apart Chicago, all wrapped up in a pretty bow:

AEA Chicago – official photo set
By John Morrison, subism studios llc. See also (and contribute to) An Event Apart Chicago 2009 Pool, a user group on Flickr.
A Feed Apart Chicago
Live tweeting from the show, captured forever and still being updated. Includes complete blow-by-blow from Whitney Hess.
Luke W’s Notes on the Show
Smart note-taking by Luke Wroblewski, design lead for Yahoo!, frequent AEA speaker, and author of Web Form Design: Filling in the Blanks (Rosenfeld Media, 2008):

  1. Jeffrey Zeldman: A Site Redesign
  2. Jason Santa Maria: Thinking Small
  3. Kristina Halvorson: Content First
  4. Dan Brown: Concept Models -A Tool for Planning Websites
  5. Whitney Hess: DIY UX -Give Your Users an Upgrade
  6. Andy Clarke: Walls Come Tumbling Down
  7. Eric Meyer: JavaScript Will Save Us All (not captured)
  8. Aaron Gustafson: Using CSS3 Today with eCSStender (not captured)
  9. Simon Willison: Building Things Fast
  10. Luke Wroblewski: Web Form Design in Action (download slides)
  11. Dan Rubin: Designing Virtual Realism
  12. Dan Cederholm: Progressive Enrichment With CSS3 (not captured)
  13. Three years of An Event Apart Presentations

Note: Comment posting here is a bit wonky at the moment. We are investigating the cause. Normal commenting has been restored. Thank you, Noel Jackson.

Short URL: zeldman.com/?p=2695

Categories
Applications Brighter Planet bugs business Career Code Community content Design ethics glamorous homeownership parenting work Zeldman

In-Box Twenty

Found in my in-box on this gloriously muggy morning:


  • E-mail from a neighborhood mom interested in hiring our child’s nanny in September, when the girl enters kindergarten. Would our nanny work part-time? (No, she would not.)
  • Invitation to speak.
  • Account status message from American Express, freezing my business account.
  • Personal letter from a co-author of CSS.
  • Correspondence from one half of a feud, demanding that A List Apart delete “libelous” comments made by the other half.
  • QA correspondence on Brighter Planet beta.
  • Photo of kid on general store porch-front rocking horse, sent by ex, from mini-vacation they’re taking together.
  • Responses from speakers selected to present at An Event Apart in 2010.
  • Discussion of “send to friend” links in context of COPPA compliance.
  • Raw personal truth from my dear sponsee.
  • Notes from a developer whose web fonts platform I’m beta testing.
  • Query from a mom whose friend is expecting: what do we pay our nanny? Would she take less? (I hope not.)
  • Basecamp notifications concerning Chapters 7, 9, 2, and 4 of Designing With Web Standards, 3rd Edition.
  • Invitation from a social media network’s director of strategic relationships.
  • Milestone reminder.
  • Note from my brother about the release of his CD.
  • Case study for review.
  • Notice of Credit Limit Reduction on my personal account from American Express. “In this difficult economic environment, we all need to make choices about how we spend and save.”
  • Discussions of Happy Cog new business activities in various stages of ripeness.
  • Note about a magic berry that will make me look like a princess.

Typical day.

Categories
Browsers bugs CSS Design firefox Mozilla Web Design Web Standards work zeldman.com

Firefox test page

Firefox gurus, a page demonstrating the Firefox long content bug has been created for your browser fixing pleasure. Kindly visit the test page using Firefox 3.0 and Firefox 3.5 for Windows (and possibly also for Linux). The following defects should be evident:

  • At least half the comments should be cut off by the browser.
  • The footer should be cut off by the browser.
  • The form enabling you to add comments may also be cut off by the browser (or it may be incomplete, or the labels for such things as your name and email address may appear in the wrong location).

View the same page in Safari 3+, Opera 9+, or IE7/8, and compare. In the other browsers, all comments are displayed, the footer is displayed, and the content form is viewable and displays correctly. How often does Firefox compare unfavorably with some of these browsers? Hardly ever. Which is precisely why you want to fix it. (That, and you’d like your users to be able to view all the content on a page, not just some of the content.)

The test page is identical to this 2 July post, with comments frozen as of 9 July 2009, and with the site’s original CSS, which revealed the long content bug in Firefox.

A subsequent 8 July post documents the steps I and two other developers took in order to isolate this bug in Firefox, and the CSS workarounds (suggested by two of the site’s readers) which have since been put in place to cover up for this defect in Firefox. The thread also explains what we changed in the CSS to enable Firefox users to read long content on the site.

The CSS cover-up enables Firefox users to read all the content on long pages, but at a cost: there is a flash of red background during slow load times. And, obviously, it’s better to fix Firefox than to create somewhat flawed CSS workarounds that slightly diminish the experience for all users of the site.

Thanks for your help! Let me and this site’s readers know how we can assist you. And remember, please use the test page (not this page or any other page of the site) to isolate the bug in Firefox.

Read more

  • HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
  • Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
  • In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
  • XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]firefox, browser, bug, firefox3, firefox3.5, windows, linux, bugs, buggery, debugging, demo, testpage, mozilla[/tags]

Categories
Browsers bugs Design firefox Mozilla Web Design Web Standards work zeldman.com

Firefox forces orange background flash

There’s good news and bad news. The good news is that Firefox 3.0 and 3.5 for Windows no longer cut long pages of this site in half, hiding 50% or more of the pages’ content, including the footer, because of a newly discovered bug in Firefox (discovered by this site’s layout).

The bad news is that the price of the “fix” is an annoying flash of reddish-orange background. When you first load a page in any browser, rather than the main content’s off-white background area, you instead see the text against a reddish-orange background, obscuring words (including the drop cap), disrupting user experience, and raising doubts about the professionalism of the site and thus of the opinions it expresses.

With the annoying flash of colored background, everyone who reads this site suffers. But without it, Firefox 3/3.5 cuts long pages in half. Until Firefox fixes the bug, all readers of this site will experience what I’ll label “the Flash of wrongly styled background color.” (Note: although the browser is still broken, the color flash has since been “fixed.” Impatient ones, skip ahead to the 9 July update. Narrative fans, keep reading.)

Here’s the story.

Validators were no help

My 2 July post, XHTML DOA WTF, has thus far received 194 comments. Firefox users told me the thread “died” after comment #44049 in Firefox 3 and 3.5 for Windows. The problem also later surfaced on In Defense of Web Developers, written yesterday morning just prior to my surgery. Let’s stick with the 2 July post, though, which is where we did our Q&A.

W3C and WDG validation services both indicated that there was an error on the page, but neither validator could explain it.

  • The W3C showed a long list of unclosed elements (which in fact were closed), a typical W3C validation error when that validator misidentifies the actual problem. The W3C validator has made this mistake since at least 2001. Whenever I complain to the W3C, I’m told they need volunteers to help them fix the validator. So I more often rely on the WDG validation service.
  • The WDG validator (usefully and apparently correctly) indicated that a single illegal UTF character in a comment it could not show me was causing the dilemma. This validator gave me a line number, but no code output—making the line number useless, and forcing me to go into my database and examine each of 194 comments visually for unsupported character problems.

In search of a single UTF-16 character

I next spent two hours of an insanely busy pre-surgery day unsuccessfully attempting to manually track down UTF errors in comments that no validation service was able to pointpoint. I had to apologize to colleagues and clients to whom I owed work, since the quest to make my personal site legible and usable to Firefox users took precedence over paying work in my sad little mind. (Call it a mark of the high esteem in which I hold Firefox; also call it a concern for readers.)

Automattic’s designer/developer (and my friend) Noel Jackson then took over for me and was eventually able to locate a single UTF error in a Japanese pingback. Or so it seemed.

WordPress, the power behind this site, is supposed to convert illegal UTF-16 to legal UTF-8, and we thought it had done so. Nevertheless, the only validation service to have claimed anything semi-coherent said otherwise. To solve the problem required brute force: we deleted the entire Japanese comment. To the clients and colleagues to whom I owed work I was unable to finish while tracking down a Firefox bug, I now also owed an apology to a Japanese blogger. Personally, I blamed Firefox for ludicrously Draconian error handling, but at least I thought we had “solved” the needless problem raised by such behavior.

Drudge work for nothing

I owe Firefox an apology. Draconian error handling of impossible-to-trace possible UTF errors was not the cause of its failure to display pages correctly. Inability to parse valid CSS on long pages was the actual cause.

Although my page now validated, Firefox still cut it off at the waist. Thanks to this bug, users of Firefox—many of whom care greatly about web standards (it’s one reason so many developers choose Firefox)—were unable to read more than half the comments about XHTML 2 and HTML 5 from their fellow standardistas. They were also unable to post comments or view the footer (thus making them unable to view other content on this site, as well as third-party site highlighted in the footer). This was a win for nobody, except maybe Microsoft, Opera, and Safari. And, like I said, we like Firefox and people who use it. Back to the drawing board.

Seek and ye shall not find

Nikolay Bachiyski, a lead developer at Automattic, then conducted a series of tests:

  1. He established that only Firefox 3.0/3.5 (and only in Windows) cut the valid web page’s content in half.
  2. He verified that the page’s content was valid (UTF-8) as was its markup.
  3. The DOM loaded properly.
  4. There wasn’t an (X)HTML parsing problem.
  5. Disabling JavaScript made no difference.
  6. Disabling CSS enabled all the page’s content to display in Firefox; turning CSS back on cut the page in half again. Clearly, the issue was with CSS.
  7. Nikolay then disabled the lines of Mozilla- and Webkit- oriented CSS3 that generate “warnings” or “errors” in the W3C validation service. But even with those lines disabled and the CSS completely valid, the page’s content failed to display completely in Firefox. The bottom of the page was still cut off.

A CSS “fix” with a drawback

Valid CSS was somehow to “blame” for Firefox’s inability to show a long page without hiding half the content.

You may ask why I didn’t discover this problem during the building and testing of my site’s redesign. You might even ask why my readers didn’t discover it (since I beta tested the redesign at several stages). The answer is simple. I never tested a dummy blog post with nearly 200 comments. It didn’t occur to me that more than 40 comments would be necessary to test whether valid CSS and XHTML would work in good modern browsers, let alone in one as excellent as Firefox.

Michel Bozgounov and Kyle Weems then proposed a simple CSS fix:

div#wrapper {overflow: visible;}

My friend Noel implemented the CSS fix while I was unconscious and having stuff cut out of me.

It works, and I thank all these gentlemen. But it has the unfortunately side-effect of inflicting a flash of reddish-orange background on the page until most or all content has loaded. (I had previously spent over two weeks eliminating that flash of background.) And it does this in all browsers (or nearly all), not just Firefox. To force Firefox to display all content on a page, I have to force every other browser to flash red before it shows content.

Obviously, it’s vital that Firefox users be enabled to read and comment on long or popular posts. But there must be a better way than deforming the CSS. And there is a better way: namely, a Firefox bug fix.

Our friends at WordPress have contacted our friends at Mozilla, so we are hopeful that this will be fast-tracked. Mozilla friends, call on me to help at any time.

9 July Update: 99% solution

With the addition of 1000px of min-height to #wrapper, the reddish-orange flash has been eliminated, at least in pages that load quickly. (On long pages, or with slow connections, the reddish-orange background remains painfully visible until the page finishes loading.) Read more about this CSS adjustment. Note that adding CSS workarounds is not the same thing as fixing browser bugs. (Indeed, CSS workarounds may retard browser development by removing the problem so it never gets fixed.)

A Firefox Test Page

As I am not entirely satisfied with this CSS workaround (despite my gratitude to its authors) and as I do not want Mozilla’s engineering wizards to be unable to fix Firefox because of changes to my CSS, I have posted a Firefox test page using the site’s original (perfectly fine, background-flash-less) CSS, and a page explaining the Firefox test page.—JZ

Read more

  • HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
  • Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
  • In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
  • XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]browser, bugs, Firefox3, Firefox3.5, Firefox/Windows, browsers, firefoxbugs[/tags]

Categories
Apple bugs

Apple OS X 10.5.7 overheats some Macs

Robert Black was right. OS X 10.5.7 adversely affects the internal heat management of some iMacs (and apparently also some MacBooks), causing the machines to overheat. Overheating, in turn, leads to such problems as freezes during iCal sync; freezes during iTunes sync; and the inability of attached hard drives to complete a backup.

Blah blah

I confirmed this by installing smcFanControl and watching my Mac get hotter and hotter as it tried to complete a SuperDuper backup. Disk Utility confirmed nothing was wrong with the attached drive. Swapping cables proved a faulty cable was not to blame for previous failed backups. Maddeningly, the backup got within 4GB of completion before locking up due to the overheating of my iMac.

Not every iMac or MacBook is affected. It probably varies by factory run and by model. (My MacBook Pro, for instance, is fine.) Third-party stuff and Migration vs. Tabula Rasa System Install seems to have no bearing on whether or not your Mac will choke on the update.

Since even running smcFanControl at settings recommended by Robert Black and others doesn’t cool the iMac enough to finish a backup or verify the quality of the attached drives, it may not make sense to replace my external hard drives (as new drives will likely also fail as the iMac overheats during backup).

With smcFanControl in place, I can use my iMacs but not back them up.

Apple needs to release an update that fixes the hardware problems this one created.

(And someone else needs to install it before I do.)

[tags]OSX10.5.7, bugs, Apple, Macintosh, update[/tags]

Categories
Apple bugs

Quick survey on OS X 10.5.7 bug triggers

Update: see OS X 10.5.7 overheats some Macs.

Fellow Mac users, let’s see if we can isolate the triggers of the OS X 10.5.7 blues. If we learn the cause, others may know whether it’s safe for them to update, and we may provide Apple’s engineers with a clue on how to fix the problem in a subsequent update.

Theory 1: Migration Assistant

My affected iMacs have systems that were migrated. That is, when I bought the machines in December 2007, after running them for a while as-is to ensure that they worked properly, I ran Migration Assistant to bring over applications, preferences, network settings, and so on from my previous work machine (a non-Intel white powerbook).

Blah blah

Theory: Possibly OS X 10.5.7 update becomes unstable in the presence of a leftover something migrated from an older system.

Test: If you’re suffering from the 10.5.7 blues, did you run Migration Assistant on the afflicted machine? Did you migrate from a non-Intel machine?

Theory 2: Third-Party Stuff

When something goes wrong with a Macintosh update, a third-party add-on is often the trigger. Here are the add-ons on my sufferin’ iMacs:

Items marked “removed!” were my initial suspects. After the update, iTunes froze on sync. I reckoned the iLike plug-in was to blame, and after removing it, was able to sync again for a while.

Then the Mac froze during an iCal sync, so I removed MenuCalendarClock.

But removing these little guys didn’t fix anything. Soon enough, even without these add-ons, the Macs were freezing during iTunes sync and during MobileMe iCal sync. Eventually they froze on any app, doing anything. (Only to inexplicably resume normal operation again for hours at a time. But enough of this.)

And you? If your Mac is misbehaving after running OS X 10.5.7 update, are any of these add-ons on the machine?

[tags]OSX, bugs, OSX10.5.7, 10.5.7, apple, software, updates[/tags]