On Fri, 19 Apr 2024 10:09:33 -0400, Arne Vajhøj wrote:

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

Somehow I doubt that the (remaining) VMS customers are still running their
entire computing operations, or even most of it, on VMS.

On Fri, 19 Apr 2024 10:01:17 -0400, Arne Vajhøj wrote:

> 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.

The reality is that *nix (particularly Linux) has become the de-facto
standard for an OS layer. Even Microsoft has been forced to accept this,
hence the introduction of WSL.

Could VSI come up with a WSL equivalent?

On 4/19/2024 6:13 PM, Lawrence D'Oliveiro wrote:
> On Fri, 19 Apr 2024 10:01:17 -0400, Arne Vajhøj wrote:
>> 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.
>
> The reality is that *nix (particularly Linux) has become the de-facto
> standard for an OS layer. Even Microsoft has been forced to accept this,
> hence the introduction of WSL.
>
> Could VSI come up with a WSL equivalent?

MS invented WSL to allow developers to build and test Linux
applications on Windows.

VSI has no interest in trying to make developers
build and test Linux applications their code on VMS.

Arne

On 4/19/2024 4:49 PM, Dan Cross wrote:
> 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_.

I said that it was not ready.

You made some assumptions about what I meant by ready.

Some assumptions that was wrong.

> 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.

I think that is common knowledge.

> That doesn't mean
> that they are useful for VMS.

Meaning that it is irrelevant for the topic of what VSI should
have ported to.

> 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.

Yes, because it was pointless.

It does not matter that x86-64 is currently #1 and will be around
for decades. What matters is that most sites does not have
ARM servers today.

Arne

On 4/19/2024 5:44 PM, John Dallman wrote:
> In article <uvu9t1$343t5$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> 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.

Maybe. But VMS applications are traditionally not very CPU hungry.
I suspect 80 cores @ GHz speed will be overkill for the VMS application
developed on like dual CPU Alpha 200 MHz or VAX 30 MHz. It is not
like the new Java/Python/PHP/whatever applications that use
CPU power like a sponge suck in water.

And even if the cores are so slow that the combined power of
all cores are needed, then the VMS application would
typical be a few single threaded processes that could not
practically use that many cores.

But I believe that DCL would be very responsive.

:-)

Arne

On Fri, 19 Apr 2024 19:53:41 -0400, Arne Vajhøj wrote:

> On 4/19/2024 6:13 PM, Lawrence D'Oliveiro wrote:
>
>> On Fri, 19 Apr 2024 10:01:17 -0400, Arne Vajhøj wrote:
>>
>>> 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.
>>
>> The reality is that *nix (particularly Linux) has become the de-facto
>> standard for an OS layer. Even Microsoft has been forced to accept
>> this, hence the introduction of WSL.
>>
>> Could VSI come up with a WSL equivalent?
>
> MS invented WSL to allow developers to build and test Linux applications
> on Windows.

Why did they need to? It was because developers are developing Linux
applications in preference to Windows ones, and this was a last-ditch
attempt to keep at least some of that business on Windows.

> VSI has no interest in trying to make developers build and test Linux
> applications their code on VMS.

But you have all this code that already runs on Linux and other *nix, that
you would like to have on VMS, don’t you? You yourself said above, about
how “the desired functionality is based on *nix system design and does not
really fit well with VMS system design”. What else are you supposed to do
if you want that code on VMS?

On 4/19/2024 6:00 PM, Lawrence D'Oliveiro wrote:
> On Fri, 19 Apr 2024 10:09:33 -0400, Arne Vajhøj wrote:
>> But very few of the VMS customers will have ARM servers or ARM VM's
>> today.
>
> Somehow I doubt that the (remaining) VMS customers are still running their
> entire computing operations, or even most of it, on VMS.

True.

But they have x86-64 servers not ARM servers.

Arne

On Fri, 19 Apr 2024 20:29:11 -0400, Arne Vajhøj wrote:

> On 4/19/2024 6:00 PM, Lawrence D'Oliveiro wrote:
>
>> On Fri, 19 Apr 2024 10:09:33 -0400, Arne Vajhøj wrote:
>>> But very few of the VMS customers will have ARM servers or ARM VM's
>>> today.
>>
>> Somehow I doubt that the (remaining) VMS customers are still running
>> their entire computing operations, or even most of it, on VMS.
>
> True.
>
> But they have x86-64 servers not ARM servers.

That seems a dubious presumption, that those still wedded to VMS are not
looking beyond x86, when others are.

On 4/19/2024 8:17 PM, Lawrence D'Oliveiro wrote:
> On Fri, 19 Apr 2024 19:53:41 -0400, Arne Vajhøj wrote:
>> On 4/19/2024 6:13 PM, Lawrence D'Oliveiro wrote:
>>> On Fri, 19 Apr 2024 10:01:17 -0400, Arne Vajhøj wrote:
>>>> 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.
>>>
>>> The reality is that *nix (particularly Linux) has become the de-facto
>>> standard for an OS layer. Even Microsoft has been forced to accept
>>> this, hence the introduction of WSL.
>>>
>>> Could VSI come up with a WSL equivalent?
>>
>> MS invented WSL to allow developers to build and test Linux applications
>> on Windows.
>
> Why did they need to? It was because developers are developing Linux
> applications in preference to Windows ones, and this was a last-ditch
> attempt to keep at least some of that business on Windows.

There are a lot of those.

But there are also another large group: those that develop for
both Linux and Windows.

>> VSI has no interest in trying to make developers build and test Linux
>> applications their code on VMS.
>
> But you have all this code that already runs on Linux and other *nix, that
> you would like to have on VMS, don’t you? You yourself said above, about
> how “the desired functionality is based on *nix system design and does not
> really fit well with VMS system design”. What else are you supposed to do
> if you want that code on VMS?

It is not a big secret that there are a lot more code running on
Linux than on VMS.

But remember that WSL 2 is just a VM with some fancy integration stuff
to make development smooth. The Linux applications just runs in a
Linux VM.

I am sure that a lot of VMS customers will have Linux VM's around
running Linux applications. But that has little to do with VMS and
VSI.

What is relevant for VSI and VMS is porting those applications to
run on VMS.

In some cases that will require changes to VMS and C RTL.

And it is not always easy because VMS and Linux are different.

Arne

In article <uvv0nq$38qe2$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/19/2024 4:49 PM, Dan Cross wrote:
>> 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_.
>
>I said that it was not ready.

And you are wrong.

>You made some assumptions about what I meant by ready.
>
>Some assumptions that was wrong.

Not really. I'm not in your mind, nor is anyone else other than
you. If you want people to know what you are thinking, then it
is on you to state that clearly and unambiguously. What you
_actually_ wrote was:

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

Note that this was in reference to ARM and you wrote about
"readiness" in the present tense. ARM, the CPU, and systems
built around those CPUs, are "ready" by any reasonable
definition right now. If what you meant to say was that these
systems don't have sufficient market representation for a VMS
port, then you should have said that. If what you meant to say
was that these were not "ready" 10 years ago when the VMS to
x86 port started, then you should have said that. But if you
just make a general statement that "ARM isn't ready" then you're
just wrong, doubly so since that's not the same thing as, "the
ARM server market isn't ready for a VMS port."

In other words, it's on you to accurately represent what you
mean. If you don't do that, don't blame others when they
correct your misrepresentations of the current server landscape.

>> 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.
>
>I think that is common knowledge.

Perhaps, but that does not mean that you are aware of it. You
are so often wrong on the deeper technical specifics that I see
little reason to simply take your word for it, particularly when
you write the exact opposite.

>> that they are useful for VMS.
>
>Meaning that it is irrelevant for the topic of what VSI should
>have ported to.

As I said above.

Again, you cut off part of my words. The full sentence I wrote,
of which you only quoted a fragment, is: "That doesn't mean that
they are useful for VMS."
(https://comp.os.vms.narkive.com/YCdFLLzW/report-of-the-last-rendez-vous-autour-de-vms-2-feb-2024#post24)

>> 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.
>
>Yes, because it was pointless.

No. It was exactly the point. Your statement about ARM, you
know, the one that you actually wrote, was wrong. I corrected
it. I know that have a very hard time accepting it when people
point out that you are wrong, but that's your flaw, not mine.

>It does not matter that x86-64 is currently #1 and will be around
>for decades. What matters is that most sites does not have
>ARM servers today.

Ah, but I didn't say that they did. You don't get to have it
both ways. You don't get accuse making others of bad
assumptions regarding things that you wrote rather plainly, and
then put words into their mouths.

- Dan C.

On Fri, 19 Apr 2024 20:40:29 -0400, Arne Vajhøj wrote:

> But remember that WSL 2 is just a VM with some fancy integration stuff
> to make development smooth. The Linux applications just runs in a Linux
> VM.

It’s there just so Microsoft can claim that software written for Linux is
running on a Windows desktop.

If VSI can do the same, it too can claim that software written for Linux
is running on a VMS desktop.

In article <uvv2s0$392q8$7@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
> On Fri, 19 Apr 2024 20:29:11 -0400, Arne Vajh�j wrote:
> > But they have x86-64 servers not ARM servers.
> That seems a dubious presumption, that those still wedded to VMS
> are not looking beyond x86, when others are.

Some others are. This is not universal, or even terribly widespread. Most
ARM Linux work happens on cloud servers, running Python and other
scripting languages, where the customer doesn't know or care about the
underlying architecture. VMS cares a lot, because it's all compiled to
native code.

I work at a large ISV, on a site that produces software components for
sale to third parties. We are the only site, out of at least 30 in the
company, that has ARM Linux or ARM Windows running locally, or does
development for iOS, Android or ARM macOS. One or two other sites do
development for ARM Linux on AWS. Other sites have lots of iOS and
Android devices in use as personal devices, of course, and may have a few
Macs for publishing or other creative work.

But I have to explain to central IT all the time about ARM being a
different instruction set and incompatible, and it's taken ages to get
them to stop trying to install stuff remotely on ARM Windows. Fortunately,
the installers for OS services and the like refuse to install on the
wrong architecture, but that meant the installers failed and didn't
terminate. They just sat there consuming CPU and RAM, on machines that
aren't terribly powerful to start with.

John

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

> 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.

In spite of how long it has been, a decision to run on ARM at that stage
would still have been fatal now.

John

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

> Maybe. But VMS applications are traditionally not very CPU hungry.

Not now, because the CPU-intensive ones migrated off Itanium in search of
faster processors.

John

In article <uvvr6l$3htoa$1@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:

> If VSI can do the same, it too can claim that software written for
> Linux is running on a VMS desktop.

Ah, I thought you meant getting VMS running in VMs on Windows desktops.
That might actually be useful; VSI regard VMS' role as being purely for
servers these days, and aren't trying to support desktops.

John

On 4/20/2024 3:34 AM, Lawrence D'Oliveiro wrote:
> On Fri, 19 Apr 2024 20:40:29 -0400, Arne Vajhøj wrote:
>> But remember that WSL 2 is just a VM with some fancy integration stuff
>> to make development smooth. The Linux applications just runs in a Linux
>> VM.
>
> It’s there just so Microsoft can claim that software written for Linux is
> running on a Windows desktop.

No. It is for developers.

> If VSI can do the same, it too can claim that software written for Linux
> is running on a VMS desktop.

VSI is not targeting the desktop market at all.

Arne

On 4/20/2024 5:08 AM, John Dallman wrote:
> In article <uvv1fb$395df$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> Maybe. But VMS applications are traditionally not very CPU hungry.
>
> Not now, because the CPU-intensive ones migrated off Itanium in search of
> faster processors.

True. CPU intensive applications has likely moved off VMS
years ago. So some selection in who is left.

My point was that I expect the majority of VMS sites to run
applications originally developed more than 25 years ago.

Some of them may have added CPU demanding extensions along
the way. But a lot of them would run damn fast even on
low end CPU's of today.

Arne

In article <memo.20240420100817.10388P@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <uvs6f5$2g9b9$8@dont-email.me>, ldo@nz.invalid (Lawrence
>D'Oliveiro) wrote:
>
>> 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.
>
>In spite of how long it has been, a decision to run on ARM at that stage
>would still have been fatal now.

Perhaps. But arguing with the village idiot (this Lawrence guy
who's been spamming most groups I read lately) is unlikely to
sway anyone's opinion.

- Dan C.

On Sat, 20 Apr 2024 10:08 +0100 (BST), John Dallman wrote:

> In article <uvs6f5$2g9b9$8@dont-email.me>, ldo@nz.invalid (Lawrence
> D'Oliveiro) wrote:
>
>> 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.
>
> In spite of how long it has been, a decision to run on ARM at that stage
> would still have been fatal now.

It’s not clear that VMS has achieved non-fatality as it is.

On Sat, 20 Apr 2024 10:08 +0100 (BST), John Dallman wrote:

> Most ARM Linux work happens on cloud servers ...

You are neglecting the huge installed base of Raspberry Pi boxes and
copycats. Very popular among the “Maker” movement, for example.

> But I have to explain to central IT all the time about ARM being a
> different instruction set and incompatible, and it's taken ages to get
> them to stop trying to install stuff remotely on ARM Windows.

ARM Windows does seem to be an ongoing trainwreck, in spite of Microsoft’s
best efforts ...

On Sat, 20 Apr 2024 08:17:18 -0400, Arne Vajhøj wrote:

> No. [WSL] is for developers.

It may be now, but how long do you think it will stay that way? It seems
very likely that, at some point, WSL will become a mandatory part of a
Windows install.

On Sat, 20 Apr 2024 10:08 +0100 (BST), John Dallman wrote:

> Ah, I thought you meant getting VMS running in VMs on Windows desktops.
> That might actually be useful ...

We can already do that with SIMH.

On 4/20/2024 6:37 PM, Lawrence D'Oliveiro wrote:
> On Sat, 20 Apr 2024 08:17:18 -0400, Arne Vajhøj wrote:
>> No. [WSL] is for developers.
>
> It may be now, but how long do you think it will stay that way? It seems
> very likely that, at some point, WSL will become a mandatory part of a
> Windows install.

Not likely.

Nobody will want to run server apps in WSL for production. There
are more suitable ways to run Windows and Linux on same
box whether it is VMWare ESXi, KVM or (plain) Hyper-V.

And for desktop then the general users have no interest
in anything Linux.

Arne

On 21/04/2024 00:03, Arne Vajhøj wrote:

>
> Not likely.
>
> Nobody will want to run server apps in WSL for production. There
> are more suitable ways to run Windows and Linux on same
> box whether it is VMWare ESXi, KVM or (plain) Hyper-V.
>
> And for desktop then the general users have no interest
> in anything Linux.
>
> Arne
>

Arne - don't feed the troll!

Shame we can't get him banned - that is the advantage of forums!

--
Chris

On Sat, 20 Apr 2024 19:03:49 -0400, Arne Vajhøj wrote:

> On 4/20/2024 6:37 PM, Lawrence D'Oliveiro wrote:
>
>> On Sat, 20 Apr 2024 08:17:18 -0400, Arne Vajhøj wrote:
>>
>>> No. [WSL] is for developers.
>>
>> It may be now, but how long do you think it will stay that way? It
>> seems very likely that, at some point, WSL will become a mandatory part
>> of a Windows install.
>
> Not likely.

Think of how difficult and expensive it is for Microsoft to continue
developing Windows as a stand-alone OS. Clearly the profit isn’t there any
more, as witness the deteriorating quality of Windows releases, and even
the quality of the patches to fix up the problems, which often end up
causing their own problems.

It would be following the path of least resistance to rely more and more
on the Linux kernel, and let the Windows kernel itself gradually wither
away.