IT is already being dDelivered, Mr Robinson, is it not? Or are you going to dismiss the Virtualised State in Quantum Controls? That would be tantamount to not Really believing in your own HyPing Rhetoric...... Viably Imaginative Developments for Human Thought Taken to the NXXXXT Levels in AI Red LITe Zone for the ............ For Real Gamer and Scarlett Pimpernel/Invisible Man.

One Reality in Fact 42 Run in Parallel with Earlier Controllers. Market Makers and Breakers.

Am I being thick or something? I thought all you had to do to get an application originally written for Solaris on Sparc to run on Linux on x86 was

sparcbox $ scp application.tar.gz x86box:/usr/local/src/

x86box $ tar xvzf application.tar.gz

x86box $ cd application

x86box $ ./configure

x86box $ make

x86box $ sudo make install

..... in other words, just copy over the tarball and recompile it for the target architecture (constants which may differ across systems are obtained from header files on the target machine, and the configure script does all the remaining high-level magic for you). What am I missing, exactly?

There are actually quite a few products out there in the commercial UNIX world that are commercial, closed source products. As luck would have it, some of those products are unavailable for transferring to an x86 platform (Solaris x86, Linux, whichever). Sometimes it is next to impossible to justify the costs associated with licenses, or support (especially if support had lapsed and the vendor requires you to buy support for all the years in between). Other times, the software does not exist for any other platform other than Solaris, although that is becoming rarer. And sometimes, a piece of legacy code is hanging around on old hardware on an outdated OS because there is simply no source code to be had because the vendor went out of business / the developer took the code / oops, but "our end of line shipping operations were built around this custom code and absolutely can't be replaced without spending a bazillion <insert local currency> to rework the whole solution." Sometimes I feel like I work at the American subsidiary of the BOFH's operation, only without the gratifying occasion to be a BOFH.

All that said, being a Solaris bigot, I like the news that they are working on a package to let you run Solaris SPARC on Solaris x86. I have seen their product at work in Apple's and on virtual Linux hosts (talk about ingenious), and it holds up incredibly well.

Is doing it without the source code.

(Because not everything has got source code, written using GNU autoconf. No in-house developments that I know of ever go to the effort of writing cross-platform code in that manner. It's all "unnecessary" overhead.)

Transitive's pitch is all about taking old, SPARC binaries and getting an instant boost by running them on x86 hardware. This would seem to be of most interest for binaries that you can't simply recompile.

The problem with the Transitive SPARC-play is that ISVs are not going to certify/support their customer running old, SPARC binaries on Linux/x86 via Transitive's emulation layers. Then you have to also realise that a big part of the effort of any platform switch is in testing. Oh, and the Solaris environment that your program then runs in looks mostly like Solaris 10 (it's OpenSolaris based), which can have implications for a binary that expected to be running on 6 or 8. So, more testing.

If you had the source that already compiles on Solaris/SPARC, you'd find it far easier to build it on Solaris/x86 anyway (you'd encounter any lurking endian issues on both Solaris and Linux) to get an x86 'boost'. In fact, if you had the source you'd get a boost just by building it with the latest SPARC compilers for the latest UltraSPARC hardware.

All the talk is in $, and you could be forgiven for thinking that this is a US company. It's not, it's a British company, and people like TheReg should be trumpeting that fact that we do still have some technology capacity over here !

Itanium is a dead chip walking. Why on earth would someone take old, legacy code and try to run it on soon to be legacy Itanic?

It makes much more sense to run it on x86. In fact, what Transitive needs to offer is an Itanic on x86 emulator, to help HP's victims, er, "customers" escape from Itanic.

The same idiocy applies to running Linux/x86 on POWER. Why? If you need performance, recompile to Linux or AIX on POWER. Maybe the value proposition is you can spend ten to fifteen times as much on the hardware.

The idea of Transitive on Solaris on x86 makes a lot of sense, especially if you could run Transitive sessions within Solaris Containers.

What would make even more sense would be to integrate Transitive with Xen or VMware. In fact, if Transitive could port its emulator to run natively on VMware ESX, that would get real interesting. I would love to see VMware buy Transitive, and perhaps FunSoft, and make a product which could emulate as well as virtualize. Combined with big-iron four-socket quad-core Opteron and Xeon, it could clean house in the data center.

"what Transitive needs to offer is an Itanic on x86 emulator, to help HP's victims, er, "customers" escape from Itanic."

They could call it Lifeboat.

"the developer took the code / oops, but "our end of line shipping operations were built around this custom code and absolutely can't be replaced without spending a bazillion <insert local currency> to rework the whole solution."

That's a very gray picture, anonymous. And Inconvenient.