Enterprise Mac | Tom Yager | TAG: New Products

MORE ENTRIES

TAG: New Products

April 16, 2008

I made a couple of statements in my recent "Ahead of the Curve" blog that Apple contscted me to correct.

First, contrary to my claim that the iPhone SDK is the first time that Apple has released a public preview editions of Xcode in the past, Apple claims to have done so.

Apple tells me that it is not incorporating FORTRAN into beta 3 of its iPhone SDK, a release that includes the newest stable build of the GNU Compiler Collection toolchain. MacOSForge lists FORTRAN as a default language in its distributions of gcc after v4.0, This accounted for my confusion. Note that while gcc 4.x will build for OS X, it is only supported informally by Apple, as are all Apple open source projects.

My apologies for any inconvenience brought about by my incorrect information.

Posted by Tom Yager on April 16, 2008 01:28 AM

March 31, 2008

iPhone SDK: Interface Builder added; WebKit kicks into overdrive

Apple isn't shipping the official iPhone SDK until June, but if you're planning to create apps for iPhone or iPod touch, the pre-release SDK just became more than a curiosity for those writing native code. Interface Builder, the Xcode tool for creating graphical user interfaces for Mac applications, has been added to the iPhone SDK. This not only gives developers the ability to add non-HTML GUIs to their native applications, but Interface Builder also makes it easier to carry hardcore Mac coding skills to iPhone.

Webkit Icon

The SVG Animation in WebKit (Safari) is still under development, but in its latest incarnation it is fast, smooth and very close to passing the standard's acid test. I have little doubt that it will be in Safari's public release in time for WWDC in June. Developers who want to check SVG Animation out now can grab the latest nightly build of WebKit from www.webkit.org. Installing a nightly build binary will add an executable, webkit.app, to your Applications folder. It is indiscernible from Safari--even the title bar says "Safari" and all of your bookmarks are present. The tip-off is a gold-tinged rim around the compass icon. The About box reflects the latest full release build of Safari rather than the WebKit framework version.

There is always the risk that installing a nightly build over the top of production software will introduce some instability. I can't recommend it for Joe Machead, but if you're developing for iPhone, or developing for Safari for desktop, you should be tracking the WebKit builds and reading the blogs attached to the WebKit site.

You might not intend to build WebKit for yourself, but if you can read C and Objective-C, you'll find the WebKit source code to be a study in well-crafted code, written against multiple very complicated and moving specifications. Look at the HTML5 and CSS3 specifications on www.w3c.org to get a feel for what the WebKit crew is up against. Fortunately, it's a serious team that includes Apple engineers, and Apple is a key player in the specifications and standards processes.

Posted by Tom Yager on March 31, 2008 11:30 AM

March 19, 2008

iPhone 2.0: Safari hosts local apps; SQL on a smartphone!; go get Safari 3.1 now

I have a secret: I love JavaScript. It has an extremely simple C-like grammar--it has far more in common with C than Java--and is readable and compact. I can teach it to a child in an hour. With just a few days of messing around, a beginner can write powerful client and server applications in JavaScript, and the minimum required toolset is a browser and a text editor. To test changes to your code, you refresh its browser page.

I developed my appreciation for JavaScript by using it to create applications of surprising scale. In 1999, I wrote a book about creating Web applications, laying out in detail how one can do anything with JavaScript, CSS, DHTML, XML and SQL. The pinnacle of client-side JavaScript at the time was Microsoft's JScript, implemented in Internet Explorer. I took great care in my book to balance IE against Netscape, and to document the ways in which each browser adhered to and diverged from W3C standards. IE did better than most people would assume. It went on to become the basis of the ECMAScript standard. Then Microsoft all but pulled the plug on the language's internal development. The JScript editor and debugger vanished from Visual Studio. My book flopped, but worse than that, a simple language that had justifiable momentum, and even a job market built around it, dropped from sight except as a means to render dynamic HTML content and discern one browser from another.

JavaScript has reemerged as the J in AJAX, where it's assigned such common duties of manipulating in-memory data structures, loading plug-ins and performing explicit animation on user interface elements. It's good to see JavaScript back in action, but for years I've imagined what JavaScript might have become if it had been actively developed after Microsoft let it go. My crushing disappointment was that AJAX, not so advanced in light of history, didn't aim at the one target I felt JavaScript was destined for: Standalone browser-based applications.

Now we're back on track. Incremental developments in WebKit, the open source project on which Apple's Safari is based, have coalesced into the Safari browser for iPhone 2.0, due out in June, and Safari 3.1, which was just delivered for OS X. Apple and WebKit developers have invested an impressive amount of effort to implement vital portions of HTML 5, CSS 3 and SVG (scalable vector graphics) standards. HTML 5 provides a standard for embedded SQL statements into script code. SVG (scalable vector graphics) does what its name suggests, but also brings motion into places where only static bitmap graphics worked before. SQL (through SQLite) and SVG are linked into Safari, not plug-ins. CSS 3 sets up implicit and explicit animation, with both managed by the renderer.

In the transition from Safari 3.0 to Safari 3.1, WebKit coders and Apple somehow blew the doors off prior JavaScript performance. Apple created a JS benchmark, SunSpider (a click here will run it immediately; be aware that it takes some time), to prove its point. It measures the average time taken to complete a few cycles of complex JavaScript tasks. An 8-core, 3 GHz Xserve ran the SunSpider suite on Safari 3.0.4 in 6624.6 millisconds (6.62 seconds). A dual-core, 2.4 GHz Santa Rosa MacBook Pro running Safari 3.1 completed the SunSpider suite in 3211.8 milliseconds, or 3.21 seconds. The fact that SunSpider expresses its results in thousandths of a second portends sub-second results.

As for persistence, well, Apple decided that cookies and XML just wouldn't do. Since SQLite is already pervasive in iPhone OS, Apple wired it into Safari to give JavaScript coders the ability to manage data using real, grown-up SQL with transaction support. SQLite is strictly client-sized, but very powerful for a database that links entirely into your code (and it's open source). I wasn't that hot on SQLite in OS X's Core Data until I saw it in action in the iPhone SDK. Now that I see it it running on an embedded device, I see SQLite for the tight coolness it is.

There is another motivation to using SQLite as the persistence mechanism for iPhone Safari applications: It forces developers to give much more thought to their use of storage, which is a finite commodity on a phone or music player. It also slashes a lot of tree walking and in-memory XML out of your script code. But if you've just got to do the DOM, Apple did fold in two new native-ized DOM query methods to displace still more iterative scans.

Safari on iPhone 2.0 (and iPod touch 2.0) pushes the envelope in so many ways that Mac users will want it in desktop Safari and Dashboard. Okay, I'll speak for myself. I've been hollering for standalone browser-based applications, not those pseudo-apps that require a teeny HTTP server, for years. I'm on record saying that if Apple just did persistence in iPhone's Safari, I'd quit harping at them about a native SDK. I got what I wanted and then some, so now I can harp at you about what Apple poured into iPhone/iPod touch 2.0, Safari and the SDK.

Posted by Tom Yager on March 19, 2008 07:14 PM

March 10, 2008

New iPhone enterprise developer program, $299; musings about iPhone app licensing

Companies and organizations that don't want to make their iPhone/iPod touch software publicly available through AppStore can now apply for a special $299 enterprise development license that entitles them to create and distribute custom software strictly for internal use. The application must be submitted by an individual empowered to make legal commitments on their employer's behalf.

This raises some questions in my mind. If you run a consulting shop that creates commercial iPhone software for clients' (say, government agencies') private use, does each client need an iPhone enterprise license? $299 is not prohibitively expensive, but some clients might balk at signing a contract with Apple as a condition of running the code you sold them. Commercial developers don't necessarily want to share their client lists with Apple.

I'll ask Apple how it works, but I'm hoping that the $299 program is the equivalent of an unlisted number. If the extra $200 buys the privilege of bypassing Apple's validation, distribution and customer registration systems, then it's the right approach.

You could argue that anyone who carries an iPhone is already registered with Apple when they activate their phone, so whatever secrets a user would wish to keep are already out. However, in enterprises, handsets are purchased and activated by the employer, not individual users (a purchase model which has, to this point, been denied iPhone buyers by AT&T). Once a phone is purchased as part of an enterprise deal, it should drop off the map where the handset manufacturer is concerned, and the wireless operator's role is limited to supplying the service and sending the bill. Which individual is using the phone, what for, where they work and what applications they're running should be nobody's business. Anything from personal security to trade secrets might be at stake. Once Apple picks up the enterprise baton, it has a lot to live up to.

iPod touch is a special case, and given my overall lack of enthusiasm for AT&T, my favorite case. touch can be used exclusively inside company, agency or a home's walls for any private use the purchaser has in mind. There is no carrier to protect. There is no requirement to sign up with iTunes or any other service in order to use iPod touch for applications. My first application for iPod touch will be to use it as a remote control for an iBootBar rack power controller. This has several network interfaces, but Telnet is the most versatile and will hide well under a GUI. This won't be a difficult first assignment. I'm more uncertain about licensing for personal applications than I am the SDK.

My read of Apple's signing and licensing requirements is that once you pay your $99 or $299 and are issued a certificate, you can start using iPhone/iPod touch units for development (prior to licensing, you can only use the emulator), permitting you to use real devices as develop and debug targets. I have a hunch that units are activated for development use individually (how and how many, I have no idea; perhaps an iTunes-like model) to prevent the use of the SDK as a means of distributing apps.

Where applications written for my sole use are concerned, do I have to sign my code, upload it to AppStore, wait for approval, and re-download it in order to use it? Do I have to re-sign and resubmit the app I wrote for myself every time I make a change (because the checksum changes)? So many questions.

Developer and user licensing will be the messiest aspects of iPhone custom development leading up to the public release in June. I'm going to try to snag a briefing with Apple prior to the release to go over iPhone/iPod touch certificates and licensing. I'll share those details with you.

Posted by Tom Yager on March 10, 2008 07:06 AM

March 06, 2008

Apple's iPhone software strategy moves me

A colleague scolded me for applauding during Apple's press conference to announce iPhone 2.0, next-generation firmware that will bring a host of enterprise features and support for a native software development kit (SDK) to iPhone and iPod touch. In my defense, I kept my pen and pad in my hands while the room went berserk over Apple's deal with Microsoft to bring an extraordinary array of Exchange Server connectivity to iPhone. I was moved, but not to clapping, by Apple's implementation of Cisco VPN compatibility, WPA2 security and other touches that IT administrators set as requirements for devices that connect to their networks. The enterprise half of Apple's new mobile strategy speaks to IT, and therefore to me as an IT journalist. iPhone 2.0 brings iPhone and iPod touch many steps closer to parity with the high-end BlackBerry, Windows Mobile and Nokia QWERTY and stylus handsets that are enterprise mainstays now. My journalist appreciates having a new contender in enterprise mobile, but does not applaud at press conferences presenting same. I nod and note.

[ Read my iPhone 2.0 Q&A. Read about the developers' reaction to the news. Read our special report, "IT's guide to the iPhone." Learn how to make the iPhone work at work. ]

But I am more than a journalist. I worked in engineering, consulting and technical management in the wireless industry before coming to InfoWorld. I've covered wireless, mobile and embedded technology during my entire tenure here simply by continuing to think and operate like a professional with skin in the mobile and embedded game. For over a decade, I've seen wireless carriers, hardware and component manufacturers and OS vendors come at custom software development from every imaginable angle but the right one. I've known for so many years that the barrier to a boom in mobile applications is a stable, simple, documented platform and a matched set of development tools. I've known that these things don't exist because no entity has found a way to make such an effort profitable. Apple has.

Lest I carry on too long in one post about a topic that will take many posts to cover, I'll clue you in on the points that provoked my applause.

Apple's native dev tools include live remote debugging and run-time profiling of USB-connected devices. During the demo, Apple showed Xcode's Instruments (formerly Xray, derived from Sun's DTrace) recording stack traces in real-time from software running on an iPhone. Developers of embedded software--and that's precisely what handset apps are--appreciate how difficult, expensive and tedious it is to design, code and debug with a tethered physical target, and what a big deal it is to have live debugging baked into an embedded platform and a free toolset. English translation: Applause.

Apple is hosting a catalog of third-party applications (AppStore), splitting the proceeds with developers 70/30, and paying developers for software sold on a monthly basis. AppStore will automatically notify iPhone and iPod touch customers when new releases of their purchased software is available. No desktop approach to shareware and small-volume licensing is adaptable to mobile. All a third-party developer needs to do is upload its software to Apple, hang on it the price tag of his choice, and it'll be added to the catalog. From there, the developer just waits for the checks. And, one hopes, responds to calls for support.

Apple will not charge developers or customers for free third-party software. Huzzah!! Developers will need their $99 certificate, but you can band together with your buds and code under an assumed name. Only the guy that actually has the phone needs the license. Everyone else can work for free, using free tools, with the free simulator.

Apple is opening the same APIs that it uses internally. OS X, BSD, TCP/IP, Sockets, security, power management, Keychain, Core Services (e.g. Address Book, Mail), Core Audio, OpenAL, audio recording, graphics (JPG PNG TIFF), PDF, Quartz 2D, OpenGL ES and H.264, to name a few. A new GUI API layer, Core Touch, has been added. A database layer, managed by SQLlite, is in there. Might could get something done with all that.

Apple will charge $99 per developer to issue a code signing certificate, and Apple will police the AppStore catalog for malware and the like. That's cheap, and in return, Apple's taking responsibility for security. Gutsy.

The iPhone SDK and documentation are entirely free of charge for use with the integrated iPhone simulator. You don't have to buy a certificate to write code. You don't even need an iPhone.

Interface Builder (the GUI designer in the Xcode toolset) is loaded with all standard iPhone and iPod touch interface elements and actions. No more AJAX hacks that look sorta like...

Safari WebView was only mentioned as a term, but if it gives me locally-hosted apps, written in JavaScript, with an HTML front end, I'm down. That might tide me over until Silverlight and Flash come around.

No, seriously, I won't wait. I must code.

After the break, a Q & A with our resident cynic.

Posted by Tom Yager on March 6, 2008 03:43 PM

January 18, 2008

InfoWorld Test Center Preview: Time Capsule wireless remote Time Machine backup

Take an Airport Extreme 802.11n base station, add a 3.5-inch internal drive and modify the device's firmware to permit the built-in LAN to share a drive as a volume (a device) rather than a folder within the filesystem, and you've got Time Capsule. Apple has also done away with the power brick; Time Capsule's power supply is internal.

The reason for Time Capsule's existence is to compensate for a few unfortunate realities: Time Machine, wonderful as it is, requires desktop USB or FireWire drives. All of these have to be sized appropriately, which is no easy thing, and worse, notebook users have to remember to plug them in often enough to make the backups useful. Xserve is one fix, but it is a dear investment considering how fast one Mac can eat through a hard drive with Time Machine. Time Capsule fixes that. It is expandable via inexpensive external USB drives. You won't get breakneck speed, but if one Time Capsule gets bogged down, set up another. The Time Machine client lets you choose your backup destination.

Time Capsule does not precisely match the protocol used by Time Machine Server on OS X Server Leopard. The effect is the same: A network that includes a Time Machine Server and one or more Time Capsules populates a pull-down list of Time Machine destination volumes.

Time Capsule does allow users the full set of Time Machine abilities of doing point-in-time file system exploration. It also supports Time Machine's ability to perform a migration or restore from a Time Machine image.

Time Capsule's USB port still handles printer sharing. Except for the direct power input, Time Capsule's enclose is identical to that of Airport Extreme 802.11n. Time Capsule's base price is $299 with a 500 GB drive, and $499 with a 1 TB drive. Apple claims that it uses "server grade" drives, which I learned require special care compared to lesser drives. I carried a Hitachi DeskStar drive in an external enclosure and pulled it about two feet onto the ground while operational. It was shock-mounted in it chassis, but the drive was immediately destroyed. Server-grade drives don't park their heads by default. The next time I configure one, I'll see if it's an option.

I also need to test Time Capsule to see what the reasonable maximum number of USB drives is, and where performance starts to hit that part of the curve that says "buy a second one."

Posted by Tom Yager on January 18, 2008 12:30 AM

January 17, 2008

MacBook Air, a detailed preview

The room service menu in my hotel, the San Francisco Marriott Courtyard, is the size and weight of Apple's new commercial notebook, MacBook Air. MacBook Air, Apple's newest, thinnest, lightest, simplest notebook in Apple history weighs three pounds. It's 3/4s of an inch at the display hinge (closed), sloping down aerodynamically to a much narrower snout. You have to hold it and tumble MacBook Air to experience what a three pound, aerodynamically inspired notebook feels like, because it'll be a first for you. You have to imagine carrying MacBook Air everywhere in a slipcase, being able to whip it out, open it and have it ready for note taking, research, order entry, voice recording, podcasting, writing or what-have-you faster than you can jot your first word with that legal pad and pen in your bag.

Apple got MacBook Air so skinny and light by removing everything that the majority of mainstream commercial users don't use when they're not in the office or at home. There is no wired Ethernet and no FireWire. MacBook Air has just physical I/O ports: USB 2, audio output and micro-DVI (the latter for connecting to a digital, VGA or video monitor). These are all mounted on a tiny panel that flips down from the bottom of the notebook. When the I/O panel is closed, MacBook Air is nothing but smooth, sloped aluminum skin all the way around. There are no lumps or access covers to tip you off to component placement.

Many questions remain that require a full review to answer. My encounter was with a prototype, so I didn't get a chance to experience heat or fan noise. The charger is 45 watts, and the clocked-down chips in smaller packaging is encouraging. I also didn't get to see how far back the display tilts. I did find that the microphone is no to the right of the iSight window, though I don't know if the sound quality is improved. Likewise, I did not audition the speakers. A test left to run is to use this machine with Bluetooth stereo headphones. This works on MacBook Pro, but it's buggy. Does MacBook Air fix it?

MacBook Air's battery is sealed inside. It offers no external indication of its charge state. Apple's battery replacement program for MacBook Air is to drop it at any authorized facility, get it replaced, and get your machine back having been charged for the cost of the battery alone. I wouldn't expect this swap to happen while you wait, and I don't know whether Apple will commit to returning your data intact.

The thin lid encasing the 13.3-inch glossy display is astonishingly rigid. With so little distance between the top of the lid and the surface of the display, I felt sure that it would fail my warp test. I pressed hard on the back of the prototype MacBook Air's lid. It did not flex, and the display's image did not distort. It's my feeling that the shape of MacBook Air's case will make it a tougher travel partner than the typical squarish notebook.There isn't anything to cave in.

MacBook Air is gives you only what you need: A keyboard, a 13.3-inch display, 80 GB hard drive, wireless networking and 2 GB of RAM. The 1.6 GHz Core 2 Duo CPU (1.8 is an option) is clocked slow by modern standards, but it is cooler and more power efficient than the latest Penryn CPUs. Apple claims that MacBook Air's battery will last five hours, with Wi-Fi. If that's true, then it'll run 90 minutes longer than the much heavier MacBook Pro that I carry. The 45-watt charger makes in-flight and in-car charging cheap and easy.

MacBook Air's keyboard is MacBookish in style with widely space keys, but it is full size and backlit. The prototypes weren't lighting properly, so I can't speak to brightness of the lights or the opacity of the keycaps. The trackpad is massive relative to the size of the notebook. If it worked with a stylus, it'd make a fair tablet. The new trackpad supports a subset of iPhone's multi-touch gestures in bundled Leopard applications. In Safari, for example, you can navigate backward and forward among cached pages by sweeping across the trackpad. To enlarge text in the browser, you make a spreading motion with two fingers. In iPhoto, you can scroll, zoom and even rotate images in the thumbnail view with a single trackpad gesture. The gestural vocabulary will undoubtedly expand, and multi-touch will reach into other Apple software. Apple wasn't ready to address giving third-party developers access to multi-touch.

It goes without saying that this notebook isn't for everyone. MacBook Air's chief drawback is the display. Apple chose a sharp, glossy and bright LED-backlit 13.3-inch LCD panel. It looks marvelous, but it has a vertical resolution of 800 pixels. Pages and applications that are (poorly, lazily) designed to just fill a 1024x768 Windows screen have to be scrolled vertically on a Mac's 800 pixel tall display, while the 900 pixel tall screen of a 15-inch MacBook Pro is a perfect fit. The reason for this is a rant for another time.

Apple's usual thin, slot-loading optical drive would have made the case and the battery too thick, so Apple sells a thin, slot-loading, USB-powered external DVD burner for $99 (beautiful, portable and a bargain for any notebook). MacBook Air also comes with Remote Disc software that allows it to use the DVD drive in any PC or Mac on your LAN. Remote Disc completely bypasses the hassles of fire sharing. The shared disc shows up in Finder as a read-only CD/DVD drive. You cannot use Remote Disc to play DVD movies.

Before pointing to performance as a reason to take MacBook Air off your list, keep in mind that its Core 2 Duo CPU enables OS X Leopard's 64-bitness. With 2 GB of RAM, running Windows, Solaris or Linux as a guest OS under Parallels Desktop or VMWare Fusion is well within its reach. Given MacBook Air's small hard drive, using Boot Camp to dual-boot between OS X and Windows is impractical. With Intel's integrated graphics, the primary impetus for running Boot Camp--to run games and other graphics intensive Windows apps--isn't a factor for MacBook, MacBook Air or Mac mini.

Making MacBook Air at home everywhere I go would require some additional purchases: A USB to Ethernet adapter to connect to hotels' in-room networks, a DVI to HDMI adapter so that I can use hotels' LCD TVs as eye-friendly monitors, and the external DVD drive, because I get CDs and DVDs, and burn them, everywhere I go. But all of these fit in a sandwich-sized baggie that stays behind in the office or hotel while I fly, attend meetings and sit in conference sessions. I can't strip these things out of a big notebook to lighten it up, and they are among the peripherals that fatten the case and make a large, heavy battery necessary.

You do have to weigh MacBook Air's $1,799 sticker price against the benefits of traveling very, very light. If you run to meetings now with a wheeled bag in your wake because your notebook and charger are too fat and heavy to sling over your shoulder, you need to make a change. If it's such a pain to extricate and pry open your big notebook just to make a note, check an appointment or send an e-mail that you sometimes just don't bother, you definitely need a smaller notebook. If you start shopping with MacBook Air, I'm afraid that touring PC alternatives will prove unfulfilling.

Posted by Tom Yager on January 17, 2008 09:59 PM

January 14, 2008

Thoughts on the iPhone/iPod touch SDK

[Late note to helpful commenters: I only write from my experience, observation and analysis. I don't read anyone else's work on topics I cover.]

If everything is still on track, Apple will roll out a software development kit (SDK) for iPhone and iPod touch, which share a platform, in February. I have been pondering some possibilities about that SDK. I don't have answers, but perhaps the questions will get you thinking.

Why do an SDK? Certainly not to make the world happy. If Apple spoke with me about iPhone, it would point out that I'm among a tiny handful of people campaigning for a native iPhone SDK. Casual developers would be overjoyed if Apple beefed up iPhone's Javascript to provide programmers with access to a protected subset of the filesystem and the ability to add icons to the home screen. If it were possible to browse "file://" in Safari, then local HTML apps with XML data stores could function as off-line applications.

A similar purpose would be served by a tiny HTTP server capable of performing data binding and mixing of local and on-line content.

In the long run, I think that the reason for doing a native iPhone SDK is to make iTunes Music Store a marketplace for downloadable mobile software. It's been done; Forum Nokia has catalogs of third-party software and hosts developers' applications. An icon on your phone takes you to the Nokia catalog, and software that you purchase from there gets tacked onto your phone bill. Developers get a check for their cut. Games and network tools are very popular.

Commercial developers (shareware and up) need to wire their code for time-limited trials and phone home activation, which is harder to work into non-native software. Nokia tags offerings in its catalog by programming language, and the vast majority are written in C.

If the iPhone SDK is genuinely native, that is, compilers can target the ARM CPU, then that openness will come with high-tensile strings attached that will prevent working around any of the restrictions that protect Apple and wireless operator revenue, and to protect non-savvy iPhone users (the majority). If the SDK permitted the opening of arbitrary TCP sockets, for instance, half of the world's iPhones would be running P2P file sharing clients 24/7, at wireless operators' expense. Trusting users would be downloading malware-stuffed Tetris clones that ship address books and mail folders to identity thieves. I don't see Apple opening itself to this.

Apple will provide as much cover for customers as it can. iPhone apps will be sandboxed so that system and iTunes files are invisible. The first custom app you run will see an empty file system from / on down. Further protection will be afforded by Apple just as Nokia has done it (and with great controversy): Vendor code signing. There is no getting around the fact that native mobile apps, except for those you write for yourself, must be signed, and that no developer can be equipped with the means to sign code that runs on another device. Code has to blessed by a single trustworthy authority. I can't imagine what the signing process would be, how long it would take or how much it would cost--I'd hate to see no potential for iPhone/iPod touch freeware--but I don't think that it's something Apple will farm out.

iTunes' adaptable infrastructure and digital rights management technology are already there. After receiving and signing an app on behalf of a developer, Apple need only add a workflow item to ship that material, price attached, to iTunes. The question in my mind is how developers will get paid. Is Apple going to cut hundreds of developers individual checks? Will Apple demand to be the only source through which signed applications can be acquired?

So many questions. That's what I love about this job.

Posted by Tom Yager on January 14, 2008 11:17 PM

January 14, 2008

Macworld Conference and Expo: Why am I here?

I always look forward to Macworld Expo, but this year my expectations are especially high. It may be the bracing San Francisco weather that's got my blood moving, but it's my anticipation of the keynote and the exhibit floor that have me blogging in the shower.

Apple has scheduled two briefings with me this week. One is a keynote follow-up on Wednesday, and the other is a sit-down on Mac Pro and Xserve on Thursday. I've already got the skinny on Mac Pro and Xserve, both quite impressive, but both falling under the category of pre-show announcements that make room for something else. So will the Wednesday briefing be all about iPhone?

I am braced for that possibility. With 3G, a lower price, streaming media and an upcoming software development kit (SDK), I'm prepared to treat iPhone '08 as a new device. I have speculation related to the SDK that I'll relate under separate cover. Suffice it to say that I don't expect to be able to wipe iPhone's system software clean and replace it with Darwin. That would subvert the primary purpose of Apple's mobile platform: To be an iTunes terminal that fits in your pocket and sticks to your dashboard. The only need that I can see for an iPhone SDK is to allow Apple to market signed commercial software on iTunes Music Store. The only justification that I can see for native code is to support games, and to allow commercial code to enforce licenses.

Apple could surprise me. After all, there is no obvious revenue justification for publishing those portions of Darwin that are not covered by GPL, the GNU Public Licenses that require vendors to publish their adaptation of software covered by the license. I can imagine, and I'm sure that others can, too, iPhone and iPod touch being the world's most sought-after robotics controllers and de facto platforms for university courses in embedded systems. I don't expect iPhone/iPod touch to be opened to kernel hackers, but I think that in the long run, Darwin has good potential as an embedded OS.

I hear from my editors that there is still speculation about a Mac tablet. I'm bearish on that; PC tablets aren't hot commodities. With so much low-hanging fruit yet to harvest from the seasonal evolution of Mac, iPod, iPhone, iTunes, Leopard, Pro Apps and .Mac, I can't foresee any bold new lines of business for Apple right now. My attention this year is largely focused on third-party vendors. I am always hopeful for products that I didn't see coming, and I'd be delighted to hear Steve say something that nobody expects.

In any case, this'll be fun. I hope you'll come along.

Posted by Tom Yager on January 14, 2008 01:05 PM

January 08, 2008

For CPU power draw, trust Apple, not Intel

Apple dropped me a note in response to my blog post on its Harpertown Xserve and Mac Pro announcement. I attributed the per-socket CPU power draw claim of "80 watts max, 4 watts idle" to Intel. That turns out to be Apple's number, not Intel's.

I'm not much interested in Intel's stated Harpertown per-socket power draw because I can't reproduce Intel's test conditions. Outside Intel's labs, you can't pin down a single component's true power draw without a well-equipped test bench and a very steady hand.

200801081915
If you have an Xserve or Mac Pro, you can skip the bench and skip Intel's data sheets as well. Apple builds an uncommon level of instrumentation into Xserve and Mac Pro. OS X Server Leopard's (or Tiger's) Server Monitor reports on component-level power draw and fine-grained regional temperatures in real-time. You can subject Xserve or Mac Pro to varying workloads and track power utilization of CPUs, DIMM sockets and the Intel north bridge independently. It is through this facility that I learned that Intel's north bridge (memory and I/O hub) chip is the least green component in the system.

I was green before green was in, and I am a firm believer that the only place to measure power draw is at the outlet. But chipmakers, and OEMs who ride the shirttails of chipmakers' marketing, compete based on power consumption per CPU socket without providing consumers or product testers the means to validate their claims. At least with Xserve and Mac Pro, I can see for myself. The figures may not be absolute--they can only safely be compared Apples to Apples--but Server Monitor will reveal whether Harpertown's 45 nanometer-ness is directly related to its greenness. With faster front side and memory busses, will cooler CPU sockets matter? As you can tell, I'm eager to find out.

Posted by Tom Yager on January 8, 2008 07:16 PM

January 08, 2008

Apple ships new eight-core Harpertown Mac Pro and Xserve

Apple has once again taken up Intel's fresh-from-the-fab processor technology to give its two top-end systems a serious performance kick. Apple has reengineered its Xserve rack server and Mac Pro desktop/workstation for Intel's 45 nanometer quad-core Harpertown Xeon CPU with 12 MB of shared Level 2 cache per socket.

Xserve's top configuration now reaches to eight 3 GHz cores. Xserve's second socket is empty by default, making the standard config four cores, but the incremental config-to-order (CTO) cost to take the base Xserve to eight cores is just $500. The new Mac Pro elevates the standard configuration from four cores to eight while maintaining the previous Mac Pro's price level. That change is especially significant given that before today, a CTO eight core Mac Pro carried a premium of $1,200 over the standard four core system.

Apple claims that its new Mac Pro and Xserve deliver an impressively linear 1.9 to 2.3 times increase over the compute speed of prior four-core models, and with 800 MHz DDR2 memory (up from 667), 60 percent higher memory throughput. The new systems share support for PCI-Express 2.0 expansion cards, an option to upgrade to multiple 1 TB swappable hard drives, and when 4 GB FBDIMMs (fully buffered dual inline memory modules) are used, room for up to 32 GB of system memory. Both Xserve and Mac Pro are now shipping with 2 GB of RAM standard (previously 1 GB) and a SuperDrive dual-layer DVD burner.

Intel's Harpertown CPU is more energy efficient; Intel claims power consumption of 80 watts per socket, dropping to as little as 4 watts when idle. Apple has swapped out Xserve's redundant power supplies for stronger 750 watt units that exceed Energy Star 80 percent efficiency requirements. Mac Pro's system enclosure is identical to the previous model, while Xserve now has a USB 2.0 socket on its front panel.

Mac Pro and Xserve ship standard with discrete AMD/ATI 3-D graphics processing units (GPUs). Mac Pro's baseline config utilizes the Radeon HD 2600 XT with 256 MB of video memory, while Xserve ships with an on-board Radeon X1300. Mac Pro can support up to four AMD/ATI or NVidia graphics cards, while a 16x PCI-Express slot on Xserve permits the optional use of a standalone graphics adapter to supplant the built-in GPU.

AMD/ATI graphics cards are available now. An Apple spokesman said that optional NVidia graphics cards are "several weeks away."

Apple's systems are engineered in-house, not based on Intel reference designs. Mac Pro and Xserve are thoroughly instrumented for multi-point monitoring of power utilization, temperature and fan speed. Both systems have standard swappable hard drive backplanes--Mac Pro has four internal swappable drive bays, while Xserve has three front-facing bays--and the option to use either Serial ATA or Serial Attached SCSI (SAS) drives. SAS is new to this generation of Mac Pro, a benefit of the optional hardware RAID controller. The same RAID controller is an option for Xserve, but Xserve is capable of using any mix of SATA and SAS drives without the RAID option.

At $2,799, the standard Mac Pro ships with two 2.8 GHz quad-core Xeon CPUs, an AMD/ATI Radeon HD 2600 XT graphics card with 256 MB of video RAM, a 320 GB SATA hard drive, a 16X SuperDrive DVD burner with dual-layer support, Bluetooth 2.0, 2 GB of 800 MHz DDR2 memory, and Apple's wired aluminum keyboard and Mighty Mouse. Mac Pro ships with OS X Leopard and the iLife '08 personal digital media suite installed.

In its $2,999 standard configuration, Apple's Xserve has a single quad-core, 2.8 GHz CPU, an 80 GB SATA hard drive, 2 GB of 800 MHz DDR2 memory and a slot-loading SuperDrive DVD burner. Both systems have a large catalog of configure-to-order options that are factory-installed and tested by Apple.

The new Mac Pro and Xserve are shipping today via Apple's on-line and retail stores, and through authorized resellers.

Posted by Tom Yager on January 8, 2008 09:46 AM

December 16, 2007

Time Machine Server, or local external drive?

One of the services packaged with OS X Server Leopard (there are so many) is Time Machine Server. If you're running a network of Leopard notebooks and desktops, centralized Time Machine backups are easier to administer and secure than doling out a fleet of FireWire and USB drives. However, if you want to carry each client's protection beyond Time Machine's rolling 30 day window--Time Machine will retain weekly backups until it runs out of space--you might have to set aside twice the size of each busy client's internal hard drive to exceed 30 days' worth of coverage. The headroom varies widely by user, but do you want to try to tailor a backup strategy to each machine?

You have to weigh Time Machine Server's physical server (Xserve or Mac Pro) and storage costs--expenses that can't be avoided in any disk-based backup scenario--against savings in administrators' time ("please mount volume xxx") and user data lost to infrequent backups and cumbersome restore procedures.

For me, what sets aside all arguments about cost and flexibility of Time Machine Server is its catalog. Lots of backup utilities maintain catalogs, but Time Machine's catalog is chock full of metadata and is completely maintenance free. Users access Time Machine with a Finder-like interface that conceals the fact that they're even accessing a shared volume. When using Time Machine server, administrators maintain the ability to do point in time restores, or migrations, without the time or effort of taking full volume snapshots.

With regard to the incremental cost of storage as clients are added to the LAN, someone suggested attaching the USB or FireWire drives that would be on users' desks on the server instead. For five clients in a casual setting, sure. You could unmount any machine's backup drive, hand it to the user and tell them to do their own restore. Leopard presents "restore from Time Machine backup" as an option when you boot from the install DVD. For more than a few clients, or where the purpose of Time Machine is more critical than "undelete," I'd rather see a more robust enclosure, even a dumb backplane, than a daisy chain of FireWire drives.

Keep in mind that Time Machine doesn't absolutely require a server or an external physical volume. You can split local drives into multiple volumes, and use one for Time Machine. You end up with a backup volume that's bigger than the primary, but the average user is none the wiser. That takes care of undelete, and more old fashioned methods can be used at the server to cover worst case recovery.

What would I like to see in Time Machine? My one and only desire is to have Time Machine run only when the client is idle. This is really driven home when you try to use Wi-Fi, even 802.11n, to connect to a Time Machine Server. My strong recommendation is to use copper for Time Machine, at least for the volume copy that it makes as a first step. I realize that RJ-45 sockets, and users who sit still long enough to take advantage of them, are rare these days. If you must use Time Machine Server over wireless, or, heaven forbid, broadband, remember that I warned you against it.

Posted by Tom Yager on December 16, 2007 08:01 AM

December 05, 2007

Wii News Channel report: German court re-locks iPhone, bad dad blogger baffled

The funny thing is, this happened (link to AP) before I filed my brilliant analysis on the subject of European court and law-imposed unlocking of iPhone. However, even though the German court, operating under my precisely tuned radar, pulled its injunction against iPhones locked to T-Mobile, German law still requires that iPhones be unlocked after the 2-year contract expires.

Anyways, my point remains.

You can't get this kind of up-to-the-yesterday news commentary at any price, my friend. It may also interest you to learn that I spotted the updated AP story on my trusty news ticker, the Nintendo Wii that I'm giving my kid for Christmas.

I see that despite the fact that I have tons of actual work to do, I'll have to explain why I had my son's gift out of its box. I had to pair it with my Airport Extreme, install the batteries in the remote and set the parental controls. And wouldn't it be a drag if it came out of the box on Christmas not working? Yes, I absent-mindedly left it out in my office, and it was sitting next a GameCube controller and Blockbuster rentals of Super Mario Galaxy and Sonic Heroes. He saw that whole pile, but in my office, they blend. When we're all gathered 'round the tree, he'll pretend to be surprised, and I'll pretend that I didn't check it out. Isn't that everybody's Christmas?

Stop judging me.

Posted by Tom Yager on December 5, 2007 01:35 PM

December 04, 2007

How Leopard Time Machine works, and how it doesn't

For Time Machine's primary target audience, home users, backups of desktops and notebooks running OS X Leopard are fully automated, just as advertised. All that's needed is an external hard drive that's at least as large as the system's internal drive. Pull up the Time Machine pane in System Preferences, select your external backup drive, and flip the big switch from OFF to ON.

After making an initial full copy of your system's drive--file by file, not sector by sector--Time Machine scans your system hourly and copies the files changed since the last scan to the external drive. The copy is non-destructive: A file is not overwritten if the archive already has a copy of it. In effect, the old file is renamed before the new copy is written. A catalog tracks the location of every file in the archive, and the time at which file was appended to the archive.

Time machine conserves disk space by folding every 24 hours' worth of hourly backups into one daily backup. It retains 30 days' worth of daily backups. After 30 days, Time Machine starts folding daily backups into weekly backups, which are kept until the backup volume is full.

Apple brilliantly created a Finder-like view into the archive catalog that lets you browse your backup archive's catalog hierarchically and temporally. As Apple puts it, you can see your entire disk as it was at a given point in time. True, but depending on how far back you step to find a lost file (for example), time may rewind in increments of hours, days or weeks.

As Apple presents the Time Machine filesystem view, you can see your system approximately:
As it was at the top of each hour today
As it was each day for the past 30 days, starting yesterday
As it was each week, starting 31 days ago, going back as far as disk space permits

A distraught user might only be interested in the amount of data he may have lost:
If you accidentally deleted a file today, you lose up to an hour's work
If you deleted it between yesterday and 30 days ago, you lose up to a day's work
If you deleted it more than 30 days ago, you can lose up to one week's work, or all of it

There are users even among Apple's targeted consumer population who need to think about their use of Time Machine, or who may be better off not using it at all. Consider the case of a home user who time-shifts television shows via iTunes, BitTorrent or another source. A sensible user deletes episodes he's already watched to conserve disk space, but when Time Machine is active, it may take a month for that deleted episode to vanish from the backup drive. If the backup drive fills before it can archive 30 days' worth of data, Time Machine flags an error and quits.

That scenario plays out for any user or application that creates expanding or volatile files. A 10 GB database can be appended to your Time Machine archive hourly. A lengthy log will be appended in its entirety even if only one line is added between hourly archive runs. Deft management of Time Machine's exclusion list is essential for busy systems.

Time Machine is archiving, not data protection. If your external drive fails, you lose all of your backed up data. Data protection that covers the failure of a storage device calls for a disk array with RAID mirroring or parity striping. If you want to archive and protect your data, which isn't a bad idea if you're a professional Mac user, use a RAID volume as a Time Machine backup device.

Or, as I'll detail in the next entry on the subject, use Xserve as a Time Machine back-end.

Lastly, to get ahead of what will likely be the most frequently asked questions about Time Machine:

Q: I set up a directory for Time Machine on my external drive. Why can't I see it in Time Machine's list of backup destinations?
A: Time Machine can only back up to volumes (formatted partitions) that are dedicated to the purpose. For geeks' sake, if it doesn't have a /dev/disk* entry, Time Machine can't target it.

Q: Why won't Time Machine use my AirPort Extreme base station's USB drive, or other Mac or Windows storage on the network?
A: Windows and Apple file sharing share at the directory level. Even if you share a whole Windows lettered drive or the root directory of a Mac partition, you're sharing a folder, not a volume.

Q: I'm a fearless genius. Isn't there some way to work around these limitations short of hacking the kernel?
A: Learn ZFS, but know that the likelihood of creating unreadable Time Machine archives is enormous despite what appears to be success. I won't help you beyond that.

Posted by Tom Yager on December 4, 2007 10:24 PM

December 03, 2007

InfoWorld's OS X Leopard review: "A Perfect 10," and thanks for the links

If you haven't seen it yet, I'd be honored if you'd check out my just-posted review of OS X Leopard. It was a long time in the making, and if you can believe it, I'm still not done. Part II of that review is being edited as I write this, and my review of OS X Leopard Server is nearing completion. You don't have to wonder whether InfoWorld is serious about Mac coverage. You just have to ask yourself how much Mac you can handle.

I'm exceedingly grateful to bloggers, aggregators and other sites that create links to my stories.

Posted by Tom Yager on December 3, 2007 07:28 PM

November 24, 2007

The only Leopard tip guide you'll ever need

If you want to be in the know about Leopard's new features and how they can improve your work and life, you could wait for a book, sift though OS X tips sites, or have insider secrets leap into your hands the moment you need them.

The first step is to abandon presumptions about what Apple couldn't possibly have built into Leopard and its bundled apps. These presumptions lead to premature workarounds for absent features that actually exist in Apple's code. It's folly, bordering on hubris, to imagine that you're the first person who ever needed to do a given thing. Instead of assuming that a feature is missing because it isn't where you expected to find it, ask your Mac where that feature is.

Whenever you need to do something you haven't tried yet, turn to Help first. Query each application's Help; the Help for Leopard as a whole is linked to the Help menu that's available when Finder is selected. If your query fails, your terminology might be to blame. Go to the Help table of contents and drill down the hierarchy until you narrow in on what you're trying to accomplish, or its nearest identifiable neighbor.

If you lose your way in System Preferences, which is much harder in Leopard since Apple did a major reworking of the most complicated Security, Sharing and Networking preferences, enter a keyword or two (e.g. "firewall") into the search field in the corner of the System Preferences window. Preferences panes matching your query will light up. Most buttons and fields pop up brief, useful descriptions when you hover over them for a few seconds, and you'll often see questionmark buttons on dialog boxes that open context-sensitive Help.

Enter "shortcuts" into any Help window's search field. This will point you to a list of keyboard shortcuts for the app or, using Help while Finder is active, for Leopard. Even if you're not a fan of shortcuts, Apple wires most important and most commonly-used interactive features to the keyboard. Reading the one-line shortcut descriptions is much easier than pulling down every app's menu bar item and trying to figure out what it does.

I spell this out in such detail because Help is grossly underutilized on the Mac, especially among Mac users who are just too cool to click Help. Leopard's Help is concise and easily navigable. Use it when no one's looking if you must, but no matter how good you are, you will always find happy surprises in Help. Covert use of Help has made many a superstar on OS X tips sites.

If you still can't figure out how to make your Mac do what you need it to, open Automator. It drives GUI apps in ways that you'd never have imagined, and if Automator can make an app do what you want, then so can you.

Lastly, you'll come across simple needs, like sorting a list of number/name pairs, or converting data from one format to another, or removing the top five lines from every file in a certain folder, that you won't find in GUI apps because it's already been done in UNIX. The command line (Applications/Utilities/Terminal from Finder) opens the astonishingly well-stocked UNIX cupboard that Apple doesn't expose through GUIs. If GUI Help doesn't reveal a way to do what you want, open up a Terminal window and type "apropos" followed by a keyword (for example, try "apropos firewall"). This will search the documentation for commands relevant to the keyword. Then type "man" followed by one of the command names displayed by apropos. If the resulting manual page is long and confusing, many have Examples sections that spell out the most common usages. Of the roughly 1,500 command line programs in OS X, you may only need a handful, and learning these will take some experimentation. But you will discover that most of the wheels you have in mind to invent to work around some perceived shortcoming in OS X were created by a guy at AT&T or Berkeley back in 1983.

Familiarity with grep, awk, tr, find and the built-ins of the bash shell will serve you well.

Rest easy. Help is always there when you need it, and it's right on your Mac.

Posted by Tom Yager on November 24, 2007 12:08 AM

November 22, 2007

Leopard kernel source code published November 8

Happy Thanksgiving, everyone. Among countless other things, I'm thankful to have a weekday during which I can leave my BlackBerry powered down.

I have also chosen today to give overdue thanks to the Leopard project team. The Darwin kernel used in Leopard has been posted to Macosforge.org. This figured into my ten out of ten review score, but yelling about sources in a review targeted to users, admins and IT buyers is a little too gearheady. If Apple is popping any champagne corks over Leopard being InfoWorld's first ten out of ten review, then I bid them set aside a well-chilled bottle of the finest (or their preferred adult or hypercaffeinated beverage) for Kevin Van Vechten and his team.

If you watch for Darwin kernel releases, you might have bookmarked Apple's Darwin kernel (xnu) project page, which still shows Tiger 10.4.8 as the newest announced version of the Darwin kernel. Keeping the news page current for media snoops isn't as important as getting the real work done. I confess being glad for that, because not many can grasp the relevance of Apple's lock-step kernel source publishing policy.

The sure-fire URL to bookmark for up to the minute Darwin sources is http://www.opensource.apple.com/darwinsource/tarballs/apsl/, which is an HTML gateway into Apple's open source version control system. The pretty page URL, which also provides convenient pointers to tools, docs and related sources, is at http://www.opensource.apple.com/darwinsource/. I haven't watched that page closely enough to vouch that it is kept up to date, but the xnu (kernel) releases listed there do reflect the full list of downloadable tarballs.

By keeping the release of kernel sources in step with commercial OS X updates a priority, Apple's engineers, program and project managers have now put a universe's worth of distance between OS X and other commercial OSes. Readers should know that xnu, the Darwin kernel, is an "extra mile" project. Publication of the kernel sources is not mandated by a license lien on any of Darwin's open source components. The BSD license attached to much of the Darwin kernel requires attribution, not distribution. I've always admired that.

The Leopard project team's brilliance and vision doesn't end there. I've unearthed some exciting details that deserve a post headline of their own, to follow immediately.

Posted by Tom Yager on November 22, 2007 06:31 AM

November 15, 2007

Apple issues 23 updates in two days; highlights of Tiger and Leopard updates

200711151902

Make sure your broadband bill is paid up, because Apple's got a crate full of fixes with your name on them.

In a couple of cases, these are the updates we've all been waiting for. I'm hoping that the iMac Graphics Firmware Update will get iMac users out of their work/save/reboot cycle. Such beautiful machines behaving so badly. I still wonder whether Apple or ATI did the brunt of the work on this fix.

The entire Pro Apps suite has gotten significant attention. One of the many qualities to appreciate about Final Cut Studio, Aperture and Logic is the frequency with which Apple tunes and enhances them. TV networks and movie studios deserve a bit of extra attention, no?

All Tiger and Leopard users have gotten major attention. 10.4.11 is the latest scheduled release of Tiger, and high points among its improvements include Safari 3.0, RAW image decoding for a range of new Olympus and Panasonic cameras, VMware Fusion stability fixes, the addressing of a bug affecting port mapping with shared Internet connections, 3rd-party WAN device compatibility, USB hard drive reliability, and security updates.

I'm all in for that USB hard drive update. I wonder if it would have kept my dead MacBook Pro eval unit alive. I just missed it.

OS X Server 10.4.11 has all this, along with some server essentials, like allowing users to belong to more than 16 groups, repairs to the FTP server to handle the LIST command properly, failover between Intel and PowerPC servers, LAN registration of OS X servers via Bonjour, proper handling of aliases on UFS and Xsan volumes, having the chmod command cause corresponding changes in ACL permissions, and fixes for memory panics in servers with 2 GB and 4 GB of RAM.

The OS X 10.5.1 update has some changes that really matter. It puts password-protected AirPort disks in the Finder's Shared sidebar and claims to fix Leopard's annoying tendency to forget wireless network passwords.

Have you used Back to My Mac? It's a simple tunnel to your home Mac from a remote system that works even when one machine or the other is behind a NAT router. The Back to My Mac fix shows remotely-accessible Macs in Finder's sidebar more reliably, and fixes glitches with D-Link NAT gateways. D-Link gear is priced right, but it tends to present challenges, doesn't it?

iCal and Mail have substantial fixes in the areas of the delivery of alarms via e-Mail, the invitation of meeting attendees through CalDAV, attachments inside HTML e-mail, SMTP connection failures in accounts created with Simple Setup, and a couple of significant fixes affecting .Mac users.

In security and firewall (which have been combined in Leopard), Apple has arranged to allow unsigned third-party applications through the firewall if they're whitelisted in either Application Firewall or Parental Controls. Apple has changed some confusing wording in the Firewall tab; instead of Block All, which sounds like your machine is cut off from the outside world, Apple has inserted the wording "Allow only essential services." Apple's idea of "essential" may differ from yours; dealing with that is your problem.

One potentially serious squashed nasty regards the risk of dropping data when moving files across partitions using Finder. Time Machine no longer shrieks at huge, single-partition MBR (master boot record) drives and NTFS volumes.

Posted by Tom Yager on November 15, 2007 05:03 PM

November 12, 2007

A little more detail on MacBook Pro recovery

As I related, I have recovered the data from a MacBook Pro that quit working on me a couple of weeks ago, and that I used the ditto command to do it. For the benefit of those more savvy Macheads among my honored readers, I'll offer a few more details on the process and its outcome.

When I discovered that Disk Utility would not create a restorable image of the dead MacBook Pro's internal drive, I fell back to ditto, figuring that to populate the new MacBook Pro with my existing data, I'd have to resort to a cautious, manual transfer to a clean Tiger install of those documents, applications and preferences that I could safely overwrite. I knew that some information that was encoded in binary form would have to be recreated in the application or preference pane that produced it, and that I'd lose the benefit of Migration Assistant's automated upgrade to Leopard.

As it turns out, Migration Assistant transfers files without much concern about the validity of their contents except when data translation is part of the process. When I finished with ditto, I had an OS X Tiger partition that I knew wasn't worth finessing into a bootable state. It might be worthwhile as the source for a Leopard Migration Assistant run. It was, and the result was better than I could have hoped. Most 3rd-party kernel extensions didn't survive the trip, but this gave Migration Assistant no trouble.The sole losses were kernel extensions and license managers and keys.

The lesson here is that a restorable block-by-block partition image need not be your objective in backing up or recovering data. It is okay to write changes to files as they are modified, just as Time Machine does. Time machine can even be outdone by ZFS and overlay mounts.

Whatever you do to back up your data to an external hard drive, don't use USB. Buy enclosures that have USB and FireWire.

Posted by Tom Yager on November 12, 2007 07:44 PM

October 31, 2007

Five frustrating, wasted days

Before I begin, I need to point out that I do not claim a cause and effect relationship between what I've done and the result it produced. Still, the story bears relating. Because of the length of this post, I'll offer my advice from what I've learned so that you can skip the rest:

1. Purchase an external hard drive of at least the size of your Mac's internal drive
2. Boot the Leopard install DVD and when the Tools/Utilities menu appears, start Disk Utility
3. Partition your external drive, and be sure to click Options to create a GUID partition
4. Click on the icon for your internal drive's OS X partition
5. Click "New Image" from the toolbar
6. In the destination dialog box, choose the name of your external drive
7. For image type, choose Read Only. The default is "compressed," but this is extremely slow
8. Once this completes, it's now safe to install Leopard on your internal drive

You should do this, or its equivalent, for any OS upgrade.

As I related in my prior blog, I checked into a hotel so that I could have uninterrupted, quiet time set aside for my review of Leopard. It had been my intent to blog throughout the process of installing and migrating Leopard from the internal hard drive of the MacBook Pro loaned to me by Apple. That drive had a fully working copy of Tiger.

For safety's sake, I installed first to a small external FireWire drive, a process that went exceedingly well. But with an internal drive of 150 GB and an external FireWire drive of only 18 GB, there was no point in attempting to use Migration Assistant to migrate my apps and files. Booted from the FireWire drive, I was able to navigate the MacBook Pro's internal drive, and launch applications from it, without difficulty.

I thought the wisest next step would be to do a complete backup of the MacBook Pro's internal drive to an external device large enough to contain it. So I shut down, unplugged the FireWire drive, plugged in a known good 250 GB external USB 2.0 drive and powered back up.

[mark this paragraph; you'll be returning to it] The MacBook Pro did not boot. It went completely unresponsive, stuck at the white background where the Apple logo and spinning animation usually appear. With the install disc in the drive, holding the C key down (the shortcut for booting from the CD/DVD), nothing happened even after waiting several minutes. I plugged the external 18 GB FireWire drive back in and held down the Option key to bring up the boot volume selection menu. The drive's icon appeared--neither the internal drive's icon nor the install DVD's appeared--but clicking on the arrow beneath the FireWire drive it had no effect; the button changed color to indicate its response, but after repeated clicks, nothing happened.

With only wired network service at the hotel, I had to use my BlackBerry to go to Apple's support site to find the magic key sequence to clear the system's non-volatile configuration RAM (Option+Command+P+R+Power). This caused the external FireWire drive to boot to Leopard, and once booted, icons for the internal drive and the install DVD appeared. I launched Disk Utility to check for problems on the MacBook Pro's internal drive and got thousands of notices of invalid hard links. I repeated the repair process and the internal drive checked out clean. So I set the startup drive to the internal disk and rebooted.

For the system's reaction to this, re-read from the paragraph marked above to this sentence. At no point was I able to boot directly from the install DVD at startup. However, I was able to boot from the FireWire drive, click "Install Mac OS X," and reboot from the DVD.

Using the boot DVD's Disk Utility, I asked to image the MacBook Pro's internal drive to the 250 GB external USB drive. The process failed partway through with an I/O error. I was able to install Leopard to the 250 GB USB drive, and I attempted to fire up Migration Assistant. It began assembling the catalog of data that I could import, and while doing this the system rebooted itself. Return to the paragraph marked above.

I am now working from the external USB drive. The C key still will not boot from the DVD. At this point, the files from my internal drive are visible, and that volume passes verify and repair. Now comes the task of attempting to recover essential files like e-mail and address book by hand (from the command line; doing so with Finder complains that I lack proper permission). However, I have no backup and cannot create one.

To say that this has been a frustrating exercise is an understatement. Very few things anger me more than wasted time and money, and this has been both.

Why did all of this happen? I haven't the faintest idea. I only know that prior to installing Leopard on the external FireWire drive, everything was working perfectly, and I had every expectation of a clean install and a pleasant weekend of blogging.

I can't help that some will read this as a cautionary tale. Don't. Something bizarre happened here, some juxtaposition of a hardware failure with an attempt to install Leopard. In any case, I'm frozen in state until I can recover essential files my MacBook Pro's hard drive. I have a backup image that's about two months old; perhaps I'll start with that.

It may surprise you, but this does not color my opinion of Leopard in the least. Instead of blogging my progress as I had planned, I'm moving straight to a full review, which will have no reference to this post.

Posted by Tom Yager on October 31, 2007 11:33 AM

October 26, 2007

Leopard Hands-On: The Beginning

As a counterpoint to the crushing disappointment that was Vista, which emerged with only a fraction of its promise intact, Apple's OS X Leopard (10.5) is everything that Steve Jobs said it would become when Apple first placed that first unsteady cub in developers' hands. Leopard is also a thick catalog of inventions and improvements that Steve flat neglected to mention, so thick that Apple had to resort to running the equivalent of a software project change log on its site for marketing purposes. You can't possibly chew through that list. I've been testing and assembling my own list of relevant and remarkable changes in Leopard, a list that speaks to more professional and savvy Mac users as well as those who might switch (or are sure they'll never switch) from Windows and Linux.

I have to start the introduction to this series of hands-on Leopard stories with what I consider to be Leopard's most impressive quality. For its 300 changes since Tiger (OS X 10.4), the line item reading of which provokes a range of reactions from the head nod to the ear-to-ear grin, there is not one ounce of fat, no feature in Leopard that you'd opt to leave on the DVD the next time you install it. Instead, for all that's been added, Leopard remains trim enough to run on a PowerBook G4 with 512 MB of RAM. The very same OS is a robust, Open Group certified 64-bit UNIX when run on Intel Core 2 Duo and PowerPC G5 machines, with no need to buy a special edition. One of Apple's marketing lines says that everyone gets the ultimate edition of Leopard because that's the only edition there is. I'd argue that if Microsoft's Vista product tagging is the basis for comparison, then all Leopard buyers get the 64-bit enterprise edition.

Despite the fact that I'm far past this stage, the first hands-on experiences I can relate involve stability and installation.

If you're eyeing Leopard, one concern that you can cross off your list straight away is stability. I've spent several months working with Leopard as a developer and administrator. I began rolling Leopard into production on MacBook, MacBook Pro, Mac Pro and Xserve Xeon, against Apple's advice but not requiring its consent, at a point well prior to its release. I'd be testing the bounds of non-disclosure to tell you when I felt Leopard hit its stride. Instead, I'll just say that there is no need to obey the standard advice to wait for the first boatload of fixes before buying in. That's true of Windows, and true of Linux, but not Leopard. Leopard shed its training wheels a while ago.

Non-Mac users coming to Leopard will find a really simple, automated install experience, but it is more flexible than before. That's most notable in network configuration, where auto-detection of wired and wireless networks is more accurate. It's easier to enter the SSIDs of private Wi-Fi networks, and you can bypass network configuration entirely. OS X doesn't phone home for authorization, so you can install completely and permanently without exchanging registration info with Apple.

Existing Mac users thinking of taking the leap can safely take ease of upgrades and installation for granted, after they burn their most critical data to DVD or an external hard drive. Migration Assistant, which you can invoke at install time or at your whim later, transfers your user data and applications from Tiger to Leopard after what amounts to a clean install. The Leopard installer will let you do an overlay install, which updates the system software and tries to leave everything else alone. It is impossible to automate all possible cases, but I can't imagine any user who could make Migration Assistant fail. Do be patient, though. Take measures to ensure that Migration Assistant runs uninterrupted, and understand that Migration Assistant's estimated time to completion is a wild guess. In my experience, it finishes sooner than expected.

As a taste of what's to come, I'll spend a few words on what I found to be the most substantial user interface enhancement: Spaces. Spaces gives you multiple virtual desktops, and you can switch among them via the keyboard, Dock or menu bar icon. It isn't fast user switching--all desktops are the same user--but it's more lightweight, and there's no need to enter a password when you switch desktops. The unexpected killer here is that Spaces lets you target specific applications to selected desktops. So, for example, you can arrange things so that Mail always opens in Spaces' second desktop, or you can set up separate developer and productivity desktops.

I'll go on from here through the weekend and into next week. I'm holed up in a hotel doing nothing but Leoparding. To tide you over until my next hands-on dispatch, you'll find one Apple exec's selected Leopard high points in this interview, and my thoughts on Leopard from a technologist's perspective are in my Leopard: A Beautiful Upgrade column. Hang out. You're welcome to the pull-out sofa, and you get used to the noise from the Xserve.

Yes, there will be screens and video. Many, many visuals.

Posted by Tom Yager on October 26, 2007 05:40 PM

October 24, 2007

Why Leopard matters, plus more ZFS details

I can't assume that subscribers and visitors to Enterprise Mac necessarily follow my Ahead of the Curve blog. Pointing you toward other Mac-related content I've created saves me the effort of paraphrasing it for use here.

My recent column, "OS X Leopard: A beautiful upgrade" highlights Leopard as a turning point for Apple, Mac users, UNIX and the market as a whole. It's worth a read even if you've already decided to pop for Leopard, and even worth reading if you're sure you'll never touch a Mac. Leopard is an exemplar of user-focused design that doesn't obscure the underlying power of the OS.

My last Ahead of the Curve is a higher-altitude look at ZFS, a "why ZFS?" counterpart to the two-minute ZFS primer I've already written in Enterprise Mac.

Posted by Tom Yager on October 24, 2007 12:51 PM

October 19, 2007

The impatient person's introduction to ZFS

You may have read that Apple is baking ZFS, Sun's Zettabyte File System, into Leopard. The flavor and extent of ZFS support in Leopard is an open question. ZFS, however, is very real and readily observable in its native habitat, Solaris, as well as in its equally capable open source counterpart, OpenSolaris.

At its foundation, ZFS looks and works like software RAID, and looking at ZFS from that familiar perspective makes it seem less intimidating.

Roughly drawn, here is software RAID:

1. Physical disks are combined to create a RAID logical volume
2. A logical volume is divided into partitions (or slices) of fixed size
3. Each partition or slice is formatted with a filesystem
4. Files live in filesystems

Conceptually, software RAID looks like this:

raid_logical_volume=RAID(disk1+disk2+disk3)

ZFS uses a similar construct, but calls it a pool:

zfs_pool=RAID(disk1+disk2+disk3)

On the Mac, to manage a logical volume you fire up Disk Utility and draw out partitions. In one step, Disk Utility creates the partition table, creates a blank filesystem in each partition and assigns each filesystem the name you gave the partition. Conceptually:

size(raid_logical_volume)=100 GB
raid_logical_volume/partition_1 size=10 GB, name="jampacks" # auto-mounts as "/Volumes/jampacks"
raid_logical_volume/partition_2 size=90 GB, name="projects" # auto-mounts as "/Volumes/projects"

With ZFS, you do the equivalent of logical voluming and partitioning from the command line, and the actual commands illustrate the concepts (the # is the shell prompt):

# zpool create ZFS_pool c1d0 c2d0 c3d0 # Just striped; no data protection by default
# zfs create ZFS_pool/jampacks # auto-mounts as /ZFS_pool/jampacks
# zfs create ZFS_pool/projects # auto-mounts as /ZFS_pool/projects

ZFS_pool is an arbitrarily chosen name. You can name a ZFS pool or filesystem whatever you like. Just two commands (zpool and zfs) run the whole show.

Highly distilled, ZFS has these properties:

1. Physical disks are grouped into ZFS pools, which are the rough equivalent of RAID volumes
2. Each pool can be split into any number of datasets, which work roughly like partitions or slices
3. Files live in datasets

Yes, it is that easy, and yes, I left out most of what makes ZFS so remarkable. It's a ploy to keep you coming back here.

Posted by Tom Yager on October 19, 2007 03:12 PM

October 16, 2007

News summary and interview: Apple to release Leopard in ten days

After a months-long delay that only seemed to provoke greater buzz and anticipation, Mac OS X Leopard and OS X Server Leopard will go on sale at 6:00 PM on October 26, 2007. Apple boasts 300 new features in its Leopard client OS, and 250 new features in its server operating environment. During a harried 15-minute briefing, Brian Croll, Senior Director of Product Marketing for Mac OS X, rattled off what he considers to be the high points in the client version of OS X Leopard:

A redesigned desktop with a consistent look across applications, and a semi-transparent menu bar to allow desktop backgrounds to show through.
A redesigned Dock, a row of icons for launching frequently-used applications, with a semi-transparent background and reflections under each icon.
Finder, OS X's counterpart to Windows' Explorer, has an updated Sidebar. The customizable collection of icons for frequently-accessed folders now locates and displays network files shared from PCs and Macs on the same LAN.
Finder has gotten an overall revamping to a more intuitive and modern look and feel. The new Finder borrows its appearance and behavior from iTunes, Apple's media player and content purchasing interface, including an iTunes feature called Cover Flow that lets you flip through images and other viewable content like pages in an album. "It's really fun and useful to browse content on the PCs and Macs on your network using Cover Flow," said Croll.
Most viewable content types, such as images and PDF and Word documents, can be viewed with Finder's integrated Quick Look without launching an additional application.
To-do lists synchronize with both Mail and iCal, OS X Leopard's bundled e-mail and calendar/scheduling clients. Croll said, "We've noticed that people send reminders to themselves in e-mail."
Leopard's Mail application implements Data Detectors, which scan e-mail messages for phone numbers, e-mail addresses and street addresses. These can be added to Leopard's Address Book, located in Google Maps or copied into iCal.
iChat, Apple's bundled instant messaging client, takes on a host of new features in Leopard, including special effects from OS X's Photo Booth Web cam snapshot app (iSight Web cameras are standard in Intel-based Mac client systems). Leopard's iChat also supports the live playback of images, audio and video during a live chat, and users can share their screens for remote viewing or remote control.
Croll also pointed to several new facilities for OS X Leopard Developers: Core Animation automates smooth 2-D animation with simulated 3-D paths and transforms; Xcode 3.0 is a rich integrated development environment for programs written in C, C++. Objective-C and other languages; Xray, adapted from Sun's DTrace, lets developers monitor and profile applications while they execute without the hassle of a debugger.

Croll described "reasonable system requirements" for Leopard that reach well into Apple's legacy PowerPC platforms. Any Macintosh with a 32-bit PowerPC G4 CPU running at 867 MHz or higher can run Leopard, as can all Macs with 64-bit PowerPC G5. All Intel Macs support Leopard, and Croll said that the minimum memory requirement for all architectures is 512 MB. An optical drive capable of reading DVD media is also required.

Croll laid out the plan for upgrading recent buyers of Mac systems from Apple's currently shipping operating system, OS X Tiger, to Leopard. Apple is giving Mac buyers, including those who purchased Apple's Xserve rack server, a free copy of Leopard (for a handling fee of $9.95) provided that they purchased their systems after October 1, 2007. Customers purchasing new Mac or Xserve systems after October 26 will receive Leopard either pre-installed on their systems or as a DVD inside the box.

Boxed copies of OS X Leopard client and Server will be priced at $129 and $999, respectively. A family pack with five client licenses of OS X Leopard will sell for $199. Apple's Web site for Leopard can be found at http://www.apple.com/macosx.

Posted by Tom Yager on October 16, 2007 07:21 AM

October 16, 2007

LEOPARD SERVER SHIPS 10/26 (press release)

Apple Announces Mac OS X Server Leopard

CUPERTINO, Calif., Oct. 16 /PRNewswire-FirstCall/ -- Apple(R) today
announced that Mac OS(R) X Server version 10.5 Leopard will go on sale on
Friday, October 26, at the same time as Mac OS X Leopard. Leopard Server
extends Apple's legendary ease of use, making it even easier to take advantage
of the benefits of a server, and introduces Podcast Producer, the ideal way to
automatically publish podcasts to iTunes(R) or the web. Leopard Server packs
more than 250 new features including Wiki Server, allowing people to
collaboratively create and modify their shared web sites with just a few
clicks; and iCal(R) Server, the world's first commercial CalDAV standard-based
calendar server.
"Leopard Server is the best release of Mac OS X Server yet, bringing more
great innovations, like Podcast Producer, Wiki Server and iCal Server," said
Philip Schiller, Apple's senior vice president of Worldwide Product Marketing.
"With new setup features that have a server up and running within minutes and
no client access licenses, Leopard Server is the ideal alternative to
complicated and expensive server offerings for small and large businesses."
Leopard Server presents new features for effortless setup, management and
monitoring of systems on the network. Server Assistant configures server
applications, network settings such as IP addresses and DNS configurations and
user accounts with just a few clicks. Server Preferences simplifies management
of users, groups and key server applications, and a Server Status Dashboard
widget remotely monitors activity and usage. Leopard Server also eliminates
the need to manually set up Leopard clients by automatically configuring
client applications, including file sharing, Mail, iChat(R), iCal, Address
Book and VPN from user information stored on the server.
Podcast Producer is the easiest way for anyone to record content,
automatically upload it to the server and convert it into a podcast optimized
for playback on almost any device, including a High Definition TV, iPod(R),
Apple TV(TM) or multimedia-enabled cell phone.
With Wiki Server, anyone can easily create and edit collaborative web
pages, called wikis, with a few clicks of a mouse. Wiki Server has 20
Apple-designed web page themes and provides a complete revision history to
make it easy to restore previous entries and merge or compare different
versions. Wiki Server can automatically notify users whenever a change is
made, keeping them up-to-date on the latest information, and users can tag
keywords to find content quickly.
It's easy to share calendars, schedule meetings and coordinate events
within a workgroup, school, small business or large corporation using iCal
Server. iCal Server is the first open, standards-based calendar server that
works with popular calendar programs which support the new CalDAV standard and
does not require client access licenses, so businesses can add users freely as
they expand at no additional cost.
Leopard Server is fully UNIX compliant and its core services, including
Apache 2, MySQL 5, Postfix, Podcast Producer and QuickTime(R) Streaming
Server, are 64-bit, allowing users to work with la