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/
<quote>
"X86 is the future of VMS ..."
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.
But VMS could not wait years for a new CPU.
<quote>
- CVE reporting program
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!!
On 2024-04-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
<quote>
- CVE reporting program
About bloody time. :-(
VSI should have done this [...]
Simon.
Simon Clubley schrieb am 18.04.2024 um 14:23:
On 2024-04-17, Arne Vajhj <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... :-)
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.
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... :-)
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.
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.
Because VSI ported to a CPU that was ready.
I wonder what has driven this sudden change and if this will be more permanent than it was the last time around ?
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.
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.
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.
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!!
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:Yes. Because VSI ported to a CPU that was ready. Instead of to a CPU
But VMS could not wait years for a new CPU.
VMS wasn’t “waiting” for anything. It was customers waiting for VMS. >>
that may be ready some day in the future.
ARM is ready right now.
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.
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.
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:Yes. Because VSI ported to a CPU that was ready. Instead of to a CPU
But VMS could not wait years for a new CPU.
VMS wasn’t “waiting” for anything. It was customers waiting for VMS. >>>
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".
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.
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.
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.
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.
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.
But very few of the VMS customers will have ARM servers or ARM VM's
today.
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.
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?
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.
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.
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 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.
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 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 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.
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.
On Fri, 19 Apr 2024 20:29:11 -0400, Arne Vajhj 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.
Maybe. But VMS applications are traditionally not very CPU hungry.
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.
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 <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 toThat's reinforcing my point, about how long ago that was.
depend on for a server OS and RISC-V was in its infancy.
In spite of how long it has been, a decision to run on ARM at that stage >would still have been fatal now.
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 onThat's reinforcing my point, about how long ago that was.
for a server OS and RISC-V was in its infancy.
In spite of how long it has been, a decision to run on ARM at that stage would still have been fatal now.
Most ARM Linux work happens on cloud servers ...
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.
No. [WSL] is for developers.
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.
Ah, I thought you meant getting VMS running in VMs on Windows desktops.
That might actually be useful ...
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 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.
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,
Windows is still a cash cow for MS.
Windows maintenance cost must be like 1% of Windows revenue.
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 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 19/04/2024 9:05 am, Dan Cross wrote:
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.
ARM64 and X86-64 are both going to be around for decades. ARM is
becoming more interesting in the server space, but is a pretty fractured >ecosystem that requires a lot of coding-to-the-hardware; that said you
can go to AWS or Azure and spin up a nice ARM machine for cheap right
now. It's definitely worth investigating a port; I'm not sure if OpenVMS
is self-hosting enough to cross-compile yet but I suspect there's a lot
of hard-coded C in there.
On the other side, x86s and FRED are worth some serious investigation.
On 21/04/2024 8:37 am, Lawrence D'Oliveiro wrote:
We can already do that with SIMH.
Sadly, not without grooming the internet for pakgen or whatever.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 429 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 116:40:00 |
| Calls: | 9,056 |
| Calls today: | 3 |
| Files: | 13,396 |
| Messages: | 6,016,483 |