With a landmark decision, AT&T will let me and some other 4+ million users initiate Skype calls from the iPhone without being limited to Wi-Fi hotspots.

I expect that other carriers will follow suit. It’s a tipping point for the mobile Internet. It’s a boon for the smartphone segment.

In turn, some new applications will soon come out and seize the opportunity. I recently blogged about the wheel of innovation. Today, I saw that wheel turning a notch.

UPDATE. Make that two notches with the announcement of the strategic Android partnership between Verizon and Google.

Although I’m not a big fan of video clips, there’s something that I really like in this video produced by my PayPal colleagues. It conveys a powerful vision. It does so in terms that are easy to relate to.

Clearly, these folks were not blindsided and timely anticipated a connected world that is no longer centered around the desktop/laptop experience. They spun the “Internet of Things” into a promising new vehicle for payments.

To walk their talk, they have put out some additional material on http://x.com (no joke, what a great domain name this is) and announced a SDK that realizes a rich payment platform (formal unveiling at a conference in early November)

The Internet is a late-bloom gift from the 60s — the decade that gave us so many things in the way of technology innovations and social advances. It now feels as Kleinrock & C. were prescient of the 60s legacy and wanted to squeeze their pioneering proof of concept in, not too long past the moon shot and shortly before that wonder decade was over.

It took quite a long incubation before the Internet grew out of ARPA’s sugar daddy support (today, we got no patience for anything…). Back in the days, one could hardly think of the Internet as a global innovation engine. OK, you will end up with a better/cheaper version of SNA LU6.2, what else. It would have stayed within geekdom longer if it wasn’t for Sir TBL and the Mosaic browser. The Web was a sumptuous killer app and the wheel of innovation began spinning ‘round and ‘round to benefit just about every cause:

1. New infrastructure build-outs
2. Leading to faster/broader connectivity
3. Making it a breeding ground for new applications
4. Some of them reaching viral spread, network effect, etc. resulting in larger addressable markets
5. Thus creating demand for more/different infrastructure

[ loop back to 1 ... ka-ching at every step ]

To celebrate Internet’s 40th in style, the latest spin of this virtuous wheel has brought us the unbundled wireless handheld. Take, for instance, community video applications running on top of open-source Android hosted on one of several smartphone hardware platforms, with choice between GSM cell and Wi-Fi connectivity. This was unthinkable just a few years ago. There’s no slowing down of the innovation wheel. Thank you, Internet.

I’m increasingly involved in security and thus managed to make a brief appearance at the Black Hat 2009 Briefings in Las Vegas.

I enjoyed the program. Hereafter some of my personal take-away and favorite sound bites.

Smartphones. There will be exploits:

• Target volumes and personal data becoming interesting, really interesting
• Hordes of 1st-time programmers writing code … which raises the significance of application/system separation that one can depend on
• Also, some seasoned engineers who built highly reliable telco protocols (e.g., SS7, SMS) are now asked to operate in a hostile open world … the price of convergence
• To witness, at Black Hat some folks gave a public account of an iPhone vulnerability exposed with a SMS attack vector. Before Black Hat was over, Apple issued the v3.0.1 patch release (though they had been given a few weeks lead on this exploit)

Smartphones. There will be patches:

• What’s a reasonable time-to-patch benchmark given gazillion of units in the field?
• Apple’s “monoculture” can play out as a strength (homogeneous field, iTunes-centralized lifecycle for patches) and a weakness (magnet for new targeted exploits)
• Others will have to ripple their patches through OS release cycles, hardware manufacturers, providers’ security policies, and the various QA cycles therein

Smartphones. There will be tussles:

• The Apple/Google one is already capturing the news
• Microsoft and Nokia won’t let it go by without a fight
• Android’s licensing model (Apache style, no permission to use) is due to make wave in the whole mobile OS segment (some impressive uptake numbers reported by presenters)

Cloud Computing:

• Hackers/rootkiters have taken notice of the Cloud but are still struggling to figure out the new implications (New attack vectors? Is everything Cloud Computing?). Just like everyone else!
• SaaS/PaaS exploits: any new “Cloud” material here other than the OWASP10 vectors!?
• IaaS exploits: any new “Cloud” material here other than VM attack vectors (like device drivers flaws or pseudo-random generation)!?
• A presenter talked about legal and regulatory implications (e.g., data is subpoenaed and then what) — this was distinctively “Cloud”

Miscellaneous:

• Bruce Schneier provided some excellent food for thoughts on the psychology of security (ref. to his essay)
• The traversal of x.509 certs is still a weak spot after all these years… Basic constraints are not enforced properly and OCSP is easily subverted by toggling a return code, which is inexplicably left out of signature (I haven’t had a chance to validate this claim). Net out, end-to-end SSL is less secure than we think…
• According to a presenter, the hacker-proof shield of Cisco IOS stems from the 250,000+ different images of IOS that resulted from just as many release trains since inception. To hackers’ detriment, each release scrambles waymarks and other reference points thus making it virtually invulnerable
• I wrote about my serendipitous Mach OS encounter in an earlier post

Black Hat 2009 material is here.

I know that I’ve worked on a technology that stands the test of time if, after some 20 years, there’s still some buzz around it at a conference.

This is obviously the case of Unix.

It must be the case of Mach as well. This week, I made an appearance at Black Hat 2009 and stumbled upon a session entirely dedicated to Mach-based rootkits for Mac OS X. The presenter, Dino Dai Zovi, did a good job at describing Mach. Why would someone hack Mach nowadays? Because it’s possible and is a fun thing to do It turns out that Mach is a fairly obscure piece in the Mac OS X ensemble and makes a hacker’s maneuvers a lot less likely to be detected.

Among things, Dino talked about MiG stubs (I did a total overhaul of MiG in 1993) and Mach-O. He recreated a sort of NetMsgServer (which has never been adopted by Apple Inc. as far as I can tell) with which he can siphon or inject Mach IPC messages. In my last Mach endeavor, I created a NetMsgServer that could work over INET.

Back in the days,  Rick Rashid opened Mach conferences by saying that the Mach crowd used to fit inside an elevator.  Twenty some years later, a couple hundred people still crowd a conference room for a solid Mach speech.

I’ve had the fortune to hone my system skills on Mach 3.0 along with a terrific team at the Open Software Foundation and the proxies into the team at CMU.  I’m obviously very pleased that Mach still beats inside my home desktop, laptop, and smartphone. I believe that Dino’s public contribution makes a compelling case for code hardening and pen-testing of the venerable Mach (which I surely hope it will happen on time for Snow Leopard!).

Today morning, I tuned to some concerning news in Bruce Schneier’s blog. Bruce writes about a new attack against 10-round AES-256. He defines it as impressive, practical, and more devastating attack that we have ever seen against AES.

Full AES-256 has 14 rounds, thus there still is some margin left … however, we also know that when there’s smoke there’s fire. Cryptography is an interesting science (and art). It would appear that AES with a 128-bit key is totally immune from these attacks and is as strong as ever. Uhm. I’ve heard that this is due to AES-256’s key schedule being ill-designed. The reason why is beyond me.

Rijndael (as it was called before being awarded the contest) was heralded as the transform for the new century. For the first time in ages, it featured a radical new design.  These research results are coming out way too soon. Concerned.

The Tarte Tatin is an upside apple cake. It used to be my favorite dessert when I lived in France. Yum.

Eating a Tarte Tatin on a lovely summer afternoon while catching up on Google Chrome OS (yeah, I’ve fallen way behind due to my ever demanding day job plus a pile of papers to review out of conference TPC duties).

Google Chrome OS (and other browser OS wannabes) makes me think of an upside cake, just like the Tarte Tatin. Let me explain. In the mid 90s, the Web browser rocketed into the scene. It became the pinnacle of our stack. Fast forward 15 years. With the Google Native Client, one can load and launch native x86 code in the browser without giving up on security (what could possibly be worse than PHP anyway…). Application management is quickly moving to the Cloud (SaaS, PaaS, the-whole-Enchillada-as-a-Service). Likewise, resource management has to play out in the Cloud. Thus, the new-wave browser must underpin both application management and resource management. The browser has become a shim layer buried deep near the bottom of the stack. Voila the upside down cake.

Have we seen other examples of upside down cakes in technology? For sure. Take the Internet. In the 70s, the revolutionary packet networking movement started off as a geeky use case that piggybacked on the very circuit switched network laid out for telephony. This set-up worked well for a long time, until data traffic outweighed voice traffic, in sheer volumes as well as business pull-through. The packet network then moved to the bottom of the pile, with telephony running as an application (VoIP) atop of it, along many others. Voila another upside down cake.

Legend has it that the Tarte Tatin was the lucky byproduct of a bad day in the kitchen. Unlike the Tarte Tatin, there’s little serendipity in what’s happening to the browser and what has happened to the Internet long before. Rather, they are huge R&D undertakings. In my career, I want to see some more of these upside down cakes! Along with chilled passito wine, please, for which I don’t have a geeky metaphor just yet.

I’m taking a break from the buttoned-up posts on ICT scaling and write about people that scale, for a change. I want to share the joy of my bicycle ride up to the top of Mt. Hamilton. I had the pleasure to do this (and the many weekend rides that preceded) alongside my long-time friend Enzo. This summit was a first for both.

Mt. Hamilton is one of the great rides in the South Bay, if not the greatest. We left the car at the intersection of Alum Rock and Mt. Hamilton Rd, San Jose, CA. From there, it took us 3 hours to climb to the summit and 1 hour to make it back.

The long, gentle climb helped us to pick up a good rhythm, without any coup de grace lurking at the next turn of the road. The last 4 miles were the toughest ones because legs felt quite tired and heavy by then. After the bridge, I was on the 28t final position cog most of the time (but never ever on the granny gear!), with short stints on the 25t whenever the road eased a little bit. I created this elevation chart compliments of Bike Route Toaster (note: it’s meters on the Y-axis and kilometers on the X-axis).

At the summit, the view is breathtaking. The Lick Observatory is a treat in its own right. We joined a (free) tour of the dome. Very engaging. For sure, the hosts up there know their crowd! Please remove the shoes with cleats before stepping in. Please don’t feed damp bills into the vending machine

On the way back, we made a few deliberate stops to keep safe and alert. My bike has me pretty low for aerodynamics’ sake, thus I had to shift weights and rest arms and neck every so often. The rustling noise of the wind was so loud that I could not quite hear cars approaching from behind. I had noticed this in preceding trials and bought a rear view mirror that attaches to the drop-down handlebar. The last 3-4 miles before returning to sea level, the road’s pavement turned wonderfully silky smooth on us. It felt as we were welcomed back in style, after a most enjoyable and rewarding ride.

The pictures of this climb are posted here.

Over the last quarters, I spent much time developing the case (ROI, TCO, etc.) for the latest multi-core processors and their yield, measured in transactions/$ and transactions/watt.

Flashback. ‘Twas the end of the 80s and I was a jr. engineer hard at work to get a 4-way 68020 SMP Unix box to perform reasonably well by placing locks in a recalcitrant SVR2.4 kernel. David Cheriton (or was this AST?) quipped that one could either work allnighters for 18 months to figure out all the locks, or else could go to the beach for just as long, come back, and expeditiously plug the CPU du-jour into a uniprocessor with a huge gain over the SMPs with yesteryear’s silicon. This figurated view of Moore’s law hit home. I went on to  find some new challenges (note:  microkernels; no beach).

Fast forward twenty years, and we hit our head on the ceilings of clock frequency and gate density. We have no choice left but run a multi-socket multi-core setup flat out. The superior CPU horsepower and memory hierarchy quickly surface the concurrency shortcomings in our code. The performance line tops off and then turns South.

So, let’s take on concurrency head on. My colleagues recently went to JavaONE and gave a good, well-received run down of their lessons learned in Java concurrency, resulting in some practical patterns and anti-patterns.  Do try them at home!

Sangjin Lee (eBay), Debashis Saha (eBay), Mahesh Somani (eBay), “Robust and Scalable Concurrent Programming: Lessons from the Trenches”. Here’s a before/after flashcard gleaned from their presentation. The full presentation is up for free download here.

There’s another side to this story: The memory wall. It’s just as important to single-out and rework those constructs that get in the way of L2/L3 cache efficiency, like HashMaps and the traversals of linked lists. Furthermore, we like to have a systemic way to manage and leverage any NUMA-ness in our systems.

I list hereafter topics that I’m highly interested in and will be following:

• Post core-spread principles for kernel re-design, like Robert Morris’ Corey that I profiled earlier on; I anticipate that this year’s SOSP will feature quite a few papers in this space;
• Java-only production stacks for which there is (at least) one layer too many between hypervisor, kernel, and JVM, and beg for due simplifications;
• Machine-learning techniques to manage the combinatorial explosion of configuration knobs-and-dials and their inter-dependencies, like Ganapathi’s HotPar09 paper;
• Transactional memory (I read a good article by Drepper on the Feb issue of CACM);
• Access to all hardware counters that can inform tuning (you can’t manage what you can’t measure);
• Share-nothing languages like Scala actors or the re-discovered Erlang (which dates back to  just about the same time of my flashback in the opening).

Some interesting times for sure!!!

Renowned DBMS leaders (including DeWitt and Stonebraker) just published a paper in which they contrast the DBMS magnum opus and the green-ish, increasingly popular MapReduce paradigm. This work will be presented at SIGMOD in a couple of months. Before then, you can get a sneak preview here.

Andrew Pavlo, Erik Paulson, Alexander Rasin, Daniel J. Abadi, David J. Dewitt, Samuel Madden, and Michael Stonebraker, “A Comparison of Approaches to Large-Scale Data Analysis,” in SIGMOD 2009: Proceedings of the 2009 ACM SIGMOD International Conference, July 2009 (Providence, RI)

Back on January 2008, DeWitt and Stonebraker made some waves with their op-ed titled “MapReduce, a major step backwards”. This new paper offers far more nuanced claims, with the benefit of empirical data.

Without venturing into oversimplifying such claims, I was struck by observations such as: “we were impressed by how easy Hadoop was to set up and use in comparison to the databases” and “extensibility was another area where we found the database systems we tested lacking”.

May a constructive tussle benefit both camps, as there seems to be work left at either side, regardless of how long a journey they have been in. Plus, there will be hybrid forms.

In practical terms, I expect that DBMS and MapReduce will continue to exhibit very different TCO models and thus will be quite easy to set apart for a given use case (with the caveat that one’s own TCO model will be different).