Tag Archives: os x

Mountain Lion and the Future of Apple

Johnathan Gruber has a big post today about Apple’s announcement of Mountain Lion, the next version of OS X.

My reaction to the news: “finally.”  I’ve been waiting for OS X to fully embrace iCloud since last year, when I thought it would happen with the initial release of Lion, but it looks like it will finally happen this summer, when Mountain Lion is released.

Gruber’s post is worth reading. He gives his impressions of a pre-release copy of Mountain Lion he’s been using for the past week, and also ruminates on how Apple orchestrated the announcement. They used a new technique; VP Phill Shiller did one-on-one presentations to a dozen or so tech writers a week before the official announcement.

Among other things, Gruber considers what this announcement says about the current state of the relationship between OS X and iOS

[recounts a few years ago when Apple delayed an OS X release to devote resources to iOS]


Putting both iOS and OS X on an annual release schedule is a sign that Apple is confident it no longer needs to make such tradeoffs in engineering resources. There’s an aspect of Apple’s “now” — changes it needs to make, ways the company needs to adapt — that simply relate to just how damn big, and how successful, the company has become. They are in uncharted territory, success-wise. They are cognizant that they’re no longer the upstart, and are changing accordingly.

It seems important to Apple that the Mac not be perceived as an afterthought compared to the iPad, and, perhaps more importantly, that Apple not be perceived as itself considering or treating the Mac as an afterthought.

I don’t think this goes far enough.  What stands out for me is not just that OS X is (back) on an annual release cycle, its that the cycle is in close sync with iOS’s annual release cycle; both are released in the summer, rather than at, say, a six month offset. Why?

I think the reason is obvious, OS X and iOS are part of the same product. The promise I saw in iCloud, iOS 5 and Lion last summer was the arrival of a pervasive computing environment that spanned devices. Moving between a Mac, and iPhone and an iPad was close to becoming seamless. A Keynote presentation you started on your Mac would automatically be sitting in your pocket on your iPhone, waiting for a quick review while waiting in line for lunch. Without a second thought, you could open your iPad on the bus-ride home and finish up the last few slides. And that is just the beginning.

“Real” OS X Apps on the iPad, Are You Crazy ?!?!?

I’m posting this from my iPhone, so I can’t be bothered to name names, but trust me when I tell you, there are a lot of people criticising Apple for basing the iPad off the iPhone OS, rather than making it capable of running Macintosh applications by using a touch-enabled version of the version of OS X that runs on Mac desktops and laptops. I understand the impulse, but these people are either crazy, or they just aren’t thinking things through.

Let’s get one thing out of the way right up front. There is just no damn way to profitably sell a device that matches the price, performance and portability of the iPad that also runs existing Mac apps. This will change in the future, but it’s just not something that can happen this year.

There are many reasons for this, but it really starts with the fact that modern Macs use Intel CPUs and Intel CPUs just aren’t as power efficient for a given level of performance as the ARM CPU in the iPad, iPhone and other mobile devices. So, an iPad that runs existing Mac apps would have to have an Intel CPU, and so would have shorter battery-life, which hurts portability. This could be compensated for with a larger battery, but a larger battery would be heavier, which hurts portability and add expense which would already be higher, because intel CPUs cost more than ARM CPUs.

So on the hardware side, price and weight are two strikes against an iPad that runs Mac apps, but that is only half the problem. The bigger problem is software. Mac apps are built to be run on fairly powerful computers that are capable of multitasking and which people use a mouse and keyboard to interact with. There are a few implications of this.

First, there is a good chance that existing OS X apps, designed to run on powerful hardware, would be both slow and power hungry on an iPad becuase acceptable performance and efficiency on a iMac or MacBook could be completely unacceptable on an iPad. This is on top of the inherent power-efficiency disadvantages of compatible hardware.

An even biggher problem is that the user interface would be ill-suited to the iPad. There are no apps for the Mac designed for the type of interaction the iPad supports. On the otherhand, there are hundreds of thousands of iPhone apps that will run on the iPad. They were designed for touch interaction, so their UIs are more likely to translate to the iPad, which is in many ways an iPhone with a larger screen, than UIs designed for mouse and keyboard interaction. Perhaps less obvious, but at least as important, developers of iPhone apps are likely to be futher down the learning curve for multitouch UIs than developers of “desktop” Mac applications, so they will likely be able to release versions of their apps that take advantage of the possibilies of the larger screen on the iPad than Mac developers.

Further, all of those apps were designed for a device that is even more constrained interms of power consumtion and performance than the iPad. If anything they should run better on the iPad the the iPhone.

I understand why people would like the iPad to run OS X apps. People conflate running Mac OS X applications with “openness” that we don’t get when iPhone and iPad apps all have to go through the iTunes App Store approval process. But let’s face it, an iPad than ran Mac apps would come into this world some combination of slower, more expensive, less portable (in terms of both weight and battery life) and with far fewer good quality multitouch apps.  I don’t think anyone really wants that, so rather than asking for it, lets focus narrowly on the real issue because while it may be unlikely that Apple opens the iPad to apps distributed through channels other than the App Store, at least it possible.  An iPad that ships in 60 days runs Mac apps and doesn’t suck is pretty much impossible.

Fixing Upgrade Problems with Netatalk on Ubuntu 9.04 Jaunty Jackelope

As of Ubuntu 9.04 (aka Jaunty Jackelope), it is no longer necessary to jump through hoops to access files on an Ubuntu (or Debian) server from a Macintosh OS X client via netatalk.  Unfortunately, if you’ve previously gone to the trouble of jumping through those hoops by doing a custom compile of netatalk with openssl support , you are likely to run in to problems once you upgrade to Jaunty (and probably the soon to be released v9.10, aka Karmic Koala).  Fortunately, the fixes are pretty easy if you’ve managed to find this blog post.

There are two issues.  First, in order to support encrypted login, the custom build and configuration of netatalk loads some custom user authentication managers (‘uams’) that aren’t present in the latest packaged version of netatalk.  The /etc/netatalk/afpd.conf file probably ends with a line like this:

- -transall -uamlist uams_randnum.so,uams_dhx.so -nosavepassword -advertise_ssh

This both produces failures when trying to load the nonexistent modules, it also means the default modules fail to load, including a new, prebuilt, module ‘uams_dhx2.so’ which supports encrypted authentication on Mac OS X 10.4 and later.  The simplest solution is to edit /etc/netatalk/afpd.conf to either remove or comment out that line and just use the defaults.  Once you’ve updated the config, restart netatalk with the following command ‘sudo /etc/init.d/netatalk restart’.

The next problem is that the newer versions of netatalk use a newer version of a simple database library to store Apple-specific file information.  They provide a script for updating the db files, but you probably don’t know to look for it to run it manually.  For details, check the README.debian for the netatalk package, which is most likely found in ‘/usr/share/doc/netatalk/README.debian’.

Upgrading Problems
This version of Netatalk use to Berkeley DB 4.7.

Earlier releases used Berkeley DB 4.2.  As Netatalk does not
automatically update its database, you may experience problems like
those described in bug #200373: no files showing up in your folders.

If you have such problems, you may try to upgrade the database using the
script /usr/share/doc/netatalk/examples/netatalk_update.sh

Before you run the script, run ls -la on the target directory and pay attention to the user and group ownership on the .AppleDB directory because after running the script, it tells you to check the permissions/owernership on the files it updated, and it is really good to know what the correct permissions were.

Making Ubuntu into Proper Fileserver for Macs and Time Machine

This guide does a pretty good job of covering everything you need to do to get Ubuntu running as a proper server to Mac OS X clients using Apple File Protocol, rather than SMB, the more common Windows standard, or NFS, from the Unix world.

So far so good.  Now I have to try using it for Time Machine backups.