Bryan Larrick (via Kyle Sluder):
What Amazon has done is create a solid mass of text that has no breathing room. It’s claustrophobic. It’s stressed. It’s like standing three feet in front of a brick wall and pretending you’re appreciating the architecture of a building.
The idea here is to give developers a platform to address complaints, offer helpful tips, and let users know when features they’ve requested in an app review have shown up.
[…]
Developer responses will be public alongside reviews on a Google Play app listing. And, when a developer has something to say, Google will email the user who wrote the review to let them know there is a response.
So far it’s limited to “top developers,” which leaves a good opportunity for a competing app store to do better.
Update (2012-07-01): Matt Gemmell:
A review that you feel compelled to respond to is probably, in essence, a conflict situation. We have a rule of thumb for this: deal with conflict privately. Don’t shout at subordinates in front of the whole office. Don’t bicker with your spouse at someone else’s dinner party. It’s the same rule. It doesn’t matter what the tone or content is, on average; it’s still a crappy way to handle a situation.
One idea I’ve had is giving developers the ability to add a support link to a review.
There are certainly some problems with responding in public, but I still think it would be better than the status quo.
Dennis Fisher (via Slashdot):
PayPal’s decision to offer financial incentives to researchers follows the establishment of similar programs by companies including Google, Mozilla, Facebook, Barracuda and others. Google’s bug bounty program may be the most well-known and comprehensive, as it includes bugs not just in its software products such as Chrome, but also its Web properties. The company has paid out more than $400,000 in rewards to researchers since the program began and researchers who consistently find bugs in Google’s products can make a nice side income off the program.
Sandboxing is intended to protect Mac users from malware and poorly designed apps. I think it will accomplish some of these goals, but with a high price.
[…]
I would like a control in the preferences app to allow App Store apps to override core OS functionality and escape some of the sandboxing rules. Let’s call it “geek-mode” for now. Geek-mode should take effort to find. Geek-mode should require a password. If geek-mode is off, the App Store should not show apps that require it.
In my view, there should be entitlements available for everything that apps want to do. This would allow every app to be sandboxed, but apps would be prevented from doing things they aren’t supposed to be doing. Then, because every app comes with its list of entitlements, it would be possible for the system or the store to make the user opt-in to access apps that are potentially dangerous or confusing.
Little Snitch is the only third-party kernel extension that I use. I doubt that it’s the cause of the kernel panics I’ve been having, but I wanted to temporarily uninstall it just to be sure. I ran the uninstaller, which said it was successful, but the bundle identifier was still showing up in my kernel panic logs and in kextstat’s list of currently installed extensions. This was strange because I could see that the .kext file had indeed been deleted from the /System/Library/Extensions folder.
Even stranger, the logs showed version 2.5.1, when I’d had 2.5.2 installed for over a month. It seemed that Mac OS X’s kernel extension cache wasn’t being updated. I found various tips online, such as sudo touching the installed kernel extensions or removing the folder /System/Library/Caches/com.apple.kext.caches. None of these helped.
I then tried manually unloading the kernel extension:
icarus$ sudo kextunload -v -b at.obdev.nke.LittleSnitch (kernel) Can't remove kext at.obdev.nke.LittleSnitch; services failed to terminate - 0xe00002c7. Failed to unload at.obdev.nke.LittleSnitch - (iokit/common) unsupported function. Jun 21 10:37:46 icarus com.apple.kextcache[92]: Error copying //System/Library/Caches/com.apple.corestorage/EncryptedRoot.plist.wipekey to /Volumes/Recovery HD/com.apple.boot.R/System/Library/Caches/com.apple.corestorage/EncryptedRoot.plist.wipekey Jun 21 10:37:46 icarus com.apple.kextcache[92]: ucopyRPS - Error copying files used by the booter. errno 28 No space left on device
The error shows that the OS was trying to copy to the “Recovery HD” partition for Lion Recovery, but the partition was full. Apparently it was aborting without updating the cache on my main partition (which was not full). I used diskutil to mount the “Recovery HD” partition, and sure enough it only had about 40KB free.
Live-resizing the partitions didn’t seem to be possible, so I reformatted my drive and reinstalled Lion, which created a fresh recovery partition (now called “Boot OS X”, for some reason), which has 128 MB free. Now there’s enough space for the system to automatically update the kernel extension cache.
Sidenote: While trying to free up some space on the recovery partition, to avoid having to repartition, I inadvertently messed something up and rendered the main partition unbootable. Since there doesn’t seem to be a convenient way to create a new recovery partition, it’s probably a good idea to keep a backup. I’m going to create a device image of mine using DropDMG. I also learned that Carbon Copy Cloner can do this automatically when backing up the main partition.
The hostility for and against Microsoft and Apple hasn’t abated. (At a product announcement last week, I sat next to fellow tech columnist Walt Mossberg from The Wall Street Journal. We laughed about our hate mail; Walt, in fact, has identified what he calls the Doctrine of Insufficient Adulation. That’s when you give a rave review to an Apple product – but you still get hate mail from Apple fanboys because, in their judgment, it doesn’t rave enough.)
David Smith (via John Gruber):
So long as you don’t actually delete the old version of the app within iTunes Connect you can continue submitting updates to apps even while they are in the Developer Removed from Sale state. Whether this is intentional functionality is unclear but I have verified that it does in fact work and the resulting approved updates are available for customers.
This is good news, although I still think the App Store needs paid upgrades. One of the strange things about the “hack” is that the store will notify users about minor updates to apps they’ve purchased but not major ones.
Because TextExpander must observe your keystrokes anywhere on your Mac to be useful, it can’t work in sandboxed form, so TextExpander 4 isn’t available in the Mac App Store. Now that the Mac App Store requires sandboxing, developers of non-sandboxed apps can submit only bug fixes for those apps in the store; any new or significantly updated apps must restrict themselves to operating in a sandboxed environment.
As before, Smile has gone to some extra effort to support both their Mac App Store and direct customers.
While the Maps API remains free for the vast majority of sites, some developers were worried about the potential costs. In response, we have lowered the online price from US $4 per 1,000 map loads to 50¢ per 1,000 map loads.
With iOS 6 removing the transit features from Apple’s built-in Maps app, I’m hoping that we’ll see some third-party apps (or an official Google one) that use Google’s maps and data.
There was no story. It was all over the place: Here’s an ARM tablet. Here’s the clever keyboard cover that goes with it. Now here’s another tablet that looks much the same but a little thicker but in fact is running a different and incompatible OS. Oh and here’s another keyboard cover, this one with moving keys. Design is about making decisions, and Microsoft could not decide. ARM or Intel? Who should be on stage? Soft or hard keys on the keyboard cover? They went with “all of the above”.
The keyboard cover looks intriguing, though. Typing on an iPad is still no fun.
