Thursday, June 26, 2008

Does LLVM Mean An Alternative to Objective-C is in the Works?

The LLVM project has popped up on the radar a bunch of times lately. There's a variety of speculation about why the sudden interest.

I'll throw my hat in and suggest that Apple is thinking seriously about a full-service alternative to Objective-C for programming against the native OS X (Cocoa) API.

Objective-C hasn't spread as a general use language on other platforms, and Apple is showing a higher level of interest in expanding its ISV/developer base.

While other language bindings have been promised or offered over the years, none have been developed or maintained to the point that they are a realistic equivalent/alternative to ObjC. For example, according to an Apple insider I spoke with, it turned out that, under the hood -- at the level of linking, marshaling, etc. -- the cost of the incompatibilities with Java just got to be too great to try and keep it as a first-class environment next to ObjC.

It would seem that LLVM could open up a lot of doors here.

If, as reported, the Xcode environment hooks in with LLVM/GCC, then there is a natural integration point introduced at the intermediate representation (IR) level.

It may not be trivial -- LLVM is designed to be lower-level than, say Microsoft's CLR. The CLR, together with the CTS (common type system) and various other infrastructure and requirements, created a level of guaranteed interoperability between any two .Net languages ... somewhat different from the purpose of LLVM, which appears to be more about the ability to rigorously transform and optimize code in a hardware independent manner.

In this sense it may be about helping with Apple's parallelization work as well as cross-compilation for GPUs or PowerPC. Still, at the end of the day, there are libraries to be called into and data to be passed. And having a big multi-language abstraction in the middle would seem to make it a lot easier to massage the call patterns of other languages so that they play nice with ObjC system libraries.

Oh, and check this out: it's fun and interactive: you can try it in your browser and see the IR right now!

Friday, June 20, 2008

Want to Read Your Parents' / Boss' / Coworkers' Files? Mozy Client Circumvents Windows File Access Permissions

Last fall I wrote about Mozy, a cloud-backup company (now owned by EMC), which had a severe bug: it didn't back up all the files it was scheduled to. What was most disturbing was not that they hadn't caught the bug ... it's that when I tried to work with them to resolve it, they blew me off. Apparently I wasn't the only one to have this problem either, as people from all over found my blog post and emailed me, saying they saw the same behavior and asking if I had a fix.

I still think that not backing up files is the biggest possible bug for a backup program.

But now there's competition: their latest client allows a non-privileged user on a Windows XP system (haven't tried it on Vista yet) to restore private files belonging to any other user ... including Administrators, and place the "restored" files into the non-privileged user's folders, with full access, and fully decrypted.

How does this work? Say Jim, the Admin on the box, installs Mozy in a default configuration. Mozy is backing up Jim's "My Documents" folder and subfolders, among various other things. Jim's son Lenny, who is a non-privileged XP user and who is not supposed to have access to Jim's private files logs on.

Lenny notices that "My Computer" contains a virtual drive corresponding to the Mozy backup set. In that virtual drive is ... a "C:" drive ... and a "Documents and Settings" folder ... and a "Jim" folder. Now in XP, "C:\Documents and Settings\Jim" is another name for Jim's "My Documents" folder. This particular instance though is not the actual "C:\Documents and Settings\Jim", which Lenny doesn't have any access rights to, but the backup image of the folder.

So Lenny browses through, finds something interesting, right clicks and chooses "Restore To," which lets him "restore" his dad's file to somewhere of his choosing. He browses to his Desktop, clicks ok, waits a few seconds, and now he has the file.

(Even if Jim has chosen to manage his own crypto key -- one of Mozy's coolest features -- the Mozy client keeps that key accessible so that it can perform automated backups. Unfortunately, it also uses the key for restore operations no matter who performs the restore ... so files restored in this way are decrypted.)

Ok, so there are no secrets on the family computer. Not the biggest surprise, since if junior really wants the data, there are tons of other ways to get it, from booting a Live CD and mounting the hard disk, to yanking the hard drive right out of the box.

But here's where it gets more interesting: In many (most? ... all that I've worked at anyway) corporate, Active Directory- / Domain Controller- managed XP Pro deployments, folks can log on to each others' workstations at will, provided they use their own credentials in the Domain. Their Domain profile updates to the local machine as necessary, and they can then work there. They may even be able to log in remotely via Remote Desktop.

So at work, I walk up to my co-worker's machine (or maybe RDP in) and log in as myself. I open the Mozy tray icon, and proceed to restore their files from the backup set to my own directory, or to an unprotected area like C:\Temp. From there I can open/read/copy these files however I like. Incidentally, if my boss' files weren't already scheduled to back up, I can add them to the backup set. Next time the backup runs, they'll show up in my view of the "Virtual/Restore Drive."

I haven't tested the Mozy "Pro" business client, but since the docs [PDF] look identical to the Home client (apart from a color accent) I suspect it behaves exactly the same way (see in particular sections 7.3 "Using the MozyPro Virtual Drive" and 7.4 "Right-Click Restores") Not to mention that if Mozy fixed this in the Pro edition I can't think of any reason they'd intentionally keep a broken code fork for the Home edition.

I think there are some other fun tricks one could play with this client too, but it all boils down to two things:

  1. The underlying process is a privileged process, but it takes orders from a client run by any user.(I'm no security guru, but this sounds like a Confused Deputy problem to me.)
  2. The full fidelity of the local file (including a way to associate ownership and permissions) is not being preserved through the backup round trip.

I'd have reported it to Mozy before writing about it here, but they made their lack of interest clear last time around.

Update: I forgot to mention, MozyPro offers "Network share and mapped drive support" ... combined with the bug described here, that's some serious potential risk to add to the mix.

Wednesday, June 18, 2008

Please, Tell Me Another Cool Story About Your AAPL Stock

A comment I read today claimed that Research in Motion (maker of the Blackberry mobiles) stock (RIMM) has outperformed Apple's over any conceivable period you might want to look at. (Yes, I checked it out, it's true, and I have some numbers for you later if you don't want to go try it yourself.)

Here's what I find really interesting: Apple doesn't just have product fanboys, it has stock fanboys too. I've personally met dozens of people who -- entirely unprompted -- insisted on telling me about their AAPL stock adventures, successes, questions about timing and the future ... I haven't met a single RIMM investor who has spontaneously felt the need to chat me up about the stock.

Now there's no mystery about RIMM: Anyone who understands fundamentals could analyze RIMM as easily as AAPL. Or if they want to really get into it, RIMM's products, plans, sales channels, and management are arguably more transparent, simpler, and easier to crack than AAPL's. (Most investors love leaks and hate surprises.) So it's not like these AAPL investors stuck with the company they could understand and analyze.

Instead, I'd venture the opposite: I bet they know little to nothing about either company under the hood, but they love the drama and the theater of an Apple product announcement, whether it's really good or bad for the stock. They think that press coverage somehow equals investing success.

As for the numbers, I checked Google Finance and observed that ... yes ... in all the time that these two companies have been public, RIMM has outperformed AAPL over all reasonable intervals. In fact, even if you had, say, sold your AAPL to buy RIMM at the worst conceivable moment, when RIMM peaked relative to AAPL, within a few years your RIMM holdings would already be worth much more than the AAPL shares.

I'm not bringing this up to recommend one stock over the other. They have actually trended together, and if this sector is your thing (I count them together today, because of the iPod/iPhone contribution to Apple's success), then you might want to invest in both of them ... and some of their other competitors too ... to diversify, at the expense of trying to make the most money on a single horse.

But what cracks me up is how people so often want to believe a story they know over a story they don't know; a simple story over a complex story; and a story (narrative construct in general) over the tricky realities that motivate and underlie all of our constructs.

And if you're one of those people so in love with a romanticized Apple story that you don't mind having half the returns (in the last 5 years), 40% of the returns (last 2 years), or even just 30% of the returns (1 year) of a RIMM investor ... I'm not saying sell Apple, but diversify, diversify, diversify!

Monday, June 16, 2008

If Developers Love Speed, Why Is a Slow Laptop More Popular than a Fast Desktop?

When I was in college, there was an anthropology meme about how childbirth became riskier when the human pelvis adjusted for walking upright. So the ability to walk and run -- or the brain developments that caused humans to deal with problems by walking and running instead of some other way -- must have offered some massive evolutionary advantage that outweighed increased risk to mother and offspring in childbirth.

I'm not sure where this belief stands now -- whether it's established dogma or the anthro equivalent of an urban legend -- but there seems to be a funky analogy among developers and their dev machines.

I'm amazed by how many devs want to be mobile so bad that they use a laptop as a principal (or only!) development machine. I'm more amazed when these same people then get into a silly debate about "the best tools for the job," whether that's an OS debate, or IDEs, or something else.

Because, like walking upright in the story, a laptop offers mobility at a very heavy price.

I work machines pretty hard -- running server software, virtual machines, development environments / debuggers, lots of browsers, random other tools, some of which even use CPU cycles and not just memory. I appreciate the productivity and uninterrupted "flow" that a really fast machine offers.

Laptop performance is awful compared to desktop machines, and with every passing month a laptop (due to its limited ability for upgrade) falls farther and farther behind its well-maintained desktop counterpart. And a plain ol' $100 motherboard and $250 processor in a desktop will do things that make most laptops implode into a singularity, whether it's the 1333 MHz FSB, the 3+ GHz quad-core CPU, or a graphics card whose cooling pipe alone can't fit inside a laptop.

Even the top end, like the fastest Alienware gear, has some fundamental limitations that sound like desktops from a few years back: 2.8 GHz CPU / 800 FSB / 667 Memory ... and a price tag (with the best options) near $5,000!

It's not an OS thing either: the hyper-popular MacBook Pro, while one of the fastest "conventional/mass-availability/non-gaming" laptops, is a complete lightweight compared to the base 8-core Mac Pro tower (that runs the same $2,800 as a the top-end MacBook Pro).

Don't even get me started on the garbage laptops that most companies give their employees, machines which are optimized for durability, enterprise management, and running Office. Sporting things like 4200 rpm hard drives.

And for the occasional but real necessity of mobility, a $250 cheeseball laptop does a fine job for giving presentations, working with Office, and even a quick hack here or there, so it's not as though there's a huge sunk cost just in being able to bring a slide deck to a client.

Yet ... the ability to move around instead of sitting in one place offers -- or at least appears to offer -- some kind of power that compensates for all of these issues.

Can anyone clue me in on exactly what it is?

Thursday, June 12, 2008

I Say "Ôpen" - You Say "Õpen": It's Not iPhone vs. Android, It's Software vs. Telcos

I couldn't find the first article I had read spreading the Android vs. iPhone competition meme. No matter, it has taken root and grown like ivy. iPhone doesn't compete with feature phones or smartphones, but with Android, yada yada. Where's Microsoft and RIM, yada yada. iPhone is closed, Android is open...

Hold that last part just a sec.

It is true that by the standards of the software world, iPhone is less "open" than Android -- Android will run on lots of hardware, it is open to programming at more layers of the stack, doesn't involve an App Store or a pseudo-proprietary language. iPhone is more constrained.

It's shaping up to be an epic battle if you accept that framing of the story... But:

By the standards of the wireless telco world, both iPhone and Android are "open" (as are Symbian and Windows Mobile) because they let you choose what you want to run, and by exposing services like GPS location and push messaging to ISVs, they allow a freeform relationship between the device owner and the software vendors offering real, fast-paced innovation. Such a relationship is a huge change from tradition, where the telco mediates the relationship to the detriment of everyone involved.

Never mind if the data access costs a bit more than some folks might like (Gizmodo shows that there isn't really any change here from existing smartphone plans). The carrier has to make money somehow, and building wireless infrastructure and selling access to it is what they're good at. Controlling the user experience is not what they're good at (one reason they rank slightly below used car salesmen and vampires in terms of customer satisfaction).

Looked at this way, iPhone and Android have a whole lot in common: they're trying to push the evolution of consumer use of mobile devices while trying to wrest control of the narrative from telcos who have stifled the industry for almost a decade.

The hype and success of iPhone and Android is a boon for consumers and for the entire industry, a chance for America to move from a cellular Minitel world to an Internet world.

Monday, June 09, 2008

In Blue Trunks, Skyfire and ISPs; In Red Trunks, Multi-Core CPUs, GPUs, Smartphones, iPhone and Laptops

Skyfire is a mobile browser that has been exhibited at DEMO and has just closed a $13 million B-series funding round (they had received $4.8 million total prior funding). The elevator pitch is that Skyfire brings any web content to the mobile phone, including Flash applications, YouTube videos, Ajax, etc.

I've been trying the Skyfire beta, and I have to say that it's a neat piece of engineering, even if it's just a stripped down VNC-style screen/audio scraping client for a server-side browser session.

But I'm stunned that it has received this level of venture backing.

My surprise isn't because the software is buggy, slow, and has a bad interface on my Samsung Blackjack. Since I'm running a beta in the 0.6 or 0.7 version range, I feel I should be charitable and I'll pretend that all the bugs will be fixed by 1.0, the interface will be great, and it'll run 10x as fast as it does today.

Instead, my surprise is because Skyfire is really about a great periodic function known as "thin client, no, fat client, no, thin client, no, fat client ..." and Skyfire is the epitome of the thin-client position.

Instead of running a browser (which ironically was once considered the thin client, but is now just the universal fat client, consuming hundreds of MB of memory on a desktop to run several Flash or Ajax apps) on a small device, they punted. They'd run the browser in a data center with memory, CPU, and bandwidth, and hand the phone a 2008 equivalent of a green-screen terminal.

This is a losing proposition. For a long time now, all signs have pointed to the fact that fat clients win. And not just because they happen to offer a better user experience (thin-client proponents insist that will change 'someday' although I doubt it).

The economics and technology lean toward the fat client: Although bandwidth has gotten cheaper on an absolute dollars-per-megabit basis,

  • Bandwidth has gotten more expensive relative to the speed of "local" hardware buses: USB 2.0, eSATA, PCI-X, 1333MHz memory, gigabit Ethernet etc.
  • Bandwidth has gotten more expensive relative to the cost of local computation: a midgrade Intel proc costs the equivalent of a few months of home DSL or cable ISP service, and this equivalent has been stable for a number of years ... and the computational power of that midgrade CPU has gone up severalfold, while the DSL/cable bandwidth has stagnated ... and now is threatened by both metered-pricing and traffic-shaping schemes. On the GPU side, the differential has changed by orders of magnitude to the advantage of the fat client.
  • A given "bandwidth experience" has gotten more expensive as users expect to be connected in multiple contexts: To have the same "experience" I have to buy the same bandwidth several times, once for when I'm home, again for when I'm on my cell phone, again when I need to use WiFi somewhere, and maybe a fourth time for a 3G laptop card.
  • Cheap powerful computation has innovators, while bandwidth has innovation obstructers.

Sure, raw dollars-per-CPU-cycle and per-kWh can be optimized in a data center somewhere.

But as long as the cost to connect me and that computation dwarfs the inefficiencies of just carrying the computer with me, Skyfire and its investors have bet on the wrong horse.

Sunday, June 08, 2008

Microsoft Should Trumpet, not Downplay, iPhone's Real Accomplishment (Hint: It's not about Sales Volume)

In this article, Philip Elmer-DeWitt deconstructs a Microsoft partner mass email to discuss how a heap of chest thumping is presumably hiding real insecurities about how the Windows Mobile ecosystem stacks up to that of the iPhone.

Coming before the new iPhone launch, I agree this is not a coincidence. And although I've penned defenses of Microsoft in this blog, this post isn't one them. Instead of chest thumping, Microsoft should be talking to its partners about what Apple has accomplished with the iPhone that Microsoft has not in the 6-odd years since the first Windows Mobile phone shipped... and how that accomplishment has created new opportunities and liberated new value for the entire wireless space including the WinMo world.

In a nutshell, one of the enduring problems with wireless is that no matter how good the phones got (first WAP, then Java apps -- with networking, then color and multimedia and .Net and push data and QWERTY keyboards etc.), U.S. customers just never seemed to get that this was a real computing device, that would powerfully complement their PC(s) and could be just as general in use.

No matter how much analysis showed that the phones people already had could save weeks out of their lives through increased convenience and productivity (with the right software), almost no one used productivity apps, or mobile websites, on their phone. Some conceptual chasm just stopped people in the U.S.

So Apple comes along with the iPhone. And feature-for-feature, the original iPhone OS (not the OSX core, but as it was exposed developers/users) couldn't hope to keep up with Windows Mobile 2003, let alone '07 (WinMo 6.0).

But Apple was hunting different game. By combining a beautiful interface, ridiculously fast processor (to the point that battery life suffered), and an all-in-one experience featuring massive "On Ramp" signage to apps and the web, Apple got people to understand the phone was a computer that normally, natively runs apps and accesses the network, something no one else had accomplished on a mass scale in America.

I've written before about stuff Apple does poorly. This iPhone-as-computer play isn't one of those things. It was a big gamble, but arguably Apple has pulled off another early-Macintosh-type accomplishment in terms of changing how the public understands what a device can/should do.

And, as with the Macintosh, there is no reason that this "enlightenment" should only put dollars on Apple's bottom line. It boosts Windows Mobile, Symbian, Blackberry, Palm ... by focusing free mindshare on the phone as computer.

Now the other players need to follow through. Microsoft and RIM have the lead in the U.S. -- the first thing they ought to do is stop everything and get a browser on their phones that doesn't totally stink (that's the sanitized version of how both those guys' browsers deal with the modern web).

I won't detail requirements; I think Safari on the iPhone is a clear enough target. And while the wide variety of OEM hardware that runs Windows Mobile won't all have the CPU muscle for a Safari, Microsoft should make a credible effort to replace notepad, er, I mean Pocket IE. Meanwhile, why not send out a partner mass email confessing that PIE alone is costing everyone in the WinMo value chain bigtime.

If I were Ballmer, I'd dig up half a dozen hackers from inside or outside who have worked on the Mozilla codebase. I'd get them porting whatever they could to WinMo, and I'd have an internal team building a new Pocket IE product as well. At the end of Q3 '08, whichever browser works better on the most Windows Mobile devices, becomes part of WinMo, the other guys get a mediocre line for their resume (unshipped product), a vacation, and a reassignment to the next Microsoft Bob.

Saturday, June 07, 2008

Maybe a Reason to Learn some Scheme, not a Reason to Avoid Anonymous Functions

A team member with one of my consulting projects sent an email yesterday, describing his counterintuitive run-in with the this keyword in an ActionScript 3 anonymous function. He found a fellow traveler looking at the same issue here... and concluded this might by 'yet another reason to avoid anonymous functions.'

I have a different view, which I thought might be worth reproducing here:

I'm not sure this is a reason to avoid anonymous functions. Looking at the issue and the blog post, the following points may be helpful for the newbies to ActionScript. AS3, and the Flex/Eclipse (FlexBuilder) environment especially, make ActionScript seem like a strange flavor of Java (or C#). But it's not.
ActionScript 3 is an implementation of EcmaScript 4. It has much more to do with JavaScript than with Java, although Adobe intentionally created an environment that would be familiar and comfy for Java devs.

EcmaScript (aka JavaScript) is a Lisp/Scheme family language not a C/C++/Java family language.

Unfortunately, for historical reasons, it shares some syntax constructs with the C-derivative languages, and ES4/AS3/JS2 adds more of those -- but many of them have different meanings, as the aforementioned blogger discovers the hard way.

If you're interested in how this came about, and how to think about it, I can't say enough to praise Douglas Crockford's lectures on "The JavaScript Programming Language", which you can watch from YUI theater. Brendan Eich takes issue with some of the "politics" stories in Crockford's account. But confirms that engineers were recruited to Netscape with the promise of implementing [some flavor of] Scheme in the browser.

If you expect to spend any amount of time in the future doing JS or AS, a couple hours watching Doug Crockford speak are unbelievably worth it. JavaScript (and AS) are extremely powerful languages and can work really well ... only they definitely don't work like they appear they should, if you see the syntax and come from a C/Java background...

Once we realize that we're basically running Scheme in the browser (Brendan says Self), lambda -- anonymous functions and their closures -- become first-class objects as fundamental to us as stack vars in a C language.

As a bonus, if you're new to this and have some time, MIT has published one of the classic textbooks, "Structure and Interpretation of Computer Programs" online for free under a Creative Commons License, along with instructors' manual, exercises, etc.

Actually, I'm gonna go out on a limb here and say if your company or team has a C/stack/register kind of background (Assembly/C/C++/C#/Java/Pascal/Delphi/ and you're looking at getting involved in JavaScript/ActionScript/Ruby projects, make a team workshop out of doing as much of the Abelson/Sussman book as you can get away with. As a practical side effect, it'll also make your SQL code easier (core SQL is more like Scheme than C) and give you another way to look at problems.