Dear friends of VMS,

We suppose you enjoyed the VSI webinar of today. All of us too.

We have just posted today the report(s) of our last "rendez-vous autour
de VMS".

The detailed report is translated in english. The slides from IMPERVA
about security directive NIS2, and from COMMVAULT about their products
are mostly in english.

Have a look:
https://www.vmsgenerations.fr/rendez-vous-autour-de-vms-du-6-fevrier-2024/

Our candle for Camiel and Darya is lit :)

VMSgenerations working group

On 4/17/2024 5:27 PM, vmsgenerations wrote:
> We have just posted today the report(s) of our last "rendez-vous autour
> de VMS".
>
> The detailed report is translated in english. The slides from IMPERVA
> about security directive NIS2, and from COMMVAULT  about their products
> are mostly in english.
>
> Have a look:
> https://www.vmsgenerations.fr/rendez-vous-autour-de-vms-du-6-fevrier-2024/

A few things I consider important:

<quote>
- a general security initiative is underway at VSI :
- for HITRUST certification is targetted in spring
- CVE reporting program
- partial NIST-2 compliance
- study for ISO 27001 certification
</quote>

sounds good.

<quote>
"X86 is the future of VMS, so the sooner you start thinking about
migration the better. We're
sharing links to all the resources to help you. We look forward to
helping you with your
migration".
....
Q: Examples of migration to x86?
....
A: HF: Yes, around 80 to 100 customers in the evaluation, test or
migration phase.
</quote>

That number need to x10 in 2024.

<quote>
R DZ: Can you explain the type of collaboration you're expecting?
R GC: Python example: no collaboration with one of the French
specialists (JFP). We ended
up with two channels that were moving forward without collaborating. We
had problems
receiving sources in a standard format. There are now opensource
products in the VSI
catalog, and it would be great to be able to participate in development
as we do with any
other opensource. Currently, participation in opensource development
related to VMS is
virtually closed. It's different from standard opensource. With VSI, the
answer is "we don't
have the resources to do it". VSI has been around for 10 years... it's
time to change that
</quote>

I think this is important.

It may be time-consuming and VSI has limited resources, but given
that >70% of code used in modern solutions is open source code
and because VSI has limited resources, then it very important
for VSI to get the VMS open source collaboration working!!

Arne

On Wed, 17 Apr 2024 19:56:23 -0400, Arne Vajhøj wrote:

> <quote>
> "X86 is the future of VMS ..."

Just in time for x86 to no longer be quite at the forefront of server
computing, or even computing generally. ARM is having more of a presence,
and RISC-V is not far behind.

On 4/17/2024 9:36 PM, Lawrence D'Oliveiro wrote:
> On Wed, 17 Apr 2024 19:56:23 -0400, Arne Vajhøj wrote:
>
>> <quote>
>> "X86 is the future of VMS ..."
>
> Just in time for x86 to no longer be quite at the forefront of server
> computing, or even computing generally. ARM is having more of a presence,
> and RISC-V is not far behind.

x86-64 must still have liked a 90-95% market share in servers. Enough
for VMS.

It may be very different in 10 years. Who knows.

But VMS could not wait years for a new CPU. Itanium development
stalled around 2012. The last Itanium CPU's was shipped in 2021.

Arne

On Wed, 17 Apr 2024 22:27:58 -0400, Arne Vajhøj wrote:

> But VMS could not wait years for a new CPU.

VMS wasn’t “waiting” for anything. It was customers waiting for VMS.

On 2024-04-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
><quote>
> - CVE reporting program

About bloody time. :-(

VSI should have done this as soon as they started shipping products.

Don't forget these are the same jokers who _finally_ introduced a
public security reporting mechanism in the immediate aftermath of
the DCL issue and then silently removed it from their website some
time later after the fuss had died down. :-(

I can't even begin to imagine the mentality of people who think that
was an appropriate thing to do.

I wonder what has driven this sudden change and if this will be more
permanent than it was the last time around ?

[snip]

>
> It may be time-consuming and VSI has limited resources, but given
> that >70% of code used in modern solutions is open source code
> and because VSI has limited resources, then it very important
> for VSI to get the VMS open source collaboration working!!
>

Don't forget that they now ship Perl as part of the x86-64 kit and
that was only possible because of the work Craig has put into making
the public distribution continue to work on VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Simon Clubley schrieb am 18.04.2024 um 14:23:
> On 2024-04-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> <quote>
>> - CVE reporting program
>
> About bloody time. :-(
>
> VSI should have done this [...]

A simple "thank you, I've been waiting for this" would have been
sufficient... :-)

> Simon.

Hans.

On 2024-04-18, Hans Bachner <hans@bachner.priv.at> wrote:
> Simon Clubley schrieb am 18.04.2024 um 14:23:
>> On 2024-04-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> <quote>
>>> - CVE reporting program
>>
>> About bloody time. :-(
>>
>> VSI should have done this [...]
>
> A simple "thank you, I've been waiting for this" would have been
> sufficient... :-)
>

Well Hans, there are certain optional things a company can do, and
there are certain expected things the same company _should_ have already
done, especially when they go around claiming that they sell the most
secure operating system on the planet. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <uvptfj$2126r$2@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:

> Just in time for x86 to no longer be quite at the forefront of
> server computing, or even computing generally. ARM is having more
> of a presence, and RISC-V is not far behind.

x86 is still running a vast majority of server workloads, and
organisation that are running VMS tend to be conservative. Also, when the
x86 port started, Aarch64 was way too new to depend on for a server OS
and RISC-V was in its infancy.

It's still the case that there is a very limited range of Aarch64 server
hardware available for on-premises use, and virtualisation for it is
pretty new. I've been porting and building software for Aarch64 Linux for
a few years, and the ecosystem is nowhere near as mature as x86.

As for RISC-V, who is offering RISC-V 64-bit servers or cloud instances
as of now? I count Scaleway, since early March, but they're bare metal
servers, *not* Linux ready to run. RISC-V has a lot of hype, somewhat
questionable potential, and not very much in service that's suitable for
VMS.

John

On 4/18/2024 10:50 AM, Hans Bachner wrote:
> Simon Clubley schrieb am 18.04.2024 um 14:23:
>> On 2024-04-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> <quote>
>>> - CVE reporting program
>>
>> About bloody time. :-(
>>
>> VSI should have done this [...]
>
> A simple "thank you, I've been waiting for this" would have been
> sufficient...   :-)

For some people the glass is half empty not half full.

Arne

On 4/18/2024 8:23 AM, Simon Clubley wrote:
> On 2024-04-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> It may be time-consuming and VSI has limited resources, but given
>> that >70% of code used in modern solutions is open source code
>> and because VSI has limited resources, then it very important
>> for VSI to get the VMS open source collaboration working!!
>
> Don't forget that they now ship Perl as part of the x86-64 kit and
> that was only possible because of the work Craig has put into making
> the public distribution continue to work on VMS.

If I have understood that context correctly, then the end
result is all good, but not really collaboration.

Arne

On 4/17/2024 11:29 PM, Lawrence D'Oliveiro wrote:
> On Wed, 17 Apr 2024 22:27:58 -0400, Arne Vajhøj wrote:
>> But VMS could not wait years for a new CPU.
>
> VMS wasn’t “waiting” for anything. It was customers waiting for VMS.

Yes. Because VSI ported to a CPU that was ready. Instead of to a CPU
that may be ready some day in the future.

Arne

On Thu, 18 Apr 2024 14:49:22 -0400, Arne Vajhøj wrote:

> Because VSI ported to a CPU that was ready.

Pity the same cannot be said of the port itself ...

On Thu, 18 Apr 2024 19:00 +0100 (BST), John Dallman wrote:

> Also, when the x86 port started, Aarch64 was way too new to depend on
> for a server OS and RISC-V was in its infancy.

That’s reinforcing my point, about how long ago that was.

On 18/4/24 22:23, Simon Clubley wrote:

> I wonder what has driven this sudden change and if this will be more
> permanent than it was the last time around ?

It's odd it's not there. Corporate insurance for 'cyber' issues,
absolutely vital in any banking or finance environment. You need to be
able to demonstrate you have clear standards for managing CVE issues
that Qualys or Tenable throw at you, or else. The CVE industry is just a
snake farm, nevertheless it's not something you can ignore.

--
motk

In article <uvrpvg$2dbgu$3@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/17/2024 11:29 PM, Lawrence D'Oliveiro wrote:
>> On Wed, 17 Apr 2024 22:27:58 -0400, Arne Vajhøj wrote:
>>> But VMS could not wait years for a new CPU.
>>
>> VMS wasn’t “waiting” for anything. It was customers waiting for VMS.
>
>Yes. Because VSI ported to a CPU that was ready. Instead of to a CPU
>that may be ready some day in the future.

ARM is ready right now. But that's irrelevant;
we'll be dealing with x86 for the next 20 to
30 years, at least. It may loss it's position
as #1 in 10, but it's not going away any time
soon.

- Dan C.

On 4/18/24 1:48 PM, Arne Vajhøj wrote:
> On 4/18/2024 8:23 AM, Simon Clubley wrote:
>> On 2024-04-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> It may be time-consuming and VSI has limited resources, but given
>>> that >70% of code used in modern solutions is open source code
>>> and because VSI has limited resources, then it very important
>>> for VSI to get the VMS open source collaboration working!!
>>
>> Don't forget that they now ship Perl as part of the x86-64 kit and
>> that was only possible because of the work Craig has put into making
>> the public distribution continue to work on VMS.
>
> If I have understood that context correctly, then the end
> result is all good, but not really collaboration.

Yes and no. I've had cordial correspondence with one of the engineers
and traded tips about some of the initial problems building Perl on x86.
Before that we had exchanges about their adding signing information to
my kits for Alpha and Itanium and releasing those with my blessing.
These things could be construed as a form of collaboration, but mainly
in kitting and distribution, not in porting or maintaining.

But the story with Perl is probably not a model to follow for other
things. I suspect what happened with Perl is that some of the cooks
wanted a longer spoon to stir the soup they were making and just grabbed
one they happened to like, and it's hard to keep the cooks from choosing
some of the tools for their kitchen. There's nothing wrong with that,
but there are other reasons to choose packages worth porting or
distributing, and there are a lot of other things that will be necessary
to create, at the risk of a cliché, an open source ecosystem.

Probably the most important thing for VSI related to open source is to
focus on the basic enabling features that only they can do. That means
finishing SSIO, finishing or reimplementing named pipes, implementing
pthread_sigmask (which is not just a function call but a whole threads +
signals thing), implementing posix_spawn(), implementing a pipe() that
is truly both unbuffered and stream-oriented, and implementing 64-bit
versions of all the CRTL functions that don't have them yet as well as
the system and library calls that are still 32-bit only (yes,
sys$filescan, I'm looking at you). This off the top of my head and no
doubt leaving out a lot of things.

There is probably not much room for collaboration with such core
infrastructure, but something akin to GNV or analogous toolset will be
necessary as well in order to build anything else, and there always have
been at least a few people willing to participate in porting and
maintaining those things.

Higher up the application chain, better collaboration seems both
possible and necessary. I infer from reports of the recent French
workshop that JFP and VSI were both working on getting Python onto x86
but without collaborating. Oops. Lets hope that gets sorted out, and
that when VSI is looking at maintaining ports of PHP, or OpenSSL, or
whatever, that it works with the people who are already doing those things.

In article <uvpnj8$1sbff$1@dont-email.me>, arne@vajhoej.dk says...
>
> On 4/17/2024 5:27 PM, vmsgenerations wrote:
> > We have just posted today the report(s) of our last "rendez-vous autour
> > de VMS".
> >
> > The detailed report is translated in english. The slides from IMPERVA
> > about security directive NIS2, and from COMMVAULT  about their products
> > are mostly in english.
> >
> > Have a look:
> > https://www.vmsgenerations.fr/rendez-vous-autour-de-vms-du-6-fevrier-2024/
>
> A few things I consider important:
>
> <quote>
> - a general security initiative is underway at VSI :
> - for HITRUST certification is targetted in spring
> - CVE reporting program
> - partial NIST-2 compliance
> - study for ISO 27001 certification
> </quote>
>
> sounds good.
>
> <quote>
> "X86 is the future of VMS, so the sooner you start thinking about
> migration the better. We're
> sharing links to all the resources to help you. We look forward to
> helping you with your
> migration".
> ...
> Q: Examples of migration to x86?
> ...
> A: HF: Yes, around 80 to 100 customers in the evaluation, test or
> migration phase.
> </quote>
>
> That number need to x10 in 2024.
>
> <quote>
> R DZ: Can you explain the type of collaboration you're expecting?
> R GC: Python example: no collaboration with one of the French
> specialists (JFP). We ended
> up with two channels that were moving forward without collaborating. We
> had problems
> receiving sources in a standard format. There are now opensource
> products in the VSI
> catalog, and it would be great to be able to participate in development
> as we do with any
> other opensource. Currently, participation in opensource development
> related to VMS is
> virtually closed. It's different from standard opensource. With VSI, the
> answer is "we don't
> have the resources to do it". VSI has been around for 10 years... it's
> time to change that
> </quote>
>
> I think this is important.
>
> It may be time-consuming and VSI has limited resources, but given
> that >70% of code used in modern solutions is open source code
> and because VSI has limited resources, then it very important
> for VSI to get the VMS open source collaboration working!!

Shame they seem to be actively working in the opposite direction. The
current licensing situation isn't likely to encourage any sort of open-
source community to form so if its important they're probably going to
have to do it themselves.

On 4/18/2024 10:19 PM, Craig A. Berry wrote:
> On 4/18/24 1:48 PM, Arne Vajhøj wrote:
>> On 4/18/2024 8:23 AM, Simon Clubley wrote:
>>> On 2024-04-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> It may be time-consuming and VSI has limited resources, but given
>>>> that >70% of code used in modern solutions is open source code
>>>> and because VSI has limited resources, then it very important
>>>> for VSI to get the VMS open source collaboration working!!
>>>
>>> Don't forget that they now ship Perl as part of the x86-64 kit and
>>> that was only possible because of the work Craig has put into making
>>> the public distribution continue to work on VMS.
>>
>> If I have understood that context correctly, then the end
>> result is all good, but not really collaboration.
>
> Yes and no.  I've had cordial correspondence with one of the engineers
> and traded tips about some of the initial problems building Perl on x86.
> Before that we had exchanges about their adding signing information to
> my kits for Alpha and Itanium and releasing those with my blessing.
> These things could be construed as a form of collaboration, but mainly
> in kitting and distribution, not in porting or maintaining.
>
> But the story with Perl is probably not a model to follow for other
> things.  I suspect what happened with Perl is that some of the cooks
> wanted a longer spoon to stir the soup they were making and just grabbed
> one they happened to like, and it's hard to keep the cooks from choosing
> some of the tools for their kitchen.  There's nothing wrong with that,
> but there are other reasons to choose packages worth porting or
> distributing, and there are a lot of other things that will be necessary
> to create, at the risk of a cliché, an open source ecosystem.

> Higher up the application chain, better collaboration seems both
> possible and necessary.  I infer from reports of the recent French
> workshop that JFP and VSI were both working on getting Python onto x86
> but without collaborating.  Oops.  Lets hope that gets sorted out, and
> that when VSI is looking at maintaining ports of PHP, or OpenSSL, or
> whatever, that it works with the people who are already doing those things.

To me it seems like first step is to have a single source repo.

Optimal:
* single upstream repo
* both VSI contributors and community contributors use that
* community contributors can do a build and distribute a ZIP
* VSI can do a build and distribute a PCSI kit for those customers
that only install VSI approved software on their VMS system
(I suspect that mentality will be dying out, but there are probably
still some left)

Almost optimal:
* upstream repo
* VMS repo shared by VSI contributors and community contributors
* community contributors can do a build and distribute a ZIP
that everyone can grab
* VSI can do a build and distribute a PCSI kit for those customers
that only install VSI approved software on their VMS system
(I suspect that mentality will be dying out, but there are probably
still some left)

Disaster:
* upstream repo
* VSI repo used by VSI contributors
* N repo's used by N community contributors
* signficant differences between builds from different repos

> Probably the most important thing for VSI related to open source is to
> focus on the basic enabling features that only they can do. That means
> finishing SSIO, finishing or reimplementing named pipes, implementing
> pthread_sigmask (which is not just a function call but a whole threads +
> signals thing), implementing posix_spawn(), implementing a pipe() that
> is truly both unbuffered and stream-oriented, and implementing 64-bit
> versions of all the CRTL functions that don't have them yet as well as
> the system and library calls that are still 32-bit only (yes,
> sys$filescan, I'm looking at you). This off the top of my head and no
> doubt leaving out a lot of things.
>
> There is probably not much room for collaboration with such core
> infrastructure, but something akin to GNV or analogous toolset will be
> necessary as well in order to build anything else, and there always have
> been at least a few people willing to participate in porting and
> maintaining those things.

The required OS and compiler functionality to support (mostly)
open source C code coming from *nix world is obviously on VSI.

The good thing is that it is limited in scope. The bad thing is
that some of this can be tricky if the desired functionality
is based on *nix system design and does not really fit well with
VMS system design.

Arne

On 4/18/2024 7:05 PM, Dan Cross wrote:
> In article <uvrpvg$2dbgu$3@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/17/2024 11:29 PM, Lawrence D'Oliveiro wrote:
>>> On Wed, 17 Apr 2024 22:27:58 -0400, Arne Vajhøj wrote:
>>>> But VMS could not wait years for a new CPU.
>>>
>>> VMS wasn’t “waiting” for anything. It was customers waiting for VMS.
>>
>> Yes. Because VSI ported to a CPU that was ready. Instead of to a CPU
>> that may be ready some day in the future.
>
> ARM is ready right now.

You can buy an ARM server or rent an ARM VM in a public
cloud if you search for it.

But very few of the VMS customers will have ARM servers
or ARM VM's today.

So even though ARM would have been better than Itanium,
because it is possible to buy a new one, then it would
still have been a market disaster as VMS would still be
"that weird OS that requires different HW than the
rest of our stuff".

Arne

In article <uvttut$31g69$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/18/2024 7:05 PM, Dan Cross wrote:
>> In article <uvrpvg$2dbgu$3@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 4/17/2024 11:29 PM, Lawrence D'Oliveiro wrote:
>>>> On Wed, 17 Apr 2024 22:27:58 -0400, Arne Vajhøj wrote:
>>>>> But VMS could not wait years for a new CPU.
>>>>
>>>> VMS wasn’t “waiting” for anything. It was customers waiting for VMS.
>>>
>>> Yes. Because VSI ported to a CPU that was ready. Instead of to a CPU
>>> that may be ready some day in the future.
>>
>> ARM is ready right now.
>
>You can buy an ARM server or rent an ARM VM in a public
>cloud if you search for it.
>
>But very few of the VMS customers will have ARM servers
>or ARM VM's today.
>
>So even though ARM would have been better than Itanium,
>because it is possible to buy a new one, then it would
>still have been a market disaster as VMS would still be
>"that weird OS that requires different HW than the
>rest of our stuff".

I see you omitted the rest of my post in which I
largely agreed with you. The point was that you are
mistaken in asserting earlier that ARM is not ready.
It absolutely is.

- Dan C.

On 4/19/2024 11:51 AM, Dan Cross wrote:
> In article <uvttut$31g69$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/18/2024 7:05 PM, Dan Cross wrote:
>>> In article <uvrpvg$2dbgu$3@dont-email.me>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 4/17/2024 11:29 PM, Lawrence D'Oliveiro wrote:
>>>>> On Wed, 17 Apr 2024 22:27:58 -0400, Arne Vajhøj wrote:
>>>>>> But VMS could not wait years for a new CPU.
>>>>>
>>>>> VMS wasn’t “waiting” for anything. It was customers waiting for VMS.
>>>>
>>>> Yes. Because VSI ported to a CPU that was ready. Instead of to a CPU
>>>> that may be ready some day in the future.
>>>
>>> ARM is ready right now.
>>
>> You can buy an ARM server or rent an ARM VM in a public
>> cloud if you search for it.
>>
>> But very few of the VMS customers will have ARM servers
>> or ARM VM's today.
>>
>> So even though ARM would have been better than Itanium,
>> because it is possible to buy a new one, then it would
>> still have been a market disaster as VMS would still be
>> "that weird OS that requires different HW than the
>> rest of our stuff".
>
> I see you omitted the rest of my post in which I
> largely agreed with you. The point was that you are
> mistaken in asserting earlier that ARM is not ready.
> It absolutely is.

No. In this context being ready means that the CPU
has a position in the market where VMS users will consider
it an acceptable platform - and it does not. Maybe it will
in 10 years, maybe in 20 years. But not today.

Arne

On 4/19/2024 1:02 PM, Arne Vajhøj wrote:
> On 4/19/2024 11:51 AM, Dan Cross wrote:
>> In article <uvttut$31g69$1@dont-email.me>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> On 4/18/2024 7:05 PM, Dan Cross wrote:
>>>> In article <uvrpvg$2dbgu$3@dont-email.me>,
>>>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>>>> On 4/17/2024 11:29 PM, Lawrence D'Oliveiro wrote:
>>>>>> On Wed, 17 Apr 2024 22:27:58 -0400, Arne Vajhøj wrote:
>>>>>>> But VMS could not wait years for a new CPU.
>>>>>>
>>>>>> VMS wasn’t “waiting” for anything. It was customers waiting for VMS.
>>>>>
>>>>> Yes. Because VSI ported to a CPU that was ready. Instead of to a CPU
>>>>> that may be ready some day in the future.
>>>>
>>>> ARM is ready right now.
>>>
>>> You can buy an ARM server or rent an ARM VM in a public
>>> cloud if you search for it.
>>>
>>> But very few of the VMS customers will have ARM servers
>>> or ARM VM's today.
>>>
>>> So even though ARM would have been better than Itanium,
>>> because it is possible to buy a new one, then it would
>>> still have been a market disaster as VMS would still be
>>> "that weird OS that requires different HW than the
>>> rest of our stuff".
>>
>> I see you omitted the rest of my post in which I
>> largely agreed with you.  The point was that you are
>> mistaken in asserting earlier that ARM is not ready.
>> It absolutely is.
>
> No. In this context being ready means that the CPU
> has a position in the market where VMS users will consider
> it an acceptable platform - and it does not. Maybe it will
> in 10 years, maybe in 20 years. But not today.

And just to be clear.

The problem with ARM is not that x86-64 is #1 currently.

The problem with ARM is that a lot - probably most - sites
do not have any ARM at all.

Requiring ARM for VMS would mean introducing a new CPU type. And with
todays multi-multi-core CPU's that would typical mean
either having a lot of wasted resource by only using it for VMS
or having to move other workloads from x86-64 to ARM to accomodate
VMS.

Total no go most places.

Arne

In article <uvu841$33rl6$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/19/2024 11:51 AM, Dan Cross wrote:
>> In article <uvttut$31g69$1@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 4/18/2024 7:05 PM, Dan Cross wrote:
>>>> In article <uvrpvg$2dbgu$3@dont-email.me>,
>>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 4/17/2024 11:29 PM, Lawrence D'Oliveiro wrote:
>>>>>> On Wed, 17 Apr 2024 22:27:58 -0400, Arne Vajhøj wrote:
>>>>>>> But VMS could not wait years for a new CPU.
>>>>>>
>>>>>> VMS wasn’t “waiting” for anything. It was customers waiting for VMS.
>>>>>
>>>>> Yes. Because VSI ported to a CPU that was ready. Instead of to a CPU
>>>>> that may be ready some day in the future.
>>>>
>>>> ARM is ready right now.
>>>
>>> You can buy an ARM server or rent an ARM VM in a public
>>> cloud if you search for it.
>>>
>>> But very few of the VMS customers will have ARM servers
>>> or ARM VM's today.
>>>
>>> So even though ARM would have been better than Itanium,
>>> because it is possible to buy a new one, then it would
>>> still have been a market disaster as VMS would still be
>>> "that weird OS that requires different HW than the
>>> rest of our stuff".
>>
>> I see you omitted the rest of my post in which I
>> largely agreed with you. The point was that you are
>> mistaken in asserting earlier that ARM is not ready.
>> It absolutely is.
>
>No. In this context being ready means that the CPU
>has a position in the market where VMS users will consider
>it an acceptable platform - and it does not. Maybe it will
>in 10 years, maybe in 20 years. But not today.

That might have been what you _meant_, but that's not what you
_said_. What _I_ mean and what I said is that server-class ARM
machines exist, and they are ready for production use now, and
they are eating into the x86 server market. That doesn't mean
that they are useful for VMS.

Again, you omitted the context around what I wrote, in which I
said that the "readiness" of ARM was irrelevant, as x86 will
remain with us for decades to come.

- Dan C.

In article <uvu9t1$343t5$1@dont-email.me>, arne@vajhoej.dk (Arne Vajh�j)
wrote:

> The problem with ARM is not that x86-64 is #1 currently.
>
> The problem with ARM is that a lot - probably most - sites
> do not have any ARM at all.

Dead right. VMS as an OS primarily intended to be run under x86-64
virtualisation is not a problem for today's corporate datacentres.
Requiring ARM would be a significant additional barrier.

> Requiring ARM for VMS would mean introducing a new CPU type. And
> with todays multi-multi-core CPU's that would typical mean
> either having a lot of wasted resource by only using it for VMS
> or having to move other workloads from x86-64 to ARM to accomodate
> VMS.

Probably not, actually. The common ARM servers have Ampere Altera
many-cores processors with 64 or 80 cores. Those cores aren't very fast,
because their design prioritised low power usage. That's because their
target market was huge cloud datacentres, where their selling point is
their power efficiency reducing the cooling requirements. The square-cube
law means that in a big enough datacentre, cooling becomes the main
problem.

Those Ampere-based servers aren't terribly expensive. If VMS can handle
80 cores, it might be quite responsive running on one.

John