Linked by Thom Holwerda on Thu 20th Mar 2008 21:34 UTC
Sun Solaris, OpenSolaris "Sun Microsystems has gone totally native. Customers can now run unmodified SPARC/Solaris applications on x86 systems thank to a partnership with Transitive. The two companies also plan to craft a new package for running native x86 applications on SPARC machines. Transitive this week announced that the long in beta QuickTransit for Solaris code has moved into production form. It even gets a Solaris Ready Logo and all."
Order by: Score:
Comment by flanque
by flanque on Thu 20th Mar 2008 22:35 UTC
Member since:

This is great progress, but I think the performance hit is a bit too much to tempt me at this stage. There are a few areas I could definately use this, so I'll watch this over time with much interest.

I'll even give it a shot to investigate compatibility.

Reply Score: 2

limitations of JIT
by JoeBuck on Thu 20th Mar 2008 23:35 UTC in reply to "Comment by flanque"
JoeBuck Member since:

Certainly a JIT approach can be useful if you've got a machine around and you want to run a non-native app. But it's never going to be a first-choice option, it's more like an option you would choose if you're stuck with an incompatible processor or an incompatible app. Native execution is always going to be better, unless you have an app for such an old architecture that, even with the JIT performance penalty, your new machine can still run it faster.

And that might even be the case for your old Solaris/SPARC apps. We've got plenty of old, underpowered SPARC hardware around here.

Reply Score: 2

RE: Comment by flanque
by james_parker on Fri 21st Mar 2008 16:41 UTC in reply to "Comment by flanque"
james_parker Member since:

One place this will definitely be useful is for sales demos. This technology will allow SPARC-based products to be demonstrated using fairly standard laptops. Current solutions are more problematic; porting to Solaris x86 (which may be complicated by third party software availability), transporting a small SPARC server (even a SPARCbook may be difficult if the salesperson also needs a separate laptop), or using a remote server (prospective customer's firewalls can create substantial problems).

Reply Score: 1

Comment by zizban
by zizban on Fri 21st Mar 2008 01:10 UTC
Member since:

Its actually for x86-64 systems. A small quibble.

Reply Score: 2

by kaiwai on Fri 21st Mar 2008 02:07 UTC
Member since:

The quote is confusing because on the first part you state that SPARC applications running on x86, and then in the second part of the quote it says x86 applications running on SPARC - which one is it?

Reply Score: 2

RE: Confusing
by digitaleon on Sat 22nd Mar 2008 06:15 UTC in reply to "Confusing"
digitaleon Member since:

Admittedly, the way the text was quoted for the summary was suboptimal. It's actually referring to two separate announcements:

1. Now - A QuickTransit package is available that enables you to run "unmodified" Solaris SPARC binaries on the Solaris x86 platform. This package was in beta until recently.

2. Later - It is intended to develop a QuickTransit package that enables you to run (presumably also "unmodified") Solaris x86 binaries on the Solaris SPARC platform. This is in the planning/early development stages.

I hope that clears things up.

Reply Score: 1

What's the point
by rom508 on Fri 21st Mar 2008 02:33 UTC
Member since:

They're just constructing layers of code that takes up valuable memory and processor resources. Same goes for virtualisation, etc. If the software vendor cannot provide native versions of their binaries for a particular platform (there aren't that many, for Solaris the choice is x86/64 and Sparc), well they can go to hell. The more turd you pile up on top of your OS, the more bugs and bloat you have to deal with.

Reply Score: 1

RE: What's the point
by Aronek on Fri 21st Mar 2008 22:52 UTC in reply to "What's the point"
Aronek Member since:

Valuable memory and processor resources? What computer resource is cheaper than CPU cycles and RAM these days?

Lots of enterprise customers are running important SPARC apps that continue to make them money.... but will never be ported to another OS (i.e. the original vendor went out of business, or the source code is otherwise unavailable). This is a way to let them get on new hardware (i.e. quad-core multi-socket x86 systems, still comparatively cheap compared to SPARC gear)... and even if they lose some efficiency it will likely still run at the same speed (or faster) since x86 has a price/performance advantage.

This is just a tiny step closer to the day when any program will run on any hardware.

Reply Score: 2