Archive for June 1, 2012

Friday, June 1, 2012 [Tweets] [Favorites]

The Sandbox Chill

Brent Simmons:

I have to admit that I remain worried about sandboxing. I find myself discarding good ideas for apps just because of sandboxing rules. That can’t be a good thing for the platform.

I’m not worried so much that Apple will prevent me from running the Mac apps that I choose, but rather that they will indirectly prevent those apps (or features) from being developed in the first place.

A Tale of Two Cryptographically Signed OSes

Patrick Rhone:

So, today Apple released a very nerdy but quite well written in a way that humans can understand white paper on iOS security. It’s a fascinating read and I urge you to do so in full. At the outset, Apple provides the following explanation about the first level of security in iOS — The Secure Boot Chain…

Fear and Loathing and Windows 8

Michael Mace (via John Gruber):

My conclusion is that Windows 8 in its current form is very different; attractive in some ways, and disturbing in others. It combines an interesting new interface with baffling changes to Windows compatibility, and amateur mistakes in customer messaging. Add up all the changes, and I am very worried that Microsoft may be about to shoot itself in the foot spectacularly

Alfred and Sandboxing

Vero Pepperrell:

You’ll continue to find the free version of Alfred in the MAS, as Apple allows existing apps to remain in the store and receive bug fixes. However, if you’re looking for the big juicy new features, your best bet is to download Alfred from our website. With this version, you can take advantage of the Powerpack and of pre-releases, which give you a sneak preview of new features.

API Copyrights Are Dead

Eric Raymond:

Instead, Alsup did something subtle and clever. Under the guise of writing an exhaustive dissection of Oracle’s claims, he actually wrote a sort of roadmap or how-to manual explaining how to demolish claims of API copyrightability in general. If and when such a claim is again litigated in a U.S. jurisdiction, you can bet a vital organ that this ruling will be cited – and even though it’s not claiming to decide anything but the instant case, it is near certain that the judge will treat it as precedential for that future case in exactly the same way that (for example) Computer Associates vs. Altai has been repeatedly cited.

After X Years Programming

Dave Winer:

The conventional wisdom is that you “move up” into management long before you've been coding for 37 years. Only thing is I don't see programming as a job, I see it as a creative act. I drew a big circle shortly after I started, and said I was going to fill the circle. So until the circle is full, I still have more to do.

Mac App Store vs. Buying Direct

Jonathan Rentzsch:

Apple now only accepts sandboxed Mac apps, clarifying the situation: customers should buy Mac apps directly unless there’s a good reason not to.

Here are some reasons why it’s preferable to buy non-sandboxed apps directly from developers…

Reverting Apple’s “PNG’s”

Daniel Jalkut:

Essentially, the authors of this tool figured out the optimizations that Apple were doing, and reversed the steps to convert them back into standard PNG images. The tool relied upon a compiled-in version of the libpng library.

Recently when I went to use this tool again, I noticed that it did not work reliably. It dumped lots of memory errors and complained of “extra compressed data” in the input files. I then proceeded to spend too many hours trying to fix it, bashing my head against libpng, before my friend Tom Harrington alerted me to an Xcode-bundled tool that can do the job reliably:

iPhoneOS.platform/Developer/usr/bin/pngcrush

Jens Ayton:

…a more accurate description of the issue is that they are not PNGs despite using a PNG header and similar file structure and purloining the .png extension.

The PNG specification has very specific conformance requirements specifically to avoid incompatible variants popping up, and disguising the iPhone-optimized pictures as PNGs is a downright Microsoftishly destructive thing to do.

Sandboxing Deadline Arrives

Lex Friedman:

Rich Siegel of Bare Bones Software spoke to Macworld about his concerns regarding sandboxing last November too, rattling off a long list of features in the company’s popular text editor BBEdit that he feared might not be allowed going forward: multi-file search and replace; text factory applications; multi-application automation using AppleScript or Automator; Open File by Name; disk browsers; live folder views in projects; SCM integration; bulk HTML tools operations (syntax check, site update); and lots of behind-the-scenes stuff such as scanning directories for ctags data. Back then, Siegel said he literally wasn’t sure which features BBEdit would be able to continue to support once sandboxed. And now that sandboxing is here, Siegel still isn’t sure…

First, there’s what your app does. Then there’s the subset of features that one would expect to work based on Apple’s WWDC presentation of the sandbox design and intent last June. A subset of that are the features that Apple has actually implemented. And a subset of that are the ones that actually work in Mac OS X 10.7.4 (or the various 10.8 previews). Thus, as Siegel says, “there’s a lot of testing to do.”

On the one hand, it’s kind of a waste of time to do this testing. The longer you wait, the more OS bugs will be fixed. You could work on improving your app and sandbox it more easily later. On the other hand, in theory, if you find and report the bugs now they’ll be fixed sooner. If showstopper bugs aren’t fixed by the time your feature update is ready, you can’t ship it.