Tuesday, July 13, 2010

Orwellian Apple Censorship

Here's my comment on the story about Apple censoring its Discussion Boards over Consumer Reports refusal to recommend the new iPhone 4 based on reception issues. Part of the reason for this blog is document my own troubleshooting efforts and problems I've had with Apple hardware and software.

Apple discussion boards have done this for years. They have devoted stormtroopers on there who will edit or delete your posts in a flat second, if they deem the posts unflattering to their products.

What’s unfortunate is that I’ve had several negative things to write in those forums, usually about hardware. My Powerbook’s lower memory slot went out and I never got it fixed because mine wasn’t in the “range of serials” that Apple deemed to be the problem; no one told my Powerbook that. My current Airport Extreme has to be reset usually once each day…again, Apple’s response to me is to make an appointment and bring it in to the Genius Bar (not sure how they are going to replicate my issue there, since it’s random). If you Google it, however, you’ll see that it’s a common problem, and people get inconsistent help (some get products replaced straightaway while others don’t).

Same sort of censoring happened when Apple decided to remove pdf manuals and hardcopy manuals from Logic Studio and replace them with the cumbersome Apple Help system. Apple finally relented and quietly brought back the pdf files after all the complaints. But they never acknowledged the complaints.

I think Apple would do well to have a revamped hardware testing division: A group of folks to test a product for six months thoroughly, before Apple releases it. They’ve always relied on users and developers to QC their software just before and right after release, but it’s a mistake to use that model on hardware. There are certain things in hardware that simply can’t be fixed after the genie is out of the bottle. I’m afraid what happens is that users end up being guinea pigs for the hardware a lot of the time; Apple simply (quietly) fixes the issues discovered in the next iteration, but the original buyers are left out in the cold.

[From Apple Censoring Discussion Forums Ref. Consumer Reports | Cult of Mac]

Monday, July 12, 2010

Airport Extreme Freezes and Connection Slowness

Not even a year ago, we replaced our old Netgear Ethernet Router and old Airport Express with a nice, shiny, new Apple Airport Extreme. Lot's o' promise. The main problem (apart from other minor hiccups you'll find on here) has been that we typically have had to soft reset the unit daily, because the connection would become completely unresponsive--including Ethernet and wireless connections. So, it was either the cable modem (which worked fine with our old router) or the Airport Extreme, which judging from a Google search is giving more users than just me fits. So, I've played with all sorts of settings, including turning off IPv6 in the unit and on all the computers in the house; that didn't seem to fix anything.

However, I may have just made some changes that greatly improved my download speed while also eliminating the need to reset the AEBS each day! We'll see if my "fix" holds up. But the speed improvement is a plus.

First, I changed from "Automatic" to 100 Mbps/Full Duplex in the Airport Utility and restarted the AEBS:

Next, I changed similar settings in System Preferences->Network ("Automatic" to "Manually"):
Speeds via speedtest.net showed a dramatic improvement for download:

Then, I finally found the culprit: The automatic MTU!!
I couldn't believe it. Such a stupid, basic cause of such a big problem. This is most certainly a BUG.

To fix the MTU:

1. Apple Menu > System Preferences... then Network.

2. On the left, choose Ethernet , then Advanced... on the bottom.

3. Choose Ethernet tab:
. . . Configure: Change from Automatically to MANUALLY.
. . . MTU: Change from Standard to CUSTOM. Put 1452 then click OK. Then Apply at the bottom.

[From Apple - Support - Discussions - A fix for random, slow, intermittent ...]

Saturday, July 03, 2010

1Password Slow Safari Starts and Command Key Sluggishness

I've had these issues for sometime now. Turns out that I may have discovered something crucial about the problems. Rebuilding the datafile, clearing the cache, and removing all InputManagers did not fix the issues, which were reproducible on two Macs. Removing the Internet plugins also did not resolve the issues.

If Safari is starting slow for you under Snow Leopard and you use 1Password 3, make certain that you remove the old InputManager called something like "1Passwd." I was able to start Safari far faster than before. Until Agile fixes the command key sluggishness issue, make sure you lock your keychain after you're done using it. It's a pain in the ass, but your browsing snappiness will return if you like to use key commands like me.


Another discovery (apart from the one listed below) can be read here. Turns out that it's the "key icon" in the Safari menubar that's somehow contributing to the command key slowness in Safari. If I disable that in 1Password's preferences, the sluggishness disappears, even with the keychain unlocked. No clue, but that's somehow the culprit. Maybe it will help others. Please let me know here if you're able to reproduce this problem.

First, I can verify that removing the old InputManager left over from the 1PW 2.x days definitely made Safari (ver. 5) start up faster (2 - 3 icon bounces in the Dock instead of about 10). Start up is almost instantaneous now, thank goodness.

Second, this command-key sluggishness (and even clicking the 1P or key icons) I've been going through has persisted (any Command key combination is slow on Safari 4 and 5). This means sluggish behavior for key combinations like Cmd-T to make a new tab, Cmd-W to close a tab, or even Cmd-Q to quit Safari. Very LONG pauses before the desired result follows the keystroke combination.

However, I made a discovery today that I wanted to pass along to you all at Agile, which may or may not help troubleshoot this issue. It's reproducible on my Mac Pro and my MacBook. The sluggishness ONLY occurs while 1PW is unlocked. As soon as I LOCK 1PW again, the snappiness of my command keys in Safari 5 returns!!! Unlock the keychain, back to sluggishness. Completely reproducible on both my machines.

I have rebuilt the data file and cleared caches several times. The only other InputManagers I still have running are DeliciousSafari and the latest beta of Glims (if that's even still an InputManager).

Any advice you can provide would be greatly appreciated.

[From Slow Safari startup with 1Password enabled (when the Cache is out of date)]