We’ve done literally hundreds of these upgrades and our best guess (given the pictures you show) is that your particular machine may have experienced a spill or possibly a heat releted issue that caused mic to adhere to top case.

The microphone placement was not mentioned in the video because it is not a component that normally would come into play in swapping out a hard drive.

Perhaps you also happened to run across bad instructions. The internet probably isn’t known for correct nor complete information. In my experience the step-by-step instructions on ifixit.com are quite good. I used them to fix many Apple machines (TiBook, G4 iMac, MacBooks) and their instructions as well as photos always seemed quite precise and warning me of pitfalls like those little wires I might accidentally damage.

defaults write com.apple.Dock show-expose-menus -bool no; killall Dock

does not stop the Exposé ‘madness’…

I am sudo -s when I perform the command. thx.

I submitted a Bug Report to Apple on this gem.

Boy, talk about a hugh mental interrupter, nothing i can recall is so visually imposing… Apple? May I REQUEST you place an item in Apple Menu > System Preferences > Exposé and Spaces > Exposé > ‘• Enable Exposé use with dock’ ?

I was also confused about that – thanks for the information

@ Jeremy: This updater is only available for OS X Server. The 1.0 built had problems with Xserves with more than one ethernet jack on the same subnet. It deactivated all settings because it detected more than one instance of its serial number

Regards,

Christian

Apple screwed this one seriously.

Any ideas?

Thanks Jeff.

Also, I find Gruber’s and your argument about “the record that Flash has” to be very curious. Essentially, the argument that Flash Player is known to be buggy, so therefore it shouldn’t be updated? It seems to me that’s the opposite of what should happen.

Again, we’re not talking about a major update to Flash Player, for example from 9 to 10, but simply a fix for one security bug. Although I should say, for many users who upgraded from Leopard to Snow Leopard, they were automatically and unknowingly upgraded from Flash Player 9 to 10 by Apple. The automatic upgrade from Flash 9 to Flash 10 also occurred in Leopard via Security Update 2009-005, even to those users who had already installed Flash Player 9.0.246.

You can place the blame for it wherever you want, but expecting something different is not rational.

I’m not sure the way the discussion is going makes sense. (Withdraw the GM) Rather I think there’s a deeper issue of what to do if a serious flaw is found after disks are on the shelves. While Apple has been lucky there is the chance of something happening ala many XP installs where systems are compromised within minutes of being installed if older media is used.

The solution just has to be to make a security update check as part of the installation process. The fact Apple doesn’t do this is worrisome.

1. Seed the release candidate to developers
2. Tell developers that it’s a release candidate
3. If no show-stopping bugs are found, tell developers that the release candidate is GM
4. Tell developers the release date
5. Tell consumers the release date

Unfortunately, Apple skipped steps 2 through 4. Indeed, at no point prior to or even on August 28 did Apple ever tell us that 10A432 was either a release candidate or the GM.

“If Apple had already declared build 10A432 the GM before seeding it to developers for testing, that would be completely irresponsible [...].”

This is true if the sole purpose of developer seeds is to discover bugs in the seed that might be showstoppers. But there is another purpose, which is to allow developers to make sure their apps can be ready to ship when the OS does go GM, whenever that may be.

I think your point that “Apple could have un-declared it GM” still stands. From our point of view 10A432 would just have been another seed that turned out not to be GM. Even if they had told us it *was* GM, they could have un-GMed it.

I’m also a developer and publisher of Mac software. Are you?

But by all means, continue with your armchair commentary.

Does anyone want a broken Adobe Flash in a GM or (worse) corruptions or instabilities introduced elsewhere in the environment? Having been in (many) these discussions for OS-level release work (not at Apple), and a conservative engineering development practice (usually) carries these decisions. Experience has led me to be skeptical around claims of entirely isolated and modular code, too.

After the realization that a fix is not going into the GM is grokked, the discussion then (usually) becomes “and how quickly can the fix be tested and made available?” And “will we have systemic risks or exposures in the wild prior to that?”

The whole GM discussion here is somewhat of a canard, too. An SL Server software licensing fix didn’t make the GM, after all. The better question is “when is the fix going to be tested and available?” Faster is better. Faster and unstable is worse. And you can only go as fast here as you have staff for and testing coverage for. But a GM? That’s substantially more than a vehicle for a fix.

Load ClickToFlash, and move on.

I got sick and tired of his relentless pro-Apple fanboyism, his snide personal attacks, and the one-sided nature of his ruthless commentary.

it comes as no surprise whatsoever that Gruber would automatically take Apple’s position on the Flash issue.

1. Even if Apple did not manage to ship the latest version of Flash with their OS install, most of the ‘outrage’ seemed to be about the X.6 updater _downgrading_ the installed version. It should be hard to find a parallel universe in which that makes sense.

2. What exactly do people think that Apple do in terms of quality control that they couldn’t manage to achieve within a week? Even in their own code there are plenty of untested areas and if you’re using non-English localisations it is blatantly obvious that Apple consider it perfectly acceptable to sell software which hasn’t even been looked at (by a human who is awake and speaks the language), so what exactly will they do with the Flash plug-in before shipping it.

Of course, in the days of ClickToFlash, the practical relevance of this seems negligible. It would be interesting to read what people commented had Apple not shipped Flash at all with their OS.

This way, anyone who hadn’t updated to 10.5.8 yet got 9L31a, with the proper drivers included, and anyone who had 9L30 already only needed the small AirPort SU to fix things up.

I don’t think boycotting Radar will help at all, unfortunately. Though I’ll admit I’ve already got frustrated enough that I’m skipping filing some bugs. I probably see twice as many as I file these days, and that’s not even counting feature suggestions/SDK deficiencies.

(1) The radar front line exists to route stuff as quickly as possible and to ask for more information directly, when it is obviously needed. Unfortunately, the front line often doesn’t have anywhere enough information to really know what questions to ask or even if further information from the developer is required. It helps if you title your bugs appropriately: “Cocoa: etc.etc.etc”, “Garbage Collection: etc.etc.etc”, “Xcode: etc.etc.etc”.

(2) Dupes are second class, but a very important second class. However, the duplicates are considered when analyzing the master bug and, often, more information is asked of specific duplicate filers that have a unique or more informative bug. Generally, though, once there are more than a couple of dupes, more information isn’t needed.

(3) There are many reasons for a non-searchable bug database, most revolve around secrecy. Not just Apple’s, but external developer’s secrecy, too. And by secrecy, I don’t mean just product secrecy, but also intellectual property protection, too. There is a big bundle of potential liability there and to address it would require a bunch of resources beyond engineering.

(4) If you send me email containing bug #s of bugs that are frustrating you, I will double-check on the bug. I may not respond beyond saying “thanks”, but I’m always happy to double-check (see (3) — it is the way it is).

The problem is that, for an outsider, once your bug has been flagged as a duplicate you no longer get any information about it. Apple needs more information? It goes to the original, not to you. Apple fixed it in a seed and wants verification? You’ll never know it. Apple shipped the fix? Hope you noticed the one-line mention in the release notes, if it even merited one.

Any bug system MUST flag bugs as duplicates. It’s just inevitable that people will submit multiple bugs about the same problem. But most systems allow the person who filed a duplicate bug to still find out about how the original is progressing. That Apple does not makes us all extremely fearful of filing a duplicate, because as soon as our bug is flagged as a duplicate, all interaction with Apple would end.

If Apple kept doing the exact same stuff they’re doing now, but allowed us to start tracking the original bug when one of ours is flagged duplicate, this complaint would go away.

Mike, I’m a solipsist, so that’s where you’re wrong. Anyway, I am a person, last time I checked, and I demand to be treated as a person, not simply a cog in Apple’s giant profit machine. If I’m not, I’ll walk away. By the way, although I’ve never punched a bus, I have in fact punched an airplane.

Bill, I’m sorry to say that your comment sounds like a canned response. I don’t get the impression that you read and understood my post. Notice that none of my 4 complaints was “My bugs never get fixed.” (The little devil on my shoulder is screaming something about irony right now.)

Overwhelmingly, the radars do get fixed, the product(s) do improve, and the input from various external developers is extremely useful. Sometimes it takes a long time — I recently verified as fixed a handful of bugs that I filed in 2000, 2001, and 2002.

Even if it feels like your bug is falling into a black hole, it is not.

For duplicate bugs, it is almost always the engineering team itself that makes the duplicate call. Furthermore, when a bug is duplicated, anything uniquely useful from your now duped bug is generally captured directly or indirectly in the original bug.

But with other types of bugs, I’d agree with you: there’s a decent probability that your time will be wasted. If you have something specific and clearly wrong in an app, it can still be helpful. If it’s a matter of opinion or would confuse an Apple Genius, you might as well tell it to your hand.

QA people, whose job is solely to patrol Radar. They do not fix bugs or add features; they merely curate the system. See App Store Mercenaries.
Actual “engineers”, who work on the products you’ve found bugs in. These people really are of limited supply and have limited time, some of which needs to go into actually fixing bugs and adding features, and not just fielding Radar reports. Throwing more people at the problem is not a solution; see The Mythical Man-Month.

It’s a hard problem. The number of developers is going up, which means (I would hope) that the number of bug reports is going up. I wouldn’t expect that the number of engineers per product to fix those bugs is going up much faster than replacement rate; that leaves the QA groups, whose job definitions may still be open to the kinds of problems Daniel Jalkut wrote about.

+ (NSAlert *)alertWithMessageText:(NSString *)messageTitle defaultButton:(NSString *)defaultButtonTitle alternateButton:(NSString *)alternateButtonTitle otherButton:(NSString *)otherButtonTitle informativeTextWithFormat:(NSString *)informativeText, …;

Nibless Window Example

http://blog.hyperjeff.net/code?id=292

Rob, it depends on what you mean. On the logistical side, this is to be done for debugging only, not for the ‘GM’ of the app. On the technical side, stripping has very different implications for DWARF than for STABS. As I discussed in my earlier post, DWARF symbols are not put in the executable itself. The executable only contains references to the intermediate object files. Thus, stripping merely removes those references, not the debugging symbols, which were never there to be stripped.

+[NSBundle loadNibNamed:owner:]
-[NSNib instantiateNibWithOwner: topLevelObjects:]
The documentation of these two methods should really mention this fact.

As long as you choose a good password (mine is Joshua), all of your data is safe.

Not any more it’s not, now you’ve put that on the Web.

I’d guess that this is more a theft prevention issue, as well as a way to get more visual presence on the shelf. These were the two issues initially with CD long-boxes I believe.

Recently, new units were introduced to try and lift this confusion. The kibibyte (kiB, 1024 bytes), mebibyte (MiB, 1024 x 1024 bytes) and gibibyte (GiB, 1024 x 1024 x 1024 bytes). So drive manufacturers use Gigabytes because it makes the number bigger and OSes use Gibibytes, but display them as GB instead of GiB because it’s what people have been using for years.

I can’t lie to you, Dean Martin. Yes, it is Steve Jobs.

But I have to clarify — you really got an email from Steve Jobs? He really knows enough about code to talk intelligently about these issues?

I’m assuming sarcasm but I can’t tell

Scott, it should be clear from my post that the accessors were never intended to be thread-safe.

if (_thing != aThing)
{
[_thing release];
// if your getter hit here on a different thread — you have problems.
_thing = [aThing retain];
}

A safer approach is to release the old object AFTER the the pointer to the new object has been assigned. use a local pointer to keep the reference of the ivar so it can be released afterwards

-(void) setThing:(id)aThing{
if (_thing!= aThing){
id oldThing = _thing;
_thing = [aThing retain];
[oldThing release];
}
}

Can be easily rewritten as:
-(void) setThing:(id)aThing {
[aThing retain];
[_thing release];
_thing = aThing;
}

Andrew, that’s a good question. Suppose that on line 2 you have [updater updateThings] instead of [myThing setThing:nil], where updateThings contains the following code:

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
...
[[allThings objectAtIndex:i] setThing:nil];
...
[pool release];

Since the setter’s [_thing autorelease] occurs within the context of this nested pool, _thing could still be deallocated before line 3.

All the people who used to write cocoa blogs are more active on Twitter now, snarking back and forth in little bite-size chunks.

Basically, there are three possible solutions:

2. Bind to a different object in the nib rather than to the File’s Owner.

Sounds like the reason I’ve been looking for to use NSObjectController.