The Problem with Android

⌘ Permalink

Nilay Patel:

[Google’s Android boss man Andy] Rubin said that the biggest problem for Android on tablets is “there’s no organized way for consumers to recognize it as a viable platform,” and that Google wants consumers to see its tablets as part of the broader Android ecosystem. “The educated consumer realizes it now that they’re either picking the Apple ecosystem or the Microsoft ecosystem or the Google ecosystem… we’re going to do a better job at making people understand what ecosystem they’re buying into.”

I’ve got to hand it to Rubin, he seems to understand some of the problems Android — and not just the tablet end of things — is facing. But then, just then, he blows it. Again, Patel:

Of course, one of Android’s biggest challenges in the tablet market is the lack of high-quality apps designed for the larger screen, but Rubin was somewhat dismissive of those concerns.

Android’s fragmentation is a bad thing, and the lack of a cohesive consumer-facing strategy is bad, too. While Google may claim that Android is one ecosystem, walking in to a Best Buy doesn’t really portray that. In fact, it feels like the PC wars — OEMS facing off against each other, despite the mass similarities between their products.

But those things would matter far less if there were decent apps out there for Android.

Apple Launches Developer ID Program

⌘ Permalink

Apple:

The Mac App Store is the safest place for users to get software for their Mac, but we also want to protect users when they download applications from other places. Developer ID is a new way to help prevent users from installing malware on their Mac. Along with Gatekeeper, a new feature in Mountain Lion, signing applications with your Developer ID certificate provides users with the confidence that your application is not known malware and has not been tampered with.

Get your applications ready for Gatekeeper today. It’s easy to get started with Developer ID using the automated certificate request tools in Xcode 4.3 or the Developer Certificate Utility.

Thanks to everyone who sent this in.

On the Macintosh File System

⌘ Permalink

After listening to this week’s Hypercritical, on which John and Dan discuss file systems for about 17 hours, I realized that I didn’t know much about what came before the Hierarchical File System.

HFS, of course, is the grandfather of HFS+, which the Macintosh uses today. It was first released with the Hard Disk 20 for use with the Fat Mac in September 1985.

Apple dropped support for MFS in System 7.6.1.

The original Macintosh shipped with the Macintosh File System. Designed to run on the 400k floppy disks that Mac owners knew so well, it had several notable features:

Resource Forks

From Wikipedia:

A resource fork stores information in a specific form, such as icons, the shapes of windows, definitions of menus and their contents, and application code (machine code). For example, a word processing file might store its text in the data fork, while storing any embedded images in the same file’s resource fork. The resource fork is used mostly by executables, but every file is able to have a resource fork.

At first, the resource fork was used to store all graphic data for a file for being drawn on the screen of the Macintosh. These files helped the original Mac team run the machine with a measly 128 KB of RAM, down from the 1 MB the Lisa required for its GUI.

Today, resource forks are still a part of HFS+. They store icon information, program associations and more.

Character Limits

MFS supported file names with up to 255 characters. However, the Finder didn’t support file names longer than 63 characters. When Apple released HFS, the limit was dropped to 31 characters in the OS. With OS 8.1 (coupled with HFS+), 255 characters were supported, although Finder’s limit of 31 wasn’t changed until OS X.

Flat File System

The most dated feature of MFS is that it was a flat-file system.

The concept of folders existed under MFS, but they weren’t nested as we are used today — there was no hierarchy of directories on the original Macintosh.[1]

Here’s Wikipedia again:

They were visible in Finder windows, but not in the open and save dialog boxes. There was always one empty folder on the volume, and if it was altered in any way (such as by adding or renaming files), a new Empty Folder would appear, thus providing a way to create new folders. MFS stored all of the file and directory listing information in a single file. The Finder created the illusion of folders, by storing all files as a directory handle/file handle pair. To display the contents of a particular folder, MFS would scan the directory for all files in that handle. There was no need to find a separate file containing the directory listing.

Good times.

  1. My pal Thomas Brand has clarified this on Twitter. Nested folders could be created, but were just an illusion built with metadata. Far out, right?  ↩

Farewell, Old Friend and Enemy

⌘ Permalink

IMG 1905

They’re about to tear this down.

I only cut through the medical district yesterday on a whim, and while I knew this day was coming, I was shocked to see that the room in which my life — and the lives of my family members — changed forever was about to get demolished.

Part of me wanted to chain myself to the equipment, and another part of me wanted to tear what was left of the building to the ground for them.

Huh.

Dual Booting with Mountain Lion

⌘ Permalink

Thomas Brand:

A reckless enthusiast might throw caution to the wind, install 10.8 over their existing operating system, only to complain about the rough edges later. An experienced veteran of beta software knows you can’t easily undo an operating system upgrade and prefers to preserve their current OS while dual booting into 10.8.

Depending on your Mac, dual booting between two versions of OS X can be accomplished in a number of ways.

I have it running on an SSD inside an external FireWire 800 case. It is crazy fast.

App Recommendation: ReaddleDocs for iPad

⌘ Permalink

At $4.99 in the App Store, some might think its pricey, but ReaddlDocs scratches me right where I itch, so to speak.

For my day job, I have to carry (and be familiar with) hundreds of PDFs worth of building plans, schematics, cut sheets and service contracts.

Now, I have a 13-inch MacBook Pro which, while being ridiculed by some, is the perfect machine for me. However, my iPad 2 is obviously much more portable, with better battery life.

ReaddleDocs for the iPad sits on my home screen, and for good reason. Using the built-in Wi-Fi sharing function, I can add files to my iPad without dealing with iTunes. The app super fast, handling large PDFs better than any app I’ve tried. The app lets me keep the same folder structure I have on my Mac, so finding files is just as easy. It really saves me a ton of time in meetings and in the field.

And unlike GoodReader, I can look at the UI without wanting to die. I just wish Readdle would make the iPhone version so handsome. As it stands today, it’s pretty bad.