Saturday, December 04, 2010

will Apple sandbox Mac apps?

You know, most Window's users would hardly notice if they weren't able to use software other than Office to manipulate their Office-generated documents. They already behave very much as though Windows were a sandboxed environment, with one big sandbox and a handful of smaller ones.

That's a far cry from the experience of most Mac users. Aside from iTunes, which must be used to connect to Apple's online content and app stores, to a lesser extent Safari, which is the best browser for use with all Apple websites, including MobileMe, and Xcode for programming for the Mac and iOS, there's no one Mac application or suite of applications that dominates any use category. For whatever you might want to do, there's a choice, and it's common for Mac users to first use one software tool, then another, then another, in a workflow that makes use of the best characteristics of several programs.

This is harder to do in a sandboxed environment, like iOS was originally and still is, except as developers take advantage of provisions for file sharing between applications.

Would Apple similarly cramp multi-app workflows on the Mac?

There's probably two answers to this question, "no" and "yes".

No, we're not going to find that some major update to Mac OS X comes at the price of the inability to save a file with one app and open it in another. Not tomorrow, probably not ever.

On the other hand, Apple probably will find a way to provide some of the security that iOS gains from sandboxing, without actually imposing sandboxes, for the most part.

One way in which they've already done this is their use of property list files, which use a small set of basic object types to wrap data, and make it extremely unlikely that data will be run as code by accident, or by any program other than the one that saved it. Property list support is ubiquitous in Apple's frameworks, and they're very simple for the application programmer to use.

Something else Apple might do is to verify that saved files conform to the type they claim to be, that a JPEG is actually organized as a JPEG and not concealing something that doesn't belong. Developers that provide executable definitions for their custom file types might be given more elbow room than those who don't go to the trouble, and developers who don't go to the trouble might be presented with a choice between using standard file types and property lists exclusively or having their applications sandboxed, prompting some to cry "foul" and others to characterize them as whiners for doing so. Does the operating system have a right to know, in general terms, the content of every file? Of course it does; end of subject.

That's a plausible scenario for how Mac OS X might evolve in the wake of the advent of iOS, far more plausible than the scarecrow that Mac owners might look up from some software update to find their machines locked down. Sure, some apps might be sandboxed, until and unless their developers get with the program, but not the system as a whole, and, most likely, not anything distributed by a reputable company, for which the user paid real money; such apps would already have been updated by the time the deadline arrives.

So quit worrying and enjoy the ride, and think twice before using a custom file type that you aren't prepared to nail down with a schema, or something similar.

Friday, November 19, 2010

TBL warns Web fragmenting into walled gardens

While I've yet to read more than the first page of Tim Berners-Lee's latest, I've already stumbled across several statements that merit response, the following in particular.

TBL writes "The Web evolved into a powerful, ubiquitous tool because it was built on egalitarian principles and because thousands of individuals, universities and companies have worked, both independently and together as part of the World Wide Web Consortium, to expand its capabilities based on those principles."


Certainly, in part, but the potential for profit played no small part in motivating most of those involved, who shared that egalitarian vision only insofar as it served their own proprietary purposes. For example, contending browser vendors attempted to push through their own extensions to the initial standards, with an eye to reaping licensing fees for their use.

It's testimony to the purity of TBL's own motivation that he can still see the development of the Web in such terms, and apparently believe that it is only recently succumbing to the taint of divisive commercial interests, but, as well informed as his view undeniably is, it fails the test of objectivity.

There was never any chance that the Web could grow as it has while existing in isolation from such influences. The best possible outcome would be if the Web continues to make provision for the unencumbered exchange of information and opinion, alongside the walled gardens and pay-to-play sites, far into the future.

Monday, November 15, 2010

something BIG

When Steve Jobs suggests that Apple's $50+ Billion in liquid assets was being saved for the opportunity to acquire something big, we shouldn't confine our thinking to the obvious, companies with market caps smaller than Apple's mountain of cash.

Take, for instance HP. If things continue as they are for awhile longer, Apple's cash reserves will surpass HP's market cap in a few years, but even before that it might be possible to execute an acquisition that included an issue of new stock.

So, why would Apple be the least bit interested in buying HP, nostalgia aside?

HP is among the more nimble of the well established technology companies, and has a reputation for quality that suggests its corporate culture might at least be compatible with Apple's. It has a more diverse product line than does Apple, with distribution channels to match, and has a huge collection of intellectual property, including that recently acquired along with Palm.

But HP sells computers that run Windows! What good would that be to Apple?

To begin with, Apple could make sure those computers all shipped with Safari, iTunes, and MobileMe Control Panel preloaded, and include the same trial MobileMe account that they do for Mac buyers. Apple has plenty of experience with supporting Windows, so this much wouldn't even be a challenge.

Beyond that, Apple could alter the circuit board designs to make them Mac-compatible, and offer them with Windows, Mac OS X, or both, picking up some additional after-market business from people who bought Windows-only machines and later had regrets. People who were leaning towards getting a PC but tempted by Macs would flock to HP in droves, taking business away from its PC competitors.

I'm not predicting that Apple will acquire HP, only pointing out that a case for doing so might be made, and suggesting that this illustrates how broad a net is needed to gather in all of the possibilities for what Apple might do with its hoard.

Friday, November 05, 2010

of rack-mount systems and mysterious data centers

Standard 19-inch and 23-inch rack-mount systems exude the sort of geekiness found in serious IT departments and data-services operations. Is it even conceivable that their days might be numbered?

Apple's choice to discontinue their Xserve line just as their own huge data center in North Carolina is about to come online might seem to suggest they think so, but chances are that new data center will be chock-full of rack-mount hardware, just mainly not Xserves.

I expect a significant contributing factor in Apple's decision to discontinue the Xserve is that they found it wasn't a competitive option for them in equipping the new Maiden, NC facility, even considering that they could sell it to themselves for something like 30% below retail.

Perhaps also, and this is pure speculation, given their investment in miniaturization, a 19-inch rack-mount system is simply too inefficient in its use of space. That might not seem relevant when the size of your data center is measured in acres, but once it fills up that space becomes precious, and configurations that waste it won't survive long. Perhaps they plan to switch to a narrower (10-inch ?) rack-mount system that can fit nearly twice as many devices into the same space. Given the size of the facility, they can probably design and build something for themselves more economically than they can buy from another supplier, especially considering the possibility of using A4 chips or similar ARM-based SOCs, paired with commodity hard drives, and running some variant of Darwin, iOS, or Mac OS X, and doing so would provide them with valuable experience, helping them gain traction with the enterprise in the future.

On the other hand, their need for such a data center may have developed too quickly for them to rely upon technology developed in-house, at least at the outset.

For most of us, the nature of the services that data center will support is more important and far more interesting, but those of us with a geekstreak will continue to wonder over the technology in use until such questions are answered.

getting a handle on Flash

Cult of Mac has published instructions for uninstalling Flash, together with instructions for reinstalling it if you decide that's what you want, and a pointer to ClickToFlash, which replaces Flash content with an inert rectangle bearing the word "Flash", unless you click on that rectangle, in which case the Flash content is displayed.

And here's John Gruber of Daring Fireball on essentially the same topic.

Friday, October 29, 2010

code as content; code as a vector of change

First came symbolic speech. Thousands of languages and dialects blossomed, and the words of some, the shamans, those believed to have direct experience of a spirit world, seemed to possess magical potential.

Then came writing. The great variety of spoken language began to be replaced by preservation approaching permanence, joined shortly by the rigor of peer review and explicit criticism, and the magical potential of the words of the shamans, became invested instead in interpreters, the priests and scribes.

Perhaps presaging what was to follow, a variant of writing, plays, developed into instructions to be performed by acting companies.

Then came machine code, a variant of writing that controls the operation of hardware designed to process such instructions. Very early on that machine code gained conditional branching, the ability to perform different sets of instructions based on the value of some numerical/logical expression. At that point it must have already been apparent to a few that something like machine code would eventually surpass conventional writing, by virtue of its potential to directly control the actions performed by machines. At about the same time, a process of increasing abstraction began, whereby machine code was wrapped in assembler code, which was itself wrapped in higher languages, more closely resembling conventional writing.

Thus far, the impact of computer code on what these days passes for natural language (speech having already been molded by thousands of years of close association with writing) has been to facilitate its production, dissemination, and consumption, but that's only a small part of the whole story.

Computer code, embedded in machinery, has the potential to render meaning tangibly, as real physical performance, with real consequences, good or bad. Given that the design and production of machinery is itself becoming increasingly automated, the question becomes one of what you want the machines to do, and not do, and how those desires can be represented in code.

For example, I can say that I want to preserve what remains of Earth's original biological diversity, while at the same time reducing the dependence of agriculture on petroleum, but in that form it is merely a feeble wish, displaced by the next thought. I can write a treatise explaining why we ought to do what we can to preserve what remains of Earth's original biological diversity and free agriculture from dependence on petroleum, and it may stir others momentarily, but it takes more than that to make any real difference, and if I were to be asked exactly what I'm talking about in practical terms my answer isn't likely to satisfy those whose livelihoods would be effected by any such initiative.

If, on the other hand, I express my intention in the language of machine design and control logic (computer code), the implications, not only of the basic design but of various approaches to managing the system, can be explored through simulation, and that expression goes a long way towards constituting a detailed plan for its own implementation. It's all just code, even the design for the physical machinery, but in a form that makes the decision to go forward with it almost as easy as the decision to flip a switch, at least as compared with a vague call for the desired end results.

Such a project would be too big for any individual, of course, so tools that facilitate collaboration on such projects are needed. Some such tools already exist; others remain to be invented, and much effort is being expended in this direction, even if those involved don't see their work in such grand terms, with the potential to achieve change that could never be achieved through conventional political means alone.

Thursday, October 21, 2010

the parts of Lion which remain secret

I must confess some disappointment over yesterday's announcement, not because the stuff they showed wasn't cool - it was! - but because the stuff that interests me the most remains secret. What we saw of Lion were mainly user interface enhancements, a category that was famously, intentionally missing from Snow Leopard, which concentrated on bug fixes and lower level enhancements. It might even be that the pause in the introduction of new user interface features, represented by Snow Leopard, made possible the integration of such features seen in Lion's new Mission Control view.

But what's Lion got to compare with OpenCL and Grand Central Dispatch? Something, most likely, but that something remains secret. Does it have a new file system or file system abstraction layer? Does it bring true resolution independence? Are any technologies developed for Apple application software, like iPhoto's face recognition, moving into system code and becoming available to third party applications? Are there any important new APIs?

Patience, I try to tell myself, which of the major releases of Mac OS X has not brought such advancements? Maybe 10.1, which was primarily a bug fix and code efficiency update to 10.0. Are they out of ideas? Surely not! Are they underfunding lower level R&D? Not likely. What then?

A Mac OS X engineering position announcement awhile back stated quite plainly that a successful applicant could wind up working on something unprecedented and revolutionary. Sure, Apple spreads such verbiage a little thick at times, but the clear implication was there's something big happening in the wings, and the timing was such that it's likely to be included in Lion, which won't be released until next summer.

Moreover, in yesterday's collection of announcements, everyone on stage was careful to point out that only some of Lion's features were being shown. Clearly there's something else, something they aren't yet ready to talk about.

Something else Steve was careful about, in discussing touch input on Macs and how they've concluded that it just doesn't work on a vertical screen, was that he was talking about laptops, not necessarily all Macs. So, perhaps this recently revealed Apple patent is more than a design exercise. Time will tell.

Wednesday, October 13, 2010

Nice kitty!

The invitation for an Apple Event taking place one week from today strongly suggests that the primary topic of the day will be the next major version of Mac OS X, 10.7, and that the cat-name for this version will be "Lion". Cheetah, Puma, Jaguar (the first to be marketed as such), Panther, Tiger, Leopard, Snow Leopard, and now Lion.

Recent versions have brought, in no particular order, the Kernel Extension APIs, the Acceleration Framework, Spotlight, Core Animation, Core Data, OpenCL, Grand Central Dispatch, and Objective-C 2. What might 10.7 have in store to match these?

Something, no doubt. ;-)

Friday, September 17, 2010

China meets the iPad

China isn't just another market, much as the iPad isn't just another gadget.

China is the most populous country on Earth and has one of the fastest growing economies. So much for the obvious.

While China's economy is rocketing upwards at an annual rate of eight percent, the spending power of most individual citizens is still modest, which makes the affordable iPad a good match.

What makes it an even better match is the touchscreen input, which doesn't discriminate against character-based input, providing the iPad an even greater advantage over keyboard-based netbooks in China than elsewhere.

The advantage the iPad has over other touchscreen tablets, running other operating systems, is more subtle but still substantial, deriving from factors such as attention to detail in both hardware and software, a fast-maturing application software market, and the goodwill Apple has gained through its efforts to improve conditions for the hundreds of thousands of Chinese workers involved in manufacturing its products (even though it turns out those conditions weren't so bad in the first place, aside from the economic incentives for workers to put in exorbitant amounts of overtime, or to end their lives for the compensation their families would receive as a result).

The iPad is destined to be a particularly huge hit in China, but the whole world will benefit from this.

Tuesday, August 31, 2010

AutoCAD returns to the Mac, and comes to iOS in the bargain

As before, I merely pass along a pointer to Architosh's report, which discusses the iOS companion program as well as AutoCAD itself.

Architosh also reports on what appears to be a 60-second TV spot, produced (or at least paid for) by AutoDesk, the company behind AutoCAD.