On 2/19/2023 4:02 PM, Dan Cross wrote:
> In article <tstaid$dhc4$2@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/18/2023 9:49 PM, Dan Cross wrote:
>>> In article <tsrr9q$5qhq$4@dont-email.me>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 2/18/2023 4:47 PM, Dan Cross wrote:
>>>>> In article <tsrfpl$4bfn$2@dont-email.me>,
>>>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>>> On 2/18/2023 4:01 PM, Dan Cross wrote:
>>>>>>> In article <tsrdl6$4bfn$1@dont-email.me>,
>>>>>>> Arne Vajhøj <arne@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.
>>
>> 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.
>
> 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.

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

In article <memo.20230219101729.11588I@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <tsrmfk$b8i$1@reader2.panix.com>,
>cross@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.

In article <tst72r$r3d$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>John Dallman <jgd@cix.co.uk> wrote:
>>In article <tsrmfk$b8i$1@reader2.panix.com>,
>>cross@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.

Just so.

- Dan C.

In article <tst9dd$dhc4$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/18/2023 10:06 PM, Dan Cross wrote:
>> In article <tsrpoc$5qhq$2@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 2/18/2023 5:08 PM, Dan Cross wrote:
>>>> In article <tsrf3b$4krc$1@dont-email.me>,
>>>> Dave Froble <davef@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.

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.

In article <tsu3r4$gfrl$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/19/2023 3:56 PM, Dan Cross wrote:
>> In article <k5ea4nF3u82U1@mid.individual.net>,
>> Michael Kraemer @ home <M.Kraemer@gsi.de> wrote:
>>> Dan Cross wrote:
>>>> In article <tsrr9q$5qhq$4@dont-email.me>,
>>>> Arne Vajhøj <arne@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.

In article <tsu4h0$13i$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>Scott Dorsey <kludge@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.

In article <tsu4oc$gfrl$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/19/2023 4:02 PM, Dan Cross wrote:
>> In article <tstaid$dhc4$2@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 2/18/2023 9:49 PM, Dan Cross wrote:
>>>> In article <tsrr9q$5qhq$4@dont-email.me>,
>>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 2/18/2023 4:47 PM, Dan Cross wrote:
>>>>>> In article <tsrfpl$4bfn$2@dont-email.me>,
>>>>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>>>> On 2/18/2023 4:01 PM, Dan Cross wrote:
>>>>>>>> In article <tsrdl6$4bfn$1@dont-email.me>,
>>>>>>>> Arne Vajhøj <arne@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.
>>>
>>> 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.
>>
>> 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.
>
>The term EOL has a very specific meaning in software.

Citation needed.

In article <memo.20230219222022.11588L@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <tsu4mu$fuk$2@reader2.panix.com>,
>cross@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.

In article <memo.20230219223054.11588N@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <tsu5fl$fuk$5@reader2.panix.com>,
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>> In article <tst9dd$dhc4$1@dont-email.me>,
>> Arne Vajhøj <arne@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.

That's good news!

- Dan C.

On 2/19/2023 4:48 PM, Dan Cross wrote:
> In article <tst9dd$dhc4$1@dont-email.me>,
> Arne Vajhøj <arne@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

On 2/19/2023 4:59 PM, Dan Cross wrote:
> In article <tsu4oc$gfrl$2@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/19/2023 4:02 PM, Dan Cross wrote:
>>> In article <tstaid$dhc4$2@dont-email.me>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 2/18/2023 9:49 PM, Dan Cross wrote:
>>>>> In article <tsrr9q$5qhq$4@dont-email.me>,
>>>>> Arne Vajhøj <arne@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.
>>>>
>>>> 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.
>>>
>>> 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.
>>
>> The term EOL has a very specific meaning in software.
>
> Citation needed.

There is a great tool called Google.

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

Arne

On 2/19/2023 4:39 PM, Dan Cross wrote:
> In article <memo.20230219101729.11588I@jgd.cix.co.uk>,
> John Dallman <jgd@cix.co.uk> wrote:
>> In article <tsrmfk$b8i$1@reader2.panix.com>,
>> cross@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

On 2/19/2023 4:35 PM, Dan Cross wrote:
> In article <tsu14t$g5l7$1@dont-email.me>,
> Arne Vajhøj <arne@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

On 2/19/2023 5:20 PM, John Dallman wrote:
> In article <tsu4oc$gfrl$2@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> Anybody that can confirm when 7.3 officially went EOL?
>
> Wkipedia has December 2012.

Thanks.

So that is the EOL date for VMS VAX.

A little over 10 years ago.

Arne

On 2/18/2023 10:00 PM, Dan Cross wrote:
> In article <tsrpf1$5qhq$1@dont-email.me>,
> Arne Vajhøj <arne@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

On 2/18/2023 10:08 PM, Dan Cross wrote:
> In article <tsrqg0$5qhq$3@dont-email.me>,
> Arne Vajhøj <arne@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

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

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

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

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.

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

In article <tsug6g$hia4$4@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/19/2023 4:35 PM, Dan Cross wrote:
>> In article <tsu14t$g5l7$1@dont-email.me>,
>> Arne Vajhøj <arne@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.

In article <tsuf5n$hia4$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/19/2023 4:59 PM, Dan Cross wrote:
>> In article <tsu4oc$gfrl$2@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 2/19/2023 4:02 PM, Dan Cross wrote:
>>>> In article <tstaid$dhc4$2@dont-email.me>,
>>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 2/18/2023 9:49 PM, Dan Cross wrote:
>>>>>> In article <tsrr9q$5qhq$4@dont-email.me>,
>>>>>> Arne Vajhøj <arne@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.
>>>>>
>>>>> 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.
>>>>
>>>> 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.
>>>
>>> The term EOL has a very specific meaning in software.
>>
>> Citation needed.
>
>There is a great tool called Google.
>
>Try enter the search term:
> definition:eol
>and read.

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.

In article <tsui1g$hia4$6@dont-email.me>,
Arne Vajhøj <arne@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.

In article <tsujfa$hr32$2@dont-email.me>,
Arne Vajhøj <arne@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.

In article <tsuep3$hia4$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/19/2023 4:48 PM, Dan Cross wrote:
>> In article <tst9dd$dhc4$1@dont-email.me>,
>> Arne Vajhøj <arne@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.

In article <tsup8s$lhc9$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
>On 2/19/23 3:48 PM, Dan Cross wrote:
>> In article <tst9dd$dhc4$1@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>
>>> 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.
>
>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.

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.