Darya Zelenina, speaks 9 languages, looks like she is about 35.
Practically all of the OpenVMS users seem to be 65+ years old!
She is soon to be the CEO!

https://www.linkedin.com/in/darya-zelenina-8a3b3272/

Darya will assume the role of CEO in June 2024. She joined VMS Software as a technical writer and OpenVMS instructor in 2017 and has since held key leadership positions in software and web development, documentation, the Community Program and Marketing. Darya brings extensive expertise in OpenVMS and the OpenVMS ecosystem, coupled with deep commitment to shaping the platform's long-term trajectory.

On 1/3/2024 3:16 PM, Slo wrote:
> Darya Zelenina, speaks 9 languages,

Per her LinkedIn profile:

Russian
English
Esperanto

French
German

Dutch
Hebrew
Swedish
Turkish

> looks like she is about 35.

She is younger than most other VSI managers.

And she does not have a past in DEC/CPQ/HP.

New times.

Arne

On Wed, 3 Jan 2024 15:52:16 -0500, Arne Vajhøj wrote:

> And she does not have a past in DEC/CPQ/HP.

Does she have a background in finance? If yes, then ...

.... is the company being prepared for a selloff?

On 1/3/2024 5:49 PM, Lawrence D'Oliveiro wrote:
> On Wed, 3 Jan 2024 15:52:16 -0500, Arne Vajhøj wrote:
>> And she does not have a past in DEC/CPQ/HP.
>
> Does she have a background in finance?

Per her LinkedIn profile her bachelor degree is in linguistics.

> If yes, then ...
>
> ... is the company being prepared for a selloff?

I don't think there would be much point in that.

VSI seems to be in good shape financially, but it is not
a "hot" company that can be sold for X B$ due to buzz
in the press.

And it also seems that they try to benefit from some
synergies between the multiple companies in the
Teracloud group.

Arne

On 2024-01-03, Slo <slovuj@gmail.com> wrote:
> Darya Zelenina, speaks 9 languages, looks like she is about 35.
> Practically all of the OpenVMS users seem to be 65+ years old!
> She is soon to be the CEO!
>
> https://www.linkedin.com/in/darya-zelenina-8a3b3272/
>
> Darya will assume the role of CEO in June 2024. She joined VMS Software as a technical writer and OpenVMS instructor in 2017 and has since held key leadership positions in software and web development, documentation, the Community Program and Marketing. Darya brings extensive expertise in OpenVMS and the OpenVMS ecosystem, coupled with deep commitment to shaping the platform's long-term trajectory.

This move does not give me a good feeling.

She does not seem like a good fit for a CEO of a company providing
the types of mission-critical services that companies running VMS
rely on.

Even ignoring all the touchy-feeling stuff in her bio, someone who
has "successfully managed teams in documentation, marketing, web
development, and DevOps" as her main achievement does not seem to
be a good match for the needs of VMS users.

Where were all the other candidates for the job, and why was she
considered to be the best one for the job ? Would no-one else
look at taking the job for some reason ?

BTW, what the hell is "Intercultual Communication" ?

Also, is her Russian background going to be a problem for the
US governement ? I'm not saying it is an issue in real life, I am just
asking how some people might react. For example, look at all the crap
the Sailfish OS people have to deal with in this area...

Simon.

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

On 1/4/2024 9:00 AM, Simon Clubley wrote:
> On 2024-01-03, Slo <slovuj@gmail.com> wrote:
>> Darya will assume the role of CEO in June 2024. She joined VMS
>> Software as a technical writer and OpenVMS instructor in 2017 and
>> has since held key leadership positions in software and web
>> development, documentation, the Community Program and Marketing.
>> Darya brings extensive expertise in OpenVMS and the OpenVMS
>> ecosystem, coupled with deep commitment to shaping the platform's
>> long-term trajectory. >
> This move does not give me a good feeling.
>
> She does not seem like a good fit for a CEO of a company providing
> the types of mission-critical services that companies running VMS
> rely on.
>
> Even ignoring all the touchy-feeling stuff in her bio, someone who
> has "successfully managed teams in documentation, marketing, web
> development, and DevOps" as her main achievement does not seem to
> be a good match for the needs of VMS users.

A CEO has to have managerial experience for obvious reasons. People
do not move directly from individual contributor to CEO.

She does not have an engineering background. But CEO's for tech
companies not having an engineering background is not unusual.

She has experience with the development process and the engineering
teams from her devops work.

She has experience with customers from marketing and sales work.

She seems more focused on new ways (CI/CD, web etc.) than
how DEC did things 40 years ago.

She was working on the CL program, which I think turned out
very good for VSI - I suspect a lot of the bug reports come
from CL users.

Based on VSI web page and LinkedIn profile I think it looks
as a good choice.

> Where were all the other candidates for the job, and why was she
> considered to be the best one for the job ? Would no-one else
> look at taking the job for some reason ?

They have had plenty of time to look for and evaluate candidates.

We will probably never know who was interested and exactly what
made Johan Gedda pick her.

But I suspect that some of the managers within engineering was
not interested because they prefer EVE/LSE/VSCode over Excel.
That is quite common, so probably also in VSI.

> Also, is her Russian background going to be a problem for the
> US governement ? I'm not saying it is an issue in real life, I am just
> asking how some people might react. For example, look at all the crap
> the Sailfish OS people have to deal with in this area...

I suspect that she will be presented as "born in Russia" and
"living and working in Copenhagen".

Denmark is a member of NATO and EU, close ally to the US etc..

Arne

On 1/4/2024 9:00 AM, Simon Clubley wrote:
> BTW, what the hell is "Intercultual Communication" ?

Probably something about the need to communicate differently
with people from different cultural backgrounds. Do you start directly
with the point or do you start with some polite chit chat. Does the
boss order or suggest to team. Etc.etc..

Useful skill.

Arne

Le 04/01/2024 à 16:02, Arne Vajhøj a écrit :
> On 1/4/2024 9:00 AM, Simon Clubley wrote:
>> BTW, what the hell is "Intercultual Communication" ?
>
> Probably something about the need to communicate differently
> with people from different cultural backgrounds. Do you start directly
> with the point or do you start with some polite chit chat. Does the
> boss order or suggest to team. Etc.etc..
>
> Useful skill.
>
> Arne
>
Perhaps intercultural is necessary to speak altogether with computers,
computers scientists, business men, from Europe to US and US to europe... :)

I remember having met her during the first bootcamps of the new age.
Impressive for her cleverness, really curious of VMS culture.

I am hoping she will be the one who gets a "vision"... which is the
first function of a good ceo.

Yes, to be borned russian can generate problems. I think it underlines
the determination behind this choice. Johan Geda here takes a risk.

Gérard Calliet

--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com

On 1/4/2024 1:45 PM, gcalliet wrote:
> Le 04/01/2024 à 16:02, Arne Vajhøj a écrit :
>> On 1/4/2024 9:00 AM, Simon Clubley wrote:
>>> BTW, what the hell is "Intercultual Communication" ?
>>
>> Probably something about the need to communicate differently
>> with people from different cultural backgrounds. Do you start directly
>> with the point or do you start with some polite chit chat. Does the
>> boss order or suggest to team. Etc.etc..
>>
>> Useful skill.

> Perhaps intercultural is necessary to speak altogether with computers,
> computers scientists, business men, from Europe to US and US to
> europe... :)

And Asia.

Many westerners have messed up big time in Asia because they did not
understand the culture.

> I remember having met her during the first bootcamps of the new age.
> Impressive for her cleverness, really curious of VMS culture.

:-)

> I am hoping she will be the one who gets a "vision"... which is the
> first function of a good ceo.

To me the most significant is that she is not ex-DEC (or ex-IBM
or ex-bigcorpwhatever). That must give a different perspective on VMS.

She joined a small company with a niche OS that she need to get to
prosper and grow.

She did not join the second largest IT company in the world (DEC
80's) with one of the worlds major OS (VMS 80's), has seen
it decline over several decades and want to "resurrect" it.

Nothing wrong with being old (I am old!). But experience leaves an
impact on ones thinking.

She could be the right person to move VSI and VMS into the 2030's.

Arne

On Thu, 4 Jan 2024 09:56:31 -0500, Arne Vajhøj wrote:

> She seems more focused on new ways (CI/CD, web etc.) than how DEC did
> things 40 years ago.

If she is less invested in how DEC used to do things, maybe she’s the one
to put in place the program I suggested sometime back: get rid of most of
VMS itself, leaving only the parts that users care about--namely their
userland programs and DCL command procedures. All that could run on an
emulation layer on Linux.

On 1/4/2024 2:25 PM, Lawrence D'Oliveiro wrote:
> On Thu, 4 Jan 2024 09:56:31 -0500, Arne Vajhøj wrote:
>> She seems more focused on new ways (CI/CD, web etc.) than how DEC did
>> things 40 years ago.
>
> If she is less invested in how DEC used to do things, maybe she’s the one
> to put in place the program I suggested sometime back: get rid of most of
> VMS itself, leaving only the parts that users care about--namely their
> userland programs and DCL command procedures. All that could run on an
> emulation layer on Linux.

Not likely.

Lots of work to implement.

Not much interest from customers.

Sector 7 has offered such products for decades. Without taking away
the VMS customer base. Apperently VMS customer prefer to either stay
on VMS or port to Windows or Linux instead of running VMS emulation
on top of Windows or Linux.

Arne

On Thu, 4 Jan 2024 15:42:57 -0500, Arne Vajhøj wrote:

> On 1/4/2024 2:25 PM, Lawrence D'Oliveiro wrote:
>
>> On Thu, 4 Jan 2024 09:56:31 -0500, Arne Vajhøj wrote:
>>
>>> She seems more focused on new ways (CI/CD, web etc.) than how DEC did
>>> things 40 years ago.
>>
>> If she is less invested in how DEC used to do things, maybe she’s the
>> one to put in place the program I suggested sometime back: get rid of
>> most of VMS itself, leaving only the parts that users care
>> about--namely their userland programs and DCL command procedures. All
>> that could run on an emulation layer on Linux.
>
> Lots of work to implement.

Much less than the 7 years it took to reimplement VMS on top of AMD64.
Remember, it took less time (and resources) than that to move Linux from
32-bit x86 to 64-bit Alpha.

> Not much interest from customers.

Just think: there would have been more customers left if they’d got it
working sooner.

> Sector 7 has offered such products for decades. Without taking away the
> VMS customer base.

Maybe they have.

On 1/4/2024 5:20 PM, Lawrence D'Oliveiro wrote:
> On Thu, 4 Jan 2024 15:42:57 -0500, Arne Vajhøj wrote:
>> On 1/4/2024 2:25 PM, Lawrence D'Oliveiro wrote:
>>> On Thu, 4 Jan 2024 09:56:31 -0500, Arne Vajhøj wrote:
>>>> She seems more focused on new ways (CI/CD, web etc.) than how DEC did
>>>> things 40 years ago.
>>>
>>> If she is less invested in how DEC used to do things, maybe she’s the
>>> one to put in place the program I suggested sometime back: get rid of
>>> most of VMS itself, leaving only the parts that users care
>>> about--namely their userland programs and DCL command procedures. All
>>> that could run on an emulation layer on Linux.
>>
>> Lots of work to implement.
>
> Much less than the 7 years it took to reimplement VMS on top of AMD64.

I doubt that.

Mapping from one OS to another OS is not easy.

> Remember, it took less time (and resources) than that to move Linux from
> 32-bit x86 to 64-bit Alpha.

Very different task.

Adding support for a new CPU to an OS mostly written in C and
making the API's and utilities of one OS run on top of another
OS kernel are not the same.

>> Not much interest from customers.
>
> Just think: there would have been more customers left if they’d got it
> working sooner.

Sector 7 has been around for many years. So the lack of interest in
their product is not likely to be due to timing.

>> Sector 7 has offered such products for decades. Without taking away the
>> VMS customer base.
>
> Maybe they have.

That is something we would know about.

They have customers, but not nearly as many as those migrating
natively to other platforms.

Arne

On Thu, 4 Jan 2024 20:26:33 -0500, Arne Vajhøj wrote:

> On 1/4/2024 5:20 PM, Lawrence D'Oliveiro wrote:
>> On Thu, 4 Jan 2024 15:42:57 -0500, Arne Vajhøj wrote:
>>> On 1/4/2024 2:25 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>> ... put in place the program I suggested sometime back: get rid of
>>>> most of VMS itself, leaving only the parts that users care
>>>> about--namely their userland programs and DCL command procedures. All
>>>> that could run on an emulation layer on Linux.
>>>
>>> Lots of work to implement.
>>
>> Much less than the 7 years it took to reimplement VMS on top of AMD64.
>
> I doubt that.
>
> Mapping from one OS to another OS is not easy.

Linux is a more versatile kernel than VMS. For example, the WINE project
has been able to substantially implement the Windows APIs on top of Linux,
while Microsoft’s attempt to do the reverse, implement the Linux APIs on
top of the Windows kernel with WSL1, has been abandoned as a failure.

>> Remember, it took less time (and resources) than that to move Linux
>> from 32-bit x86 to 64-bit Alpha.
>
> Very different task.

How different? It’s exactly the same sort of thing: port an OS to a new
architecture.

>> Just think: there would have been more customers left if they’d got it
>> working sooner.
>
> Sector 7 has been around for many years. So the lack of interest in
> their product is not likely to be due to timing.

I mean, customers left who are still interested in original VMS.

>>> Sector 7 has offered such products for decades. Without taking away
>>> the VMS customer base.
>>
>> Maybe they have.
>
> That is something we would know about.

You mean “would not know about”?

> They have customers, but not nearly as many as those migrating
> natively to other platforms.

I think we’ve discussed their product before. Reading between the lines of
their case studies, seems their product lacks some of the niceties that it
should be possible to implement on top of the Linux kernel. DECnet, I
think, was one thing they seemed to be missing.

On 1/4/2024 8:48 PM, Lawrence D'Oliveiro wrote:
> On Thu, 4 Jan 2024 20:26:33 -0500, Arne Vajhøj wrote:
>
>> On 1/4/2024 5:20 PM, Lawrence D'Oliveiro wrote:
>>> On Thu, 4 Jan 2024 15:42:57 -0500, Arne Vajhøj wrote:
>>>> On 1/4/2024 2:25 PM, Lawrence D'Oliveiro wrote:
>>>>>
>>>>> ... put in place the program I suggested sometime back: get rid of
>>>>> most of VMS itself, leaving only the parts that users care
>>>>> about--namely their userland programs and DCL command procedures. All
>>>>> that could run on an emulation layer on Linux.
>>>>
>>>> Lots of work to implement.
>>>
>>> Much less than the 7 years it took to reimplement VMS on top of AMD64.
>>
>> I doubt that.
>>
>> Mapping from one OS to another OS is not easy.
>
> Linux is a more versatile kernel than VMS. For example, the WINE project
> has been able to substantially implement the Windows APIs on top of Linux,
> while Microsoft’s attempt to do the reverse, implement the Linux APIs on
> top of the Windows kernel with WSL1, has been abandoned as a failure.

Excellent examples.

Have you noticed how the world has moved from Windows to Linux
with Wine? No. Because it did not happen. Wine is a niche
thing.

MS tried WSL1 and changed to to a VM model with WSL2.

2 x commercial failure.

>>> Remember, it took less time (and resources) than that to move Linux
>>> from 32-bit x86 to 64-bit Alpha.
>>
>> Very different task.
>
> How different? It’s exactly the same sort of thing: port an OS to a new
> architecture.

If you call both a CPU and an underlying foreign OS kernel for "a new
architecture" then yes.

But the reality is that it is very different.

>>>> the VMS customer base.
>>>
>>> Maybe they have.
>>
>> That is something we would know about.
>
> You mean “would not know about”?

No. We would know.

A company could not pick a large number of DEC/CPQ/HP/HPE/VSI
customers without the VMS community knowing.

>> They have customers, but not nearly as many as those migrating
>> natively to other platforms.
>
> I think we’ve discussed their product before. Reading between the lines of
> their case studies, seems their product lacks some of the niceties that it
> should be possible to implement on top of the Linux kernel. DECnet, I
> think, was one thing they seemed to be missing.

They do run on Linux (and Windows).

It is possible that someone could do better than them.

But they did not.

And there were a couple of other companies offering
similar (or somewhat similar) services: Accel8 and BosBC. They
are no longer in business.

That makes it a 0 out of 3 success rate.

Arne

On Thu, 4 Jan 2024 21:11:49 -0500, Arne Vajhøj wrote:

> Have you noticed how the world has moved from Windows to Linux with
> Wine?

Yes. Look at the (Linux-based) Steam Deck, which has been making some
inroads into the very core of Windows dominance, namely the PC gaming
market. Enough to get Microsoft to take notice.

> MS tried WSL1 and changed to to a VM model with WSL2.
>
> 2 x commercial failure.

On the part of Windows, not on the part of Linux.

>>>> Remember, it took less time (and resources) than that to move Linux
>>>> from 32-bit x86 to 64-bit Alpha.
>>>
>>> Very different task.
>>
>> How different? It’s exactly the same sort of thing: port an OS to a new
>> architecture.
>
> If you call both a CPU and an underlying foreign OS kernel for "a new
> architecture" then yes.
>
> But the reality is that it is very different.

New CPU -- check
“underlying foreign OS kernel” -- this was about porting the same kernel
onto a different CPU. In both cases.

So tell me again: “very different” how?

On 1/4/2024 10:01 PM, Lawrence D'Oliveiro wrote:
> On Thu, 4 Jan 2024 21:11:49 -0500, Arne Vajhøj wrote:
>>>>> Remember, it took less time (and resources) than that to move Linux
>>>>> from 32-bit x86 to 64-bit Alpha.
>>>>
>>>> Very different task.
>>>
>>> How different? It’s exactly the same sort of thing: port an OS to a new
>>> architecture.
>>
>> If you call both a CPU and an underlying foreign OS kernel for "a new
>> architecture" then yes.
>>
>> But the reality is that it is very different.
>
> New CPU -- check
> “underlying foreign OS kernel” -- this was about porting the same kernel
> onto a different CPU. In both cases.
>
> So tell me again: “very different” how?

Sorry. I messed up this one.

I was not comparing "Linux port to Alpha" with "VSI actual port
of VMS to x86-64" but to "hypothetical port of VMS to being on
top of Linux kernel".

Arne

In article <un7ren$3s7nl$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Thu, 4 Jan 2024 21:11:49 -0500, Arne Vajhøj wrote:
>
>> Have you noticed how the world has moved from Windows to Linux with
>> Wine?
>
>Yes. Look at the (Linux-based) Steam Deck, which has been making some
>inroads into the very core of Windows dominance, namely the PC gaming
>market. Enough to get Microsoft to take notice.

That's not Linux with wine. You can install Wine on the steam
deck, but their success has much more to do with their native
architecture.

>> MS tried WSL1 and changed to to a VM model with WSL2.
>>
>> 2 x commercial failure.
>
>On the part of Windows, not on the part of Linux.

2024 will be the year of the Linux desktop. I can feel it!

>>>>> Remember, it took less time (and resources) than that to move Linux
>>>>> from 32-bit x86 to 64-bit Alpha.
>>>>
>>>> Very different task.
>>>
>>> How different? It’s exactly the same sort of thing: port an OS to a new
>>> architecture.
>>
>> If you call both a CPU and an underlying foreign OS kernel for "a new
>> architecture" then yes.
>>
>> But the reality is that it is very different.
>
>New CPU -- check
>“underlying foreign OS kernel” -- this was about porting the same kernel
>onto a different CPU. In both cases.
>
>So tell me again: “very different” how?

I think, again, you are talking at cross-purposes: my suspicion
is that Arne is referring to a VMS compatibility layer built on
top of Linux, not the effort of porting VMS to x86_64.

That said, VMS was not originally written for portability and
wasn't ported to anything other than successive version of the
VAX for the first 10 or so years it existed; Linux was ported
to the Alpha pretty early on (sponsored by DEC; thanks Mad Dog).
So Linux filed off a lot of portability sharp edges for the
machines at the time pretty early on, when it was still pretty
small; VMS not so much.

- Dan C.

On 1/4/2024 10:09 PM, Dan Cross wrote:
> In article <un7ren$3s7nl$1@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 4 Jan 2024 21:11:49 -0500, Arne Vajhøj wrote:
>>> MS tried WSL1 and changed to to a VM model with WSL2.
>>>
>>> 2 x commercial failure.
>>
>> On the part of Windows, not on the part of Linux.
>
> 2024 will be the year of the Linux desktop. I can feel it!

:-)

>>>>>> Remember, it took less time (and resources) than that to move Linux
>>>>>> from 32-bit x86 to 64-bit Alpha.
>>>>>
>>>>> Very different task.
>>>>
>>>> How different? It’s exactly the same sort of thing: port an OS to a new
>>>> architecture.
>>>
>>> If you call both a CPU and an underlying foreign OS kernel for "a new
>>> architecture" then yes.
>>>
>>> But the reality is that it is very different.
>>
>> New CPU -- check
>> “underlying foreign OS kernel” -- this was about porting the same kernel
>> onto a different CPU. In both cases.
>>
>> So tell me again: “very different” how?
>
> I think, again, you are talking at cross-purposes: my suspicion
> is that Arne is referring to a VMS compatibility layer built on
> top of Linux, not the effort of porting VMS to x86_64.

Yes.

I was being unclear in my response, so I think that one is on me.

> That said, VMS was not originally written for portability and
> wasn't ported to anything other than successive version of the
> VAX for the first 10 or so years it existed; Linux was ported
> to the Alpha pretty early on (sponsored by DEC; thanks Mad Dog).
> So Linux filed off a lot of portability sharp edges for the
> machines at the time pretty early on, when it was still pretty
> small; VMS not so much.

Yes.

But there is also the difference that Linux was implemented
(first and later) for existing architecture. They had to live
with what they got. When VMS was first created the VMS software
people could walk over to the VAX HW people and say "we want
this nifty instruction to make our work easier". An Alpha got
the PAL code mechanism.

I believe one of the VSI people has told that one of issues
in the x86-64 port is probing memory. VAX got PROBEx instructions.
Alpha got CALL_PAL PROBER and PROBEW.

Arne

On Thu, 4 Jan 2024 22:09:12 -0500, Arne Vajhøj wrote:

> I was not comparing "Linux port to Alpha" with "VSI actual port of VMS
> to x86-64" but to "hypothetical port of VMS to being on top of Linux
> kernel".

Remember, I’m not talking about porting the whole of VMS, just the part
that users care about: userland executables and DCL command procedures.
That’s it.

On Fri, 5 Jan 2024 03:09:37 -0000 (UTC), Dan Cross wrote:

> I think, again, you are talking at cross-purposes: my suspicion is that
> Arne is referring to a VMS compatibility layer built on top of Linux,
> not the effort of porting VMS to x86_64.

I thought I made it pretty clear early on that I was only talking about
porting across userland executables and DCL command procedures--just the
parts of VMS that users care about, nothing more.

> That said, VMS was not originally written for portability and wasn't
> ported to anything other than successive version of the VAX for the
> first 10 or so years it existed ...

And being typical of proprietary software, think of the layers of cruft
the code will have accumulated, first in the move to Alpha, then Itanium,
and now AMD64. All without ever really becoming a fully 64-bit OS.

> Linux was ported to the Alpha pretty early on (sponsored by DEC; thanks
> Mad Dog). So Linux filed off a lot of portability sharp edges for the
> machines at the time pretty early on, when it was still pretty small;
> VMS not so much.

Which is reinforcing my point, is it not? That Linux stands a good chance
of being able to take on enough of a VMS layer to make VMS itself
unnecessary.

On Thu, 4 Jan 2024 22:22:19 -0500, Arne Vajhøj wrote:

> I believe one of the VSI people has told that one of issues in the
> x86-64 port is probing memory. VAX got PROBEx instructions.
> Alpha got CALL_PAL PROBER and PROBEW.

Linux, too, has the issue of having to check that addresses that a caller
passes are actually accessible by them, in relevant system calls. And
unlike VMS, it has to deal with that issue across something like 2 dozen
different processor architectures, at current count.

Maybe look at how that deals with it?

Or, like I said, avoid the issue by letting Linux deal with it.

On 1/4/2024 10:09 PM, Dan Cross wrote:
> In article <un7ren$3s7nl$1@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 4 Jan 2024 21:11:49 -0500, Arne Vajhøj wrote:
>>
>>> Have you noticed how the world has moved from Windows to Linux with
>>> Wine?
>>
>> Yes. Look at the (Linux-based) Steam Deck, which has been making some
>> inroads into the very core of Windows dominance, namely the PC gaming
>> market. Enough to get Microsoft to take notice.
>
> That's not Linux with wine. You can install Wine on the steam
> deck, but their success has much more to do with their native
> architecture.
>
>>> MS tried WSL1 and changed to to a VM model with WSL2.
>>>
>>> 2 x commercial failure.
>>
>> On the part of Windows, not on the part of Linux.
>
> 2024 will be the year of the Linux desktop. I can feel it!
>

That's a weird thing to say. I have been running Linux Desktops for
over 20 years.

bill

On 1/4/24 1:10 PM, Arne Vajhøj wrote:

> She did not join the second largest IT company in the world (DEC
> 80's) with one of the worlds major OS (VMS 80's), has seen
> it decline over several decades and want to "resurrect" it.
>
> Nothing wrong with being old (I am old!). But experience leaves an
> impact on ones thinking.

The previous CEO (Kevin Shaw) was 44 when he was killed by a car while
crossing the street, so it's not news that the next generation of
leadership will be too young to have been ex-DECCies.

> She could be the right person to move VSI and VMS into the 2030's.

Let's hope. Some of the engineering seems to be getting done. It
remains to be seen whether they will get back to any of the bigger
engineering projects after the port is done or develop any more of a
clue about the customers and the community than previous purveyors of
VMS have had.

In article <un81en$l6e$2@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Fri, 5 Jan 2024 03:09:37 -0000 (UTC), Dan Cross wrote:
>
>> I think, again, you are talking at cross-purposes: my suspicion is that
>> Arne is referring to a VMS compatibility layer built on top of Linux,
>> not the effort of porting VMS to x86_64.
>
>I thought I made it pretty clear early on that I was only talking about
>porting across userland executables and DCL command procedures--just the
>parts of VMS that users care about, nothing more.

That would necessarily entail dragging in much of the rest of
the operating system. Which isn't to say that it couldn't be
done, but your, "I'm only..." pseudo-subset appears to be a
suggestion borne of ignorance of what's actually involved.

>> That said, VMS was not originally written for portability and wasn't
>> ported to anything other than successive version of the VAX for the
>> first 10 or so years it existed ...
>
>And being typical of proprietary software, think of the layers of cruft
>the code will have accumulated, first in the move to Alpha, then Itanium,
>and now AMD64. All without ever really becoming a fully 64-bit OS.

You are, once again, speculating from a position of ignorance.

Consider that for both the VAX _and_ Alpha, DEC was able to
shape the design of the hardware _and_ of VMS simultaneously to
match one another. There is a big difference between "cruft"
and deep design decisions that impact portability to different
architectures that were not nearly so tightly coupled with the
software being ported.

>> Linux was ported to the Alpha pretty early on (sponsored by DEC; thanks
>> Mad Dog). So Linux filed off a lot of portability sharp edges for the
>> machines at the time pretty early on, when it was still pretty small;
>> VMS not so much.
>
>Which is reinforcing my point, is it not? That Linux stands a good chance
>of being able to take on enough of a VMS layer to make VMS itself
>unnecessary.

No, it isn't. At least not for those who aren't confused. It
is a comparison of very different things. Your point is simply
unfounded speculation based on fan-boyism and lack of technical
depth.

- Dan C.