Rendez-vous autour de VMS" of January 31 2023 report

[Jan-Erik Söderholm]

English version of the meeting notes:

https://www.vmsgenerations.fr/wp-content/uploads/2023/02/CR-rdv-31-janv-2023-EN.pdf

Rest of the material from the presentations:

https://www.vmsgenerations.fr/rdv-31-jan-2023/

[John Dallman]

In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com

(Jan-Erik Söderholm) wrote:

> English version of the meeting notes:

The license news is good. The ADA news is not, but is hardly unexpected.

Bare metal is a question of market segments, as far as I understand it.
Enterprise IT shops in the US tend to be strongly in favour of
virtualising everything. What is the compelling use case for bare metal?

The costs of bare metal are considerable, since x86 hardware has a vast
range of designs. There are probably 50-100 times more x86-64 server
designs than the total numbers of Alpha and Itanium server designs
produced by DEC, Compaq and HP for running VMS. Supporting it requires
writing enormous numbers of VMS device drivers, a skill that is not at
all common today. The VSI staff who can do it can do other things which
will be more valuable to the company.

Running under virtualisation needs only a few VMS device drivers. The
actual hardware is managed by device drivers for the virtualisation
software. Those are written by the hardware manufacturers so that
virtualisation software can be run on their machines. Those hardware
manufacturers are not going to start writing VMS device drivers unless
VMS becomes /much/ more widely used.

This view may seem negative, but it reflects the commercial reality that
VSI need to cope with.

John

[Arne Vajhøj]

On 2/18/2023 3:41 AM, Jan-Erik Söderholm wrote:
> English version of the meeting notes:
>
> https://www.vmsgenerations.fr/wp-content/uploads/2023/02/CR-rdv-31-janv-2023-EN.pdf

Good news about license.

And a status for x86-64 that matches previous message:

<quote>
On the development tools side, native C, C++ and Fortran compilers should
arrive soon, followed by Basic, Pascal and Cobol with a lower priority.

The debugger is under test and should arrive with v9.2-1.
...
The v9.2-1 delivery is announced for the first half of 2023. The
strategic goal
is sufficient stability to allow customers and ISVs to port their
applications to
x86. It should support AMD processors, offer better performance, most
native compilers, new documentation and a Beta version of OpenJDK.
</quote>

And Oracle status:

<quote>
The 11.2.0.4 version of the Oracle Enterprise database is the last one to be
supported on VMS and as such, potentially subject to a particular long-term
support policy (Market Driven Support).

For the Rdb family of tools, version 7.4 has Premier support until December
2025 and is recommended to all Rdb users.

There were questions about the Oracle VMS client that allows access to
remote databases. This client is not currently planned for VMS x86, the
priority of developments and ports being given to Rdb.
</quote>

Arne

[Arne Vajhøj]

On 2/18/2023 5:41 AM, John Dallman wrote:
> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
> (Jan-Erik Söderholm) wrote:
>> English version of the meeting notes:
>
> The license news is good. The ADA news is not, but is hardly unexpected.

And I think it is worth noting that VSI did not drop Ada. That happended
way before VSI.

I believe DEC/Compaq dropped Ada sometime back in the 90's.

(instead ACT had Ada for VMS - and ACT later dropped VMS as platform.)

Getting the current VSI maintained compilers on VMS x86-64 are
"must haves".

When that is achieved they will need to look at the "nice to have"
list.

And honestly I don't see Ada make the cut.

Ada is a technical very interesting language but business wise it has
it best years behind it.

I see other stuff being way more relevant business wise:
* improving Python on VMS
* improving PHP on VMS
* get node.js running on VMS (either V8 or GraalVM)
* get .NET running on VMS
(maybe even Go, Rust and R)

> Bare metal is a question of market segments, as far as I understand it.
> Enterprise IT shops in the US tend to be strongly in favour of
> virtualising everything. What is the compelling use case for bare metal?
>
> The costs of bare metal are considerable, since x86 hardware has a vast
> range of designs. There are probably 50-100 times more x86-64 server
> designs than the total numbers of Alpha and Itanium server designs
> produced by DEC, Compaq and HP for running VMS. Supporting it requires
> writing enormous numbers of VMS device drivers, a skill that is not at
> all common today. The VSI staff who can do it can do other things which
> will be more valuable to the company.
>
> Running under virtualisation needs only a few VMS device drivers. The
> actual hardware is managed by device drivers for the virtualisation
> software. Those are written by the hardware manufacturers so that
> virtualisation software can be run on their machines. Those hardware
> manufacturers are not going to start writing VMS device drivers unless
> VMS becomes /much/ more widely used.
>
> This view may seem negative, but it reflects the commercial reality that
> VSI need to cope with.

Absolutely correct.

VMS on VM's meet 80% of customers need for 20% of the cost.

Obvious priority.

Arne

[Dan Cross]

In article <memo.20230218...@jgd.cix.co.uk>,

John Dallman <j...@cix.co.uk> wrote:
>In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>(Jan-Erik Söderholm) wrote:
>
>> English version of the meeting notes:
>

>The license news is good. [snip]

Meh.

I'll be blunt: the only reasonable path for VMS to survive
is to open source it under an OSI-approved license. VSI
should dedicated itself to finishing the x86_64 port and
doing the necessary legal work to make that happen, and
then pivot to consulting and services (honestly: this is
what DEC should have done, and it's largely what IBM did
in order to survive in the 00's).

Trying to push VMS as a _product_ at any price point will
undoubtedly lead to an ever-dwindling user base and an
eventual fade into obscure irrelevancy.

- Dan C.

[Michael Kraemer @ home]

Dan Cross wrote:

>
> I'll be blunt: the only reasonable path for VMS to survive
> is to open source it under an OSI-approved license. VSI
> should dedicated itself to finishing the x86_64 port and
> doing the necessary legal work to make that happen, and
> then pivot to consulting and services (honestly: this is
> what DEC should have done, and it's largely what IBM did
> in order to survive in the 00's).
>

what exactly did IBM opensource in the 00's?
MVS? AIX? i? the Tivoli stuff?

[Arne Vajhøj]

On 2/18/2023 3:20 PM, Dan Cross wrote:
> In article <memo.20230218...@jgd.cix.co.uk>,
> John Dallman <j...@cix.co.uk> wrote:
>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>> (Jan-Erik Söderholm) wrote:
>>> English version of the meeting notes:
>>
>> The license news is good. [snip]
>
> Meh.
>
> I'll be blunt: the only reasonable path for VMS to survive
> is to open source it under an OSI-approved license. VSI
> should dedicated itself to finishing the x86_64 port and
> doing the necessary legal work to make that happen,

The general assumption is that VSI can't do that as
they don't own VMS - HPE does.

> and
> then pivot to consulting and services (honestly: this is
> what DEC should have done, and it's largely what IBM did
> in order to survive in the 00's).

IBM did not open source its OS'es. They still make
money selling licenses.

IBM has become a huge general IT consulting
company competing with DXC, CGI, Accenture,
Cap Gemini, TCS, InfoSys, HCL etc..

But it is far from obvious that it would make any
sense for VSI to go that route. It is a very
crowded field - and big companies has huge advantages
when bidding on the big and lucrative contracts.

> Trying to push VMS as a _product_ at any price point will
> undoubtedly lead to an ever-dwindling user base and an
> eventual fade into obscure irrelevancy.

So the suggestion for VSI on how to prevent the
license revenue from decreasing slightly every year
is to let license revenue drop to zero immediately.

I don't think they will buy into that.

Arne

[Dan Cross]

In article <k5crhd...@mid.individual.net>,

JFS, a bunch of stuff that went into Linux, etc, etc,
etc. More importantly, they embraced consulting and
services, which arguably saved them.

- Dan C.

[Dan Cross]

In article <tsrdl6$4bfn$1...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2023 3:20 PM, Dan Cross wrote:
>> In article <memo.20230218...@jgd.cix.co.uk>,
>> John Dallman <j...@cix.co.uk> wrote:
>>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>>> (Jan-Erik Söderholm) wrote:
>>>> English version of the meeting notes:
>>>
>>> The license news is good. [snip]
>>
>> Meh.
>>
>> I'll be blunt: the only reasonable path for VMS to survive
>> is to open source it under an OSI-approved license. VSI
>> should dedicated itself to finishing the x86_64 port and
>> doing the necessary legal work to make that happen,
>
>The general assumption is that VSI can't do that as
>they don't own VMS - HPE does.

Which is why they should start working with HPE now
to make it happen. Sun didn't own SVR4; AT&T did.
Yet somehow OpenSolaris happened.

>> then pivot to consulting and services (honestly: this is
>> what DEC should have done, and it's largely what IBM did
>> in order to survive in the 00's).
>
>IBM did not open source its OS'es. They still make
>money selling licenses.

AIX is dead, replaced by Linux as far as IBM is
concerned. While they do make some money on the
mainframe and iSeries side from licensing, they
make significantly more money selling consulting
and services.

>IBM has become a huge general IT consulting
>company competing with DXC, CGI, Accenture,
>Cap Gemini, TCS, InfoSys, HCL etc..
>
>But it is far from obvious that it would make any
>sense for VSI to go that route. It is a very
>crowded field - and big companies has huge advantages
>when bidding on the big and lucrative contracts.

It worked for RedHat, which was bought for 34
billion USD. By IBM.

>> Trying to push VMS as a _product_ at any price point will
>> undoubtedly lead to an ever-dwindling user base and an
>> eventual fade into obscure irrelevancy.
>
>So the suggestion for VSI on how to prevent the
>license revenue from decreasing slightly every year
>is to let license revenue drop to zero immediately.

No. The suggestion is to pivot into consulting
and services around an open source OS, following
the RedHat model.

>I don't think they will buy into that.

Then VMS is doomed: it's that simple.

- Dan C.

[Dave Froble]

On 2/18/2023 3:20 PM, Dan Cross wrote:

What benefits do you imagine for VSI, for customers, if VSI were to do what you
suggest. Talking about the "open source" issue. That ignores the fact that
they do not have the right to do so, at least with what they got from HP. I've
read that what VSI produces is theirs, and they could do whatever they want with
it. We're pretty sure that any of the Macro-32 and Bliss code isn't from VSI.
But my primary question, what benefits do you see of "open source"?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 2/18/2023 4:01 PM, Dan Cross wrote:
> In article <tsrdl6$4bfn$1...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> IBM has become a huge general IT consulting
>> company competing with DXC, CGI, Accenture,
>> Cap Gemini, TCS, InfoSys, HCL etc..
>>
>> But it is far from obvious that it would make any
>> sense for VSI to go that route. It is a very
>> crowded field - and big companies has huge advantages
>> when bidding on the big and lucrative contracts.
>
> It worked for RedHat, which was bought for 34
> billion USD. By IBM.

Redhat did not go into general consulting like
IBM did.

Redhat went into open source support. Very different
business.

>>> Trying to push VMS as a _product_ at any price point will
>>> undoubtedly lead to an ever-dwindling user base and an
>>> eventual fade into obscure irrelevancy.
>>
>> So the suggestion for VSI on how to prevent the
>> license revenue from decreasing slightly every year
>> is to let license revenue drop to zero immediately.
>
> No. The suggestion is to pivot into consulting
> and services around an open source OS, following
> the RedHat model.

Redhat is/was doing fine.

But there are a few things to remember before
considering VSI going that path.

1) Redhat is doing fine delivering support service. But
they may have done even better if they could also have
charged real license fees, but they cannot because
they mostly did not create the products and the products
are typical under GPL or LGPL. VSI can and do sell
licenses.

2) Redhat doing fine delivering support service benefits
significantly from two facts:
- other companies and volunteers are doing the majority
of the maintenance work on the products they offer
support on
- the products are widely used products, so even
relative low prices generate a lot of of revenue
Neither will be the case for VSI.

Arne

[Arne Vajhøj]

On 2/18/2023 4:15 PM, Dave Froble wrote:
> On 2/18/2023 3:20 PM, Dan Cross wrote:
>> In article <memo.20230218...@jgd.cix.co.uk>,
>> John Dallman <j...@cix.co.uk> wrote:
>>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>>> (Jan-Erik Söderholm) wrote:
>>>
>>>> English version of the meeting notes:
>>>
>>> The license news is good. [snip]
>>
>> Meh.
>>
>> I'll be blunt: the only reasonable path for VMS to survive
>> is to open source it under an OSI-approved license.  VSI
>> should dedicated itself to finishing the x86_64 port and
>> doing the necessary legal work to make that happen, and
>> then pivot to consulting and services (honestly: this is
>> what DEC should have done, and it's largely what IBM did
>> in order to survive in the 00's).
>>
>> Trying to push VMS as a _product_ at any price point will
>> undoubtedly lead to an ever-dwindling user base and an
>> eventual fade into obscure irrelevancy.
>

> What benefits do you imagine for VSI, for customers, if VSI were to do
> what you suggest.  Talking about the "open source" issue.  That ignores
> the fact that they do not have the right to do so, at least with what
> they got from HP.  I've read that what VSI produces is theirs, and they
> could do whatever they want with it.  We're pretty sure that any of the
> Macro-32 and Bliss code isn't from VSI. But my primary question, what
> benefits do you see of "open source"?

The most successful OS (Linux) is open source, so
the idea that open sourcing is good is pretty
easy to get.

But the problem is that open sourcing VMS would
not bring it on the same path as Linux. The context
is too different.

Arne

[Dan Cross]

In article <tsrfpl$4bfn$2...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2023 4:01 PM, Dan Cross wrote:
>> In article <tsrdl6$4bfn$1...@dont-email.me>,
>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> IBM has become a huge general IT consulting
>>> company competing with DXC, CGI, Accenture,
>>> Cap Gemini, TCS, InfoSys, HCL etc..
>>>
>>> But it is far from obvious that it would make any
>>> sense for VSI to go that route. It is a very
>>> crowded field - and big companies has huge advantages
>>> when bidding on the big and lucrative contracts.
>>
>> It worked for RedHat, which was bought for 34
>> billion USD. By IBM.
>
>Redhat did not go into general consulting like
>IBM did.

Talk about not seeing the forest for the trees.

>Redhat went into open source support. Very different
>business.

Note I said both service _and_ consulting.

>>>> Trying to push VMS as a _product_ at any price point will
>>>> undoubtedly lead to an ever-dwindling user base and an
>>>> eventual fade into obscure irrelevancy.
>>>
>>> So the suggestion for VSI on how to prevent the
>>> license revenue from decreasing slightly every year
>>> is to let license revenue drop to zero immediately.
>>
>> No. The suggestion is to pivot into consulting
>> and services around an open source OS, following
>> the RedHat model.
>
>Redhat is/was doing fine.

Yes, they sure are.

>But there are a few things to remember before
>considering VSI going that path.
>
>1) Redhat is doing fine delivering support service. But
> they may have done even better if they could also have
> charged real license fees, but they cannot because
> they mostly did not create the products and the products
> are typical under GPL or LGPL. VSI can and do sell
> licenses.

RedHat got started when the commercial Unix vendors, who did
charge for software, were still in their prime. Which among
them are still selling licenses?

The salient characteristic here is that competition from
operating systems available gratis undercut the market.

>2) Redhat doing fine delivering support service benefits
> significantly from two facts:
> - other companies and volunteers are doing the majority
> of the maintenance work on the products they offer
> support on

What percentage of commits to the Linux git repository come
from authors with an `@redhat.com` email address? How many of
those are for major subsystems? For example, KVM's primary
maintainer is at RedHat.

Moreoever, this sort of ecosystem doesn't exist around VMS
right now because it simply cannot.

> - the products are widely used products, so even
> relative low prices generate a lot of of revenue
> Neither will be the case for VSI.

Yes. Because insistence on an outdated licensing
and revenue model is strangling adoption.

- Dan C.

[Scott Dorsey]

It was a long time ago when T.J. Watson Jr. said that "IBM is not a
computer company-- IBM is a business solutions company." IBM really
never did make their billions selling hardware; if they were in the
hardware business they would have been creamed by the competition.
They just made hardware for their business solutions.

IBM -did- provide a lot of support for the open source movement in
the post-2000 era. But they also provided a lot of open source way
back in the seventies like the IBM Scientific Subroutines Package
which you could run on any computer (but which was optimized for the
360).
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Dan Cross]

In article <tsrf3b$4krc$1...@dont-email.me>,

Dave Froble <da...@tsoft-inc.com> wrote:
>On 2/18/2023 3:20 PM, Dan Cross wrote:
>> In article <memo.20230218...@jgd.cix.co.uk>,
>> John Dallman <j...@cix.co.uk> wrote:
>>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>>> (Jan-Erik Söderholm) wrote:
>>>
>>>> English version of the meeting notes:
>>>
>>> The license news is good. [snip]
>>
>> Meh.
>>
>> I'll be blunt: the only reasonable path for VMS to survive
>> is to open source it under an OSI-approved license. VSI
>> should dedicated itself to finishing the x86_64 port and
>> doing the necessary legal work to make that happen, and
>> then pivot to consulting and services (honestly: this is
>> what DEC should have done, and it's largely what IBM did
>> in order to survive in the 00's).
>>
>> Trying to push VMS as a _product_ at any price point will
>> undoubtedly lead to an ever-dwindling user base and an
>> eventual fade into obscure irrelevancy.
>

>What benefits do you imagine for VSI, for customers,
>if VSI were to do what you suggest. Talking about
>the "open source" issue.

Establishment of a developer ecosystem, crowd-sourced fixes for
bugs, security auditing, and ensuring the longevity of the
software by no longer tying its existence to a very small
company that las recently laying off engineers.

In the meanwhile, VSI can dedicate itself to a long-term
lucrative business model that, realistically speaking if
they're talking about expanding the customer base at all,
they'll have to lean into anyway.

>That ignores the fact that they do not have the right to
>do so, at least with what they got from HP.

You quoted the part of my message that read that they should
begin, "doing the necessary legal work to make that happen."
Obviously this has not yet happened. That does not mean they
should not be working to make it possible.

>I've
>read that what VSI produces is theirs, and they could do whatever they want with
>it. We're pretty sure that any of the Macro-32 and Bliss code isn't from VSI.

Sounds like something lawyers should start talking about. Again
I point to the model of what Sun microsystems was able to do
with open sourcing a System V Unix variant.

>But my primary question, what benefits do you see of "open source"?

Let me turn this around on you: what do you see as the benefits
of a closed-source, for-pay licensing model? How does that
drive sales and benefit customers? How many margin dollars do
they anticipate to make on licensing?

- Dan C.

[Dan Cross]

In article <tsrg9t$4bfn$3...@dont-email.me>,
Arne Vajhøj <ar...@vajhoej.dk> wrote:
>[snip]

>But the problem is that open sourcing VMS would
>not bring it on the same path as Linux. The context
>is too different.

In true USENET fashion, this has been well hashed in this
newsgroup before. But to recap, it's a question of risk
analysis with respect to what is going to drive new use:
adopting a closed-source, proprietary operating system with
time-expiring licensed, maintained by a very small company
that's been laying off engineers in the middle of a
decades-past-due port to the currently dominant hardware platform
(nevermind that the industry is starting to look really hard at
ARM, by the way), leading to legitimate questions about its
long-term viability, or adopting an open-source operating system
backed by a specialized consulting and services firm?

By all indications, VSI is (unfortunately) trying to cater to a
market that no longer exists outside of a few legacy use cases.
That's just not enough for long-term viability.

- Dan C.

[Dave Froble]

On 2/18/2023 5:08 PM, Dan Cross wrote:
> In article <tsrf3b$4krc$1...@dont-email.me>,
> Dave Froble <da...@tsoft-inc.com> wrote:
>> On 2/18/2023 3:20 PM, Dan Cross wrote:
>>> In article <memo.20230218...@jgd.cix.co.uk>,
>>> John Dallman <j...@cix.co.uk> wrote:
>>>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com

Today, I do not see any benefits, and I do see some downside, to the for-pay
licensing model. Nor have I seen such for some years now.

I may have mentioned in the past that I think VMS should be free to use, with
mandatory support for commercial use. I learned long ago that recurring revenue
sure beats one-time revenue.

Thing is, VMS could do without licensing fees, and doesn't need to be open
source to do so. Two different things. So, again, I ask, what benefits might
open source provide. Not much that I can see.

I'm not sure that VSI can finish the port without the added income of license
fees. Don't know.

[Dan Cross]

In article <tsrl70$5dop$1...@dont-email.me>,

As I said above:

Establishment of a developer ecosystem, crowd-sourced fixes
for bugs, security auditing, and ensuring the longevity of
the software by no longer tying its existence to a very
small company that las recently laying off engineers.

It's also a matter of risk management. If I do not have the
source code, how can I ensure that the continued longevity of
the software should VSI fail in the market?

As other vendors have discovered, it is _more_ lucrative to give
the operating system away than to hold it close to the vest.

As to the idea of keeping it closed-source and proprietary, but
freely available, two relatively-recent counter-examples are
BeOS and NeXTStep (and then OpenStep). One could argue that the
latter lives on in macOS, but note that at least the core kernel
there is open source.

Interesting and superior technology always loses relative to
simple economics. Linux is available gratis; VMS is not. Ergo,
VMS cannot compete. 30 years ago, Linux was strictly worse than
VMS in every measurable way; now the inverse is true. This is
not an accident; economics dictate that proprietary will always
lose going forward.

>I'm not sure that VSI can finish the port without the added income of license
>fees. Don't know.

That's a fair point. Note in my original post I said that VSI
should complete the x86_64 port and _then_ figure out how to
open source the OS and pivot to consulting and services.

- Dan C.

[Single Stage to Orbit]

On Sat, 2023-02-18 at 14:30 -0500, Arne Vajhøj wrote:
> And honestly I don't see Ada make the cut.

I don't think that will be an issue, as the GNU compiler suite has
that, and once it's been ported, that will be good enough.
--
Tactical Nuclear Kittens

[Single Stage to Orbit]

On Sat, 2023-02-18 at 14:09 -0500, Arne Vajhøj wrote:
> It should support AMD processors

YESSSSS!

By the many flavoured Ghods, that's great news!
--
Tactical Nuclear Kittens

[Arne Vajhøj]

On 2/18/2023 4:01 PM, Dan Cross wrote:
> In article <tsrdl6$4bfn$1...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/18/2023 3:20 PM, Dan Cross wrote:
>>> In article <memo.20230218...@jgd.cix.co.uk>,
>>> John Dallman <j...@cix.co.uk> wrote:
>>>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>>>> (Jan-Erik Söderholm) wrote:
>>>>> English version of the meeting notes:
>>>>
>>>> The license news is good. [snip]
>>>
>>> Meh.
>>>
>>> I'll be blunt: the only reasonable path for VMS to survive
>>> is to open source it under an OSI-approved license. VSI
>>> should dedicated itself to finishing the x86_64 port and
>>> doing the necessary legal work to make that happen,
>>
>> The general assumption is that VSI can't do that as
>> they don't own VMS - HPE does.
>
> Which is why they should start working with HPE now
> to make it happen. Sun didn't own SVR4; AT&T did.
> Yet somehow OpenSolaris happened.

At that time the SCO group owned it.

But yes somehow they managed to make it happen.

Maybe SUN had some extra rights because they were
part of the development of SVR4. Maybe the fact that
SUN was way bigger than the SCO group made it easier. Or
something else.

But I suspect that VSI would pay more attention to the
business impact of the move than the IP aspects.

It did not work out business wise.

The open sourcing did not stop the decline of Solaris.

After a few years Oracle (that had bought SUN) moved back
to a closed source model.

And the open source version is something that practically
nobody use and very few can even remember the name of (I will
save people the wikipedia search - it is "illumos").

Open sourcing Solaris did not solve Solaris'es
problems.

Maybe it even made them worse.

Not a good example to provide to VSI.

Arne

[Arne Vajhøj]

On 2/18/2023 5:08 PM, Dan Cross wrote:
> In article <tsrf3b$4krc$1...@dont-email.me>,
> Dave Froble <da...@tsoft-inc.com> wrote:
>> What benefits do you imagine for VSI, for customers,
>> if VSI were to do what you suggest. Talking about
>> the "open source" issue.
>
> Establishment of a developer ecosystem, crowd-sourced fixes for
> bugs, security auditing,

That all sounds very nice.

But how does it work for the VMS stuff that are already
open source?

I can tell you: two handful of people are doing all the
work.

It is problematic to find people to maintain the ifdefs
and build scripts of for VMS in many open source projects.

Expecting the community to do serious work on 25 MLOC
is unrealistic.

Arne

[Arne Vajhøj]

On 2/18/2023 6:20 PM, Dan Cross wrote:
> Interesting and superior technology always loses relative to
> simple economics. Linux is available gratis; VMS is not. Ergo,
> VMS cannot compete. 30 years ago, Linux was strictly worse than
> VMS in every measurable way; now the inverse is true. This is
> not an accident; economics dictate that proprietary will always
> lose going forward.

Everybody likes free.

But even though creating an additional copy of software
is free/effortless, then creating the software is not
free/effortless.

Fundamentally it cost the same to create 1 line of
open source code as 1 line of closed source code.

There are some open source projects that can make
it work. Linux is a good example of a huge success.

But there are also some that can't make it work.
My last post mentioned OpenSolaris. But products
like ElasticSearch and Akka are also switching
from open source licenses to different licensing.

Arne

[Arne Vajhøj]

On 2/18/2023 4:47 PM, Dan Cross wrote:
> In article <tsrfpl$4bfn$2...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/18/2023 4:01 PM, Dan Cross wrote:
>>> In article <tsrdl6$4bfn$1...@dont-email.me>,
>>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> But there are a few things to remember before
>> considering VSI going that path.
>>
>> 1) Redhat is doing fine delivering support service. But
>> they may have done even better if they could also have
>> charged real license fees, but they cannot because
>> they mostly did not create the products and the products
>> are typical under GPL or LGPL. VSI can and do sell
>> licenses.
>
> RedHat got started when the commercial Unix vendors, who did
> charge for software, were still in their prime. Which among
> them are still selling licenses?

Most of them are still selling. Oracle is selling Solaris.
IBM is selling AIX. HPE is selling HP-UX. HPE is not selling
Tru64.

They are definitely not selling as well as they did back then.

But that does not change that Redhat did not chose
to open source RHEL, JBoss etc. - it was already open
source and they did not have any way to close source it.

>> 2) Redhat doing fine delivering support service benefits
>> significantly from two facts:
>> - other companies and volunteers are doing the majority
>> of the maintenance work on the products they offer
>> support on
>
> What percentage of commits to the Linux git repository come
> from authors with an `@redhat.com` email address?

It varies per version.

For kernel 5.10 then Redhat did 5.7% of commits with 3.9% of the lines.

For kernel 6.0 the numbers are 5.4% and 2.7%.

I am pretty sure that Redhat in the past has been over 10%.

But whether it is 3% or 5% or 10%, then the remaining 97%/95%/90%
is definitely the majority.

> Moreoever, this sort of ecosystem doesn't exist around VMS
> right now because it simply cannot.

It cannot exist for VMS itself.

It can exist for all sorts of applications and tools.

It just don't.

>> - the products are widely used products, so even
>> relative low prices generate a lot of of revenue
>> Neither will be the case for VSI.
>
> Yes. Because insistence on an outdated licensing
> and revenue model is strangling adoption.

There is a huge server market that are very cost
sensitive (the people that prefer Ubuntu Server
or RockyLinux over RHEL).

There is also a huge market where the cost of VMS is
not a problem - there are still sold a lot
of expensive software.

VSI probably find the second market more attractive
than the first.

Arne

[Arne Vajhøj]

On 2/18/2023 6:16 PM, Single Stage to Orbit wrote:
> On Sat, 2023-02-18 at 14:09 -0500, Arne Vajhøj wrote:
>> It should support AMD processors
>
> YESSSSS!
>
> By the many flavoured Ghods, that's great news!

Note that the above was something I quoted - not my text.

Arne

[Arne Vajhøj]

On 2/18/2023 6:17 PM, Single Stage to Orbit wrote:
> On Sat, 2023-02-18 at 14:30 -0500, Arne Vajhøj wrote:
>> And honestly I don't see Ada make the cut.
>
> I don't think that will be an issue, as the GNU compiler suite has
> that, and once it's been ported, that will be good enough.

But will GCC be ported to VMS (again)?

The last GCC version I have seen run on VMS is 2.8.0
(on VMS Alpha).

And that is a let us call it "not latest and greatest".

:-)

Arne

[John Dallman]

In article <tsrrf3$5qhq$6...@dont-email.me>, ar...@vajhoej.dk (Arne Vajhøj)
wrote:

> On 2/18/2023 6:17 PM, Single Stage to Orbit wrote:
> > On Sat, 2023-02-18 at 14:30 -0500, Arne Vajhøj wrote:
> > > And honestly I don't see Ada make the cut.
> > I don't think that will be an issue, as the GNU compiler suite has
> > that, and once it's been ported, that will be good enough.
> But will GCC be ported to VMS (again)?

Not apparently necessary. AdaCore are working on their LLVM backend for
GNAT <https://github.com/AdaCore/gnat-llvm>. Using this on VMS would
require VMS to be using an up-to-date LLVM, but that's presumably on the
agenda.

John

[Arne Vajhøj]

That would avoid the need for GCC.

But I don't expect ACT to reinstate VMS support.

So someone will need to take the GNAT LLVM stuff and
the VSI LLVM stuff and make it all work on VMS.

Maybe it will happen. Maybe not.

Do you know if the GNAT LLVM thingy will generated binaries
with dependencies on GPL'ed stuff without linking exception
like normal GNAT GPL?

Arne

[bill]

Sounds nice to have an Ada compiler on VMS but don't most of the
people using Ada other than hobbyists require it to be a validated
compiler?

bill

[Single Stage to Orbit]

Wow, jsut wow. 2.8.0? I remember my first time with Linux and GCC
2.7.2.3! And that was the late 90s!
--
Tactical Nuclear Kittens

[Arne Vajhøj]

2.8.0 is indeed from around that time (I don't remember exact year,
but some of the files are timestamped 1998).

$ typ test.c
#include <stdio.h>

int main()
{
printf("Hello world from C!\n");
return 0;
}

$ gcc test.c
$ gcclink test
$ r test
Hello world from C!

If anybody has something newer then I am interested.

C++ seems to be broken. Not sure if it always has been
so or some update did that.

Arne

[Dan Cross]

In article <tsrr9q$5qhq$4...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2023 4:47 PM, Dan Cross wrote:
>> In article <tsrfpl$4bfn$2...@dont-email.me>,
>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> On 2/18/2023 4:01 PM, Dan Cross wrote:
>>>> In article <tsrdl6$4bfn$1...@dont-email.me>,
>>>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> But there are a few things to remember before
>>> considering VSI going that path.
>>>
>>> 1) Redhat is doing fine delivering support service. But
>>> they may have done even better if they could also have
>>> charged real license fees, but they cannot because
>>> they mostly did not create the products and the products
>>> are typical under GPL or LGPL. VSI can and do sell
>>> licenses.
>>
>> RedHat got started when the commercial Unix vendors, who did
>> charge for software, were still in their prime. Which among
>> them are still selling licenses?
>
>Most of them are still selling. Oracle is selling Solaris.
>IBM is selling AIX. HPE is selling HP-UX. HPE is not selling
>Tru64.

Literally every single one of those has been EOL'ed.
Every. Single. One.

>They are definitely not selling as well as they did back then.
>
>But that does not change that Redhat did not chose
>to open source RHEL, JBoss etc. - it was already open
>source and they did not have any way to close source it.

No, but no one could manage to do what RedHat did with a
commercial Unix version.

Why do you think that is?

>[snip commit stats]

>> Moreoever, this sort of ecosystem doesn't exist around VMS
>> right now because it simply cannot.
>
>It cannot exist for VMS itself.

Of course not. Because VMS is closed and proprietary, and
tightly coupled to a handful of platforms that are dead or
dying, and the port to the most important server platform
currently isn't done yet.

Want to move VMS to ARM? Too bad; you can't do it. RISC-V?
Oh well.

>It can exist for all sorts of applications and tools.
>
>It just don't.

See above.

>>> - the products are widely used products, so even
>>> relative low prices generate a lot of of revenue
>>> Neither will be the case for VSI.
>>
>> Yes. Because insistence on an outdated licensing
>> and revenue model is strangling adoption.
>
>There is a huge server market that are very cost
>sensitive (the people that prefer Ubuntu Server
>or RockyLinux over RHEL).
>
>There is also a huge market where the cost of VMS is
>not a problem - there are still sold a lot
>of expensive software.
>
>VSI probably find the second market more attractive
>than the first.

Right now, VSI doesn't seem to have any real market.

I'll be sad when VMS dies because people couldn't see beyond the
way it's always been done.

- Dan C.

[Dan Cross]

In article <tsrpf1$5qhq$1...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2023 4:01 PM, Dan Cross wrote:
>> In article <tsrdl6$4bfn$1...@dont-email.me>,
>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> On 2/18/2023 3:20 PM, Dan Cross wrote:
>>>> In article <memo.20230218...@jgd.cix.co.uk>,
>>>> John Dallman <j...@cix.co.uk> wrote:
>>>>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>>>>> (Jan-Erik Söderholm) wrote:
>>>>>> English version of the meeting notes:
>>>>>
>>>>> The license news is good. [snip]
>>>>
>>>> Meh.
>>>>
>>>> I'll be blunt: the only reasonable path for VMS to survive
>>>> is to open source it under an OSI-approved license. VSI
>>>> should dedicated itself to finishing the x86_64 port and
>>>> doing the necessary legal work to make that happen,
>>>
>>> The general assumption is that VSI can't do that as
>>> they don't own VMS - HPE does.
>>
>> Which is why they should start working with HPE now
>> to make it happen. Sun didn't own SVR4; AT&T did.
>> Yet somehow OpenSolaris happened.
>
>At that time the SCO group owned it.

You might want to check your priors on that and the exact
timelines.

>But yes somehow they managed to make it happen.
>
>Maybe SUN had some extra rights because they were
>part of the development of SVR4. Maybe the fact that
>SUN was way bigger than the SCO group made it easier. Or
>something else.
>
>But I suspect that VSI would pay more attention to the
>business impact of the move than the IP aspects.
>
>It did not work out business wise.
>
>The open sourcing did not stop the decline of Solaris.

Yes, it was too little too late. I know a number of former Sun
employees; they almost universally agree that Sun killed itself
by not seeing the economics of the x86 platform and not
embracing open source until it was too late.

Sound familar?

>After a few years Oracle (that had bought SUN) moved back
>to a closed source model.

Almost immediately, in fact. Remind me, where's Solaris now?

>And the open source version is something that practically
>nobody use and very few can even remember the name of (I will
>save people the wikipedia search - it is "illumos").

Now I'm quite sure you're not very familiar with that ecosystem.

Lots more people are using illumos in one form or another than
are using Solaris. SmarOS, Joyent, MNX, Oxide and others are
all using illumos. Who's using Solaris, again?

>Open sourcing Solaris did not solve Solaris'es
>problems.
>
>Maybe it even made them worse.

Oh? How do you figure? Please be specific. Or is that just
idle speculation?

>Not a good example to provide to VSI.

No, Linux is the example here. It's also VSI's primary
competition. Indeed, the tragedy of Solaris reinforces the
thesis that open sourcing is really the only way to go; pointing
out the failure Solaris shows what happens if you _don't_
embrace open source in a timely manner. Or are you simply
saying that VMS can't compete against Linux and is doomed to
failure anyway?

Regardless of all that, however, I'm afraid you missed the point
of the example. The Solaris example is about how an
organization _can_ wrangle the legalities to get something open
sourced, despite similar challenges to VSIs vis ownership of the
code. Solaris is not a model of how to manage open source per
se; simply a roadmap to doing it at all.

- Dan C.

[Dan Cross]

In article <tsrpoc$5qhq$2...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2023 5:08 PM, Dan Cross wrote:
>> In article <tsrf3b$4krc$1...@dont-email.me>,
>> Dave Froble <da...@tsoft-inc.com> wrote:
>>> What benefits do you imagine for VSI, for customers,
>>> if VSI were to do what you suggest. Talking about
>>> the "open source" issue.
>>
>> Establishment of a developer ecosystem, crowd-sourced fixes for
>> bugs, security auditing,
>
>That all sounds very nice.
>
>But how does it work for the VMS stuff that are already
>open source?
>
>I can tell you: two handful of people are doing all the
>work.

Yes. Because there is no incentive for anyone else, because VMS
is clinging to an antiquated closed model and maintainers see it
as a dead platform. Do you not see that as a problem?

>It is problematic to find people to maintain the ifdefs
>and build scripts of for VMS in many open source projects.

Have you ever stopped to wonder why that is, and how one might
go about changing it?

>Expecting the community to do serious work on 25 MLOC
>is unrealistic.

It is unrealistic to expect VMS to be able to compete against
Linux with the current model. It's a shame that so many VMS
users are perfectly ok with that.

- Dan C.

[Dan Cross]

In article <tsrqg0$5qhq$3...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2023 6:20 PM, Dan Cross wrote:
>> Interesting and superior technology always loses relative to
>> simple economics. Linux is available gratis; VMS is not. Ergo,
>> VMS cannot compete. 30 years ago, Linux was strictly worse than
>> VMS in every measurable way; now the inverse is true. This is
>> not an accident; economics dictate that proprietary will always
>> lose going forward.
>
>Everybody likes free.
>
>But even though creating an additional copy of software
>is free/effortless, then creating the software is not
>free/effortless.

Non-sequitur.

>Fundamentally it cost the same to create 1 line of
>open source code as 1 line of closed source code.

False. It is amortized over every contributor versus having one
organization shoulder the entire cost.

>There are some open source projects that can make
>it work. Linux is a good example of a huge success.
>
>But there are also some that can't make it work.
>My last post mentioned OpenSolaris. But products
>like ElasticSearch and Akka are also switching
>from open source licenses to different licensing.

You fundamentally missed the point of the Solaris reference in
my earlier post.

Let's turn this around: what do you think that VMS's future
prospects look like?

[Michael Kraemer @ home]

Dan Cross wrote:
> In article <k5crhd...@mid.individual.net>,
> Michael Kraemer @ home <M.Kr...@gsi.de> wrote:
>
>>Dan Cross wrote:
>>

>>>I'll be blunt: the only reasonable path for VMS to survive
>>>is to open source it under an OSI-approved license. VSI
>>>should dedicated itself to finishing the x86_64 port and

>>>doing the necessary legal work to make that happen, and
>>>then pivot to consulting and services (honestly: this is
>>>what DEC should have done, and it's largely what IBM did
>>>in order to survive in the 00's).
>>

>>what exactly did IBM opensource in the 00's?
>>MVS? AIX? i? the Tivoli stuff?
>
>
> JFS,

most certainly not.
Maybe GPFS, but not JFS[2].
Wouldn't make sense anyway,
ripping an integral part off the OS,
in the hope some community will take care of it.

a bunch of stuff that went into Linux, etc, etc,
> etc.

Would be interesting to learn about the etc, etc, etc.

[Michael Kraemer @ home]

Latest release of AIX (7.3) was end 2021,
about one year ago.
And two years *after* IBM acquired RH.
Doesn't sound like EOL to me.

[John Dallman]

In article <tsrmfk$b8i$1...@reader2.panix.com>,

cr...@spitfire.i.gajendra.net (Dan Cross) wrote:

> Establishment of a developer ecosystem, crowd-sourced fixes

> for bugs, security auditing . . .

Can you be confident these things would happen?

The VMS user community is mostly fairly old, and has habits built around
getting their OS from someone else. Their skills are stronger in
application programming than systems programming, and there's much more
of a distinction between those styles on VMS than on UNIX/Linux. VMS
application programming tends to use different languages (Basic, COBOL,
Fortran) from systems programming (Macro, BLISS, C).

People from the wider open source community would be facing an alien
environment that uses weird programming languages. They'd also have to
work with plenty of people who think things were better when DEC was
around.

It seems likely to me that an open source VMS would not develop a large
enough community to keep it going. Plenty of open source projects fail.

John

[John Dallman]

In article <tsrutc$6bvd$1...@dont-email.me>, ar...@vajhoej.dk (Arne Vajhøj)
wrote:

> Do you know if the GNAT LLVM thingy will generated binaries
> with dependencies on GPL'ed stuff without linking exception
> like normal GNAT GPL?

I'm afraid I don't know.

John

[Scott Dorsey]

John Dallman <j...@cix.co.uk> wrote:
>In article <tsrmfk$b8i$1...@reader2.panix.com>,
>cr...@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> Establishment of a developer ecosystem, crowd-sourced fixes
>> for bugs, security auditing . . .
>
>Can you be confident these things would happen?

There are many, many open source operating systems where that never happened.
There are two very popular ones where it did. Maybe three if you want to
count ReactOS. Statistically speaking, your chances are not very good.

>People from the wider open source community would be facing an alien
>environment that uses weird programming languages. They'd also have to
>work with plenty of people who think things were better when DEC was
>around.
>
>It seems likely to me that an open source VMS would not develop a large
>enough community to keep it going. Plenty of open source projects fail.

The vast majority of open source projects fail. The good news is that
they are still usable and maintainable when they do, becase there is source.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arne Vajhøj]

On 2/18/2023 10:06 PM, Dan Cross wrote:
> In article <tsrpoc$5qhq$2...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/18/2023 5:08 PM, Dan Cross wrote:
>>> In article <tsrf3b$4krc$1...@dont-email.me>,
>>> Dave Froble <da...@tsoft-inc.com> wrote:
>>>> What benefits do you imagine for VSI, for customers,
>>>> if VSI were to do what you suggest. Talking about
>>>> the "open source" issue.
>>>
>>> Establishment of a developer ecosystem, crowd-sourced fixes for
>>> bugs, security auditing,
>>
>> That all sounds very nice.
>>
>> But how does it work for the VMS stuff that are already
>> open source?
>>
>> I can tell you: two handful of people are doing all the
>> work.
>
> Yes. Because there is no incentive for anyone else, because VMS
> is clinging to an antiquated closed model and maintainers see it
> as a dead platform. Do you not see that as a problem?
>
>> It is problematic to find people to maintain the ifdefs
>> and build scripts of for VMS in many open source projects.
>
> Have you ever stopped to wonder why that is, and how one might
> go about changing it?

It is not obvious to me why VMS being open source should
make it more attractive to develop open source on VMS.

There is no (non-religious) reason for an open source developer
to not develop open source on a closed source OS.

Back in the days the commercial Unix'es did not seem
to have a problem attracting open source developers.

Back in the same days a lot of free stuff (which today
would have gotten an open source license slapped on)
was available for VMS - VMS SIG tapes and L&T SIG tapes
were full of such stuff. VMS not being free did not
prevent that.

The Java world (here I am going with Bjarne's "Java isn't
platform independent; it is a platform") saw a flood
of open source before OpenJDK.

Open source simply requires people developing
open source.

A couple of well known quotes:

Benjamin Franklin - Well done is better than well said

John F Kennedy - Ask not what your country can do for you – ask what you
can do for your country

VMS does not need people that say:
- VSI please open source VMS
- someone please port GNAT to VMS
- someone please port Rust to VMS
- someone please port XYZ to VMS

VMS need people that say:
- I have ported XYZ to VMS
- I have created ABC on VMS

Arne

[Arne Vajhøj]

You can state that and sound totally convincing.

The problem is that everybody that know how to use
basic search on the internet can detect that it is
a lie.

AIX:

AIX 7.3. TL1 was released in December 2022.

https://www.ibm.com/support/pages/aix-support-lifecycle-information
states that IBM supports AIX 7.3 TL1 until end of 2025.

HP-UX:

There was an update to HP-UX 11iv3 in May 2022.

https://www.hpe.com/psnow/doc/4AA4-7673ENW states that HPE supports
HP-UX 11iv3 (on Integrity) until at least end of 2025.

Solaris:

Solaris 11.4 SRU53 was release in January 2023.

https://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pdf
says that Oracle will support Solaris 11.4 until
November 2021 / November 2034.

Do they have a future? No or probably not.

(HP-UX will die with Itanium, Oracle has clearly indicated that they
are putting much effort into Solaris, IBM did not invest in Redhat
to push AIX)

But they are not EOL today. And will not be for several years.

>> But that does not change that Redhat did not chose
>> to open source RHEL, JBoss etc. - it was already open
>> source and they did not have any way to close source it.
>
> No, but no one could manage to do what RedHat did with a
> commercial Unix version.

In their days the commercial unixes did pretty well.

Arne

[Single Stage to Orbit]

On Sat, 2023-02-18 at 21:24 -0500, Arne Vajhøj wrote:
> > Wow, jsut wow. 2.8.0? I remember my first time with Linux and GCC
> > 2.7.2.3! And that was the late 90s!
>
> 2.8.0 is indeed from around that time (I don't remember exact year,
> but some of the files are timestamped 1998).

2.7.2.3 came out in August 1997, whilst 2.8.0 was released in Jan 1997.

I was just looking at my current GCC compiler (12.2.1) documentation
and it looks like it still has support for Alpha, VAX but not Itanium
(couldn't find it!)
--
Tactical Nuclear Kittens

[Dave Froble]

A question I'd ask, is, would Linux have done so well, if it was nothing more
than "free Unix"?


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[John Dallman]

In article <30161176eef6c71f0b2fcd6...@munted.eu>,

alex....@munted.eu (Single Stage to Orbit) wrote:

> I was just looking at my current GCC compiler (12.2.1) documentation
> and it looks like it still has support for Alpha, VAX but not
> Itanium (couldn't find it!)

It's there:

<https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/IA-64-Options.html>

John

[Scott Dorsey]

Dave Froble <da...@tsoft-inc.com> wrote:
>
>A question I'd ask, is, would Linux have done so well, if it was nothing more
>than "free Unix"?

When Linux was new, that was all it was. There were some competitors like
xinu and minix, but Linux actually provided a full functional system. Because
it was unixlike, there was plenty of existing software for it (including the
whole gnu back catalogue). Because it was free, the barriers to entry were
very low.

One might ask if VMS would have done so well if it hadn't come with the Vax.
Lots of folks bought VMS because of the hardware, not because of the software.
Those folks were the first to abandon ship when the cheap and fast workstations
came out in the eighties. (I'm talking here of mostly development folks and
scientific computing folks who weren't so tied to architecture and who were
very sensitive to price/performance.)

[Arne Vajhøj]

> A question I'd ask, is, would Linux have done so well, if it was nothing
> more than "free Unix"?

I am pretty sure that it was not the technical differences
between Linux and Unix that made Linux beat the
commercial Unixes.

License cost must have been a huge factor. Directly: companies
liked to avoid the license fee. But also indirectly: students
learned Linux because it was free and companies liked an
OS where their new hires had skill.

But there was also hardware cost. Solaris, AIX, HP-UX and
Tru64 was running on expensive hardware while Linux ran
on cheaper x84-64 hardware (Solaris did also support x86-64
besides the primary platform SPARC).

And then there is the vendor independence. With Linux you
were not tied to SUN/IBM/HP/DEC. Some companies liked that.
Especially after all the Unix chaos with OSF vs UI and
the nasty interaction between usage of different code bases
and corporate business strategies.

But there were also free Unixes running on x86-64 available
back then. Why Linux and not them? My best guess is that
Linux had better "marketing" - not traditional marketing
aka slick sales people selling to big companies, but the
internet developer to developer talk type of marketing -
Linux was cool while *BSD was old.

Arne

[Dan Cross]

In article <k5e9re...@mid.individual.net>,

Michael Kraemer @ home <M.Kr...@gsi.de> wrote:
>Dan Cross wrote:
>> In article <k5crhd...@mid.individual.net>,
>> Michael Kraemer @ home <M.Kr...@gsi.de> wrote:
>>
>>>Dan Cross wrote:
>>>
>>>>I'll be blunt: the only reasonable path for VMS to survive
>>>>is to open source it under an OSI-approved license. VSI
>>>>should dedicated itself to finishing the x86_64 port and
>>>>doing the necessary legal work to make that happen, and
>>>>then pivot to consulting and services (honestly: this is
>>>>what DEC should have done, and it's largely what IBM did
>>>>in order to survive in the 00's).
>>>
>>>what exactly did IBM opensource in the 00's?
>>>MVS? AIX? i? the Tivoli stuff?
>>
>> JFS,
>
>most certainly not.
>Maybe GPFS, but not JFS[2].

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/fs/jfs?h=next-20230217

>Wouldn't make sense anyway,
>ripping an integral part off the OS,
>in the hope some community will take care of it.

See above.

>a bunch of stuff that went into Linux, etc, etc,
>> etc.
>
>Would be interesting to learn about the etc, etc, etc.

: spitfire; pwd
/home/cross/reference/linux
: spitfire; git log | grep '^Author: .*ibm.com' | wc -l
24615
: spitfire;

Feel free to browse the commits. Evidently some
will be very surprising to you.

- Dan C.

[Dan Cross]

In article <k5ea4n...@mid.individual.net>,

Michael Kraemer @ home <M.Kr...@gsi.de> wrote:

https://www.theregister.com/2023/01/17/unix_is_dead/

- Dan C.

[bill]

On 2/19/2023 3:17 PM, Scott Dorsey wrote:
>
> One might ask if VMS would have done so well if it hadn't come with the Vax.

Time to trot out one of my favorite anecdotes.

Working on a RFP for a mini-computer. My employer was offering
A Prime 50-Series. Only competitor was DEC offering an as yet
non-existent VAX Model. RFP required a benchmark. We showed up
with several boxes of green-bar with results. DEC showed up with
and envelope containing a letter that stated: "Here is what it
would do if we actually had one to test." The person driving the
bus was an Astronomy Professor. He closed the meeting with the
statement I don't care who wins as long as it says VAX on the front.
We withdrew. He got his VAX. Well, a smaller slower VAX than what
he wanted but they promised him the better one in a year or so.
The best part of it was he got all the Astronomy programs he wanted
to run from Kitt's Peak Observatory. They were all for BSD. :-)

But the point is it was a VAX he wanted, no necessarily VMS. I
expect al lot of the early VMS sites started that way and then just
grew to be stuck on VMS.

bill

[Dan Cross]

In article <tstaid$dhc4$2...@dont-email.me>,

I think the problem here is that you lack the sophistication to
understand that small security releases (likely as part of
ongoing contractual obligations) do not mean that something
isn't EOL'ed.

>AIX:
>
>AIX 7.3. TL1 was released in December 2022.
>
>https://www.ibm.com/support/pages/aix-support-lifecycle-information
>states that IBM supports AIX 7.3 TL1 until end of 2025.

Such long lead times! A little under three years! What a smart
time to invest in AIX.

>HP-UX:
>
>There was an update to HP-UX 11iv3 in May 2022.
>
>https://www.hpe.com/psnow/doc/4AA4-7673ENW states that HPE supports
>HP-UX 11iv3 (on Integrity) until at least end of 2025.

WOW, so alive....

>Solaris:
>
>Solaris 11.4 SRU53 was release in January 2023.
>
>https://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pdf
>says that Oracle will support Solaris 11.4 until
>November 2021 / November 2034.

You'll noticed that Solaris 12 has disappeared form Oracle's
roadmap.

>Do they have a future? No or probably not.
>
>(HP-UX will die with Itanium, Oracle has clearly indicated that they
>are putting much effort into Solaris, IBM did not invest in Redhat
>to push AIX)
>
>But they are not EOL today. And will not be for several years.

I can still buy licenses for VMS for VAX from HPE; does that
mean that OpenVMS/VAX hasn't been EOL'ed?

>>> But that does not change that Redhat did not chose
>>> to open source RHEL, JBoss etc. - it was already open
>>> source and they did not have any way to close source it.
>>
>> No, but no one could manage to do what RedHat did with a
>> commercial Unix version.
>
>In their days the commercial unixes did pretty well.

Times change.

- Dan C.

[Arne Vajhøj]

The headline says that Unix is dead.

Those that only read the headline may think that means
all Unix is EOL.

Those that read the content below the headline will
see that it just says that AIX, Solaris and HP-UX
are in "maintenance mode", which by definition is
not EOL.

Arne

[Dan Cross]

Dave Froble <da...@tsoft-inc.com> wrote:
>A question I'd ask, is, would Linux have done so well, if it was nothing more
>than "free Unix"?

Linux was in the right place at the right time. The industry as
a whole was trying to move away from Unix, in no small part due
to AT&T having been freed from the shackles of consent decrees
and attempting to enter the computer market. They had Unix, and
Unix had become the "open system" of record, so they wanted to
exercise control over the considerable financial pie that had
baked around Unix. Simultaneously, 20 years of research into
systems had been (at best) haphazardly retrofitted onto Unix,
which had become a bloated mess and people legitimately thought
that moving systems in new technical directions was the right
way to go. Remember the hype around microkernels?

Meanwhile, the whole industry missed three critical factors: the
power of installed base and source-level compatibility across
Unix variatns; Moore's law the in particular the implications
this had for making cheap x86 machines performance competitive
against much larger workstation and server-class machines at a
fraction of the cost; the emotional attachment people had to
systems beyond any rational basis for favor.

So people wanted Unix, and Unix was getting hard to get. UC
Berkeley had produced a port that removed almost all of the
AT&T code from the base system, but of course AT&T sued
Berkeley over that. Enter Linux: a from-scratch
reimplementation of the basic system interface, but unencumbered
in any way by AT&T/USL copyright. Oh, and it ran on cheap PCs,
not expensive workstations.

I remember at one point in the mid-90s someone showed me a PC
they had bought. It was maybe half as good as a mid-range Sun
workstation, but at a quarter of the cost. Moreover, PCs were
getting better for the cost faster than workstations were; it
was therefore axiomatic that at some point the price/performance
curves would cross, and that the future was not in the
workstation market. Of course, the same thing had happened to
the minicomputer market a decade prior.

So as PCs got better and better, the price of hardware started
driving towards zero. These days, I can buy a Raspberry Pi for
USD 100 that gives performance comparable to a top-of-the-line
gaming rig from a decade ago.

In that environment, software costs start to dominate, at which
point there's a strong incentive to drive those towards zero, as
well; using a gratis operating system becomes almost a given.

The next big cost center, of course, is on support; but by using
a common offering (like Linux), one can amortize that with
economies of scale.

In article <tsu03v$8td$1...@panix2.panix.com>,

Scott Dorsey <klu...@panix.com> wrote:
>When Linux was new, that was all it was. There were some competitors like
>xinu and minix, but Linux actually provided a full functional system. Because
>it was unixlike, there was plenty of existing software for it (including the
>whole gnu back catalogue). Because it was free, the barriers to entry were
>very low.

Neither Xinu nor Linux was a competitor to Linux; both were
pedagogical systems designed for teaching. I do think they
filled a bit of a niche among enthusiasts, but Linux's early
competitors were things like COHERENT (absolutely killed by
Linux) and commercial distributions of System V. I suppose
Arne will now tell us those are doing just fine.

>One might ask if VMS would have done so well if it hadn't come with the Vax.
>Lots of folks bought VMS because of the hardware, not because of the software.
>Those folks were the first to abandon ship when the cheap and fast workstations
>came out in the eighties. (I'm talking here of mostly development folks and
>scientific computing folks who weren't so tied to architecture and who were
>very sensitive to price/performance.)

Just so. Hence, if one wishes to see VMS survive, one must find
a way to make VMS attractive to new developers and so on.

- Dan C.

[Scott Dorsey]

Dan Cross <cr...@spitfire.i.gajendra.net> wrote:
>Scott Dorsey <klu...@panix.com> wrote:
>>When Linux was new, that was all it was. There were some competitors like
>>xinu and minix, but Linux actually provided a full functional system. Because
>>it was unixlike, there was plenty of existing software for it (including the
>>whole gnu back catalogue). Because it was free, the barriers to entry were
>>very low.
>
>Neither Xinu nor Linux was a competitor to Linux; both were
>pedagogical systems designed for teaching. I do think they
>filled a bit of a niche among enthusiasts, but Linux's early
>competitors were things like COHERENT (absolutely killed by
>Linux) and commercial distributions of System V. I suppose
>Arne will now tell us those are doing just fine.

Linux was ALSO a pedagogical system designed for teaching, and came very
stripped down without much more than a kernel at first. But it grew.
And folks added other stuff into the distribution, most of it from gnu.

It took a couple years before Linux was able to compete with something
like COHERENT or QNX.

[Dan Cross]

In article <tsu14t$g5l7$1...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/19/2023 1:12 PM, Dave Froble wrote:
>> On 2/19/2023 9:09 AM, Arne Vajhøj wrote:
>>> On 2/18/2023 9:49 PM, Dan Cross wrote:
>>>> No, but no one could manage to do what RedHat did with a
>>>> commercial Unix version.
>>>
>>> In their days the commercial unixes did pretty well.
>>
>> A question I'd ask, is, would Linux have done so well, if it was nothing
>> more than "free Unix"?
>
>I am pretty sure that it was not the technical differences
>between Linux and Unix that made Linux beat the
>commercial Unixes.

Not at the time, nope.

>License cost must have been a huge factor. Directly: companies
>liked to avoid the license fee. But also indirectly: students
>learned Linux because it was free and companies liked an
>OS where their new hires had skill.
>
>But there was also hardware cost. Solaris, AIX, HP-UX and
>Tru64 was running on expensive hardware while Linux ran
>on cheaper x84-64 hardware (Solaris did also support x86-64
>besides the primary platform SPARC).

x86_64 didn't exist when this was happening. It came in
2000 or so. There's an ironic DEC tie-in, but that's
another story.

>And then there is the vendor independence. With Linux you
>were not tied to SUN/IBM/HP/DEC. Some companies liked that.

"Sun" not "SUN"

>Especially after all the Unix chaos with OSF vs UI and
>the nasty interaction between usage of different code bases
>and corporate business strategies.
>
>But there were also free Unixes running on x86-64 available
>back then. Why Linux and not them? My best guess is that
>Linux had better "marketing" - not traditional marketing
>aka slick sales people selling to big companies, but the
>internet developer to developer talk type of marketing -
>Linux was cool while *BSD was old.

Nope. It had more to do with the USL/UCB lawsuit and the
presumed effect that that would have on the freely-available
BSD code. Since Linux was a clean-room reimplementation, it
wasn't encumbered by AT&T copyright, and would thus be "safe"
should AT&T win in court.

What's ironic is that the people making these decisions didn't
quite understand the AT&T lawsuit, which was about _trade secret
status_ of Unix, not copyright. AT&T was trying to say that it
was the system interface that was the real intellectual property
that was being violated, not the specific expression of that
interface. This would have affected Linux, too, despite being
an independent reimplementation.

Fortunately, the court sided with Berkeley and rejected USL's
trade secret claims on the basis that the system interface was
well documented and had been in the industry for decades (and
that Ken and Dennis used to mail tapes to universities for the
cost of media and shipping).

- Dan C.

[Arne Vajhøj]

The term EOL has a very specific meaning in software.

If bugfixes get released by the vendor then it is not EOL.

>> AIX:
>>
>> AIX 7.3. TL1 was released in December 2022.
>>
>> https://www.ibm.com/support/pages/aix-support-lifecycle-information
>> states that IBM supports AIX 7.3 TL1 until end of 2025.
>
> Such long lead times! A little under three years! What a smart
> time to invest in AIX.

If there will not be a TL2 with another EOL date, then it would
indeed not be long.

But expect IBM to roll out more TL's.

>> HP-UX:
>>
>> There was an update to HP-UX 11iv3 in May 2022.
>>
>> https://www.hpe.com/psnow/doc/4AA4-7673ENW states that HPE supports
>> HP-UX 11iv3 (on Integrity) until at least end of 2025.
>
> WOW, so alive....
>
>> Solaris:
>>
>> Solaris 11.4 SRU53 was release in January 2023.
>>
>> https://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pdf
>> says that Oracle will support Solaris 11.4 until
>> November 2021 / November 2034.
>
> You'll noticed that Solaris 12 has disappeared form Oracle's
> roadmap.

Yes. But that does not make Solaris EOL.

>> Do they have a future? No or probably not.
>>
>> (HP-UX will die with Itanium, Oracle has clearly indicated that they
>> are putting much effort into Solaris, IBM did not invest in Redhat
>> to push AIX)
>>
>> But they are not EOL today. And will not be for several years.
>
> I can still buy licenses for VMS for VAX from HPE; does that
> mean that OpenVMS/VAX hasn't been EOL'ed?

Again EOL has a very specific meaning.

If HPE is still providing support for what they sell
then it is not EOL.

But I am pretty sure that VMS 7.3 (last version with VAX support)
is EOL.

Anybody that can confirm when 7.3 officially went EOL?

Arne

[Dan Cross]

In article <memo.20230219...@jgd.cix.co.uk>,

John Dallman <j...@cix.co.uk> wrote:
>In article <tsrmfk$b8i$1...@reader2.panix.com>,
>cr...@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> Establishment of a developer ecosystem, crowd-sourced fixes
>> for bugs, security auditing . . .
>
>Can you be confident these things would happen?

No, I can only say that they will happen with p between 0 and 1.

But I _can_ confidently say that they will NOT happen without
open-sourcing.

>The VMS user community is mostly fairly old, and has habits built around
>getting their OS from someone else. Their skills are stronger in
>application programming than systems programming, and there's much more
>of a distinction between those styles on VMS than on UNIX/Linux. VMS
>application programming tends to use different languages (Basic, COBOL,
>Fortran) from systems programming (Macro, BLISS, C).
>
>People from the wider open source community would be facing an alien
>environment that uses weird programming languages. They'd also have to
>work with plenty of people who think things were better when DEC was
>around.
>
>It seems likely to me that an open source VMS would not develop a large
>enough community to keep it going. Plenty of open source projects fail.

Here's the difference: if a company is sufficiently invested in
VMS and the source is out there, then they _can_ invest in the
talent and development environment necessary to take things on
themselves. Is it a pain? Yes. But it's less of a risk than
relying on only a single source.

- Dan C.

[Dan Cross]

In article <tst72r$r3d$1...@panix2.panix.com>,

Just so.

- Dan C.

[Dan Cross]

In article <tst9dd$dhc4$1...@dont-email.me>,

It's prohibitively expensive to do so today. Should commercial
vendors port to OpenVMS using the hobbyist program? How about
open source vendors?

>There is no (non-religious) reason for an open source developer
>to not develop open source on a closed source OS.

Cost.

>Back in the days the commercial Unix'es did not seem
>to have a problem attracting open source developers.

That was then. Commercial Unix is dead. Ok, all-but-dead, to
satisfy the pedants who seem incapable of seeing the big picture
instead of arguing the finer points of the details ad nauseum.

>Back in the same days a lot of free stuff (which today
>would have gotten an open source license slapped on)
>was available for VMS - VMS SIG tapes and L&T SIG tapes
>were full of such stuff. VMS not being free did not
>prevent that.

That was then, this is now. Back then, Linux didn't exist and
hardware was expensive; it made sense to port to whatever
proprietary platform you were on because switching was a major
capital investment. These days, I could spin up a virtual
machine on my desktop in a matter of minutes, so what's the
point?

>The Java world (here I am going with Bjarne's "Java isn't
>platform independent; it is a platform") saw a flood
>of open source before OpenJDK.

Non-sequitur.

>Open source simply requires people developing
>open source.

...which requires an incentive, which no one has for VMS. Very
few people in the open source world are running it, so why would
they develop for it? What incentive does anyone have to develop
for a closed proprietary platform controlled by a single, small
company?

>A couple of well known quotes:
>
>Benjamin Franklin - Well done is better than well said
>
>John F Kennedy - Ask not what your country can do for you – ask what you
>can do for your country

So I know a lot about OS implementation on x86, but have no
practical way to contribute to getting OpenVMS running. Oh
well.

>VMS does not need people that say:
>- VSI please open source VMS
>- someone please port GNAT to VMS
>- someone please port Rust to VMS
>- someone please port XYZ to VMS
>
>VMS need people that say:
>- I have ported XYZ to VMS
>- I have created ABC on VMS

How, pray tell, is one going to cooperate in, say, porting GNAT
or Rust or LLVM to VMS, when all that development is being done
in a highly proprietary context that by its very nature
precludes collaboration? Suppose somebody finds a latent bug in
the OS that's tickled by the new compiler; how does one help get
that fixed without the source code? Sure, provide a really good
bug report, but none of that helps people do what you claim VMS
needs above.

- Dan C.

[Dan Cross]

In article <tsu3r4$gfrl$1...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/19/2023 3:56 PM, Dan Cross wrote:
>> In article <k5ea4n...@mid.individual.net>,
>> Michael Kraemer @ home <M.Kr...@gsi.de> wrote:
>>> Dan Cross wrote:
>>>> In article <tsrr9q$5qhq$4...@dont-email.me>,
>>>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>>> Most of them are still selling. Oracle is selling Solaris.
>>>>> IBM is selling AIX. HPE is selling HP-UX. HPE is not selling
>>>>> Tru64.
>>>>
>>>>
>>>> Literally every single one of those has been EOL'ed.
>>>> Every. Single. One.
>>>
>>> Latest release of AIX (7.3) was end 2021,
>>> about one year ago.
>>> And two years *after* IBM acquired RH.
>>> Doesn't sound like EOL to me.
>>
>> https://www.theregister.com/2023/01/17/unix_is_dead/
>
>The headline says that Unix is dead.

Yup. Commercial Unix is dead, your quibbling not withstanding.

>Those that only read the headline may think that means
>all Unix is EOL.
>
>Those that read the content below the headline will
>see that it just says that AIX, Solaris and HP-UX
>are in "maintenance mode", which by definition is
>not EOL.

Who's definiton? Yours, I suppose.

"Depending on the vendor, end-of-life may differ from end of
service life, which has the added distinction that a vendor of
systems or software will no longer provide maintenance,
troubleshooting or other support."

- Dan C.

[Dan Cross]

In article <tsu4h0$13i$1...@panix2.panix.com>,

Scott Dorsey <klu...@panix.com> wrote:
>Dan Cross <cr...@spitfire.i.gajendra.net> wrote:
>>Scott Dorsey <klu...@panix.com> wrote:
>>>When Linux was new, that was all it was. There were some competitors like
>>>xinu and minix, but Linux actually provided a full functional system. Because
>>>it was unixlike, there was plenty of existing software for it (including the
>>>whole gnu back catalogue). Because it was free, the barriers to entry were
>>>very low.
>>
>>Neither Xinu nor Linux was a competitor to Linux; both were
>>pedagogical systems designed for teaching. I do think they
>>filled a bit of a niche among enthusiasts, but Linux's early
>>competitors were things like COHERENT (absolutely killed by
>>Linux) and commercial distributions of System V. I suppose
>>Arne will now tell us those are doing just fine.
>
>Linux was ALSO a pedagogical system designed for teaching, and came very

This is emphatically not true.

Linux started as a personal project of Linus Torvalds after he
grew frustrated with Minix, but was never designed for teaching.
Succinctly, he wanted something that was a real Unix, not a
teaching system. Andy Tannenbaum wasn't interested in that.

In fact, Linux was heavily (and famously) criticized by
Tannenbaum for not being sufficiently influenced by the current
at the time academic thinking.

>stripped down without much more than a kernel at first. But it grew.

That is true.

>And folks added other stuff into the distribution, most of it from gnu.

This is not true. People created distributions around the Linux
kernel that bundled GNU utilities and so forth, but that has
always been separate from Linux itself (which is just the
kernel). There are also distributions that don't contain GNU
code, such as Alpine Linux.

>It took a couple years before Linux was able to compete with something
>like COHERENT or QNX.

Yeah, like 2 to become better than COHERENT. Torvalds announced
Linux in August, 1991; MWC (producers of COHERENT) went defunct
in 1995 following several years of sales collapse due to
competition from Linux.

Many would argue that Linux is still not particuarly competitive
against QNX, which occupies a specific market niche.

- Dan C.

[Dan Cross]

In article <tsu4oc$gfrl$2...@dont-email.me>,

Citation needed.

[John Dallman]

In article <tsu4mu$fuk$2...@reader2.panix.com>,

cr...@spitfire.i.gajendra.net (Dan Cross) wrote:

> x86_64 didn't exist when this was happening. It came in
> 2000 or so.

2003. The timing is important, because by then it was clear to alert
organisations that Itanium was a turkey, and they were ready to consider
something else. HP's insistence on sticking with Itanium finished off VMS
in the technical and scientific fields.

John

[John Dallman]

In article <tsu4oc$gfrl$2...@dont-email.me>, ar...@vajhoej.dk (Arne Vajhøj)
wrote:

> Anybody that can confirm when 7.3 officially went EOL?

Wkipedia has December 2012.

John

[John Dallman]

In article <tsu5fl$fuk$5...@reader2.panix.com>,

cr...@spitfire.i.gajendra.net (Dan Cross) wrote:
> In article <tst9dd$dhc4$1...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >It is not obvious to me why VMS being open source should
> >make it more attractive to develop open source on VMS.
>
> It's prohibitively expensive to do so today.

Actually, it isn't. There's a no-cost level for ISVs, which should
include open source developers. You need your own hardware, of course,
but that's normal for open source development.

https://videotape.com/about/partners/program/

This is of limited value until there are native compilers for x86-64, but
then it will allow open source development.

John

[Dan Cross]

In article <memo.20230219...@jgd.cix.co.uk>,
John Dallman <j...@cix.co.uk> wrote:

>In article <tsu4mu$fuk$2...@reader2.panix.com>,
>cr...@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> x86_64 didn't exist when this was happening. It came in
>> 2000 or so.
>
>2003.

You are correct. 2003 was indeed when the first opteron hardware
was avaiable, though AMDs announcement was 1999 and the first
full spec was available in 2000.

Anyway, Linux had already been long robust and available on
32-bit x86 by the time x86_64 came around.

>The timing is important, because by then it was clear to alert
>organisations that Itanium was a turkey, and they were ready to consider
>something else. HP's insistence on sticking with Itanium finished off VMS
>in the technical and scientific fields.

100% agreement.

- Dan C.

[Dan Cross]

In article <memo.20230219...@jgd.cix.co.uk>,
John Dallman <j...@cix.co.uk> wrote:

That's good news!

- Dan C.

[Arne Vajhøj]

On 2/19/2023 4:48 PM, Dan Cross wrote:
> In article <tst9dd$dhc4$1...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/18/2023 10:06 PM, Dan Cross wrote:
>>> In article <tsrpoc$5qhq$2...@dont-email.me>,

>>>> It is problematic to find people to maintain the ifdefs
>>>> and build scripts of for VMS in many open source projects.
>>>
>>> Have you ever stopped to wonder why that is, and how one might
>>> go about changing it?
>>
>> It is not obvious to me why VMS being open source should
>> make it more attractive to develop open source on VMS.
>
> It's prohibitively expensive to do so today. Should commercial
> vendors port to OpenVMS using the hobbyist program? How about
> open source vendors?

????

Commercial vendors can use VSI's excellent ISV program.

Open source developers can use either same ISV program
or hobbyist program.

Minimum cost = zero.

>> There is no (non-religious) reason for an open source developer
>> to not develop open source on a closed source OS.
>
> Cost.

Practically all software vendors has developer programs.

Including VSI.

Cost is not an issue.

>> Open source simply requires people developing
>> open source.
>
> ...which requires an incentive, which no one has for VMS. Very
> few people in the open source world are running it, so why would
> they develop for it? What incentive does anyone have to develop
> for a closed proprietary platform controlled by a single, small
> company?

It is an observable fact that open source is developed for
closed source platforms.

>> A couple of well known quotes:
>>
>> Benjamin Franklin - Well done is better than well said
>>
>> John F Kennedy - Ask not what your country can do for you – ask what you
>> can do for your country
>
> So I know a lot about OS implementation on x86, but have no
> practical way to contribute to getting OpenVMS running. Oh
> well.

There are a few hundred thousand open source projects
to get running on VMS.

>> VMS does not need people that say:
>> - VSI please open source VMS
>> - someone please port GNAT to VMS
>> - someone please port Rust to VMS
>> - someone please port XYZ to VMS
>>
>> VMS need people that say:
>> - I have ported XYZ to VMS
>> - I have created ABC on VMS
>
> How, pray tell, is one going to cooperate in, say, porting GNAT
> or Rust or LLVM to VMS, when all that development is being done
> in a highly proprietary context that by its very nature
> precludes collaboration?

Close source does not preclude collaboration.

> Suppose somebody finds a latent bug in
> the OS that's tickled by the new compiler; how does one help get
> that fixed without the source code? Sure, provide a really good
> bug report, but none of that helps people do what you claim VMS
> needs above.

The people that actually do port open source to or develop
open source for VMS does not seem to have that problem.

They report it. VSI engineering responds.

Not really that different from open source for the vast majority
of developers that don't want to do OS fixes themselves.

Recent example: Mark Daniels and the link time issue.

Arne

[Arne Vajhøj]

There is a great tool called Google.

Try enter the search term:
definition:eol
and read.

Arne

[Arne Vajhøj]

On 2/19/2023 4:39 PM, Dan Cross wrote:
> In article <memo.20230219...@jgd.cix.co.uk>,
> John Dallman <j...@cix.co.uk> wrote:
>> In article <tsrmfk$b8i$1...@reader2.panix.com>,
>> cr...@spitfire.i.gajendra.net (Dan Cross) wrote:
>>
>>> Establishment of a developer ecosystem, crowd-sourced fixes
>>> for bugs, security auditing . . .
>>
>> Can you be confident these things would happen?
>
> No, I can only say that they will happen with p between 0 and 1.
>
> But I _can_ confidently say that they will NOT happen without
> open-sourcing.

Given that it happened in the past without open sourcing, then
that guarantee is not worth much.

>> The VMS user community is mostly fairly old, and has habits built around
>> getting their OS from someone else. Their skills are stronger in
>> application programming than systems programming, and there's much more
>> of a distinction between those styles on VMS than on UNIX/Linux. VMS
>> application programming tends to use different languages (Basic, COBOL,
>> Fortran) from systems programming (Macro, BLISS, C).
>>
>> People from the wider open source community would be facing an alien
>> environment that uses weird programming languages. They'd also have to
>> work with plenty of people who think things were better when DEC was
>> around.
>>
>> It seems likely to me that an open source VMS would not develop a large
>> enough community to keep it going. Plenty of open source projects fail.
>
> Here's the difference: if a company is sufficiently invested in
> VMS and the source is out there, then they _can_ invest in the
> talent and development environment necessary to take things on
> themselves. Is it a pain? Yes. But it's less of a risk than
> relying on only a single source.

The number of companies interested in taking over OS maintenance
is extremely small.

The vast majority of companies move off a platform if it
becomes EOL no matter if it is closed source or open source.

The theoretical possibility of taking on maintenance of let
us say 50 MLOC does not appeal to businesses.

Arne

[Arne Vajhøj]

On 2/19/2023 4:35 PM, Dan Cross wrote:
> In article <tsu14t$g5l7$1...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> But there was also hardware cost. Solaris, AIX, HP-UX and
>> Tru64 was running on expensive hardware while Linux ran
>> on cheaper x84-64 hardware (Solaris did also support x86-64
>> besides the primary platform SPARC).
>
> x86_64 didn't exist when this was happening. It came in
> 2000 or so.

Linux started on x86.

But it did not kill the commercial Unixes until x86-64 had
arrived.

In 2000 commercial Unix on RISC CPU's was still the thing
that companies ported to.

>> But there were also free Unixes running on x86-64 available
>> back then. Why Linux and not them? My best guess is that
>> Linux had better "marketing" - not traditional marketing
>> aka slick sales people selling to big companies, but the
>> internet developer to developer talk type of marketing -
>> Linux was cool while *BSD was old.
>
> Nope. It had more to do with the USL/UCB lawsuit and the
> presumed effect that that would have on the freely-available
> BSD code. Since Linux was a clean-room reimplementation, it
> wasn't encumbered by AT&T copyright, and would thus be "safe"
> should AT&T win in court.

Nope.

That case was settled in February 1994. Plenty of time for
any BSD to have competed with the very new Linux and the
commercial Unixes for the following 15 years.

> What's ironic is that the people making these decisions didn't
> quite understand the AT&T lawsuit, which was about _trade secret
> status_ of Unix, not copyright. AT&T was trying to say that it
> was the system interface that was the real intellectual property
> that was being violated, not the specific expression of that
> interface. This would have affected Linux, too, despite being
> an independent reimplementation.

Do you use CharGPT to create this type of fiction?

It was both copyright and trade secrets. Plus breach of contract
and trademark.

From the judges ruling:

https://law.justia.com/cases/federal/district-courts/FSupp/832/790/1428569/

<quote>
Count 1: Breach of Contract. The University knowingly breached its
licensing agreements to use 32V by distributing, disclosing, and using
proprietary software in violation of the terms of the agreements. The
University acted under the authority of the Regents, who had cause to
know of the breach.

Count 3: Copyright Infringement. The University and BSDI violated
Plaintiff's copyright in its Unix source code by reproducing,
distributing, and preparing derivative works of Plaintiff's source code.
The University acted under the authority of the Regents, who had cause
to know of the violations.

Count 4: Misappropriation of Trade Secrets. The University and BSDI
misappropriated Plaintiff's trade secrets in violation of state law. The
University acted under the authority of the Regents, who had cause to
know of the misappropriation. *797 Count 6: Trademark. The University's
June 28, 1991 announcement, that its Net2 software is "available to
anyone and requires no previous license, either from AT & T or The
Regents of the University of California," was materially false and
misleading in violation of the Lanham Act. The University acted under
the authority of the Regents, who had cause to know of the violation.

Count 8: Trademark. The University, in promotional materials and its
notice of copyright, misrepresented that the source code in Net2
originated within the University, rather than with AT & T or Plaintiff.
The University acted under the authority of the Regents, who had cause
to know of the misrepresentation.
</quote>

Arne

[Arne Vajhøj]

Thanks.

So that is the EOL date for VMS VAX.

A little over 10 years ago.

Arne

[Arne Vajhøj]

On 2/18/2023 10:00 PM, Dan Cross wrote:
> In article <tsrpf1$5qhq$1...@dont-email.me>,

> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/18/2023 4:01 PM, Dan Cross wrote:

>>> Which is why they should start working with HPE now
>>> to make it happen. Sun didn't own SVR4; AT&T did.
>>> Yet somehow OpenSolaris happened.
>>
>> At that time the SCO group owned it.
>
> You might want to check your priors on that and the exact
> timelines.

OpenSolaris was released 2004-2008 (it took some time from announcement
of plan to it was available - lot of work).

The SVR4 rights is a bit tricky to track. One almost need to be
Hercule Poirot to track it, but my best attempt says:

AT&T USL--(1992)-->Novell--(1995)-->Santa Cruz
Operation--(2001)--Caldera/The SCO Group--(2011)-->UnXis/Xinuos

That brings the OpenSolaris open sourcing in the "The SCO Group" timeframe.

>> After a few years Oracle (that had bought SUN) moved back
>> to a closed source model.
>
> Almost immediately, in fact. Remind me, where's Solaris now?
>
>> And the open source version is something that practically
>> nobody use and very few can even remember the name of (I will
>> save people the wikipedia search - it is "illumos").
>
> Now I'm quite sure you're not very familiar with that ecosystem.
>
> Lots more people are using illumos in one form or another than
> are using Solaris. SmarOS, Joyent, MNX, Oxide and others are
> all using illumos. Who's using Solaris, again?

That is definitely not my impression.

It is a bit hard to find number for less used
server OS'es.

But Google was able to find:

https://enlyft.com/tech/operating-systems

They supposedly checked almost 4.7 million companies.

Linux approx. 1.7 million
Solaris 44083 (!)
HP-UX 20114
AIX 13251
OpenVMS 4924
ilumos 80 (!)

I don't know how good their research is, but it was what I could find.

>> Open sourcing Solaris did not solve Solaris'es
>> problems.
>>
>> Maybe it even made them worse.
>
> Oh? How do you figure? Please be specific. Or is that just
> idle speculation?

Before open sourcing Solaris was one the worlds major OS'es.

After open sourcing it was a niche OS.

That should prove that open sourcing did not solve its
problems.

Maybe it even made it worse. Oracle decision to close
source it again indicate that Oracle believed so. Given
that it was their money, then they must be the expert.

>> Not a good example to provide to VSI.
>
> No, Linux is the example here.

But the context of Linux is very different from VMS.

> Indeed, the tragedy of Solaris reinforces the
> thesis that open sourcing is really the only way to go; pointing
> out the failure Solaris shows what happens if you _don't_
> embrace open source in a timely manner.

That conclusion does not really match with what happened.

Arne

[Arne Vajhøj]

On 2/18/2023 10:08 PM, Dan Cross wrote:
> In article <tsrqg0$5qhq$3...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/18/2023 6:20 PM, Dan Cross wrote:
>>> Interesting and superior technology always loses relative to
>>> simple economics. Linux is available gratis; VMS is not. Ergo,
>>> VMS cannot compete. 30 years ago, Linux was strictly worse than
>>> VMS in every measurable way; now the inverse is true. This is
>>> not an accident; economics dictate that proprietary will always
>>> lose going forward.
>>
>> Everybody likes free.
>>
>> But even though creating an additional copy of software
>> is free/effortless, then creating the software is not
>> free/effortless.
>
> Non-sequitur.
>
>> Fundamentally it cost the same to create 1 line of
>> open source code as 1 line of closed source code.
>
> False. It is amortized over every contributor versus having one
> organization shoulder the entire cost.

cost <> financing of cost

Cost also get spread out for commercial software - that
is what license fees does.

>> There are some open source projects that can make
>> it work. Linux is a good example of a huge success.
>>
>> But there are also some that can't make it work.
>> My last post mentioned OpenSolaris. But products
>> like ElasticSearch and Akka are also switching
>>from open source licenses to different licensing.
>
> You fundamentally missed the point of the Solaris reference in
> my earlier post.

It is yet a few other examples of that open source as a
business model doe snot work for everybody.

VSI probably consider that a major point.

Arne

[Arne Vajhøj]

On 2/18/2023 10:08 PM, Dan Cross wrote:

> Let's turn this around: what do you think that VMS's future
> prospects look like?

I believe that:

compilers/libraries/tools/platform-products available on OS
=>
applications available on OS
=>
OS sale

I don't consider it realistic or even desirable for VMS
to become as big as Linux.

But if the applications desired in the market where
VMS license cost is not a problem are available on
VMS, then I believe VMS can grow.

It is pointless to try and sell VMS to someone
that runs Ubuntu or RockyLinux because RHEL
is too expensive.

But for all those systems running z, i, commercial
Unix, maybe even Windows Server then VSI may be able
to make money.

*if* the applications are there.

Arne

[Craig A. Berry]

You seem to be missing some context here and are assuming that open
source on VMS has never been done, that porting open source *to* VMS has
anything at all to do with the open sourcing *of* VMS itself, and that
the latter has never been tried. All of these are false assumptions.

[Single Stage to Orbit]

On Sun, 2023-02-19 at 15:34 -0500, Arne Vajhøj wrote:
> But there was also hardware cost. Solaris, AIX, HP-UX and
> Tru64 was running on expensive hardware while Linux ran
> on cheaper x84-64 hardware (Solaris did also support x86-64
> besides the primary platform SPARC).

Another reason was it was extremely easy to bring up Linux on a new
hardware platform. Thus it spread to other architectures such as
UltraSparc very quickly. What helped it spread was the fact the GNU
compiler suite could very quickly sprout support for a platform as soon
as it became available. This, again, is also my biggest bugbear about
the LLVM suite, it only supports a limited subset because Rust needs
LLVM to do its work. Which means platforms like m68k etc can't get Rust
until LLVM gets the support.

Today Linux runs on billions of compute devices. The majority are
Android mobile phones. It even runs on devices in outer space.

I'd consider that an success story.
--
Tactical Nuclear Kittens

[Dan Cross]

In article <tsug6g$hia4$4...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/19/2023 4:35 PM, Dan Cross wrote:
>> In article <tsu14t$g5l7$1...@dont-email.me>,
>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> But there was also hardware cost. Solaris, AIX, HP-UX and
>>> Tru64 was running on expensive hardware while Linux ran
>>> on cheaper x84-64 hardware (Solaris did also support x86-64
>>> besides the primary platform SPARC).
>>
>> x86_64 didn't exist when this was happening. It came in
>> 2000 or so.
>
>Linux started on x86.
>
>But it did not kill the commercial Unixes until x86-64 had
>arrived.
>
>In 2000 commercial Unix on RISC CPU's was still the thing
>that companies ported to.

By 2000 the economics were obvious.

>>> But there were also free Unixes running on x86-64 available
>>> back then. Why Linux and not them? My best guess is that
>>> Linux had better "marketing" - not traditional marketing
>>> aka slick sales people selling to big companies, but the
>>> internet developer to developer talk type of marketing -
>>> Linux was cool while *BSD was old.
>>
>> Nope. It had more to do with the USL/UCB lawsuit and the
>> presumed effect that that would have on the freely-available
>> BSD code. Since Linux was a clean-room reimplementation, it
>> wasn't encumbered by AT&T copyright, and would thus be "safe"
>> should AT&T win in court.
>
>Nope.
>
>That case was settled in February 1994. Plenty of time for
>any BSD to have competed with the very new Linux and the
>commercial Unixes for the following 15 years.

This is actually funny. You obviously weren't there.

>> What's ironic is that the people making these decisions didn't
>> quite understand the AT&T lawsuit, which was about _trade secret
>> status_ of Unix, not copyright. AT&T was trying to say that it
>> was the system interface that was the real intellectual property
>> that was being violated, not the specific expression of that
>> interface. This would have affected Linux, too, despite being
>> an independent reimplementation.
>
>Do you use CharGPT to create this type of fiction?

Wow, rude.

>It was both copyright and trade secrets. Plus breach of contract
>and trademark.
>
> From the judges ruling:
>
>https://law.justia.com/cases/federal/district-courts/FSupp/832/790/1428569/
>

>[snip]

Tell me you weren't there without telling me that you weren't
there.

Honesetly, I think you just want to argue.

- Dan C.

[Dan Cross]

In article <tsuf5n$hia4$2...@dont-email.me>,

No no. You're the one insisting on a particular definition;
therefore, the onus falls on you to cite a reference for that
definition.

FTR, I did look it up, and my reading is more ambiguous than
what you let on. What you are describing seems closer to
EOSL.

Anyway, none of this matters: the commercial Unixes are all
dying or dead, whether you choose to admit it or not. That is
not a good model for VMS to follow.

- Dan C.

[Dan Cross]

In article <tsui1g$hia4$6...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> Oh? How do you figure? Please be specific. Or is that just
>> idle speculation?
>
>Before open sourcing Solaris was one the worlds major OS'es.
>
>After open sourcing it was a niche OS.

Correlation is not causation.

>That should prove that open sourcing did not solve its
>problems.

I never said that it did.

>Maybe it even made it worse.

This is unsubstantiated nonsense.

>Oracle decision to close
>source it again indicate that Oracle believed so. Given
>that it was their money, then they must be the expert.

Oracle: famous for making great decisions.

>> Indeed, the tragedy of Solaris reinforces the
>> thesis that open sourcing is really the only way to go; pointing
>> out the failure Solaris shows what happens if you _don't_
>> embrace open source in a timely manner.
>
>That conclusion does not really match with what happened.

Hmm. Should I believe a) the people who were in the room at Sun
and made it happen, or b) you?

I'll go with (a). Sorry, you've shown that your opinion is that
of an uninformed outsider with a pathological inability to
consider alternative scenarios, and a distinct lack of ability
to think logically.

- Dan C.

[Dan Cross]

In article <tsujfa$hr32$2...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/18/2023 10:08 PM, Dan Cross wrote:
>> Let's turn this around: what do you think that VMS's future
>> prospects look like?
>
>I believe that:
>
>compilers/libraries/tools/platform-products available on OS
>=>
>applications available on OS
>=>
>OS sale

Maybe if those applications are available _only_ on that OS.
What incentive does a vendor have to port their applications to
VMS? If there is no demand, because, say, a site can install
Linux for free and _run the same or equivalent applications_
then your model fails.

>I don't consider it realistic or even desirable for VMS
>to become as big as Linux.

Never said that it should. I just said that if VSI doesn't
pivot to a different model, VMS will die.

>But if the applications desired in the market where
>VMS license cost is not a problem are available on
>VMS, then I believe VMS can grow.

"In the market where VMS license cost is not a problem". What
market is that? Is that a market where Linux doesn't exist as a
competitor?

>It is pointless to try and sell VMS to someone
>that runs Ubuntu or RockyLinux because RHEL
>is too expensive.
>
>But for all those systems running z, i, commercial
>Unix, maybe even Windows Server then VSI may be able
>to make money.

Yeah. I bet those people are just dying to move to a different
closed, proprietary platform.

Did you get ChatGPT to write this for you?

>*if* the applications are there.

_And_ they are not on another more attractive platform as well.

This is the part you seem incapable of grasping.

I really don't care to keep going in circles with you,
specifically, though, so feel free to respond with some kind of
(or more likely a series of) "last-word"ish posts.

Have fun!

- Dan C.

[Dan Cross]

In article <tsuep3$hia4$1...@dont-email.me>,

Arne Vajhøj <ar...@vajhoej.dk> wrote:
>On 2/19/2023 4:48 PM, Dan Cross wrote:
>> In article <tst9dd$dhc4$1...@dont-email.me>,
>> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> On 2/18/2023 10:06 PM, Dan Cross wrote:
>>>> In article <tsrpoc$5qhq$2...@dont-email.me>,
>>>>> It is problematic to find people to maintain the ifdefs
>>>>> and build scripts of for VMS in many open source projects.
>>>>
>>>> Have you ever stopped to wonder why that is, and how one might
>>>> go about changing it?
>>>
>>> It is not obvious to me why VMS being open source should
>>> make it more attractive to develop open source on VMS.
>>
>> It's prohibitively expensive to do so today. Should commercial
>> vendors port to OpenVMS using the hobbyist program? How about
>> open source vendors?
>
>????
>
>Commercial vendors can use VSI's excellent ISV program.
>
>Open source developers can use either same ISV program
>or hobbyist program.
>
>Minimum cost = zero.

Too bad there are no native compilers for x86_64 yet,
which means using a different platform, which comes back
to cost.

Do you...really not understand this? No wait, nevermind.

>> ...which requires an incentive, which no one has for VMS. Very
>> few people in the open source world are running it, so why would
>> they develop for it? What incentive does anyone have to develop
>> for a closed proprietary platform controlled by a single, small
>> company?
>
>It is an observable fact that open source is developed for
>closed source platforms.

How do you think that's relevant to the text that you quoted?
No wait, nevermind.

>> So I know a lot about OS implementation on x86, but have no
>> practical way to contribute to getting OpenVMS running. Oh
>> well.
>
>There are a few hundred thousand open source projects
>to get running on VMS.

How do you think that's relevant to participating in the port?
No wait, nevermind.

>>> VMS does not need people that say:
>>> - VSI please open source VMS
>>> - someone please port GNAT to VMS
>>> - someone please port Rust to VMS
>>> - someone please port XYZ to VMS
>>>
>>> VMS need people that say:
>>> - I have ported XYZ to VMS
>>> - I have created ABC on VMS
>>
>> How, pray tell, is one going to cooperate in, say, porting GNAT
>> or Rust or LLVM to VMS, when all that development is being done
>> in a highly proprietary context that by its very nature
>> precludes collaboration?
>
>Close source does not preclude collaboration.

How does one contribute to the work porting LLVM to VMS, then?
No wait, nevermind.

>> Suppose somebody finds a latent bug in
>> the OS that's tickled by the new compiler; how does one help get
>> that fixed without the source code? Sure, provide a really good
>> bug report, but none of that helps people do what you claim VMS
>> needs above.
>
>The people that actually do port open source to or develop
>open source for VMS does not seem to have that problem.

You are not even consistent within your own post. There are as
you said several hundred thousand projects to port to VMS, and
no one is doing that work, but that people that are doing the
work don't have a problem, even though they aren't doing it.

Which is it?

No wait, nevermind.

- Dan C.

[Dan Cross]

In article <tsup8s$lhc9$1...@dont-email.me>,

You seem to misunderstand what I'm getting at, conflating
several distinct points into one. Perhaps I am not explaining
it well.

Obviously there have been open source projects ported to VMS,
but I'm quite certain I never suggested otherwise.

There is an ongoing effort to port LLVM to VMS to get native
compiler support, but with the existing language front-ends in
addition to clang etc, correct? Where is that work happening?
Is there an open source repository where an outside contributer
can work _on that port_? If this is happening in the open, it
does not appear to be in the LLVM repository.
(for ref: https://groups.google.com/g/llvm-dev/c/MYfZW2DOU2I/m/q8oDU0UTAAAJ
and https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20OpenVMS%20Using%20LLVM.pdf)

Similarly with contributions to the operating system itself.
ARM is gaining ground in the server space, and it seems that a
VMS port to ARM is likely at some point, if VMS survives. How
does an independent third-party contribute to that, beyond just
asking VSI? As Arne said earlier, VMS needs things to be done,
but what if those things require, or would be significantly
aided, by open sourcing the OS or large parts of the
infrastructure? For example, independent security researchers
have contributed significantly to finding and fixing security
flaws in important projects by examining the source code for
projects (e.g., Linux, OpenBSD, etc). But since generally
speaking they don't have access to VMS source code, they simply
cannot do this.

Separately, there is the issue of enticing open source software
maintainers to port to VMS. Here, I agree that it is not
necessary for VMS to be open source to make this happen (and in
fact, if one goes back and rereads my posts on this I'm
confident one will find I did not suggest this, though people
like Arne obviously assumed that I did).

However, there does need to be some kind of incentive: why
should anyone port to a niche platform with a dubious future?
Here's where it becomes relevant that VMS is only supported by a
single, small company. Furthermore, that those project
maintainers may not even have an adequate compiler for the
target language: Itanium VMS C++ is stuck at C++'03 apparently,
so someone wtih a C++ project that uses any features from C++'11
on will either have to back out those features, or make them
conditional on compilation target, both of which imposes a
substantial burden for no particular benefit to the project
maintainer. Without that native clang++ port, which they don't
seem to be able to contribute to as prerequisite, the upside for
the OSS folks to port to VMS just doesn't seem to be there.

Indeed, this generalizes to any software vendor, commercial or
open source.

If open-sourcing VMS has been tried, then can anyone share the
story? And note the context now: just because it didn't work
before doesn't mean it can't be done now.

- Dan C.

[Craig A. Berry]

On 2/20/23 6:11 AM, Dan Cross wrote:

> There is an ongoing effort to port LLVM to VMS to get native
> compiler support, but with the existing language front-ends in
> addition to clang etc, correct? Where is that work happening?

At VSI, obviously. There have been numerous public presentations about
what is being done and how it is being done. The head of the compiler
group chimes in here pretty frequently with updates and explanations. I
believe the clang++ port is in field test. The customer portal now has
a download of "VSI C X7.4-725" (a different compiler from the clang++
compiler). I forget exactly what the "X" stands for, but if it's not a
"V" in that position it's not a production-quality release. As far as I
know, this is the first release of a native compiler based on the
GEM-to-LLVM conversion. I don't think they could open source this one
if they wanted to because they don't own the intellectual property to
the front end.

> Is there an open source repository where an outside contributer
> can work _on that port_? If this is happening in the open, it
> does not appear to be in the LLVM repository.
> (for ref: https://groups.google.com/g/llvm-dev/c/MYfZW2DOU2I/m/q8oDU0UTAAAJ
> and https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20OpenVMS%20Using%20LLVM.pdf)

As has been said many times, there will be some changes to LLVM
submitted upstream eventually. Anyone who expected all the compiler
work to be done completely in the open hasn't been paying attention.
You can't contribute to the next version of Apple's XCode just because
it's based on LLVM and the VSI compilers likely won't be any different.
Would it be nice if there were one compiler example available in source
form, even just for a toy language, that people could use as a template
for producing there own LLVM-based compilers? Sure. I'd love to see
it. That's obviously not going to be VSI's highest priority, but it
could happen.

> Similarly with contributions to the operating system itself.
> ARM is gaining ground in the server space, and it seems that a
> VMS port to ARM is likely at some point, if VMS survives. How
> does an independent third-party contribute to that, beyond just
> asking VSI? As Arne said earlier, VMS needs things to be done,
> but what if those things require, or would be significantly
> aided, by open sourcing the OS or large parts of the
> infrastructure?

Many, many open source projects do not have enough contributors. This
usually only makes the news when some critical piece of infrastructure
such as ntp or OpenSSL has a vulnerability that gets noticed, but the
basic problem is ubiquitous in open source. Having the doors wide open
was completely ineffective at keeping those projects adequately
resourced. So it's hard to see how open sourcing VMS would magically
allow more OS development to get done.

Consider the case of Ada, which a very few people really, really want,
but no one can make a business case to VSI that it's worth their time to
do it. Most of the important pieces are already there in the GCC
toolchain, so interested parties could retrace the steps of ACT (who
also didn't think there was a business case to continue supporting Ada
on VMS) and produce an open source Ada compiler for VMS. There is no
waiting on VSI or anybody else. Anyone with the interest, the time, and
the skill can do it right now. Why haven't they?

> Without that native clang++ port, which they don't
> seem to be able to contribute to as prerequisite, the upside for
> the OSS folks to port to VMS just doesn't seem to be there.

The availability of clang++ looks like it's happening, if much later
than anyone wanted it to be. It remains to be seen whether there will
be sufficient pieces included that someone could port Rust or Swift or
GNAT-LLVM on top of it.

There are other things VSI can and should do (and in some cases is
already doing) to enable open source ports. I believe there is a cmake
port expected at some point, and there has been mention of updates to
GNV. There is ongoing work on the CRTL that needs to continue (someone
from VSI mentioned adding posix_spawn() not long ago).

> If open-sourcing VMS has been tried, then can anyone share the
> story? And note the context now: just because it didn't work
> before doesn't mean it can't be done now.

Search for "Clair Grant" and "open source" in the archives of this
newsgroup. I think he said "We can't open source it because we don't
own it." I believe he also said he'd tried to open source it more than
once and it wasn't going to happen.

So if you have sufficient millions burning a hole in your pocket, feel
free to approach HPE to obtain the intellectual property so you can then
give it away for free. I don't see the context now being much different
from what it was five or ten or twenty years ago. I'd be happy to see
it happen, but it doesn't seem very realistic and it's not a panacea for
the dwindling VMS ecosystem.

[Arne Vajhøj]

Exactly.

I previously in this thread posted these two quotes which I think
are sort of relevant:

Benjamin Franklin - Well done is better than well said

John F Kennedy - Ask not what your country can do for you – ask what you
can do for your country

And that is really what it boils down to. The open source
world is not created by people:
- demanding closed source to be open sourced
- complaining that closed is not being open sourced
- demanding somebody else port some open source to ones favorite platform
- complaining that nobody port some open source to ones favorite platform

The open source world is created by people actually producing
open source software.

Linux has been mentioned numerous times in this thread.

Go back to 1991. Linus Torvalds had two options:
A) complain loudly about Minix not being open source (per
later definition) and try to push Tannenbaum to change
the license
B) create Linux

We know what he chose.

Arne

[Arne Vajhøj]

On 2/20/2023 6:17 AM, Dan Cross wrote:
> In article <tsui1g$hia4$6...@dont-email.me>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>> Oh? How do you figure? Please be specific. Or is that just
>>> idle speculation?
>>
>> Before open sourcing Solaris was one the worlds major OS'es.
>>
>> After open sourcing it was a niche OS.
>
> Correlation is not causation.

No. But you should read the lines following that line
to get the point.

>> That should prove that open sourcing did not solve its
>> problems.
>
> I never said that it did.

No.

But you want VSI to do the same as SUN.

>> Maybe it even made it worse.
>
> This is unsubstantiated nonsense.

The substantiation was in the following line, so you
should have read ahead.

>> Oracle decision to close
>> source it again indicate that Oracle believed so. Given
>> that it was their money, then they must be the expert.
>
> Oracle: famous for making great decisions.

If we limit "great decisions" to being "decisions maximizing profit",
then Oracle is doing way better than average.

Arne

[Arne Vajhøj]

I was not there.

But that does not change that the court document
proves that what you posted was pure fiction.

Arne

[Arne Vajhøj]

The compilers are available for VMS Alpha.

The native compilers for VMS x86-64 are available for
development for some languages and the remaining languages
will become available soon.

Not really a cost problem.

(most certainly a timing problem for those waiting for
those native compilers)

>>>> VMS does not need people that say:
>>>> - VSI please open source VMS
>>>> - someone please port GNAT to VMS
>>>> - someone please port Rust to VMS
>>>> - someone please port XYZ to VMS
>>>>
>>>> VMS need people that say:
>>>> - I have ported XYZ to VMS
>>>> - I have created ABC on VMS
>>>
>>> How, pray tell, is one going to cooperate in, say, porting GNAT
>>> or Rust or LLVM to VMS, when all that development is being done
>>> in a highly proprietary context that by its very nature
>>> precludes collaboration?
>>
>> Close source does not preclude collaboration.
>
> How does one contribute to the work porting LLVM to VMS, then?

If someone has a strong interest in working with VSI on
LLVM on VMS, then I think they should contact John Reagan.

A more practical approach would be to look at one of other few
hundred thousand possible open source project and put LLVM
on hold until VSI release their changes (later this year or next year).

>>> Suppose somebody finds a latent bug in
>>> the OS that's tickled by the new compiler; how does one help get
>>> that fixed without the source code? Sure, provide a really good
>>> bug report, but none of that helps people do what you claim VMS
>>> needs above.
>>
>> The people that actually do port open source to or develop
>> open source for VMS does not seem to have that problem.
>
> You are not even consistent within your own post. There are as
> you said several hundred thousand projects to port to VMS, and
> no one is doing that work, but that people that are doing the
> work don't have a problem, even though they aren't doing it.
>
> Which is it?

The problem is that the statement "no one is doing that work"
is again pure fiction you behalf.

What I actually wrote was:

#I can tell you: two handful of people are doing all the
#work.

And while you fictitious "no one" can't contact VSI, then
the "two handful of people" certainly can in some cases do.

Arne

[Arne Vajhøj]

The compilers are available for VMS Alpha.

The native compilers for VMS x86-64 are available for
development for some languages and the remaining languages
will become available soon.

Not really a cost problem.

(most certainly a timing problem for those waiting for
those native compilers)

>>>> VMS does not need people that say:
>>>> - VSI please open source VMS
>>>> - someone please port GNAT to VMS
>>>> - someone please port Rust to VMS
>>>> - someone please port XYZ to VMS
>>>>
>>>> VMS need people that say:
>>>> - I have ported XYZ to VMS
>>>> - I have created ABC on VMS
>>>
>>> How, pray tell, is one going to cooperate in, say, porting GNAT
>>> or Rust or LLVM to VMS, when all that development is being done
>>> in a highly proprietary context that by its very nature
>>> precludes collaboration?
>>
>> Close source does not preclude collaboration.
>
> How does one contribute to the work porting LLVM to VMS, then?

If someone has a strong interest in working with VSI on
LLVM on VMS, then I think they should contact John Reagan.

A more practical approach would be to look at one of other few
hundred thousand possible open source project and put LLVM
on hold until VSI release their changes (later this year or next year).

>>> Suppose somebody finds a latent bug in
>>> the OS that's tickled by the new compiler; how does one help get
>>> that fixed without the source code? Sure, provide a really good
>>> bug report, but none of that helps people do what you claim VMS
>>> needs above.
>>
>> The people that actually do port open source to or develop
>> open source for VMS does not seem to have that problem.
>
> You are not even consistent within your own post. There are as
> you said several hundred thousand projects to port to VMS, and
> no one is doing that work, but that people that are doing the
> work don't have a problem, even though they aren't doing it.
>
> Which is it?

[Jan-Erik Söderholm]

Den 2023-02-20 kl. 15:35, skrev Craig A. Berry:
>
> On 2/20/23 6:11 AM, Dan Cross wrote:
>
>> There is an ongoing effort to port LLVM to VMS to get native
>> compiler support, but with the existing language front-ends in
>> addition to clang etc, correct?  Where is that work happening?
>
> At VSI, obviously.  There have been numerous public presentations about
> what is being done and how it is being done.  The head of the compiler
> group chimes in here pretty frequently with updates and explanations.  I
> believe the clang++ port is in field test.  The customer portal now has
> a download of "VSI C X7.4-725" (a different compiler from the clang++
> compiler).

Note that the whole WASD web server now has been built native
using that C compiler. No major issues, as far as I undestood
from the post from the maintainer about it.

[Arne Vajhøj]

Yes.

VSI is getting there.

Maybe not as fast as many of us wished for.

But steady progress.

Arne

[Arne Vajhøj]

On 2/18/2023 9:24 PM, Arne Vajhøj wrote:
> On 2/18/2023 8:55 PM, Single Stage to Orbit wrote:
>> On Sat, 2023-02-18 at 19:45 -0500, Arne Vajhøj wrote:
>>> On 2/18/2023 6:17 PM, Single Stage to Orbit wrote:
>>>> On Sat, 2023-02-18 at 14:30 -0500, Arne Vajhøj wrote:
>>>>> And honestly I don't see Ada make the cut.
>>>>
>>>> I don't think that will be an issue, as the GNU compiler suite has
>>>> that, and once it's been ported, that will be good enough.
>>>
>>> But will GCC be ported to VMS (again)?
>>>
>>> The last GCC version I have seen run on VMS is 2.8.0
>>> (on VMS Alpha).
>>>
>>> And that is a let us call it "not latest and greatest".
>>
>> Wow, jsut wow. 2.8.0? I remember my first time with Linux and GCC
>> 2.7.2.3! And that was the late 90s!
>
> 2.8.0 is indeed from around that time (I don't remember exact year,
> but some of the files are timestamped 1998).
>
> $ typ test.c
> #include <stdio.h>
>
> int main()
> {
>     printf("Hello world from C!\n");
>     return 0;
> }
>
> $ gcc test.c
> $ gcclink test
> $ r test
> Hello world from C!
>
> If anybody has something newer then I am interested.
>
> C++ seems to be broken. Not sure if it always has been
> so or some update did that.

Does anybody remember whether GXX 2.8.0 worked
on VMS Alpha back then?

I consistently get:

%LINK-W-NUDFSYMS, 4 undefined symbols:
%LINK-I-UDFSYM, _vt$7istream$3ios
%LINK-I-UDFSYM, _vt$7ostream$3ios
%LINK-I-UDFSYM, _vt$8iostream$3ios
%LINK-I-UDFSYM, _vt$8stdiobuf

now. But maybe it worked back then with different VMS version,
different linker etc..

I know positively that C++ worked on VMS VAX back in version 1.42
a decade earlier (I used that extensively).

Arne

[ultr...@gmail.com]

On Saturday, February 18, 2023 at 5:41:04 AM UTC-5, John Dallman wrote:
> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
> (Jan-Erik Söderholm) wrote:
>
> > English version of the meeting notes:
> The license news is good. The ADA news is not, but is hardly unexpected.
>
> Bare metal is a question of market segments, as far as I understand it.
> Enterprise IT shops in the US tend to be strongly in favour of
> virtualising everything. What is the compelling use case for bare metal?
>
> The costs of bare metal are considerable, since x86 hardware has a vast
> range of designs. There are probably 50-100 times more x86-64 server
> designs than the total numbers of Alpha and Itanium server designs
> produced by DEC, Compaq and HP for running VMS. Supporting it requires
> writing enormous numbers of VMS device drivers, a skill that is not at
> all common today. The VSI staff who can do it can do other things which
> will be more valuable to the company.
>
> Running under virtualisation needs only a few VMS device drivers. The
> actual hardware is managed by device drivers for the virtualisation
> software. Those are written by the hardware manufacturers so that
> virtualisation software can be run on their machines. Those hardware
> manufacturers are not going to start writing VMS device drivers unless
> VMS becomes /much/ more widely used.
>
> This view may seem negative, but it reflects the commercial reality that
> VSI need to cope with.
>
> John

how about so software developers can write apps for small and mid size customers who don't want to run virtual ...

they don't have to support all x86 platforms how about just one like HP bladeservers they are doing now?

WITHOUT A BARE METAL PLATFORM AND LIMITING OPENVMS TO VIRTUAL PLATFORMS ONLY, IT WILL NEVER GROW ...

[ultr...@gmail.com]

On Saturday, February 18, 2023 at 9:49:41 PM UTC-5, Dan Cross wrote:

> >There is a huge server market that are very cost
> >sensitive (the people that prefer Ubuntu Server
> >or RockyLinux over RHEL).
> >
> >There is also a huge market where the cost of VMS is
> >not a problem - there are still sold a lot
> >of expensive software.
> >
> >VSI probably find the second market more attractive
> >than the first.
> Right now, VSI doesn't seem to have any real market.
>
> I'll be sad when VMS dies because people couldn't see beyond the
> way it's always been done.
>
> - Dan C.

AND WITHOUT BARE METAL SUPPORT AND AFFORDABLE LICENSING FOR THE SMALL/MEDIUM MARKET IT NEVER WILL ...

[ultr...@gmail.com]

On Sunday, February 19, 2023 at 3:17:07 PM UTC-5, Scott Dorsey wrote:
> Dave Froble <da...@tsoft-inc.com> wrote:
> >
> >A question I'd ask, is, would Linux have done so well, if it was nothing more
> >than "free Unix"?
> When Linux was new, that was all it was. There were some competitors like
> xinu and minix, but Linux actually provided a full functional system. Because
> it was unixlike, there was plenty of existing software for it (including the
> whole gnu back catalogue). Because it was free, the barriers to entry were
> very low.
>
> One might ask if VMS would have done so well if it hadn't come with the Vax.
> Lots of folks bought VMS because of the hardware, not because of the software.
> Those folks were the first to abandon ship when the cheap and fast workstations
> came out in the eighties. (I'm talking here of mostly development folks and
> scientific computing folks who weren't so tied to architecture and who were
> very sensitive to price/performance.)
> --scott
>
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."

WHICH IS WHY YOU NEED AN INEXPENSIVE BARE METAL PLATFORM ...

[Arne Vajhøj]

On 2/20/2023 12:44 PM, ultr...@gmail.com wrote:
> On Saturday, February 18, 2023 at 5:41:04 AM UTC-5, John Dallman wrote:
>> In article <tsq2vo$3utev$1...@dont-email.me>, jan-erik....@telia.com
>> (Jan-Erik Söderholm) wrote:
>>> English version of the meeting notes:
>> The license news is good. The ADA news is not, but is hardly unexpected.
>>
>> Bare metal is a question of market segments, as far as I understand it.
>> Enterprise IT shops in the US tend to be strongly in favour of
>> virtualising everything. What is the compelling use case for bare metal?
>>
>> The costs of bare metal are considerable, since x86 hardware has a vast
>> range of designs. There are probably 50-100 times more x86-64 server
>> designs than the total numbers of Alpha and Itanium server designs
>> produced by DEC, Compaq and HP for running VMS. Supporting it requires
>> writing enormous numbers of VMS device drivers, a skill that is not at
>> all common today. The VSI staff who can do it can do other things which
>> will be more valuable to the company.
>>
>> Running under virtualisation needs only a few VMS device drivers. The
>> actual hardware is managed by device drivers for the virtualisation
>> software. Those are written by the hardware manufacturers so that
>> virtualisation software can be run on their machines. Those hardware
>> manufacturers are not going to start writing VMS device drivers unless
>> VMS becomes /much/ more widely used.
>>
>> This view may seem negative, but it reflects the commercial reality that
>> VSI need to cope with.
>

> how about so software developers can write apps for small and mid size customers who don't want to run virtual ...
>
> they don't have to support all x86 platforms how about just one like HP bladeservers they are doing now?

Most small and mid size customers also run virtual (VMWare on prem,
or IaaS cloud).

Yes - some will prefer physical.

And VSI previously had a relevant specific HP Proliant model
on the target list.

But VSI are prioritizing what gives most bang for the buck right
now - and that is virtual.

Those that are current or potential future customers for
VSI and have a strong preference for physical should contact
VSI and let their voice be heard.

Arne

[ultr...@gmail.com]

On Sunday, February 19, 2023 at 7:27:18 PM UTC-5, Arne Vajhøj wrote:
> On 2/19/2023 4:48 PM, Dan Cross wrote:
> > In article <tst9dd$dhc4$1...@dont-email.me>,
> > Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >> On 2/18/2023 10:06 PM, Dan Cross wrote:
> >>> In article <tsrpoc$5qhq$2...@dont-email.me>,
> >>>> It is problematic to find people to maintain the ifdefs
> >>>> and build scripts of for VMS in many open source projects.
> >>>
> >>> Have you ever stopped to wonder why that is, and how one might
> >>> go about changing it?
> >>
> >> It is not obvious to me why VMS being open source should
> >> make it more attractive to develop open source on VMS.
> >
> > It's prohibitively expensive to do so today. Should commercial
> > vendors port to OpenVMS using the hobbyist program? How about
> > open source vendors?
> ????
>
> Commercial vendors can use VSI's excellent ISV program.
>
> Open source developers can use either same ISV program
> or hobbyist program.
>
> Minimum cost = zero.

> >> There is no (non-religious) reason for an open source developer
> >> to not develop open source on a closed source OS.
> >
> > Cost.
> Practically all software vendors has developer programs.
>
> Including VSI.
>
> Cost is not an issue.
> >> Open source simply requires people developing
> >> open source.

> >
> > ...which requires an incentive, which no one has for VMS. Very
> > few people in the open source world are running it, so why would
> > they develop for it? What incentive does anyone have to develop
> > for a closed proprietary platform controlled by a single, small
> > company?
> It is an observable fact that open source is developed for
> closed source platforms.

> >> A couple of well known quotes:

> >>
> >> Benjamin Franklin - Well done is better than well said
> >>
> >> John F Kennedy - Ask not what your country can do for you – ask what you
> >> can do for your country
> >

> > So I know a lot about OS implementation on x86, but have no
> > practical way to contribute to getting OpenVMS running. Oh
> > well.
> There are a few hundred thousand open source projects
> to get running on VMS.

> >> VMS does not need people that say:
> >> - VSI please open source VMS
> >> - someone please port GNAT to VMS
> >> - someone please port Rust to VMS
> >> - someone please port XYZ to VMS
> >>
> >> VMS need people that say:
> >> - I have ported XYZ to VMS
> >> - I have created ABC on VMS
> >
> > How, pray tell, is one going to cooperate in, say, porting GNAT
> > or Rust or LLVM to VMS, when all that development is being done
> > in a highly proprietary context that by its very nature
> > precludes collaboration?
> Close source does not preclude collaboration.

> > Suppose somebody finds a latent bug in
> > the OS that's tickled by the new compiler; how does one help get
> > that fixed without the source code? Sure, provide a really good
> > bug report, but none of that helps people do what you claim VMS
> > needs above.
> The people that actually do port open source to or develop
> open source for VMS does not seem to have that problem.
>

> They report it. VSI engineering responds.
>
> Not really that different from open source for the vast majority
> of developers that don't want to do OS fixes themselves.
>
> Recent example: Mark Daniels and the link time issue.
>
> Arne

YOU FORGOT PROVIDING THEM AN INEXPENSIVE BARE METAL BOX W/LICENSE TO SELL TO THE CUSTOMER TO RUN THE APP ...

[Single Stage to Orbit]

On Mon, 2023-02-20 at 11:36 -0500, Arne Vajhøj wrote:
> %LINK-W-NUDFSYMS, 4 undefined symbols:
> %LINK-I-UDFSYM,         _vt$7istream$3ios
> %LINK-I-UDFSYM,         _vt$7ostream$3ios
> %LINK-I-UDFSYM,         _vt$8iostream$3ios
> %LINK-I-UDFSYM,         _vt$8stdiobuf

Smells like ABI issues. It depends on what linker is being used, I
guess. Mayvbe GCC should use its linker instead of the VMS linker.
--
Tactical Nuclear Kittens

[h47...@gmail.com]

It only shows that objects, object libraries or shareable images, which define theses symbols, are not included in the link operation.

[Dave Froble]

On 2/20/2023 6:28 AM, Dan Cross wrote:
> In article <tsuep3$hia4$1...@dont-email.me>,

> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/19/2023 4:48 PM, Dan Cross wrote:
>>> In article <tst9dd$dhc4$1...@dont-email.me>,

I like to keep an open mind, but I'm wondering if I should ask, are you one of
Stallman's advocates?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486