Solaris SPARC to x86 software highway opens 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 …
"QuickTransit for Solaris makes sense particularly for those ISVs that spent a lot of money creating software for SPARC servers during Sun's late 1990s boom."
What this means, presumably, is that they are not up to recompiling their packages for x86, because I don't imagine many people have written stuff in assembler in the last 20 years.
Or, in other words: either they have lost the sources, or they just can't be bothered running the toolchain again. Would you buy software from people in either of these camps?
No, what this is actually for is people who have licenses for SPARC packages and would like to avoid paying the license fee for the x86 versions.
It sounds like someone at Sun needs to ask some hard questions about its older customers and find out why they are doing things the way they do and why they are refusing to do things the Sun way. We use sparc hardware because its hardware stack makes stack bashing buffer overflow hacking much more difficult. We will not put Solaris 10 into production because its more of a hack job than engineered as well as being full of bloat that can not be removed. Its patch list reads like pre Beta software with all the recent essential security and stability patches. We buy Netra 210 because they are the only 1RU server they sell that will fit in our racks and still run a stable operating system.
Wow, old school purists are the reason why Sun and Transitive are teaming up again. It sounds like you are an older Sun customer wanting some TLC. Hmm, this Sun customer uses T Class chips running hardened Solaris 10 everywhere and we are a Financial institution. It just runs and runs secure no real problems 100% uptime :) I will give you the nod on the overall quality of Sun's patches as of late though.
So buckaroo really give Solaris 10 a try and leave your presumptions at the door. What would you rather run your stuff on? Windows when you have to move it? How about the dieing HP-UX biz? Linux...... Please.....
We will stick with Sun and Solaris for our mission critical applications; this UNIX admin sleeps well! Unless a boat full of money falls on my lap and we can look at AIX but that's not going to happen.
:)
Having spend time porting solaris code to x86, it is not as trivial a matter of just running the toolchain again.
The biggest problem is the endianness (reread gullivers travels to find out why that can be a problem).
other problems include code written using ancient C++ compilers, that will simple not compile with newer compilers (the beauty of standards, there are so many to choose from)
Oh, and missing 3rd party libraries (these again usually only have the most recent versions ported to x86, but if you want that flavour you linked against 20 years ago, tough luck, the ABI and API have changed at least 3 times since then)
As Solaris is source code compatible, press your software companies for a Solaris x86 port. The performance increases are impressive both against Solaris SPARC and other x86/x64 operating systems (even when not running anti-virus software). The reason not to provide a port could be a third party library which is not available but that library will be portable if you press your software vendor.
Trying to dodge paying for a new license going SPARC->x86 isn't really the issue -- I doubt this software is exactly cheap -- rather it's that many sites are running software that is no longer supported, either the vendor has kicked the bucket or they've simply decided it's too much like hard work to keep supporting it.
And in any event if you're buying smaller machines Sun is about to screw you over by dropping all the low-end UltraSPARC gear. All you'll have left is Niagra, and while I'm sure that's very nice for web servers it's not so hot for big chunky batch processing jobs. Being able to take your existing binaries and have them "just work" on something like an X4100 is a nice option to have.
Not that I'll believe this really works until I've seen it for myself, which may never happen as we're freeing ourselves from dependence on SPARC and moving as much as we can to Solaris on x64.
How you can have 100% uptime when you have to reboot the thing to apply critical patches every few weeks? One of our Solaris 9 boxes went 3 years without needing any patches that required a reboot due to its lean install of less than 10 packages. Our T1000 needs patches every few weeks for lots of really broken things so how can joe's be secure with no real problems if we are both running the same OS and same hardware?
Back to the topic, How will Transitive emulate the sparc security issues on a CPU that has problems? The openbsd guys have found a large list of access control problems on the latest x86 processors where things like page write protect may not work on some cores of a multi-core cpu sometimes.
1. ajs@sparcbox:~ $ scp /usr/src/app-v1.2.3.tar.gz amd64box:/usr/src/
2. ajs@amd64box:~ $ cd /usr/src
3. ajs@amd64box:/usr/src/ $ tar xzf app-v1.2.3.tar.gz
4. ajs@amd64box:/usr/src/ $ cd app-v1.2.3
5. ajs@amd64box:/usr/src/app-v1.2.3/ $ ./configure
6. ajs@amd64box:/usr/src/app-v1.2.3/ $ make
7. ajs@amd64box:/usr/src/app-v1.2.3/ $ su
8. ajs@amd64box:/usr/src/app-v1.2.3/ # make install
So go on ..... what else are you going to try to sell me, that I have already got one of?
My employer is a small business dealing with various multinationals often leading largsh (10Million plus alpha stage budget) projects. We decide what software and hardware is required (with the client) and we prove it will work during the design phase.
Sun *used* to be great - we would truck down to Camberley and they would let us profile POC/test cases etc. It gave the client a real feel good factor.
These days they will not even talk to us - we "do not have the turnover" to fit the "market profile" because the sales do not come direct through our books. Because we can no longer prove large distributed apps will work on Suns at design we now do one of two things.
1) run the proof of concept code on the clients big hardware
2) run the POC on our own big hardware (that is now linux)
If the clients see 2) they start to plan a Sun to Linux migration for existing projects running on end of life SUn hardware as well, so Sun loses two or more expected sales.
We sometimes get a call from one part of Sun once the project is underway (too late for them to get the sale back) asking us to rejoin the VAR program but as we do not "sell" Sun kit the Sun accountants then quickly drop us as a VAR again - until they lose another biggish project to linux :-(
We still have some big Sun Kit but it obsoletes so quickly these days.
I doubt this is about license costs. I see this as being about old app versions people never move off of, older software which is no longer supported, and lots of internal software where the source code was lost.
This is the Solaris market Transitive has been going after for several years.
The ability to put a low-utilization, emulated "SPARC box" into a VM on an x86 system is a good thing. Customers can finally decommission that dusty old SPARCstation 20 they were praying would not fail.
For those who want to run the app on a Niagara chip, Sun has Project Etude to allow hard-coded Solaris 8 apps to run in Solaris 10 Containers. But it looks like for all of the older Solaris versions (mostly 2.5.1 and 2.6), Sun will use Transitive's solution on both x86 and SPARC.
"....What would you rather run your stuff on? Windows when you have to move it? How about the dieing HP-UX biz? Linux...... Please....."
*cough*<IDC market figures>*cough*
Having used Transitive to get old in-house SPARC apps that in some case we don't even have the sourcecode for, as well as some apps which just didn't reach the right performance levels on APL, I can happily state that ALL such projects have run FASTER on Transitive on-top-of Red Hat on x86 or Itanium. And just to be clear, we only "do a tranny" for apps that are simply too much of a pig to port or are not licensed for Linux or hp-ux.
Yes. licencing does play a minor part, but in many cases we have code written in the 90's that has none or little documentation. Most has very poor commenting as consultants took the view in those days that if you didn't get paid to do neat/good commenting then you didn't, as it meant the buyer was often forced to come back to you for upgrades or changes. We even had one project that was so old the two coders that wrote the core code were dead! Nowadays we hammer out a tight scope for all coding work, but we have still been caught out with apps where the vendor has gone bust and we're faced with an expensive replacement or porting the code ourselves - Transitive is just such a cheap and simple option in comparison.
Sun is gradually morphing into a software house and it looks like it's as nasty a process from the inside as it is from the outside. It needs to keep it's old Solaris customers onboard whilst developing Solaris for new platforms - how long do you think it will be before they are supporting Solaris on Itanium openly? After all, Itanium has none of those nasty endian issues as it was designed as a porting platform and is equal-endian. Transitive support gives Sun the option to dump Rock and run for Power or Itanium should the latter get too late or just too expensive.
You don't *have* to apply critical patches every three weeks - it's entirely at your discretion, as it's always been. Solaris 10 patches have been issued more frequently because the OS is open, and as such issues are identified and resolved more quickly, in line with other open OSes. As always, if you can build the OS to your requirements, then do so. Building a core install and then adding what you need will reduce the problems as you won't have so much non-essential software installed. I also wouldn't deploy Live Update in a production environment if you require reliable uptimes: you decide when to deploy upgrades, not Sun.
This post has been deleted by its author
In our case, it's a simple lack of demand from customers. The Solaris x86 platform seems entirely credible from the technical point of view, but none of our customers seem to actually want it. Sun tell us that "loads of your customers want this", and we ask them to put the customers in touch. Nothing happens. We've been round this loop a few times now.
I suspect that Sun want the Transative stuff for (a) general flexibility, which is good, and (b) as bait to get customers onto the x86 platform. If it works, then, Sun probably hopes, the customers will ask their software suppliers to do the porting.
Have you tried asking Adobe for the code to Acrobat Reader?
now i know there are alternatives to Acrobat reader for viewing PDF's ... but if you need to check on signed PDF's there is no alternative (if anyone knows otherwise i would dearly like to be proved wrong)
We also have products from Oracle (and others) that are no longer maintained, and although they can be 'converted' do not run the same on x86 hardware, the solution we've found so far is to keep some sparc kit around for the trivial job of running those apps.
For us this is trivial, but for other people it might be mission critical ... although i have to say for 440 quid for the workstation version it might well be as cheap to buy some sparc kit, and it's definitely not worth it just to run arcoread :)
We do use a reduced package build and JASS. We strip "the bloat" out before we deploy. Our SLAs are defined on the application availability not the servers so much. We do patch on a annual basis and apply patches when we are affected by a security issue all be it very very rare. That said, we meet our SLA and for the most part we as of yet have had to drop a box because of a critical security patch that needed to be applied outside our one patch window. Most of the time we will look for workarounds before we result to rebooting the server outside our window. For the most part we update so things like Oracle are happy when we upgrade the databases so its two birds with one stone.
Yes i agree with you about Sol9 it easier but like everything else with time things become more complex. I just have to stand up and look over at the WIndows admins with their zombied looks when they play the monthly patch raffle to know us *NIX admins are in a much better place :)
Matt Bryant:
I assume your point was Linux not HP-UX. I think a search of the register will show you that HP is not a safe bet vs Sun, IBM and yes RH.
I'm not going to fan the UNIX vs LINUX debate if possible but you have your opinion and i have mine. Linux has a place in datacenters but not in ours. The reasons why people move away from UNIX to LINUX are diverse as the people that use it but the driving factor was price. Sun did themselves some great disservice by screwing clients royally before the .bust . They weren't alone, IBM and HP we dryhumping clients too. Now because of their actions we are seeing Sun have to realign on price and delivery to meet the LINUX challenge. HP where are they going? Some days it looks like they don't know never mind the clients. IBM, nice gear, pricey; nice OS pricey, LINUX sure lets go with the flow. Sun has the most to loose out of the 3, so they want to give you as many compelling solutions to upgrade even if you are stuck with a legacy app, yes?
I would be interested to know what the fortune 500 are using for dB/app/web servers these days. I'm sure everyone is in there. I would guess that the world != F500 Linux % though i've eaten my words before. Does someone know?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
