IBM breaks OSS patent promise, targets mainframe emulator

IBM is threatening to pursue legal action against TurboHercules, a company that sells services relating to the open source Hercules project, an emulator that allows conventional computers with mainstream operating systems to run software that is designed for IBM System Z mainframe hardware.

In a letter that IBM mainframe CTO Mark Anzani recently sent to TurboHercules, Big Blue says that it has "substantial concerns" that the Hercules project infringes on its patents. The letter is a brusque half-page, but was sent with nine additional pages that list a "non-exhaustive" selection of patents that IBM believes are infringed by the open source emulator.

This move earned the scorn of well-known free software advocate and patent reform activist, Florian Mueller. In a blog entry that was posted Tuesday, Mueller fiercely criticized IBM, accusing the company of abusing its patent portfolio and harming open source software in order to retain monopolistic control over its expensive mainframe offerings.

"After years of pretending to be a friend of Free and Open Source Software (FOSS), IBM now shows its true colors. IBM breaks the number one taboo of the FOSS community and shamelessly uses its patents against a well-respected FOSS project," wrote Mueller. "This proves that IBM's love for free and open source software ends where its business interests begin."

He contends that IBM's support for open source software is insincere. As evidence of the company's hypocrisy, Mueller points out that two of the patents that IBM listed in its letter to Hercules are included in the list of 500 patents that IBM promised to not assert against open source software in 2005. Mueller is convinced that the patent promise was a manipulative attempt to placate government regulators.

How emulation intersects with IBM's mainframe business

IBM's position in the mainframe market has posed contentious antitrust issues for years. The company's software licensing model ties its mainframe operating system to its underlying System Z hardware, guaranteeing that companies who have built their own applications for the platform can't easily migrate to other hardware options. This lock-in strategy has proved lucrative for IBM, generating billions of dollars in revenue.

Despite the extremely high cost and the fact that some companies don't necessarily derive value from the hardware's unique characteristics, they continue buying IBM's mainframe solutions because doing so remains cheaper than rewriting all of their legacy applications. We explained this phenomenon several years ago when we looked at the reasons why IBM's mainframe business is still profitable despite the declining relevance of the technology.

A well-designed System Z emulator that allows users to migrate their own mainframe applications to commodity hardware would obviously pose a serious threat to IBM's mainframe business, but IBM's software licensing terms have historically prevented such a threat from materializing. Users would have to run IBM's mainframe operating system inside of the Hercules emulator in order to run the applications—but they aren't allowed to do that.

It's certainly possible to run modern versions of IBM's mainframe operating system with Hercules, but it can't really be officially supported or publicly condoned by the project's developers due to the licensing issues. Much like Hackintoshing, it is fairly trivial on a technical level but constitutes an unambiguous violation of the end-user license agreement. As such, Hercules never really posed a threat to IBM in the past. The legal issues simply preclude commercial adoption and deployment in production environments. Hercules is principally used by enthusiasts to run z/Architecture Linux variants, an activity that doesn't erode IBM's lock-in strategy.

In many ways, the project arguably benefits IBM by encouraging interest in the mainframe platform. That is largely why IBM has shown no hostility towards Hercules in the past. In fact, IBM's own researchers and System Z specialists have lavished Hercules with praise over the years after using it themselves in various contexts. The project was even featured at one time in an IBM Redbook. What brought about IBM's change in perspective was an unexpected effort by the TurboHercules company to commercialize the project in some unusual ways.

TurboHercules came up with a bizarre method to circumvent the licensing restrictions and monetize the emulator. IBM allows customers to transfer the operating system license to another machine in the event that their mainframe suffers an outage. Depending on how you choose to interpret that part of the license, it could make it legally permissible to use IBM's mainframe operating system with Hercules in some cases.

Exploiting that loophole in the license, TurboHercules promotes the Hercules emulator as a "disaster recovery" solution that allows mainframe users to continue running their mainframe software on regular PC hardware when their mainframe is inoperable or experiencing technical problems. This has apparently opened up a market for commercial Hercules support with a modest number of potential customers, such as government entities that are required to have redundant failover systems for emergencies, but can't afford to buy a whole additional mainframe.

IBM's response

As you can probably imagine, IBM was not at all happy with that development. Following IBM's initial threats of legal action, Hercules retaliated by filing an antitrust motion in the European Union, calling for regulators to unbundle IBM's mainframe operating system from its mainframe hardware. IBM responded harshly last month, claiming that the antitrust motion is unfounded and that a software emulation business is just like selling cheap knock-offs of brand-name clothing. The conflict escalated, leading to the patent letter that was published on Tuesday.

When faced with patent litigation, companies often try to keep the conflict quiet and hope for an out-of-court settlement because they don't want the threat of a lawsuit to scare away potential customers. That's certainly a factor here, because IBM's threats raise serious questions about whether it is truly permissible to use the Hercules emulator in a commercial setting. TurboHercules is taking a bit of a risk by disclosing the letter to Mueller for broad publication. The startup likely chose to publicize their predicament with the hope that the open source software community will notice and respond by shaming IBM into backing down.

As Mueller points out in his blog entry, the broader open source software community has some reasons to side with TurboHercules in this dispute: some of the patents cited by IBM cover fundamental functionality of virtualization and emulation. Those patents reach far beyond the scope of Hercules and could pose a threat to other open source software projects.

Source: Arstechnica.com

IBM initiative aims to hook startups while they're young

Vendor lock-in gets a bad wrap, especially when it comes to the cloud. Users may complain about it, and IT administrators may eye cloud platforms with distrust on account of it, but lock-in is one of the core tradeoffs that clients make in return for access to scalable, flexible cloud services. And that lock-in provides some security for service providers who are taking on the considerable infrastructure cost that building a cloud platform entails. That’s why IBM is now cultivating lock-in by adopting a version of the same strategy Microsoft used in the '80s and '90s to establish the Windows and Office monopolies—give away the product (in Microsoft’s case, by turning a blind eye to rampant piracy), so that your user base is locked in by the time you get really serious about charging.

That looks to be the motive behind IBM’s Global Entrepreneur initiative, which promises early-stage startups free use of specific IBM cloud services, as well as access to the kind of sales, marketing, and technical expertise that Big Blue’s growing and hugely successful services arm typically charges big bucks for. Check out the roster of goodies for startups that are accepted to the program:

Under the new initiative, start-ups can for the first time:

• access IBM's software portfolio through a cloud computing environment, including IBM industry frameworks to accelerate software development;
• work side-by-side with scientists and technology experts from IBM Research to develop new technologies;
• take advantage of dedicated IBM project managers to assist in product development;
• attend new IBM SmartCamp mentoring and networking workshops with VC firms, government leaders, academics, and industry experts at the global network of 40 IBMInnovation Centers to build business and go-to-market plans;
• tap a new social networking community on IBM developerWorks to connect with other entrepreneurs and more than eight million IT professionals from around the world.

And then, when your startup grows up, it will be very hard—if not completely impossible (more on this below)—to ditch IBM's platform for someone else's.

To qualify for the program, startups will need to be less than three years old, privately held, and "actively developing software aligned to IBM's Smarter Planet focus areas." IBM is partnering with 19 associations and VC groups in different parts of the world in order to identify startups and attract them to the initiative.

All told, anything that gets promising, early-stage companies to build their software directly to IBM's cloud is great for IBM—and the fact that these companies will also get a free taste of IBM's consulting services is an added bonus. But is it good for the startups?

The answer to that latter question depends entirely on how good IBM's cloud offerings are, and not so much on the fact of the lock-in itself. That's because lock-in is a defining feature of the cloud landscape, and when you decide to use cloud services either as a consumer or a company, you have to go in with your eyes open.

Lock-in goes with the territory

The issue of lock-in comes up enough in discussions of the cloud that it's worth recapping how it works for readers who don't follow the topic as closely.

In a nutshell, cloud services are offered at three levels of abstraction, and the higher up you go on the abstraction ladder, the more you're locked in to a specific vendor's offering.

The lowest level with the least lock-in is infrastructure-as-a-service (IaaS). A great example is Amazon's EC2, which lets you cheaply and quickly get metered access to any number of virtual Windows or Linux machines. If at some point you decide you don't like EC2, you could always host identically configured VMs on your own in-house hardware, and ditch Amazon's platform entirely.

At the next level up are platform-as-a-service (PaaS) offerings like Google App Engine. It's at this level that the real lock-in starts. If you build our application on App Engine, then it's an App Engine application. And if Google's platform goes down, as it has done once already this year, then so does your app. Or, if you decide you hate Google and want to switch, you'll have to rewrite the app.

At the topmost level of abstraction is software-as-a-service (SaaS), the most commonly cited examples of which are Salesforce.com and SugarCRM. These are cloud applications that you pay to access, and they've got your data siloed away in their cloud. For some SaaS apps, like Google Docs, you could conceivably get your data back out, but it's a pain. SaaS platforms are designed to ingest data and keep it, not to spit it back out in an easily portable format (though there's a movement afoot to change that).

Ultimately, lock-in will be a prominent feature of the cloud landscape from here on out, and more companies will follow IBM's strategy of actively targeting early-stage software startups in order to hook them on a specific platform. This isn't necessarily a bad thing or a good thing—it's just one more technological trade-off to juggle. So it's up to cloud users to educate themselves about the amount of lock-in that they'll be subject to when they commit to any cloud platform, and to factor that into their decision. If lock-in is a serious concern for you, then you'll have to be extremely careful about the kinds of cloud services you pick, and about how you use those services.

Source: Arstechnica.com

Moving beyond silicon to break the MegaHertz barrier

We're rapidly closing in on a decade since the first desktop processors cleared the 3GHz mark, but in a stunning break from earlier progress, the clock speed of the top processors has stayed roughly in the same neighborhood since. Meanwhile, the feature shrinks that have at least added additional processing cores to the hardware are edging up to the limits of photolithography technology. With that as a backdrop, today's issue of Science contains a series of perspectives that consider the question of whether it's time to move beyond semiconductors and, if so, what we might move to.

The basic problem, as presented by IBM research's Thomas Theis and Paul Solomon, is that scaling the frequency up has required scaling the switching voltage down as transistors shrink. Once that voltage gets sufficiently small, the difference between on and off states causes problems from some combination of two factors: the off state leaks (leading to heat and power use problems), or the device switches slowly, meaning lower clock speed. Faced with a "choose any two" among speed, size, and power, we've been doing pretty well via chipmakers' focus on the latter two, but that's now gotten physicists and materials scientists thinking it might be time to look elsewhere.

With four individual perspectives loaded with technical information, it's not realistically possible to dive into the details of each, so what follows is a top-down overview of some of the arguments that are advanced by the various authors.

Forget clockspeed entirely

It's not that the authors of this perspective think continued progress in the sort of electronics that appear in laptops is unimportant; they just suggest it will be increasingly less interesting as we focus on small, flexible systems that can be put in portable devices like smartphones, integrated into things (like clothing) that don't currently contain electronics, and ultimately find their way into implantable medical devices. For all of these applications, flexing and stretching are more important than raw speed.

We've covered a variety of approaches to getting bits to bend, and the perspective breaks approaches down into two basic categories: either make the electronics flexible, or make them small, and connect them with flexible material. In the former category, the obvious choice would be some sort of organic transistor, but the authors suggest that the need for this is overstated. If standard silicon is fashioned into a silicon ribbon, it's actually remarkably robust when flexed. The trick is to embed the ribbon in a stable, flexible substrate, as well as accepting that the device will never have the same power as a complex, multi-layer chip of the sort that we use today.

The alternative is to make the electronics rigid, but extremely small and simple, so that they don't occupy much space. These mini-chips can then be embedded in a flexible material without changing its bulk properties. All that's left is connecting them up and providing them with power, but a number of materials—metals, silicon, and a carbon-nanotube derivative called "buckypaste"—can provide flexible and bendable wiring. Both approaches are already working in the lab, and the primary challenges tend to involve integrating materials that have very different properties in terms of hydrophobicity, heat dissipation, etc.

More bang for your volt

The IBM duo mentioned above reason that, if the problem is that we can't switch existing gates well with small voltage changes, it's time to find a switch that will amplify the impact of a small voltage change. So they consider two approaches that allow a voltage change to have nonlinear effects. The first is something called "interband tunnel FET." In the on state, electrons have easy access to a valence band they can tunnel into. A small change in voltage, however, makes this valence band inaccessible, creating a sharp, and leakage-proof off state. The problem with this approach is that, right now, we can make these devices with carbon nanotubes, but not silicon.

The alternative is to create some sort of gain device into the circuitry that amplifies a small input voltage. A sandwich of ferroelectric and dielectric layers will apparently allow the ferroelectric layer to switch its bulk behavior between two polarization states, giving a small voltage input an all-or-nothing impact. Adding these devices would obviously increase the size of a gate but, at the moment, the real problem is switching speed: theoretically, these things could switch in less than a picosecond, but actual implementations are taking 70 to 90ps.

Forget silicon entirely

The remaining two perspectives focus on the promise of transition metal oxides. The unusual electronic properties of these materials were made famous via high temperature superconductivity, but it's a very diverse group of materials with a huge range of properties. Bonds between oxygen and metals like titanium and lanthanum are extremely ionic in nature, which brings the large, electron-rich d-orbitals of the metals to the fore. Depending on the precise structure of the material and the additional metals present (Zn, Mg, and Sr appear common), the large collection of d-orbital electrons act as a bulk material.

And, just like any bulk material, the electrons can have phases, including solids, liquids, gasses, superfluids, and liquid crystals; there are also property-based phases, like spin- and orbital-liquids. Where there are phases, there are phase transitions, which can be induced by electric and magnetic fields, among other factors. So, the potential is there for a small input to have a significant impact on a large collection of electrons. So far, the first demonstrations of this have come in the form of different types of RAM based on ferroelectric, magnetic, and resistance.

Things get even more interesting when the interfaces between different oxide layers are considered. We've covered one report in the past that described how the interface between two transition oxide insulators could allow superconductivity, and a variety of other interesting effects are described here. Some of these have already been demonstrated to switch states at features below 10nm; an atomic force microscope has created conducting lines at 2nm resolution in a different material.

A decade or more ago, the problem with these materials was having any control over their formation, but we've now gained the ability to deposit layers of the stuff with precisions of a single unit cell of the crystal. The roadblock now is theory; as one perspective puts it, the large numbers of electrons present create a many-body problem that we can't really solve. More generally, there are a lot of transition metals, and a lot of complex oxide combinations (LaAlO3-SrTiO3 and La2/3Ca1/3MnO3 are just two of the many combinations mentioned). Right now, theory simply hasn't reached the point where we can accurately model the effect of bringing these materials together, which makes designing anything with specific properties very hit-or-miss.

The overall message is that we're a long way from seeing anything resembling these ideas in a device, with the possible exception of bendable circuitry. For the moment, this hasn't been a crisis, as the fab-makers have managed to stretch out photolithography, and multicore processors are being put to reasonably good use. Still, the payoff from additional cores is likely to shrink fast, and it's nice to think that there may be something on the horizon that could restart a MegaHertz race.

Source: Arstechnica.com

The A4 and the A8: secrets of the iPad's brain

Most companies, when they go to the enormous expense of designing a complex chip, tell everyone about it. Even a company like Sun or IBM, whose chips are used only in their own computers, unveil the details of their new processors well before products based on those new parts come to market. This is true for game consoles, for SoCs of all flavors, for PC chips, and for most of the rest of the semiconductor industry. It's not, however, true for Apple.

Since the unveiling of the iPad last month, all the public has learned about the application processor that powers the device is a two-letter name: A4. The rest of the details have been treated as Top Secret, and this secrecy has stoked plenty of speculation, some of it reasonable and some of it completely and totally unhinged.

Why has Apple been so secretive about the A4? Why hasn't the company presented a paper on the device at ISSCC, or published a whitepaper?

I don't know the answer to these questions, but given what I do know about the A4, I suspect that the reason is twofold. First—and this is purely my supposition—Steve Jobs just loves secrets. The A4 no doubt gives him that special, "I have my very own custom SoC that you don't know anything about" feeling, and if we're honest with ourselves, wouldn't we all love to know what it's like to have that feeling? I know I would.

The second, and perhaps most likely reason behind Apple's silence, is that the A4 just isn't anything to write home about—and on this second point, I actually know a thing or two. If Apple were to tell you what's in the A4, most of the focus would be on what the chip is not, rather than on what the iPad is.

Meet the A4
As I watched the videos and read the reports of the iPad in action at the launch event, I was thoroughly convinced that the device was built on the out-of-order Cortex A9, possibly even a dual-core version. But it turns out that the the A4 is a 1GHz custom SoC with a single Cortex A8 core and a PowerVR SGX GPU. The fact that A4 uses a single A8 core hasn't been made public, but I've heard from multiple sources who are certain for different reasons that this is indeed the case. (I wish I could be more specific, but I can't.)

In all, the A4 is quite comparable to the other Cortex A8-based SoCs that are coming onto the market, except that the A4 has even less hardware. The iPad doesn't have much in the way of I/O, so the A4 itself can do away with the I/O that it doesn't need. In contrast, the typical Cortex A8-based SoC has more I/O hardware than a mobile phone can use, because you never know what customers will need which interface types.


For instance, an A8-based SoC like the Freescale i.MX51 shown above has an infrared block, three UART blocks for serial communication (RS232 and the like), four USB blocks, and a keypad controller, to name just a few. Of these, the iPad probably needs only one USB port and one UART for serial connections, both of which are wired to the 30-pin connector (assuming that this is the same 30-pin connector as the iPhone). The multitouch input controller will interface with the chip via either a USB port or a serial port (I looked at the datasheet for the STM32TS60, which can do either USB or serial), so perhaps there's another port for that purpose.

Apple's 30-pin connector supports TV-out, but no external display attachment has been announced for the device, so it's possible that the SoC forgoes the common TV-out I/O block and related support for a secondary display. (It has video out. Apologies for missing this detail.)

Another common SoC set of blocks that the A4 probably does without are related to still and video camera support. Apple's iPad may well be the only Cortex A8-device to come to market without any type of camera built in, so Apple has probably ditched some dedicated image processing blocks.

While it's fun to speculate about what Apple didn't include in the A4, the ultimate point is this: with one 30-pin connector on the bottom and no integrated camera of any kind, the A4 needs a lot less in the way of I/O support than comparable chips that are intended for smartphones or smartbooks. This means that the A4 is just a GPU, a CPU, memory interface block (NAND and DDR), possibly security hardware, system hardware, and a few I/O controllers. It's lean and mean to a degree that isn't possible with an off-the-shelf SoC.

What was the role of P.A. Semi?
So if Apple just licensed the A8 and didn't design a custom CPU core, then what was the point of the P.A. Semi acquisition? The answer to this question is still unclear.

Apple bought P.A. Semi in late April 2008. A little over a year isn't near enough time to do a new core design around the ARMv7 architecture. Something like Qualcomm's Scorpion core, which is a custom implementation of ARM v7 that's comparable to the A8, but with a wider SIMD engine and a deeper pipeline, was a multiyear project. I could easily imagine that Apple is working on something comparable to Scorpion, but this wouldn't be ready for a while.

If they were involved at all in the A4 design, and it's still not 100 percent clear that they were, it's likely that the P.A. Semi team made its biggest contribution to the A4 in the area of dynamic power optimization.

The PWRficient chip that the P.A. Semi team unveiled in late 2005 achieved miraculous levels of efficiency through pervasive use of power and clock gating. Power gating is a relatively straightforward technique that involves shutting down the parts of a chip that aren't in use. It's harder to implement in practice than it sounds, though, because you have to divide the chip up into blocks that can be put to sleep and awakened independently. You also have to size and arrange those blocks so that the extra delay involved in entering and exiting sleep states doesn't screw up the chip's overall timing. These delay and timing issues make power gating hard to implement in high-speed processors, which is why the amount of power gating that the PWRficient processor used was remarkable for a high-performance processor.

Clock gating is the other technique that PWRficient used extensively, and it also comes with its own challenges. The clock distribution network can account for up to half the dynamic power draw in a modern SoC. Clock gating is a method for pruning the clock tree by cutting off the clock to parts of the chip that don't need it at a particular moment.

The exact degree to which the A4 uses either of these two techniques won't be clear until Apple does a big reveal, and that may not ever happen. But even if they're not extensively used in the current A4, these techniques are very likely to be a larger part of future iterations or variants of the processor.

Speaking of variants, it's entirely possible that the majority of the P.A. Semi team's efforts are going not into an iPad chip, but into an SoC for the iPhone. Because the iPad's LCD is so large and its power draw so great relative to the other components, it's hard to imagine that the A4 gives the iPad more than a few percent battery life advantage vs. a chip like the Snapdragon—in the grand scheme of things for a tablet device, the extra hardware that chips like the Snapdragon and the i.MX515 have on A4 probably doesn't matter a whole lot. But a chip that's really aggressively optimized for the iPhone might give the phone a real battery life and performance advantage over the competition.

The iPad as Wii, or, "it's the software, stupid"
In the end, I keep coming back to the idea that Apple has stayed quiet about the A4 because any real magic or "wow factor" that the iPad delivers will come from the software—the efficiency of the OS, the user interface design of the OS and apps, and the snappiness of the overall experience all come from the software team.

In this respect, the iPad is actually a lot like the Mac. The Mac combines commodity hardware with great industrial design and a superior user experience. The iPad aims to do the same, but under a new compute paradigm that replaces the venerable keyboard-and-monitor combo with a slate form factor, and the decades-old WIMP-based UI (Windows Icons Menus Pointer) with multitouch.

Perhaps an even better analogue for the iPad is Nintendo's Wii, which is another product that relies for its success not on its processor, but on its novel interface and broadly accessible software. I'm sure that if the iPad can do for mobile computing what the Wii did for console gaming, Apple will consider it a resounding success.

Update: I thought I had checked thoroughly to ensure that there wasn't an official announcement of video out support on the iPad, but I hadn't. So, yes, it has video out, and I should not have implied that this was somehow an unknown.

Source: Arstechnica.com