[Info-vax] OT: news from the trenches (re: Solaris)

[johnwallace4 at yahoo.co.uk]

On Wednesday, 11 March 2015 15:40:06 UTC, li... at openmailbox.org wrote:
> On Wed, 11 Mar 2015 10:27:48 -0400
> Stephen Hoffman via Info-vax <info-vax at rbnsn.com> wrote:
> 
> > On 2015-03-11 11:06:57 +0000, seasoned_geek said:
> > 
> > > Sadly, putting VMS on x86 will ensure it a market life of minutes, not 
> > > years. It is a special OS and needs a special kick booty chip. The 
> > > earlier comments in this thread about Solaris running faster and better 
> > > on SPARC T5 should provide a guiding light, but it won't. By all 
> > > accounts Solaris should have been long gone from the market by now, 
> > > but, a certain segment of the market cannot make do with Wal-mart 
> > > quality chips so Solaris continues.
> > > 
> > > VMS also serves a market segment which cannot make do with Wal-mart 
> > > quality chips. Porting VMS to Wal-mart quality chips ensures its 
> > > demise. Porting VMS to the Wal-mart quality x86 line is like feeding 
> > > chocolate to dogs. They beg for it, but for them it is fatal.
> > 
> > What's your alternative to x86-64 here?   How much will the "special 
> > kick booty chip" cost to produce and integrate?
> 
> There's a lot more wrong with Intel than can ever be fixed. I agree a good
> processor would be nice from a programmer's POV and from a healthy market
> POV.
> 
> SPARC is an open design. I don't know who's fabbing them today but if it
> isn't Oracle itself than there's no R&D cost in using SPARC chips. They're
> very good and they have some great features but they are not as fast as the
> fastest Intel chips. If that doesn't matter than SPARC is a great design
> with a lot going for it.
> 
> > As for SPARC and Solaris, Oracle's business is apparently contracting -- 
> > they're profitable and variously more profitable than they've been, but 
> > that's over fewer customers, per one of the more recent financial 
> > reports.
> 
> There has been some discussion on various Solaris mailing lists about all
> this. What you wrote is entirely intentional on Oracle's part. I would seem
> there is great ego involved and getting the bish fish with killer deals and
> ignoring small-mid sized companies is what it is all about now.
> 
> Oracle no longer markets or views SPARC as a general platform, it's only
> used as an appliance engine for EXA-boxes (Oracle database appliances, etc.)
> Solaris will eventually probably go away because of this "strategy." 
> 
> A shame, because Solaris is a nice OS and the servers are very well
> thought out and well made. OpenBoot is great. SPARC is a great platform.
> And Solaris really does run better on it than on X86. You can feel it.
> 
> -- 
> Please DO NOT COPY ME on mailing list replies. I read the mailing list.
> RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8  ACAA 557C 4B36 98E4 4D49


As Hoff noted, it's a long time since Itanic had any general RAS
(reliability availability serviceability) advantage over the rest of
the server processors and chipsets and infrastructure, whatever the 
IA64 puffery may historically have claimed.

Bear in mind that modern Xeons are not just faster versions of 8086,
(with all due respect to JF). They are Intel-manufactured versions of
chips based on the *AMD64* architecture. There are a *lot* of
*architectural* differences between generic x86-32 and new improved AMD64
(as implemented by Intel).

Many of those differences are around the way the hardware and software
work together to detect, manage, and where appropriate recover from,
errors in hardware and software.

Can't provide many instant references, sorry, though AMD have plenty of
AMD64 architecture documentation which goes into DEC-style detail. (Hmmm,
I wonder how that might have happened, from the company that once helped
bring you the nightmare which was Z8001/Z8002).

At a briefer level, one of the more interesting snippets I remember was
from a Sun chap working on error management in Solaris who basically
said AMD64 gave them everything they needed. See [1].

So if there are particular aspects of Intel Xeon kit that you feel
need special attention, readers might be interested to hear about them.
Similarly, if stuff is lacking in the surrounding chips that might be
found in a likely Proliant system. Most Proliants are way ahead, in
manageability and maybe RAS terms, of most VMS boxes in recent decades;
what they need is a capable OS to match.

Whether the industry standard peripherals have the same kind of error 
management capability as the DEC world used to expect is a different
question. But then maybe the choice comes down to industry standard
peripherals at industry standard prices, or DEC-style enhanced
peripherals (at enhanced prices??).

SPARC-specific discussion saved for another day.

Have a lot of fun.

[1] Sun blog quote from 2006:
https://blogs.oracle.com/gavinm/entry/amd_opteron_athlon64_turion64_fault

"In February we (the Solaris Kernel/RAS group) integrated the
"fma x64" project into Solaris Nevada, delivering Fault Management for
the AMD K8 family of chips (Athlon(TM) 64, Opteron(TM), Turion(TM) 64).
This brings fault management on the Solaris AMD64 platform for cpu and
memory up to par with that already present on Sun's current SPARC
platforms, and addresses one of the most-requested missing
functionalities required by customers [..pr snipped..]. The project, of
course, benefits all AMD 64-bit systems [on Solaris] not just those
from Sun. " (continues)