Common questions around application binaries: What exactly does IBM mean by "Industry standard Linux"?
jscheel 0600025BWM Comment (1) Visits (5276)
By: Jeff Scheel.
As I've often mentioned in my blogs, I like to answer questions which I've been very asked frequently. Today's topic provides more details about our marketing slogan "Industry standard, Tuned to the task". We've worked so hard to eliminate the myth that PowerLinux is different (see my blog What does IBM mean when it says, "PowerLinux?") that we're now getting questions like:
The short answer to all of these questions is the same, "No".
The technical explanation, stems from a fundamental component of computer architecture -- the processor. Every processor architecture has a different machine language (command set) that it supports. So, even though Linux is built from the same source code, using the same compiler, the final executable system code is different because the compiler "targets" (builds for, generates machine instructions for) the specific processor type.
For some people, this may make perfect sense if we talk simple "Hello world" application. If I compile it on my x86 PC at home, I understand that it would not naturally expect it to run on the Power System at work. In fact, if I build the application in both places, x86 PC and Power System, I will see that even the resulting binary is a different size, demonstrating the machine language between processor architectures are likely different.
Since the Linux operating systems is simply a large collection of programs, the same explanation applies to the operating system. Red Hat and SUSE build their distributions from the same source using the same compiler,s but generate different programs for each processor architecture. Then, they bundle and distribute all the programs for the operating systems on a specific processor architecture into different DVDs -- one set for x86, one for PowerLinux, etc.
Now, let's look at an installed image. Once I get that operating system running with the programs compiled for my architecture, the answer to the final bullet above should become obvious. The executable program is unique to the processor architecture. So, the migration of VMs must naturally stay on the same processor architecture. PowerVM can move VMs (or LPARs as I grew up knowing them) from different versions of the architecture such as POWER6 to POWER7, but it cannot be moved from POWER7 to Nehalem because the executable binaries only understandable to the processor for which they were built.
Hopefully, this now makes perfect sense. But if not, let me try one more analogy. If you and I were identical twins, dressed identically by our mother, and were trained to play the violin for the same number of years by the same teacher, we would play the same piece of music (say Fritz Kriessler's Praeludium and Allegro) differently. Why? Because our brains are different. Even though the source code (written music) is the same, the executable program (our playing of the music) would be different because our processors (brains) have a different architecture even though the computer systems has all the same components like I/O (violin) and chassis (clothes and body structure).