Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OpenSSL SSL1 release details, kit
339 views
Skip to first unread message
Stephen Hoffman
Dec 23, 2015, 8:13:39 AM12/23/15
to
If you're using OpenSSL on OpenVMS and have patch management access,
then go get the HPE ENCRYPT V2.2 kit that Mr. Main recently mentioned
as being available.
One of the dependencies that will be added prior to the download is the
SSL1 V1.0 kit. The SSL1 kit is not directly listed in the patch area,
and there's no obvious download posted.
Via the kit dependencies listing in the HPE download web page — your
HPE patch shopping cart — you can select the SSL1 kit, and can access
the SSL1 kit release notes.
From reading the SSL1 kit release notes, you'll find that the SSL1 kit
is based on OpenSSL 1.0-2c, and that there's a complete parallel
installation of OpenSSL using new SSL1$ logical names and related, and
there's a parallel directory structure.
Whether HPE is going to make the SSL1 kit available outside of the
support center is not yet known. It's not (yet?) posted at the HPE
OpenVMS OpenSSL web page. Y'all can easily get OpenSSL 1.0.2-current
for OpenVMS from other sources, and the canonical OpenSSL kits
themselves build on OpenVMS with little effort.
There will be various additional product and patch kits being releases
that are also dependent on the SSL1 kit.
It is not clear why the ENCRYPT V2.2 kit has picked up a dependency on
OpenSSL yet. That's a new dependency. The ENCRYPT patch kit release
notes do not indicate any details on why this dependency has been
added, though the kit release notes might.
I'll post up an article on the SSL1 kit and related over at the
HoffmanLabs web site — probably by sometime early next year, if not
sooner — as I get the kits downloaded, installed, release notes read,
APIs reviewed, and generally sort this out.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Soderholm
Dec 23, 2015, 8:26:10 AM12/23/15
to
> you'll find that the SSL1 kit is based on OpenSSL 1.0-2c...
Note that the WASD download page has a SSL kit based on 1.0-2e:
> OpenSSL 1.0.2e (3rd December 2015) release, specifically to
> support WASD. Requires a minimum of VMS V7.0. Note that WASD
> builds and runs against the HP SSL product if you prefer (as of
> OpenVMS V8.3, SSL is always installed with the operating system).
> See http://wasd.vsm.com.au/wasd_root/doc/features/features_0400.html
> for possible options.
About the latest WASD kit it also says:
> Note: these object modules cannot be linked against version 1.3 of
> HP SSL for OpenVMS. They can be linked against version 1.4, and
> against the more up-to-date WASD SSL package below.
And "below" in the last quote above refers to the 1.0.2e kit...
The link above to the WASD documentation has further information.
Jan-Erik.
"1.0.2e (3rd December 2015) release, specifically to support WASD."
http://wasd.vsm.com.au/wasd/
>
Craig A. Berry
Dec 23, 2015, 8:32:05 AM12/23/15
to
On 12/23/15 7:13 AM, Stephen Hoffman wrote:
> It is not clear why the ENCRYPT V2.2 kit has picked up a dependency on
> OpenSSL yet. That's a new dependency.
Really? I thought ENCRYPT was one of the things that had to be updated
> It is not clear why the ENCRYPT V2.2 kit has picked up a dependency on
> OpenSSL yet. That's a new dependency.
alongside a previous update to SSL. In fact the page at
<http://h71000.www7.hp.com/openvms/products/ssl/ssl.html> indicates as much.
There is also a new LDAP kit, but it depends on the latest SSL kit, not
SSL1.
Stephen Hoffman
Dec 23, 2015, 9:05:31 AM12/23/15
to
On 2015-12-23 13:32:03 +0000, Craig A. Berry said:
> On 12/23/15 7:13 AM, Stephen Hoffman wrote:
>
>> It is not clear why the ENCRYPT V2.2 kit has picked up a dependency on
>> OpenSSL yet. That's a new dependency.
>
> Really? I thought ENCRYPT was one of the things that had to be updated
> alongside a previous update to SSL. In fact the page at
> <http://h71000.www7.hp.com/openvms/products/ssl/ssl.html> indicates as much.
Okay. Okay; my bad. AFAIK, it's not a dependency that existed in
> On 12/23/15 7:13 AM, Stephen Hoffman wrote:
>
>> It is not clear why the ENCRYPT V2.2 kit has picked up a dependency on
>> OpenSSL yet. That's a new dependency.
>
> Really? I thought ENCRYPT was one of the things that had to be updated
> alongside a previous update to SSL. In fact the page at
> <http://h71000.www7.hp.com/openvms/products/ssl/ssl.html> indicates as much.
ENCRYPT itself with V8.4, as was released with OpenVMS. That
encryption support was once entirely separate from OpenSSL — ENCRYPT
was its own layered product kit up until very recently, and was
integrated. Any idea what the API or the overlap might be here?
> There is also a new LDAP kit, but it depends on the latest SSL kit, not SSL1.
subsequent releases, too. They're either going to have to figure out
how to migrate the SSL certificates to SSL1 within the upgrade, or
they're going to punt and ship a set of instructions to their
customers. Whether we see SSL and SSL1 installed together by the
upgrade?
Craig A. Berry
Dec 23, 2015, 10:50:29 AM12/23/15
to
On Wednesday, December 23, 2015 at 8:05:31 AM UTC-6, Stephen Hoffman wrote:
> On 2015-12-23 13:32:03 +0000, Craig A. Berry said:
>
> > On 12/23/15 7:13 AM, Stephen Hoffman wrote:
> >
> >> It is not clear why the ENCRYPT V2.2 kit has picked up a dependency on
> >> OpenSSL yet. That's a new dependency.
> >
> > Really? I thought ENCRYPT was one of the things that had to be updated
> > alongside a previous update to SSL. In fact the page at
> > <http://h71000.www7.hp.com/openvms/products/ssl/ssl.html> indicates as much.
>
> Okay. Okay; my bad. AFAIK, it's not a dependency that existed in
> ENCRYPT itself with V8.4, as was released with OpenVMS. That
> encryption support was once entirely separate from OpenSSL -- ENCRYPT
> On 2015-12-23 13:32:03 +0000, Craig A. Berry said:
>
> > On 12/23/15 7:13 AM, Stephen Hoffman wrote:
> >
> >> It is not clear why the ENCRYPT V2.2 kit has picked up a dependency on
> >> OpenSSL yet. That's a new dependency.
> >
> > Really? I thought ENCRYPT was one of the things that had to be updated
> > alongside a previous update to SSL. In fact the page at
> > <http://h71000.www7.hp.com/openvms/products/ssl/ssl.html> indicates as much.
>
> Okay. Okay; my bad. AFAIK, it's not a dependency that existed in
> ENCRYPT itself with V8.4, as was released with OpenVMS. That
> was its own layered product kit up until very recently, and was
> integrated. Any idea what the API or the overlap might be here?
Don't know, but my guess would be libcrypto for the key handling. The v8.4 Upgrade and Installation Manual says that SSL is installed automatically with v8.4 and may not be removed (section 7.9.4). You're quite right that ENCRYPT has been around for ages in some form (since 7.2?); they probably had it statically linked against some crypto library until they decided to include SSL with the base OS. I'm sure that seemed like a good idea at the time, but sometimes best practices run smack into unstable APIs and dependency headaches. Not that it's especially preferable to have each dependent product with varying (and variously insecure) versions of SSL. Which is what we now have with SSL and SSL1 and different versions of different products depending on one or the other.
> integrated. Any idea what the API or the overlap might be here?
Ian Miller
Dec 23, 2015, 11:34:28 AM12/23/15
to
The HP OpenVMS SSL web page will be updated at some point with the new kit http://h71000.www7.hp.com/openvms/products/ssl/ssl.html
If you use WBEM, SMH or OVO then there are new kits to use SSL1.
If you use WBEM, SMH or OVO then there are new kits to use SSL1.
Stephen Hoffman
Dec 23, 2015, 2:23:34 PM12/23/15
to
On 2015-12-23 15:50:26 +0000, Craig A. Berry said:
> ...they probably had it statically linked against some crypto library
I'd hoped that there'd be old bits and new bits kept in the SSL kit for
a transition window and with Rdb-style redirections for linking, and we
sort of have something like that. Sort of.
But then the OpenSSL retirement of 0.9.8 series was announced well in
advance, and here we are during what is often the year-end server
maintenance window, and with a brand-new and unfortunately
down-revision OpenSSL, and with an SSL1 kit that now requires changes
to local and other build procedures and/or redirecting system logical
names to link against the new version, and with two sets of logical
names to figure out which bits are in use, and there's a manual upgrade
sequence to move the certificates around.
Fun times.
> ...they probably had it statically linked against some crypto library
> until they decided to include SSL with the base OS. I'm sure that
> seemed like a good idea at the time, but sometimes best practices run
> smack into unstable APIs and dependency headaches. Not that it's
> especially preferable to have each dependent product with varying (and
> variously insecure) versions of SSL. Which is what we now have with
> SSL and SSL1 and different versions of different products depending on
> one or the other.
Ayup; the complexity of managing security on OpenVMS just increased.
> seemed like a good idea at the time, but sometimes best practices run
> smack into unstable APIs and dependency headaches. Not that it's
> especially preferable to have each dependent product with varying (and
> variously insecure) versions of SSL. Which is what we now have with
> SSL and SSL1 and different versions of different products depending on
> one or the other.
I'd hoped that there'd be old bits and new bits kept in the SSL kit for
a transition window and with Rdb-style redirections for linking, and we
sort of have something like that. Sort of.
But then the OpenSSL retirement of 0.9.8 series was announced well in
advance, and here we are during what is often the year-end server
maintenance window, and with a brand-new and unfortunately
down-revision OpenSSL, and with an SSL1 kit that now requires changes
to local and other build procedures and/or redirecting system logical
names to link against the new version, and with two sets of logical
names to figure out which bits are in use, and there's a manual upgrade
sequence to move the certificates around.
Fun times.
Steven Schweda
Dec 23, 2015, 5:53:02 PM12/23/15
to
> The HP OpenVMS SSL web page will be updated [...]
Potentially interesting would be a summary of the
VMS-specific changes made by HP to the real OpenSSL kit. As
a mere (hobbyist) peon, it may be a long time before I can
acquire any new HP SSL kit (source or other).
In particular, I'd like to know how the new logical names
are defined, what the new object libraries and/or shared
images are called, (and what's in them), whether anyone has
scrubbed "SSLROOT" from the sources, and such like.
I gather from the openssl-dev e-mail list that Mr. Levitte
is trying to automate the creation of VMS builders for
OpenSSL version 1.1.0, so now might be yet another
opportunity to decrease the divergence between what HP does
and what any other poor slob who downloads an OpenSSL source
kit must do.
Potentially interesting would be a summary of the
VMS-specific changes made by HP to the real OpenSSL kit. As
a mere (hobbyist) peon, it may be a long time before I can
acquire any new HP SSL kit (source or other).
In particular, I'd like to know how the new logical names
are defined, what the new object libraries and/or shared
images are called, (and what's in them), whether anyone has
scrubbed "SSLROOT" from the sources, and such like.
I gather from the openssl-dev e-mail list that Mr. Levitte
is trying to automate the creation of VMS builders for
OpenSSL version 1.1.0, so now might be yet another
opportunity to decrease the divergence between what HP does
and what any other poor slob who downloads an OpenSSL source
kit must do.
Craig A. Berry
Dec 23, 2015, 6:02:43 PM12/23/15
to
On 12/23/15 4:52 PM, Steven Schweda wrote:
> In particular, I'd like to know how the new logical names
> are defined, what the new object libraries and/or shared
> images are called, (and what's in them), whether anyone has
> scrubbed "SSLROOT" from the sources, and such like.
Don't know what's happened to the sources, but the filenames have all
> In particular, I'd like to know how the new logical names
> are defined, what the new object libraries and/or shared
> images are called, (and what's in them), whether anyone has
> scrubbed "SSLROOT" from the sources, and such like.
just had a "1" stuck on them:
$ dir sys$share:*ssl1*
Directory SYS$COMMON:[SYSLIB]
SSL1$LIBCRYPTO_SHR.EXE;1 SSL1$LIBCRYPTO_SHR32.EXE;1
SSL1$LIBSSL_SHR.EXE;1 SSL1$LIBSSL_SHR32.EXE;1
Total of 4 files.
$ dir sys$startup:*ssl1*.com
Directory SYS$COMMON:[SYS$STARTUP]
SSL1$SHUTDOWN.COM;1 SSL1$STARTUP.COM;1
Total of 2 files.
Same for logical names except for OPENSSL, which will point to whichever
kit whose startup procedure you have run most recently.
Stephen Hoffman
Dec 23, 2015, 6:19:39 PM12/23/15
to
On 2015-12-23 22:52:59 +0000, Steven Schweda said:
> In particular, I'd like to know how the new logical names are defined,
> what the new object libraries and/or shared images are called, (and
> what's in them), whether anyone has scrubbed "SSLROOT" from the
> sources, and such like.
Based on a very quick look, the logical names were changed from
> In particular, I'd like to know how the new logical names are defined,
> what the new object libraries and/or shared images are called, (and
> what's in them), whether anyone has scrubbed "SSLROOT" from the
> sources, and such like.
SSL${stuff} to SSL1${stuff}, the OPENSSL logical is still used (and now
potentially ambiguous), and I've not gotten as far as digging for any
SSLROOT references or such. There are more release notes to read, and
a test install pending.
David Froble
Dec 23, 2015, 10:55:08 PM12/23/15
to
I tried to google SSL1, got some guitar stuff.
Is SSL1 some different product, or, is it just HP's method of running 2 versions
on the same instance of VMS?
I'm sooo confused ...
Normal state of affairs ...
Steven Schweda
Dec 24, 2015, 3:24:47 AM12/24/15
to
> Is SSL1 some different product, or, is it just HP's method
> of running 2 versions on the same instance of VMS?
Apparently, It's just a different file-name prefix
> of running 2 versions on the same instance of VMS?
intended to differentiate old ("SSL$*") files from new
("SSL1$*").
Until relatively recently, an official OpenSSL kit would
name its VMS shared images "LIBCRYPTO.EXE" and "LIBSSL.EXE".
HP (long ago) had the good sense to tack "SSL$" onto the
front of those names to give some clue that the things were
somehow related to SSL. Starting around version 1.0.0e, the
OpenSSL (VMS) builders were changed to use HP-like names
(with "SSL_" instead of "SSL$").
Some months ago, I sent openssl-dev a suggestion for some
changes to deal with the SSLROOT problem, but that seems to
have sunk without a trace. HP could fix it pretty easily,
too, but I don't know if that was done, or if the old
work-around ("DEFINE SSLROOT SSL$ROOT") is still needed.
Neil Rieck
Dec 24, 2015, 10:00:14 AM12/24/15
to
Neil Rieck
Waterloo, Ontario, Canada.
p.s. Last week I was talking to an employee in OpenVMS support at HPE regarding CSWS and they are aware of the numerous security issues regarding SSL/OpenSSL on the net (adding TLS support beyond 1.0, dropping RC4, increasing the minimum size of public keys to 2048, etc.) It is too bad that they still require a support contract for a lot of this stuff. Why? We dropped support for "OpenVMS on Alpha" to justify the business case of moving to "OpenVMS on Itanium". I now have one Alpha on the public internet which needs to upgrade (for security reasons) from a fully patched CSWS-2.2 to CSWS-2.2-1 but the current version of 2.2-1 requires stream_lf formatted text files and you need a support contract to get the patch. It would sure be a nice Christmas gift to the OpenVMS community if they rolled out all the patches for 2.2-1 at their free download area.
question: VSI has announced a new version of Apache based upon ver 2.4. Does anyone know if it will be linked to run on OpenVMS-8.4 or will you need to be running 8.4-H1? Will they be offering this for free or will you need a VSI support agreement?
Robert A. Brooks
Dec 24, 2015, 8:58:54 PM12/24/15
to
On 12/24/2015 10:00 AM, Neil Rieck wrote:
> question: VSI has announced a new version of Apache based upon ver 2.4. Does
> anyone know if it will be linked to run on OpenVMS-8.4 or will you need to be
> running 8.4-H1? Will they be offering this for free or will you need a VSI
> support agreement?
I would be surprised if we'd offer it for free.
> question: VSI has announced a new version of Apache based upon ver 2.4. Does
> anyone know if it will be linked to run on OpenVMS-8.4 or will you need to be
> running 8.4-H1? Will they be offering this for free or will you need a VSI
> support agreement?
We need to do whatever we can to differentiate ourselves from HPE and
HPE's VMS V8.4 in order to encourage folks to upgrade to our version
of VMS and layered products.
The enhancements we've made for V8.4-1H1 and V8.4-2 are not available on HPE's V8.4.
--
-- Rob
David Froble
Dec 25, 2015, 12:10:48 AM12/25/15
to
it would be good for them to do whatever necessary to get people on support
contracts.
I'm aware VSI cannot spread themselves too thin, but if the new TCP/IP and SSL
and such can run on Alpha, that could be some low hanging fruit.
Neil Rieck
Dec 25, 2015, 9:06:58 AM12/25/15
to
On Thursday, December 24, 2015 at 8:58:54 PM UTC-5, Robert A. Brooks wrote:
> On 12/24/2015 10:00 AM, Neil Rieck wrote:
>
> [...snip...]
> On 12/24/2015 10:00 AM, Neil Rieck wrote:
>
> -- Rob
question: In the beginning we all heard that HP (now HPE) would be selling licenses for V8.4-1H1 so would they also be selling VSI support?
speculation: I forget where I saw this but I was under the impression that HPE was no longer allowed to sell Tukwila-based platforms after 2015. (or perhaps Intel is no longer going to supply Tukwila packages for new system use). Anyway, if HPE begins shipping Poulson-based platforms then V8.4-1H1 will be the only game in town which will be good news for VSI
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
Neil Rieck
Dec 25, 2015, 9:15:45 AM12/25/15
to
Robert A. Brooks
Dec 25, 2015, 12:05:05 PM12/25/15
to
On 12/25/2015 9:06 AM, Neil Rieck wrote:
> On Thursday, December 24, 2015 at 8:58:54 PM UTC-5, Robert A. Brooks wrote:
>> On 12/24/2015 10:00 AM, Neil Rieck wrote:
>>
>> [...snip...] -- Rob
>
> question: In the beginning we all heard that HP (now HPE) would be selling
> licenses for V8.4-1H1 so would they also be selling VSI support?
Correct. You can purchase licenses for VSI software and/or VSI support
> On Thursday, December 24, 2015 at 8:58:54 PM UTC-5, Robert A. Brooks wrote:
>> On 12/24/2015 10:00 AM, Neil Rieck wrote:
>>
>> [...snip...] -- Rob
>
> question: In the beginning we all heard that HP (now HPE) would be selling
> licenses for V8.4-1H1 so would they also be selling VSI support?
from VSI directly, or through HPE.
> speculation: I forget where I saw this but I was under the impression that
> HPE was no longer allowed to sell Tukwila-based platforms after 2015. (or
> perhaps Intel is no longer going to supply Tukwila packages for new system
> use).
that HPE will only sell IA64 i4 (Poulson) starting in 2016. Whether
it's an Intel supply issue or an HPE choice, I'm not sure.
--
-- Rob
Neil Rieck
Dec 26, 2015, 11:41:14 AM12/26/15
to
On Friday, December 25, 2015 at 12:05:05 PM UTC-5, Robert A. Brooks wrote:
[...snip...]
[...snip...]
>
> > speculation: I forget where I saw this but I was under the impression that
> > HPE was no longer allowed to sell Tukwila-based platforms after 2015. (or
> > perhaps Intel is no longer going to supply Tukwila packages for new system
> > use).
>
> "Allowed to sell" may be somewhat misleading, but it's my understanding
> that HPE will only sell IA64 i4 (Poulson) starting in 2016. Whether
> it's an Intel supply issue or an HPE choice, I'm not sure.
>
> --
> -- Rob
That should be good news for VSI since V8.4-1H1 is qualified to run on Poulson while vanilla 8.4 is not. Perhaps VSI will see much more business come their way.
> > speculation: I forget where I saw this but I was under the impression that
> > HPE was no longer allowed to sell Tukwila-based platforms after 2015. (or
> > perhaps Intel is no longer going to supply Tukwila packages for new system
> > use).
>
> "Allowed to sell" may be somewhat misleading, but it's my understanding
> that HPE will only sell IA64 i4 (Poulson) starting in 2016. Whether
> it's an Intel supply issue or an HPE choice, I'm not sure.
>
> --
> -- Rob
Jan-Erik Soderholm
Dec 26, 2015, 1:09:51 PM12/26/15
to
Den 2015-12-26 kl. 17:41, skrev Neil Rieck:
> On Friday, December 25, 2015 at 12:05:05 PM UTC-5, Robert A. Brooks
> wrote: [...snip...]
>>
>>> speculation: I forget where I saw this but I was under the
>>> impression that HPE was no longer allowed to sell Tukwila-based
>>> platforms after 2015. (or perhaps Intel is no longer going to supply
>>> Tukwila packages for new system use).
>>
>> "Allowed to sell" may be somewhat misleading, but it's my
>> understanding that HPE will only sell IA64 i4 (Poulson) starting in
>> 2016. Whether it's an Intel supply issue or an HPE choice, I'm not
>> sure.
>>
>> -- -- Rob
>
> That should be good news for VSI since V8.4-1H1 is qualified to run on
> Poulson while vanilla 8.4 is not. Perhaps VSI will see much more
> business come their way.
>
Interesting that HP(E) still only lists HP-UX under "Operating Systems"
> On Friday, December 25, 2015 at 12:05:05 PM UTC-5, Robert A. Brooks
> wrote: [...snip...]
>>
>>> speculation: I forget where I saw this but I was under the
>>> impression that HPE was no longer allowed to sell Tukwila-based
>>> platforms after 2015. (or perhaps Intel is no longer going to supply
>>> Tukwila packages for new system use).
>>
>> "Allowed to sell" may be somewhat misleading, but it's my
>> understanding that HPE will only sell IA64 i4 (Poulson) starting in
>> 2016. Whether it's an Intel supply issue or an HPE choice, I'm not
>> sure.
>>
>> -- -- Rob
>
> That should be good news for VSI since V8.4-1H1 is qualified to run on
> Poulson while vanilla 8.4 is not. Perhaps VSI will see much more
> business come their way.
>
for the rx2800 i4 server. The i2 also has VMS and Nonstop...
Same with the blades. VMS only for the BL870c i2, not for the three
BL8x0c i4 variants.
They have had half a year to update their product pages, after all.
John Reagan
Dec 26, 2015, 3:08:00 PM12/26/15
to
Jan-Erik Soderholm
Dec 26, 2015, 6:55:55 PM12/26/15
to
product page for the rx2600 i4 then... :-)
Neil Rieck
Dec 31, 2015, 2:39:57 PM12/31/15
to
I am really confused by the use of "i2" vs. "i4" so perhaps you could set me/us straight. I was under the impression that the "i-number" indicated the number of sockets. But when I look at this spec for the rx2800-i4
http://www8.hp.com/h20195/v2/GetPDF.aspx/c04111437.pdf
it says that the machine in question only has two sockets.
Question: is it correct to assume that i2 means Tukwila while i4 means Poulson?
Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
Stephen Hoffman
Dec 31, 2015, 4:02:37 PM12/31/15
to
On 2015-12-31 19:39:53 +0000, Neil Rieck said:
> I am really confused by the use of "i2" vs. "i4" so perhaps you could
> set me/us straight.
i2 is marketing for Tukwila; the Intel Itanium 9300 series.
> I am really confused by the use of "i2" vs. "i4" so perhaps you could
> set me/us straight.
i4 is marketing for Poulson; the Intel Itanium 9500 series.
The next-generation Kittson servers — if (when?) those arrive — will
therefore clearly be named the HPE Integrity CloudServer Enterprise
Next i42 servers, of course.
> I was under the impression that the "i-number" indicated the number of sockets.
> But when I look at this spec for the rx2800-i4 ... it says that the
> machine in question only has two sockets.
Ayup; two sockets in that rx2800 series.
The c-class BL-prefix blade boxes can have 2, 4 or 8 sockets.
The Superdome SD-class and Superdome 2 SD2-class blade boxes can have
rather more than that.
> Question: is it correct to assume that i2 means Tukwila while i4 means Poulson?
the future, though? Integrity has been reused to mean x86-64 boxes
with the Superdome X series, for instance.
Different Integrity servers can be part-populated, and populated with
processors with different core counts. Some Integrity servers can
have varying configurations, too, and it's supported to have a mix of
x86-64 processors and Integrity Itanium processors in the c-class BL
blade boxes.
Related: https://en.wikipedia.org/wiki/HP_Integrity_Servers
Neil Rieck
Jan 2, 2016, 10:01:46 AM1/2/16
to
Thanks. Many times I wonder what marketing people are smoking. I'd bet some of their smoke that a Kittson-based rx2800 will be called "i8"
:-)
:-)
Stephen Hoffman
Jan 2, 2016, 11:59:33 AM1/2/16
to
On 2016-01-02 15:01:40 +0000, Neil Rieck said:
I'll presume this is a reply to my posting, based on what I see in the
headers, and over in Google Gorps.
> Thanks. Many times I wonder what marketing people are smoking. I'd bet
> some of their smoke that a Kittson-based rx2800 will be called "i8"
Could also be i6 or, yes, i8, or — probably more likely — the HPE
marketing folks are going to diverge from the old HP product norms and
nomenclature. They're already drawing those teal-colored text-input
boxes everywhere, after all. The pressure to re-brand and to
differentiate is large. Yes, I do hope somebody will add a flashing
text cursor into one of those new HPE teal logo boxes, too.
I'll presume this is a reply to my posting, based on what I see in the
headers, and over in Google Gorps.
> Thanks. Many times I wonder what marketing people are smoking. I'd bet
> some of their smoke that a Kittson-based rx2800 will be called "i8"
marketing folks are going to diverge from the old HP product norms and
nomenclature. They're already drawing those teal-colored text-input
boxes everywhere, after all. The pressure to re-brand and to
differentiate is large. Yes, I do hope somebody will add a flashing
text cursor into one of those new HPE teal logo boxes, too.
0 new messages