On 11/10/2022 8:32 AM, Simon Clubley wrote:
> On 2022-11-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/9/2022 8:09 AM, Simon Clubley wrote:
>>> On 2022-11-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>>>>> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>> I don't use Linux, but it is my impression that just about everything in Linux
>>>>>> is from third parties. Nor is Linux restricted to a single vendor.
>>>>>>
>>>>>> So why then should VSI be responsible for everything VMS needs?
>>>>>>
>>>>>> Gotta love double standards ...
>>>>>
>>>>> Well that's a load of bollocks David. We are talking about things
>>>>> that are integral within Linux, in the same way as, say, RMS, clustering,
>>>>> and KESU modes are integral within VMS.
>>>>
>>>> That was pretty strong words given that you are only 75% correct ...
>>>
>>> I've just reviewed my list in the posting that David is responding to
>>> and I don't see it, so can you tell me which 25% am I wrong about ?
>>
>> Really?
>>
>> So if we from that list:
>>
>> # For example, Linux has mandatory access controls and VMS is still stuck
>> # back in the DAC world.
>> #
>> # There's no ASLR/KASLR support on VMS.
>> #
>> # There's nothing like the Unix chroot jails on VMS.
>> #
>> # Compiler protections in generated code has been lacking on VMS compared
>> # to what is available elsewhere, but John in recent years has started
>> # looking at getting comparable protections in the VMS compilers, when it
>> # comes to generating code, that currently exist elsewhere.
>>
>> create a little pop quiz:
>>
>> Which of the following items:
>> A) mandatory access controls
>> B) ASLR
>> C) chroot jails
>> D) Compiler protections in generated code
>> are not "integral within Linux"?
>>
>> Then you have no idea?
>>
>
> They all are present and integrated within Linux these days Arne. Which one
> do you think is missing from Linux ?

Well - maybe you are not aware.

But the compiler used by Linux GCC is not "integral within Linux"
(your words) but "from third parties" (Davids words). It comes
from the GNU project not the Linux kernel project.

That a compiler is used to build something does not make it
an integral part of what is being build.

MSVC++ is not an integral part of MS Excel even though
it is used to build it.

Arne

On 2022-11-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/10/2022 8:32 AM, Simon Clubley wrote:
>> On 2022-11-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/9/2022 8:09 AM, Simon Clubley wrote:
>>>> On 2022-11-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>>>>>> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>> I don't use Linux, but it is my impression that just about everything in Linux
>>>>>>> is from third parties. Nor is Linux restricted to a single vendor.
>>>>>>>
>>>>>>> So why then should VSI be responsible for everything VMS needs?
>>>>>>>
>>>>>>> Gotta love double standards ...
>>>>>>
>>>>>> Well that's a load of bollocks David. We are talking about things
>>>>>> that are integral within Linux, in the same way as, say, RMS, clustering,
>>>>>> and KESU modes are integral within VMS.
>>>>>
>>>>> That was pretty strong words given that you are only 75% correct ...
>>>>
>>>> I've just reviewed my list in the posting that David is responding to
>>>> and I don't see it, so can you tell me which 25% am I wrong about ?
>>>
>>> Really?
>>>
>>> So if we from that list:
>>>
>>> # For example, Linux has mandatory access controls and VMS is still stuck
>>> # back in the DAC world.
>>> #
>>> # There's no ASLR/KASLR support on VMS.
>>> #
>>> # There's nothing like the Unix chroot jails on VMS.
>>> #
>>> # Compiler protections in generated code has been lacking on VMS compared
>>> # to what is available elsewhere, but John in recent years has started
>>> # looking at getting comparable protections in the VMS compilers, when it
>>> # comes to generating code, that currently exist elsewhere.
>>>
>>> create a little pop quiz:
>>>
>>> Which of the following items:
>>> A) mandatory access controls
>>> B) ASLR
>>> C) chroot jails
>>> D) Compiler protections in generated code
>>> are not "integral within Linux"?
>>>
>>> Then you have no idea?
>>>
>>
>> They all are present and integrated within Linux these days Arne. Which one
>> do you think is missing from Linux ?
>
> Well - maybe you are not aware.
>
> But the compiler used by Linux GCC is not "integral within Linux"
> (your words) but "from third parties" (Davids words). It comes
> from the GNU project not the Linux kernel project.
>

A review of my posting history, including discussion of work I have
done on them in the past, would make it very clear I know this.
However, you have moved from talking about the compiler protections
to talking about the compilers themselves.

> That a compiler is used to build something does not make it
> an integral part of what is being build.
>

No, but the resulting compiler protections _ARE_ an integral part of
Linux just as I stated above. Note that I never stated anything about
the compilers themselves above, but only the resulting protections.

You end up with a Linux system that has yet another layer of security
integrated right into it, which makes it harder to compromise, in exactly
the same way as ASLR and friends also make it harder to compromise.

Basic protections BTW that are missing from "the world's most secure
operating system."

Simon.

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

On 11/17/2022 8:23 AM, Simon Clubley wrote:
> On 2022-11-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/10/2022 8:32 AM, Simon Clubley wrote:
>>> On 2022-11-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 11/9/2022 8:09 AM, Simon Clubley wrote:
>>>>> On 2022-11-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>>> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>>>>>>> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>>> I don't use Linux, but it is my impression that just about everything in Linux
>>>>>>>> is from third parties. Nor is Linux restricted to a single vendor.
>>>>>>>>
>>>>>>>> So why then should VSI be responsible for everything VMS needs?
>>>>>>>>
>>>>>>>> Gotta love double standards ...
>>>>>>>
>>>>>>> Well that's a load of bollocks David. We are talking about things
>>>>>>> that are integral within Linux, in the same way as, say, RMS, clustering,
>>>>>>> and KESU modes are integral within VMS.
>>>>>>
>>>>>> That was pretty strong words given that you are only 75% correct ...
>>>>>
>>>>> I've just reviewed my list in the posting that David is responding to
>>>>> and I don't see it, so can you tell me which 25% am I wrong about ?
>>>>
>>>> Really?
>>>>
>>>> So if we from that list:
>>>>
>>>> # For example, Linux has mandatory access controls and VMS is still stuck
>>>> # back in the DAC world.
>>>> #
>>>> # There's no ASLR/KASLR support on VMS.
>>>> #
>>>> # There's nothing like the Unix chroot jails on VMS.
>>>> #
>>>> # Compiler protections in generated code has been lacking on VMS compared
>>>> # to what is available elsewhere, but John in recent years has started
>>>> # looking at getting comparable protections in the VMS compilers, when it
>>>> # comes to generating code, that currently exist elsewhere.
>>>>
>>>> create a little pop quiz:
>>>>
>>>> Which of the following items:
>>>> A) mandatory access controls
>>>> B) ASLR
>>>> C) chroot jails
>>>> D) Compiler protections in generated code
>>>> are not "integral within Linux"?
>>>>
>>>> Then you have no idea?
>>>>
>>>
>>> They all are present and integrated within Linux these days Arne. Which one
>>> do you think is missing from Linux ?
>>
>> Well - maybe you are not aware.
>>
>> But the compiler used by Linux GCC is not "integral within Linux"
>> (your words) but "from third parties" (Davids words). It comes
>> from the GNU project not the Linux kernel project.
>
> A review of my posting history, including discussion of work I have
> done on them in the past, would make it very clear I know this.

I know that you have a high opinion about yourself.

> However, you have moved from talking about the compiler protections
> to talking about the compilers themselves.

The code generated by the compiler is certainly different from the
compiler itself.

But the first comes from the second.

>> That a compiler is used to build something does not make it
>> an integral part of what is being build.
>
> No, but the resulting compiler protections _ARE_ an integral part of
> Linux just as I stated above. Note that I never stated anything about
> the compilers themselves above, but only the resulting protections.

A Linux binary compiled with GCC using the compile switch that
enable SSP has this feature.

But it is the third party product GCC that makes it possible.

It is not a characteristics of Linux. It is the benefit of the
third party tooling available for Linux.

Arne

On 2022-11-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/17/2022 8:23 AM, Simon Clubley wrote:
>> On 2022-11-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/10/2022 8:32 AM, Simon Clubley wrote:
>>>> On 2022-11-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> On 11/9/2022 8:09 AM, Simon Clubley wrote:
>>>>>> On 2022-11-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>>>> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>>>>>>>> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>>>> I don't use Linux, but it is my impression that just about everything in Linux
>>>>>>>>> is from third parties. Nor is Linux restricted to a single vendor.
>>>>>>>>>
>>>>>>>>> So why then should VSI be responsible for everything VMS needs?
>>>>>>>>>
>>>>>>>>> Gotta love double standards ...
>>>>>>>>
>>>>>>>> Well that's a load of bollocks David. We are talking about things
>>>>>>>> that are integral within Linux, in the same way as, say, RMS, clustering,
>>>>>>>> and KESU modes are integral within VMS.
>>>>>>>
>>>>>>> That was pretty strong words given that you are only 75% correct ...
>>>>>>
>>>>>> I've just reviewed my list in the posting that David is responding to
>>>>>> and I don't see it, so can you tell me which 25% am I wrong about ?
>>>>>
>>>>> Really?
>>>>>
>>>>> So if we from that list:
>>>>>
>>>>> # For example, Linux has mandatory access controls and VMS is still stuck
>>>>> # back in the DAC world.
>>>>> #
>>>>> # There's no ASLR/KASLR support on VMS.
>>>>> #
>>>>> # There's nothing like the Unix chroot jails on VMS.
>>>>> #
>>>>> # Compiler protections in generated code has been lacking on VMS compared
>>>>> # to what is available elsewhere, but John in recent years has started
>>>>> # looking at getting comparable protections in the VMS compilers, when it
>>>>> # comes to generating code, that currently exist elsewhere.
>>>>>
>>>>> create a little pop quiz:
>>>>>
>>>>> Which of the following items:
>>>>> A) mandatory access controls
>>>>> B) ASLR
>>>>> C) chroot jails
>>>>> D) Compiler protections in generated code
>>>>> are not "integral within Linux"?
>>>>>
>>>>> Then you have no idea?
>>>>>
>>>>
>>>> They all are present and integrated within Linux these days Arne. Which one
>>>> do you think is missing from Linux ?
>>>
>>> Well - maybe you are not aware.
>>>
>>> But the compiler used by Linux GCC is not "integral within Linux"
>>> (your words) but "from third parties" (Davids words). It comes
>>> from the GNU project not the Linux kernel project.
>>
>> A review of my posting history, including discussion of work I have
>> done on them in the past, would make it very clear I know this.
>
> I know that you have a high opinion about yourself.
>

Well, that's extremely rich coming from you Arne.

You have such a self-important opinion of yourself that you can confidently
state, on a wide range of subjects, that people are doing one of A, B, or C
and then assign percentages to those options and then you further state this
level of detail as if it was an established fact.

The sheer sense of self-importance of someone who feels comfortable doing
that on a regular basis easily dwarfs anything I may be guilty of.

>> However, you have moved from talking about the compiler protections
>> to talking about the compilers themselves.
>
> The code generated by the compiler is certainly different from the
> compiler itself.
>
> But the first comes from the second.
>
>>> That a compiler is used to build something does not make it
>>> an integral part of what is being build.
>>
>> No, but the resulting compiler protections _ARE_ an integral part of
>> Linux just as I stated above. Note that I never stated anything about
>> the compilers themselves above, but only the resulting protections.
>
> A Linux binary compiled with GCC using the compile switch that
> enable SSP has this feature.
>
> But it is the third party product GCC that makes it possible.
>
> It is not a characteristics of Linux. It is the benefit of the
> third party tooling available for Linux.
>

It's more than that. Linux is now developed with those options enabled
so errors are much more likely to be caught during development and testing.

Based on what has happened in the past, I very strongly suspect that if
VSI ever get around to adding this functionality to its own VMS builds,
the first thing it will find are a range of coding issues and potential
security issues that have simply not been picked up until now.

This is a good thing and will help increase the quality of VMS.

Simon.

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

On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne Vajhøj wrote:
> But VMS has a huge handicap compared to Linux - the
> interest in the VMS community to contribute to
> open source is very small.
>
> Arne

And until there is free access to VMS in some form (is there ever really going to be a community license for x86?), the interest in the open source community to contribute to VMS is going to be nonexistent.

One big difference between VMS and Linux -- Linux doesn't charge people to become developers.

On 11/21/2022 2:31 PM, Steve Kelley wrote:
> On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne Vajhøj wrote:
>> But VMS has a huge handicap compared to Linux - the
>> interest in the VMS community to contribute to
>> open source is very small.
>
> And until there is free access to VMS in some form (is there ever
> really going to be a community license for x86?), the interest in the
> open source community to contribute to VMS is going to be nonexistent.
>
> One big difference between VMS and Linux -- Linux doesn't charge people to become developers.

One can get community license for Alpha and Itanium. Used Alpha boxes
are rather cheap. There is a free open source Alpha emulator available.
I expect community license for x86-64 to become available
at some point in time (maybe when native compilers become
available).

One can get the student license with an Alpha emulator.

One can get ISV license for Alpha, Itanium or x86-64.

One can get an account on DECUS Eisner.

I really don't see cost as something stopping those wanting
to contribute to open source on VMS.

Arne

On 11/21/2022 2:31 PM, Steve Kelley wrote:
> On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne Vajhøj wrote:
>> But VMS has a huge handicap compared to Linux - the interest in the VMS
>> community to contribute to open source is very small.
>>
>> Arne
>
> And until there is free access to VMS in some form (is there ever really
> going to be a community license for x86?), the interest in the open source
> community to contribute to VMS is going to be nonexistent.
>
> One big difference between VMS and Linux -- Linux doesn't charge people to
> become developers.

Neither do we -- ISV partnership at the bronze level is free

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

--
--- Rob

In article <647a7286-58e6-45fa-b4d6-8c191d75b2d4n@googlegroups.com>,
Steve Kelley <smk488@gmail.com> writes:

> On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne Vajhøj wrote:
> > But VMS has a huge handicap compared to Linux - the
> > interest in the VMS community to contribute to
> > open source is very small.
> >
> > Arne
>
> And until there is free access to VMS in some form (is there ever really
> going to be a community license for x86?), the interest in the open source
> community to contribute to VMS is going to be nonexistent.

Maybe not nonexistent, but much less.

> One big difference between VMS and Linux -- Linux doesn't charge people to
> become developers.

I was really optimistic when VSI took over VMS, but their license policy
will probably kill it.

In article <tlgnmt$1p5j$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<arne@vajhoej.dk> writes:

> On 11/21/2022 2:31 PM, Steve Kelley wrote:
> > On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne VajhÞj wrote:
> >> But VMS has a huge handicap compared to Linux - the
> >> interest in the VMS community to contribute to
> >> open source is very small.
> >
> > And until there is free access to VMS in some form (is there ever
> > really going to be a community license for x86?), the interest in the
> > open source community to contribute to VMS is going to be nonexistent.
> >
> > One big difference between VMS and Linux -- Linux doesn't charge people to become developers.
>
> One can get community license for Alpha and Itanium. Used Alpha boxes
> are rather cheap. There is a free open source Alpha emulator available.
> I expect community license for x86-64 to become available
> at some point in time (maybe when native compilers become
> available).
>
> One can get the student license with an Alpha emulator.
>
> One can get ISV license for Alpha, Itanium or x86-64.
>
> One can get an account on DECUS Eisner.
>
> I really don't see cost as something stopping those wanting
> to contribute to open source on VMS.

For the future we are concerned with VSI VMS on Itanium. Even a
hobbyist will probably not be willing to invest much time, effort, or
money for a license which might stop working less than a year from now.

In article <tlgqhi$3q5k2$1@dont-email.me>, "Robert A. Brooks"
<FIRST.LAST@vmssoftware.com> writes:

> On 11/21/2022 2:31 PM, Steve Kelley wrote:
> > On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne VajhÞj wrote:
> >> But VMS has a huge handicap compared to Linux - the interest in the VMS
> >> community to contribute to open source is very small.
> >>
> >> Arne
> >
> > And until there is free access to VMS in some form (is there ever really
> > going to be a community license for x86?), the interest in the open source
> > community to contribute to VMS is going to be nonexistent.
> >
> > One big difference between VMS and Linux -- Linux doesn't charge people to
> > become developers.
>
> Neither do we -- ISV partnership at the bronze level is free
>
> https://vmssoftware.com/about/partners/program/

Do the licenses expire one year after creation?

On 2022-11-22, Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> wrote:
>
> For the future we are concerned with VSI VMS on Itanium. Even a
> hobbyist will probably not be willing to invest much time, effort, or
> money for a license which might stop working less than a year from now.
>

In a world where people produce emulations of hardware architectures just
for fun, it's interesting that no-one has produced a full-system Itanium
emulator.

That shows just how complex Itanium really is. (Plus the fact that the
required firmware is now only apparently available under a support contract).

Simon.

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

On 11/22/2022 2:07 AM, Phillip Helbig (undress to reply) wrote:
> In article <tlgqhi$3q5k2$1@dont-email.me>, "Robert A. Brooks"
> <FIRST.LAST@vmssoftware.com> writes:
>
>> On 11/21/2022 2:31 PM, Steve Kelley wrote:
>>> On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne VajhÞj wrote:
>>>> But VMS has a huge handicap compared to Linux - the interest in the VMS
>>>> community to contribute to open source is very small.
>>>>
>>>> Arne
>>>
>>> And until there is free access to VMS in some form (is there ever really
>>> going to be a community license for x86?), the interest in the open source
>>> community to contribute to VMS is going to be nonexistent.
>>>
>>> One big difference between VMS and Linux -- Linux doesn't charge people to
>>> become developers.
>>
>> Neither do we -- ISV partnership at the bronze level is free
>>
>> https://vmssoftware.com/about/partners/program/
>
> Do the licenses expire one year after creation?
>

Community licenses are a year to year thing. Live with it.

ISV licenses are a year to year thing. Live with it.

You get what you pay for. When it is free, the license granter is free to set
the terms.

Now, should you wish to purchase a commercial x86 VMS license, make your offer
to VSI, with your desired terms. If you haven't done so, then you cannot say
you are disappointed.

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

In article <tlj0jd$4qu4$1@dont-email.me>, Dave Froble
<davef@tsoft-inc.com> writes:

> >> Neither do we -- ISV partnership at the bronze level is free
> >>
> >> https://vmssoftware.com/about/partners/program/
> >
> > Do the licenses expire one year after creation?
>
> Community licenses are a year to year thing. Live with it.
>
> ISV licenses are a year to year thing. Live with it.
>
> You get what you pay for. When it is free, the license granter is
> free to set the terms.

The HUGE difference is that, in the past, there was always the option to
purchases a full, commercial, non-expiring license. That is no longer
the case.

> Now, should you wish to purchase a commercial x86 VMS license, make your
> offer to VSI, with your desired terms. If you haven't done so, then you
> cannot say you are disappointed.

Many people have, and were disappointed.

On 11/22/2022 2:18 PM, Phillip Helbig (undress to reply) wrote:
> In article <tlj0jd$4qu4$1@dont-email.me>, Dave Froble
> <davef@tsoft-inc.com> writes:
>
>>>> Neither do we -- ISV partnership at the bronze level is free
>>>>
>>>> https://vmssoftware.com/about/partners/program/
>>>
>>> Do the licenses expire one year after creation?
>>
>> Community licenses are a year to year thing. Live with it.
>>
>> ISV licenses are a year to year thing. Live with it.
>>
>> You get what you pay for. When it is free, the license granter is
>> free to set the terms.
>
> The HUGE difference is that, in the past, there was always the option to
> purchases a full, commercial, non-expiring license. That is no longer
> the case.

That was then, this is now. Things change.

>> Now, should you wish to purchase a commercial x86 VMS license, make your
>> offer to VSI, with your desired terms. If you haven't done so, then you
>> cannot say you are disappointed.
>
> Many people have, and were disappointed.
>

Have you? If not, then you really don't know.

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

On 11/22/2022 2:06 AM, Phillip Helbig (undress to reply) wrote:
> In article <tlgnmt$1p5j$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
> <arne@vajhoej.dk> writes:
>> On 11/21/2022 2:31 PM, Steve Kelley wrote:
>>> On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne VajhÞj wrote:
>>>> But VMS has a huge handicap compared to Linux - the
>>>> interest in the VMS community to contribute to
>>>> open source is very small.
>>>
>>> And until there is free access to VMS in some form (is there ever
>>> really going to be a community license for x86?), the interest in the
>>> open source community to contribute to VMS is going to be nonexistent.
>>>
>>> One big difference between VMS and Linux -- Linux doesn't charge people to become developers.
>>
>> One can get community license for Alpha and Itanium. Used Alpha boxes
>> are rather cheap. There is a free open source Alpha emulator available.
>> I expect community license for x86-64 to become available
>> at some point in time (maybe when native compilers become
>> available).
>>
>> One can get the student license with an Alpha emulator.
>>
>> One can get ISV license for Alpha, Itanium or x86-64.
>>
>> One can get an account on DECUS Eisner.
>>
>> I really don't see cost as something stopping those wanting
>> to contribute to open source on VMS.
>
> For the future we are concerned with VSI VMS on Itanium. Even a
> hobbyist will probably not be willing to invest much time, effort, or
> money for a license which might stop working less than a year from now.

It seems very likely that most CL will be for Alpha
today and hopefully soon x86-64.

Itanium hardware will be too rare.

But I don't think it matters much from an VMS open
source perspective.

If the open source supports VMS Alpha and eventually
VMS x86-64, then it will most likely also work fine on
VMS Itanium.

"VMS is VMS"

Arne

On 2022-11-22 19:38:19 +0000, Dave Froble said:

> On 11/22/2022 2:18 PM, Phillip Helbig (undress to reply) wrote:
>> In article <tlj0jd$4qu4$1@dont-email.me>, Dave Froble
>> <davef@tsoft-inc.com> writes:
>>
>> The HUGE difference is that, in the past, there was always the option
>> to purchases a full, commercial, non-expiring license. That is no
>> longer the case.
>
> That was then, this is now. Things change.

Yes, times and licencing and the rest can and do change.

Here's another change:

https://www.intel.com/content/www/us/en/products/docs/ondemand/overview.html

How widely (and how quickly) that change might be implemented?

--
Pure Personal Opinion | HoffmanLabs LLC

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: Tuesday, November 22, 2022 5:04 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] VMS and security
>
> On 11/22/2022 2:06 AM, Phillip Helbig (undress to reply) wrote:
> > In article <tlgnmt$1p5j$1@gioia.aioe.org>,
> > =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
> >> On 11/21/2022 2:31 PM, Steve Kelley wrote:
> >>> On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne VajhÞj
> wrote:
> >>>> But VMS has a huge handicap compared to Linux - the interest in the
> >>>> VMS community to contribute to open source is very small.
> >>>
> >>> And until there is free access to VMS in some form (is there ever
> >>> really going to be a community license for x86?), the interest in
> >>> the open source community to contribute to VMS is going to be
> nonexistent.
> >>>
> >>> One big difference between VMS and Linux -- Linux doesn't charge
> people to become developers.
> >>
> >> One can get community license for Alpha and Itanium. Used Alpha boxes
> >> are rather cheap. There is a free open source Alpha emulator available.
> >> I expect community license for x86-64 to become available at some
> >> point in time (maybe when native compilers become available).
> >>
> >> One can get the student license with an Alpha emulator.
> >>
> >> One can get ISV license for Alpha, Itanium or x86-64.
> >>
> >> One can get an account on DECUS Eisner.
> >>
> >> I really don't see cost as something stopping those wanting to
> >> contribute to open source on VMS.
> >
> > For the future we are concerned with VSI VMS on Itanium. Even a
> > hobbyist will probably not be willing to invest much time, effort, or
> > money for a license which might stop working less than a year from now.
>
> It seems very likely that most CL will be for Alpha today and hopefully soon
> x86-64.
>
> Itanium hardware will be too rare.
>
> But I don't think it matters much from an VMS open source perspective.
>
> If the open source supports VMS Alpha and eventually VMS x86-64, then it
> will most likely also work fine on VMS Itanium.
>
> "VMS is VMS"
>
> Arne
>

As a fyi, VSI's open source web page: (great improvements)
<https://vmssoftware.com/products/list/?license=Open%20Source>

A WIP, but some good stuff .e.g. PHP V8
<https://vmssoftware.com/products/php/>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On Wednesday, November 9, 2022 at 3:22:04 PM UTC-5, Arne Vajhøj wrote:
> >>
> MAC for VMS should be relative well understood. That was what
> SEVMS provided.
>
> Arne

Since the SEVMS code is still there, wouldn't making sure that code still works and fixing what doesn't be a good and
inexpensive way to start?

On 2023-01-03, ultr...@gmail.com <ultradwc@gmail.com> wrote:
> On Wednesday, November 9, 2022 at 3:22:04 PM UTC-5, Arne Vajhøj wrote:
>> >>
>> MAC for VMS should be relative well understood. That was what
>> SEVMS provided.
>>
>> Arne
>
> Since the SEVMS code is still there, wouldn't making sure that code still works and fixing what doesn't be a good and
> inexpensive way to start?

What makes you think its still there, at least in any way that is
remotely usable ?

Even if it was still usable, it still doesn't have anywhere near the
level of functionality that SELinux has. For example, SEVMS has _no_
TCP/IP integration whereas SELinux does, and in ways that actively
enhance the ability of Linux systems to help keep a successful breach
contained.

Simon.

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

On 2023-01-03 17:49:54 +0000, ultr...@gmail.com said:

> On Wednesday, November 9, 2022 at 3:22:04 PM UTC-5, Arne Vajhøj wrote:
>>>>
>> MAC for VMS should be relative well understood. That was what SEVMS provided.
>
> Since the SEVMS code is still there, wouldn't making sure that code
> still works and fixing what doesn't be a good and
> inexpensive way to start?

If you want just the underpinnings of Rainbow-era US DoD/NCSC Class B1
Orange-focused MAC, a design which was found approximately non-sellable
including to some of those same entities that had worked on and
specified Class B1 security, and that probably also involving with few
or none of the SEVMS utilities and tools available, and all that also
probably untested for a quarter-century, sure.

Serving as a foundation for a whole lot of design and development work
both on the MAC code and within on OpenVMS APIs and docs and elsewhere,
and within IP networking, and with related work on better-integrated
encryption and key stores and such, sure.

As anything that'll be likely useful by apps in the rest of this decade, no.

Pragmatically, BSD pledge is probably a better option for VSI in the
short term. And that's no small project. And that requires app
assistance. https://man.openbsd.org/pledge.2 Creating app sandboxing
/ app jail / would be the closest modern application, and some parts of
Class B1 might be (poorly) useable for that.

The only folks that might consider NCSC Class B1 Rainbow-era MAC
nowadays are scarce at best, or folks that may have never even used
Class B1 and will probably then quickly lose interest. Managing and
labeling information flow within a large and complex system is less
than easy. And again, Class B1 really isn't all that useful for
securing most apps. Approximately no commercial providers would
consider using Class B1, absent some regulatory or contractual mandate.

--
Pure Personal Opinion | HoffmanLabs LLC

On Tuesday, January 3, 2023 at 1:26:25 PM UTC-5, Simon Clubley wrote:
> On 2023-01-03, ultr...@gmail.com <ultr...@gmail.com> wrote:
> > On Wednesday, November 9, 2022 at 3:22:04 PM UTC-5, Arne Vajhøj wrote:
> >> >>
> >> MAC for VMS should be relative well understood. That was what
> >> SEVMS provided.
> >>
> >> Arne
> >
> > Since the SEVMS code is still there, wouldn't making sure that code still works and fixing what doesn't be a good and
> > inexpensive way to start?
> What makes you think its still there, at least in any way that is
> remotely usable ?
>
> Even if it was still usable, it still doesn't have anywhere near the
> level of functionality that SELinux has. For example, SEVMS has _no_
> TCP/IP integration whereas SELinux does, and in ways that actively
> enhance the ability of Linux systems to help keep a successful breach
> contained.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

that is where you hire some coal miners and add that code ...

On Tuesday, January 3, 2023 at 5:27:12 PM UTC-5, Stephen Hoffman wrote:
> On 2023-01-03 17:49:54 +0000, ultr...@gmail.com said:
>
> > On Wednesday, November 9, 2022 at 3:22:04 PM UTC-5, Arne Vajhøj wrote:
> >>>>
> >> MAC for VMS should be relative well understood. That was what SEVMS provided.
> >
> > Since the SEVMS code is still there, wouldn't making sure that code
> > still works and fixing what doesn't be a good and
> > inexpensive way to start?
> If you want just the underpinnings of Rainbow-era US DoD/NCSC Class B1
> Orange-focused MAC, a design which was found approximately non-sellable
> including to some of those same entities that had worked on and
> specified Class B1 security, and that probably also involving with few
> or none of the SEVMS utilities and tools available, and all that also
> probably untested for a quarter-century, sure.
>
> Serving as a foundation for a whole lot of design and development work
> both on the MAC code and within on OpenVMS APIs and docs and elsewhere,
> and within IP networking, and with related work on better-integrated
> encryption and key stores and such, sure.
>
> As anything that'll be likely useful by apps in the rest of this decade, no.
>
> Pragmatically, BSD pledge is probably a better option for VSI in the
> short term. And that's no small project. And that requires app
> assistance. https://man.openbsd.org/pledge.2 Creating app sandboxing
> / app jail / would be the closest modern application, and some parts of
> Class B1 might be (poorly) useable for that.
>
> The only folks that might consider NCSC Class B1 Rainbow-era MAC
> nowadays are scarce at best, or folks that may have never even used
> Class B1 and will probably then quickly lose interest. Managing and
> labeling information flow within a large and complex system is less
> than easy. And again, Class B1 really isn't all that useful for
> securing most apps. Approximately no commercial providers would
> consider using Class B1, absent some regulatory or contractual mandate.
> --
> Pure Personal Opinion | HoffmanLabs LLC

you just got done telling us it might serve as a basis to add sandboxing and some other features ...

On 2023-01-06 01:17:20 +0000, ultr...@gmail.com said:

> you just got done telling us it might serve as a basis to add
> sandboxing and some other features ...

If you missed the paragraph ending in "sure", sure.

--
Pure Personal Opinion | HoffmanLabs LLC