Discussion:
Security, support and VMS, was: Re: A new VMS?
(too old to reply)
Simon Clubley
2021-05-03 16:28:32 UTC
Permalink
Well I was talking more about simple support. Not patching etc
There are a lot of customers out there happy and content with their
current status.
They just need a hand held when something goes wrong
I would say that goes for the majority of users out there.
Huh ??? The majority of VMS users don't care about keeping their
systems up to date and fully patched ???

I am having a hard time believing that...

This isn't 20 years ago and anyone who acts like it is will find
this out sooner or later.

The thing about security is that you simply don't know if the
next security issue that will affect you is just around the corner.

Please tell me David is very wrong about this and that most VMS sites
do consider themselves to be just as vulnerable as everyone else
and take all the usual precautions as a result.

If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2021-05-03 16:57:10 UTC
Permalink
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Your obsession!!

What about when people finally realize that none of these "security
researchers" couldn't care less about VMS and have better things to
do with their time.

bill
Simon Clubley
2021-05-03 17:29:08 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Your obsession!!
We keep getting told that the remaining VMS are super important to their
owners and are vital to the running of their organisations.

So no, not an obsession, just reality.
Post by Bill Gunshannon
What about when people finally realize that none of these "security
researchers" couldn't care less about VMS and have better things to
do with their time.
Until they want to do something different that sets themselves apart
from their peers and then they find out about these super important
systems running an unusual operating system that is not Linux or
Windows and which none of their peers seem to know about.

At this point, they find out about the VSI marketing that claims "VMS
is the most secure operating system on the planet" and they promptly
go "Oh, really ???".

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Phillip Helbig (undress to reply)
2021-05-03 18:24:15 UTC
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Your obsession!!
We keep getting told that the remaining VMS are super important to their
owners and are vital to the running of their organisations.
Yes, but how many of them are running VMS on private networks? Probably
most.
Arne Vajhøj
2021-05-03 18:38:10 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
Post by Bill Gunshannon
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Your obsession!!
We keep getting told that the remaining VMS are super important to their
owners and are vital to the running of their organisations.
Yes, but how many of them are running VMS on private networks? Probably
most.
Practical all systems of any importance are on "private" network
today.

But that does not mean that they can not be attacked.

Unless they are not on a network at all or on a totally
isolated network then attacks can target a computer
that can be used to target a computer that ... and
so on.

Very few networks are totally isolated today. Almost everything
is somewhat connected.

So the attacker targets your wifes iPad, use that to get
to your work laptop, use that to get to the company windows
server and use that to reach the VMS system.

And don't say that can't happen. Remember StuxNet.

Arne
chris
2021-05-04 15:22:07 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Bill Gunshannon
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Your obsession!!
We keep getting told that the remaining VMS are super important to their
owners and are vital to the running of their organisations.
Yes, but how many of them are running VMS on private networks? Probably
most.
Practical all systems of any importance are on "private" network
today.
But that does not mean that they can not be attacked.
Unless they are not on a network at all or on a totally
isolated network then attacks can target a computer
that can be used to target a computer that ... and
so on.
Very few networks are totally isolated today. Almost everything
is somewhat connected.
So the attacker targets your wifes iPad, use that to get
to your work laptop, use that to get to the company windows
server and use that to reach the VMS system.
And don't say that can't happen. Remember StuxNet.
Arne
That's very true, no system is absolutely secure, given enough time
and resources, but that must be balanced against the benefit for the
attacker. Most systems are just not worth the effort, given the
resources required. Good firewalling, admin and process should stop
all but the most determined attempts.

Here, once systems and apps are installed, with initial patches if
available, they are usually locked down for life. Stability and
consistence being more important than obsessive patching, which
itself can break more then it fixes...

Chris
break something
Arne Vajhøj
2021-05-04 17:12:18 UTC
Permalink
Post by chris
Post by Arne Vajhøj
Post by Simon Clubley
We keep getting told that the remaining VMS are super important to their
owners and are vital to the running of their organisations.
Yes, but how many of them are running VMS on private networks? Probably
most.
Practical all systems of any importance are on "private" network
today.
But that does not mean that they can not be attacked.
Unless they are not on a network at all or on a totally
isolated network then attacks can target a computer
that can be used to target a computer that ... and
so on.
Very few networks are totally isolated today. Almost everything
is somewhat connected.
So the attacker targets your wifes iPad, use that to get
to your work laptop, use that to get to the company windows
server and use that to reach the VMS system.
That's very true, no system is absolutely secure, given enough time
and resources, but that must be balanced against the benefit for the
attacker. Most systems are just not worth the effort, given the
resources required. Good firewalling, admin and process should stop
all but the most determined attempts.
If what the system does is not important then most likely it will
not have value to hack it.

But if the system is important in some sense then most likely it
will have value for someone to hack it.
Post by chris
Here, once systems and apps are installed, with initial patches if
available, they are usually locked down for life. Stability and
consistence being more important than obsessive patching, which
itself can break more then it fixes...
This was common 30 years ago, but it is getting much rarer today.

For good reasons.

Con patching:
- N minutes of scheduled down time like once per month
- risk of M minutes of unplanned downtime due to faulty patch
requiring rollback

Pro patching:
- prevent data leak to competitors, foreign states criminal blackmailers
- prevent unauthorized data modification that creates havoc by
foreign states, terrorists or malicious competitors
- prevent system being temporarily made unavailable by criminal
blackmailers or terrorists

If a system has important data or are doing something important,
then patching is good business (and in many cases regulatory/contractual
required).

Arne
Arne Vajhøj
2021-05-03 18:29:13 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Your obsession!!
What about when people finally realize that none of these "security
researchers" couldn't care less about VMS and have better things to
do with their time.
I am also skeptical about whether VMS 9.2 on x86-64 will trigger that
much interest.

For those interested in working with VMS then there is plenty
of options for emulators available for VAX and Alpha. Only
Itanium is a bit hard to get to.

On the other side do not forget that these white hats
are not a worst case. Some black hats that goes public
1 minute after getting in is worse. And some professionals
(like what is called state actors) targeting and accessing
a system of actual value and exploit the access and keep
totally silent is much worse.

Arne
Dave Froble
2021-05-03 20:53:10 UTC
Permalink
This needs to be fixed ....

S/security researchers/hackers/%wh
Post by Bill Gunshannon
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the hackers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Your obsession!!
What about when people finally realize that none of these "hackers"
couldn't care less about VMS and have better things to
do with their time.
bill
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-04 17:46:44 UTC
Permalink
Post by Dave Froble
This needs to be fixed ....
S/security researchers/hackers/%wh
For anyone reading this message in isolation, David changed my quoted
message below to say something I did not.

Simon.
Post by Dave Froble
Post by Bill Gunshannon
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the hackers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Your obsession!!
What about when people finally realize that none of these "hackers"
couldn't care less about VMS and have better things to
do with their time.
bill
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2021-05-04 18:15:23 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
This needs to be fixed ....
S/security researchers/hackers/%wh
For anyone reading this message in isolation, David changed my quoted
message below to say something I did not.
Simon.
Mine as well. Not really very kosher.

bill
Post by Simon Clubley
Post by Dave Froble
Post by Bill Gunshannon
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the hackers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Your obsession!!
What about when people finally realize that none of these "hackers"
couldn't care less about VMS and have better things to
do with their time.
bill
Dave Froble
2021-05-04 22:20:29 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
Post by Dave Froble
This needs to be fixed ....
S/security researchers/hackers/%wh
For anyone reading this message in isolation, David changed my quoted
message below to say something I did not.
Simon.
Mine as well. Not really very kosher.
bill
Truth hurts, huh?

:-) :-) :-) :-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
abrsvc
2021-05-03 18:12:47 UTC
Permalink
Post by Simon Clubley
Well I was talking more about simple support. Not patching etc
There are a lot of customers out there happy and content with their
current status.
They just need a hand held when something goes wrong
I would say that goes for the majority of users out there.
Huh ??? The majority of VMS users don't care about keeping their
systems up to date and fully patched ???
I am having a hard time believing that...
This isn't 20 years ago and anyone who acts like it is will find
this out sooner or later.
The thing about security is that you simply don't know if the
next security issue that will affect you is just around the corner.
Please tell me David is very wrong about this and that most VMS sites
do consider themselves to be just as vulnerable as everyone else
and take all the usual precautions as a result.
If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Simon.
--
Walking destinations on a map are further away than they appear.
If you take what you say to its full extent, than you would never see VAX/VMS V5.5 systems running today, nor Alpha V7.3-2 systems running today. I currently support both for more than 1 client each.

Yes, many OpenVMS systems remain at "known" levels for extended periods of time. This is one of the reasons for uptimes measured in years.

I would posit that until OpenVMS runs native on the hardware, the majority if not all
abrsvc
2021-05-03 18:18:42 UTC
Permalink
Post by Simon Clubley
Well I was talking more about simple support. Not patching etc
There are a lot of customers out there happy and content with their
current status.
They just need a hand held when something goes wrong
I would say that goes for the majority of users out there.
Huh ??? The majority of VMS users don't care about keeping their
systems up to date and fully patched ???
I am having a hard time believing that...
This isn't 20 years ago and anyone who acts like it is will find
this out sooner or later.
The thing about security is that you simply don't know if the
next security issue that will affect you is just around the corner.
Please tell me David is very wrong about this and that most VMS sites
do consider themselves to be just as vulnerable as everyone else
and take all the usual precautions as a result.
If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
Simon.
--
Walking destinations on a map are further away than they appear.
If you take what you say to its full extent, than you would never see VAX/VMS V5.5 systems running today, nor Alpha V7.3-2 systems running today. I currently support both for more than 1 client each.

Yes, many OpenVMS systems remain at "known" levels for extended periods of time. This is one of the reasons for uptimes measured in years.

I would posit that until OpenVMS runs native on the hardware, the majority if not all of the holes will be with the OS under which VMS is running.
To take a pre-emptive strike... Yes, I know that you found a vulnerability in DCL that was there for a long time (and it was fixed), but that required you to be already connected. Do you have examples of overtaking the system WITHOUT access? While I won't claim that VMS is the best, you have to admit that a properly managed system is more secure than your standard Windows box. You don't read about VMS having problems with virus attacks or programs that run because you opened up an Email. These don't exist on VMS systems, they work differently. That is not to say there aren't any potential issues at all, but in the grand scheme of tings, there are far fewer on VMS systems than on others.
Simon Clubley
2021-05-04 12:11:20 UTC
Permalink
Post by abrsvc
If you take what you say to its full extent, than you would never see VAX/VMS V5.5 systems running today, nor Alpha V7.3-2 systems running today. I currently support both for more than 1 client each.
Yes, many OpenVMS systems remain at "known" levels for extended periods of time. This is one of the reasons for uptimes measured in years.
I would posit that until OpenVMS runs native on the hardware, the majority if not all of the holes will be with the OS under which VMS is running.
To take a pre-emptive strike... Yes, I know that you found a vulnerability in DCL that was there for a long time (and it was fixed), but that required you to be already connected. Do you have examples of overtaking the system WITHOUT access? While I won't claim that VMS is the best, you have to admit that a properly managed system is more secure than your standard Windows box. You don't read about VMS having problems with virus attacks or programs that run because you opened up an Email. These don't exist on VMS systems, they work differently. That is not to say there aren't any potential issues at all, but in the grand scheme of tings, there are far fewer on VMS systems than on others.
Actually Dan, this has absolutely nothing to do with the DCL vulnerability
other than an example of what I am about to say as I have moved on from that.

VMS is not Unix or Windows.

This is good because it has functionality that neither of them have.

This is bad because there's a good number of design constructs in VMS
and other features in VMS that are unknown to researchers of those other
operating systems.

Researchers know how to probe things in VMS that are common to other
operating systems and find issues there. However, what about the parts
of VMS that are unique to VMS ? How much of a workout do those features
get from a security researcher point of view ?

Those common features on other operating systems have had basic flaws
found in them and fixed and VMS benefits from that work.

How many basic flaws are waiting to be discovered in the VMS specific
parts of VMS simply because the researchers don't know those VMS specific
parts of VMS, at least not yet ?

That's all I am trying to point out.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2021-05-04 12:46:43 UTC
Permalink
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.

What "functionality" does VMS have that Unix and Windows don't?

Remember, we are talking "functionality", not just doing something
in a different manner.

bill
Phillip Helbig (undress to reply)
2021-05-04 13:25:12 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality. As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
Bill Gunshannon
2021-05-04 16:53:54 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality. As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
All of them exist in some form in Unix except file versions and I have
never known anyone other than VMS users who saw value in them. Sorry.

bill
Phillip Helbig (undress to reply)
2021-05-04 17:08:51 UTC
Permalink
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality. As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
All of them exist in some form
Yes, "in some form". But that form is not nearly as useful as the VMS
functionality. For example, tell me how to set up a logical-name table
which belongs to a given user or group but is cluster wide.
Post by Bill Gunshannon
except file versions and I have
never known anyone other than VMS users who saw value in them. Sorry.
There are many things which people see no value in because they have
never experienced them. Of all the things I listed, this one is
obviously of tremendous value.
Stephen Hoffman
2021-05-04 17:18:51 UTC
Permalink
Post by Phillip Helbig (undress to reply)
There are many things which people see no value in because they have
never experienced them. Of all the things I listed, this one is
obviously of tremendous value.
There are many things that people have never experienced, or features
that a platform lacks, and thus the folks continue using problematic or
inadequate or higher-effort solutions, yes.

I see little value in logical names, and little value in file versions.
Not as compared with competing solutions. Though on OpenVMS, that's
what we're stuck with.

The logical name key-value store could be—for instance—replaced with
LDAP. And I've long missed modern configuration file support while
working on OpenVMS.

And file versions paled as our tasks git more complex, and git tougher
to deal with, so we git other solutions. Yes, that does mean some of us
developers are mercurial.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2021-05-04 17:41:23 UTC
Permalink
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
There are many things which people see no value in because they have
never experienced them.  Of all the things I listed, this one is
obviously of tremendous value.
There are many things that people have never experienced, or features
that a platform lacks, and thus the folks continue using problematic or
inadequate or higher-effort solutions, yes.
I see little value in logical names, and little value in file versions.
Not as compared with competing solutions. Though on OpenVMS, that's what
we're stuck with.
The logical name key-value store could be—for instance—replaced with
LDAP. And I've long missed modern configuration file support while
working on OpenVMS.
And file versions paled as our tasks git more complex, and git tougher
to deal with, so we git other solutions. Yes, that does mean some of us
developers are mercurial.
When used not misused then logicals are nice - logicals for disks,
directories and files can help decouple application from
physical location with very little effort. Of course there
are plenty of cases of logicals being misused for all
types of weird hackery.

LDAP is nice too, but in my opinion a solution for a
different problem. LDAP works in a distributed heterogeneous
environment, but also require much more effort. LDAP
is certainly useful, but I think it would be overkill
for many current usages of logicals.

Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.

Arne
Arne Vajhøj
2021-05-04 17:46:20 UTC
Permalink
Post by Arne Vajhøj
Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.
Which of course would start WW III between the
XML people, the JSON people and the YAML people.

:-)

Arne
Simon Clubley
2021-05-04 18:08:20 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.
Which of course would start WW III between the
XML people, the JSON people and the YAML people.
JSON is better than XML IMHO. I just find it a lot easier to work with.

As for YAML, I've just read up about it and it looks like it was
created by the same people who created INTERCAL.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2021-05-04 18:13:11 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.
Which of course would start WW III between the
XML people, the JSON people and the YAML people.
JSON is better than XML IMHO. I just find it a lot easier to work with.
As for YAML, I've just read up about it and it looks like it was
created by the same people who created INTERCAL.
Clarification: I don't mean that the INTERCAL authors literally created
YAML which is what the above could imply. I meant it looks about as user
friendly as INTERCAL.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-04 18:39:36 UTC
Permalink
Post by Simon Clubley
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.
Which of course would start WW III between the
XML people, the JSON people and the YAML people.
JSON is better than XML IMHO. I just find it a lot easier to work with.
As for YAML, I've just read up about it and it looks like it was
created by the same people who created INTERCAL.
Clarification: I don't mean that the INTERCAL authors literally created
YAML which is what the above could imply. I meant it looks about as user
friendly as INTERCAL.
YAML is actually quite popular for config files today.

:-)

Arne
Arne Vajhøj
2021-05-04 18:58:32 UTC
Permalink
Post by Arne Vajhøj
On 2021-05-04, Simon Clubley
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.
Which of course would start WW III between the
XML people, the JSON people and the YAML people.
JSON is better than XML IMHO. I just find it a lot easier to work with.
As for YAML, I've just read up about it and it looks like it was
created by the same people who created INTERCAL.
Clarification: I don't mean that the INTERCAL authors literally created
YAML which is what the above could imply. I meant it looks about as user
friendly as INTERCAL.
YAML is actually quite popular for config files today.
:-)
Which of the below are most readable?

XML:

<abc>
<ab>
<a>1</a>
<b>2</b>
</ab>
<c>3</c>
</abc>

JSON:

{ "ab": {
"a": 1,
"b": 2
},
"c" : 3
}

YAML:

ab:
a: 1
b: 2
c: 3

Arne
Simon Clubley
2021-05-04 20:45:37 UTC
Permalink
Post by Arne Vajhøj
Which of the below are most readable?
JSON, especially if it is formatted in Whitesmiths style.
Post by Arne Vajhøj
<abc>
<ab>
<a>1</a>
<b>2</b>
</ab>
<c>3</c>
</abc>
This has structure, but is really ugly to read.
Post by Arne Vajhøj
{ "ab": {
"a": 1,
"b": 2
},
"c" : 3
}
This has structure and it is the best of the 3 options.
Post by Arne Vajhøj
a: 1
b: 2
c: 3
This is horrible and does not have enough structure to be robust
against editing errors when being manually edited.

Errors in both XML and JSON can be detected much more reliably
by a parser than errors in the above YAML example.

YAML was clearly created by the kind of person who thinks the
Rust language is too verbose, but would probably be well at home
if using TECO. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-05 01:21:23 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Which of the below are most readable?
JSON, especially if it is formatted in Whitesmiths style.
Really?

The curly brackets and the double quotes make it more readable.
Post by Simon Clubley
Post by Arne Vajhøj
<abc>
<ab>
<a>1</a>
<b>2</b>
</ab>
<c>3</c>
</abc>
This has structure, but is really ugly to read.
Post by Arne Vajhøj
{ "ab": {
"a": 1,
"b": 2
},
"c" : 3
}
This has structure and it is the best of the 3 options.
Post by Arne Vajhøj
a: 1
b: 2
c: 3
This is horrible and does not have enough structure to be robust
against editing errors when being manually edited.
Errors in both XML and JSON can be detected much more reliably
by a parser than errors in the above YAML example.
You do not write much Python do you?

Using indentation for structure may seem weird for
those familiar with begin end and { }, but that does
not necessarily make it more error prone.

When I dabble a little bit in Python then I don't experience
more problems with improper block structure than in
Pascal or C.

And even if an indentation is wrong then it will typical
result in an error (rather similar to JSON - XML can
be validated against a schema, which does a better
check).

Sometimes it is easier with an example.

I will use Java. I could have used Python, but I know Java
better than Python.

$ type Demo1.java
package yaml;

import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.Map;

import org.yaml.snakeyaml.Yaml;

public class Demo1 {
public static void main(String[] args) {
try {
Yaml parser = new Yaml();
InputStream is = new FileInputStream(args[0]);
Map<String, Object> cfg = (Map<String, Object>)parser.load(is);
is.close();
@SuppressWarnings("unchecked")
Map<String, Object> ab = (Map<String, Object>)cfg.get("ab");
int a = (Integer)ab.get("a");
int b = (Integer)ab.get("b");
int c = (Integer)cfg.get("c");
System.out.printf("%d %d %d\n", a, b, c);
} catch(Exception ex) {
ex.printStackTrace();
}
}
}
$ javac -cp snakeyaml-1_12.jar Demo1.java
Note: Demo1.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
$ type good1.yaml
ab:
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo1" good1.yaml
1 2 3

all good, but let us see what happens if the indentation of
the YAML gets messed up.

$ type bad1.yaml
ab:
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo1" bad1.yaml
java.lang.NullPointerException
at yaml.Demo1.main(Demo1.java:20)

We get an error when we try to get the missing ab.b (because
it was actually just a b).

But it can be even more safe by using some of the more
advanced YAML features.

It is possible to map the config to a strongly typed
object hierarchy instead of the untyped tree.

$ type Demo2.java
package yaml;

import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.Map;

import org.yaml.snakeyaml.Yaml;

public class Demo2 {
public static void main(String[] args) {
try {
Yaml parser = new Yaml();
InputStream is = new FileInputStream(args[0]);
Config cfg = (Config)parser.load(is);
is.close();
int a = cfg.getAb().getA();
int b = cfg.getAb().getB();
int c = cfg.getC();
System.out.printf("%d %d %d\n", a, b, c);
} catch(Exception ex) {
ex.printStackTrace();
}
}
}
$ type Config.java
package yaml;

public class Config {
private AB ab;
private int c;
public AB getAb() {
return ab;
}
public void setAb(AB ab) {
this.ab = ab;
}
public int getC() {
return c;
}
public void setC(int c) {
this.c = c;
}
}
$ type AB.java
package yaml;

public class AB {
private int a;
private int b;
public int getA() {
return a;
}
public void setA(int a) {
this.a = a;
}
public int getB() {
return b;
}
public void setB(int b) {
this.b = b;
}
}
$ javac -cp snakeyaml-1_12.jar Demo2.java Config.java AB.java
$ type good2.yaml
!!yaml.Config
ab:
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo2" good2.yaml
1 2 3

And now we get some very specific error messages if we mess
up the indentation.

$ type bad2.yaml
!!yaml.Config
ab:
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo2" bad2.yaml
Can't construct a java object for tag:yaml.org,2002:yaml.Config;
exception=Cannot create property=b for JavaBean=***@8347192
; Unable to find property 'b' on class: yaml.Config
in 'reader', line 1, column 1:
!!yaml.Config
^

at
org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:333)
at
org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:182)
at
org.yaml.snakeyaml.constructor.BaseConstructor.constructDocument(BaseConstructor.java:141)
at
org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseConstructor.java:127)
at org.yaml.snakeyaml.Yaml.loadFromReader(Yaml.java:481)
at org.yaml.snakeyaml.Yaml.load(Yaml.java:412)
at yaml.Demo2.main(Demo2.java:15)
Caused by: org.yaml.snakeyaml.error.YAMLException: Cannot create
property=b for JavaBean=***@8347192; Unable to find propert
y 'b' on class: yaml.Config
at
org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:299)
at
org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.construct(Constructor.java:189)
at
org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:331)
... 6 more
Caused by: org.yaml.snakeyaml.error.YAMLException: Unable to find
property 'b' on class: yaml.Config
at
org.yaml.snakeyaml.introspector.PropertyUtils.getProperty(PropertyUtils.java:132)
at
org.yaml.snakeyaml.introspector.PropertyUtils.getProperty(PropertyUtils.java:121)
at
org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.getProperty(Constructor.java:308)
at
org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:240)
... 8 more

Arne
Simon Clubley
2021-05-05 12:43:46 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Which of the below are most readable?
JSON, especially if it is formatted in Whitesmiths style.
Really?
The curly brackets and the double quotes make it more readable.
Was there a question mark at the end of that sentence ? If so, yes.
They give it nice visible structure without going over the top as XML does.
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
<abc>
<ab>
<a>1</a>
<b>2</b>
</ab>
<c>3</c>
</abc>
This has structure, but is really ugly to read.
Post by Arne Vajhøj
{ "ab": {
"a": 1,
"b": 2
},
"c" : 3
}
This has structure and it is the best of the 3 options.
Post by Arne Vajhøj
a: 1
b: 2
c: 3
This is horrible and does not have enough structure to be robust
against editing errors when being manually edited.
Errors in both XML and JSON can be detected much more reliably
by a parser than errors in the above YAML example.
You do not write much Python do you?
I write quite a bit of Python. I also dislike how whitespace is used
in Python as well.
Post by Arne Vajhøj
Using indentation for structure may seem weird for
those familiar with begin end and { }, but that does
not necessarily make it more error prone.
I am familiar with Wirth style block structure, C style block structure
and whitespace style block structure and the whitespace style block
structure is horrible compared to the first two.
Post by Arne Vajhøj
When I dabble a little bit in Python then I don't experience
more problems with improper block structure than in
Pascal or C.
And even if an indentation is wrong then it will typical
result in an error (rather similar to JSON - XML can
be validated against a schema, which does a better
check).
Sometimes it is easier with an example.
I will use Java. I could have used Python, but I know Java
better than Python.
$ type Demo1.java
package yaml;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.Map;
import org.yaml.snakeyaml.Yaml;
public class Demo1 {
public static void main(String[] args) {
try {
Yaml parser = new Yaml();
InputStream is = new FileInputStream(args[0]);
Map<String, Object> cfg = (Map<String, Object>)parser.load(is);
is.close();
@SuppressWarnings("unchecked")
Map<String, Object> ab = (Map<String, Object>)cfg.get("ab");
int a = (Integer)ab.get("a");
int b = (Integer)ab.get("b");
int c = (Integer)cfg.get("c");
System.out.printf("%d %d %d\n", a, b, c);
} catch(Exception ex) {
ex.printStackTrace();
}
}
}
$ javac -cp snakeyaml-1_12.jar Demo1.java
Note: Demo1.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
$ type good1.yaml
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo1" good1.yaml
1 2 3
all good, but let us see what happens if the indentation of
the YAML gets messed up.
$ type bad1.yaml
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo1" bad1.yaml
java.lang.NullPointerException
at yaml.Demo1.main(Demo1.java:20)
A NullPointerException error is _really_ bad here. Ideally, the
syntax should allow some type of a syntax error exception or error
along with the suspected line number causing the error.

Failing that, even raising an exception saying that you could not find
an expected element (and including the missing element name)
would be vastly better than just throwing a NullPointerException.

Is the above the acceptable quality of error reporting these days ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-05 14:36:45 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Which of the below are most readable?
JSON, especially if it is formatted in Whitesmiths style.
Really?
The curly brackets and the double quotes make it more readable.
Was there a question mark at the end of that sentence ?
Yep.
Post by Simon Clubley
If so, yes.
They give it nice visible structure without going over the top as XML does.
I doubt it. Maybe try apply it to English.

=>

{ "I" doubt it } { Maybe try apply it to "English" }

:-)
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
This is horrible and does not have enough structure to be robust
against editing errors when being manually edited.
Errors in both XML and JSON can be detected much more reliably
by a parser than errors in the above YAML example.
You do not write much Python do you?
I write quite a bit of Python. I also dislike how whitespace is used
in Python as well.
Post by Arne Vajhøj
Using indentation for structure may seem weird for
those familiar with begin end and { }, but that does
not necessarily make it more error prone.
I am familiar with Wirth style block structure, C style block structure
and whitespace style block structure and the whitespace style block
structure is horrible compared to the first two.
Everyone is entitled to like or not like a certain style.

But it is an observable fact that millions of people are able
to use indentation for structure.
Post by Simon Clubley
Post by Arne Vajhøj
And even if an indentation is wrong then it will typical
result in an error (rather similar to JSON - XML can
be validated against a schema, which does a better
check).
Sometimes it is easier with an example.
$ type good1.yaml
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo1" good1.yaml
1 2 3
all good, but let us see what happens if the indentation of
the YAML gets messed up.
$ type bad1.yaml
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo1" bad1.yaml
java.lang.NullPointerException
at yaml.Demo1.main(Demo1.java:20)
A NullPointerException error is _really_ bad here. Ideally, the
syntax should allow some type of a syntax error exception or error
along with the suspected line number causing the error.
Failing that, even raising an exception saying that you could not find
an expected element (and including the missing element name)
would be vastly better than just throwing a NullPointerException.
The point is that YAML is no different than JSON or a VMS logical
or most else.

If something is not configured the info is missing.

If the code explicit test for whether it is present then it can
give a user friendly error message.

If the code does not check then something bad happens.

The only format I can think of that detect that type of problem
without explicit application code is XML with schema and a validating
parser.

And XML schema does not exactly improve readability.

Arne
Simon Clubley
2021-05-05 17:39:51 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
You do not write much Python do you?
I write quite a bit of Python. I also dislike how whitespace is used
in Python as well.
Post by Arne Vajhøj
Using indentation for structure may seem weird for
those familiar with begin end and { }, but that does
not necessarily make it more error prone.
I am familiar with Wirth style block structure, C style block structure
and whitespace style block structure and the whitespace style block
structure is horrible compared to the first two.
Everyone is entitled to like or not like a certain style.
But it is an observable fact that millions of people are able
to use indentation for structure.
El Reg readers have a different opinion:

https://www.theregister.com/2021/05/04/yaml/

(Skip the article and go straight to the comments if you wish.)
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
all good, but let us see what happens if the indentation of
the YAML gets messed up.
$ type bad1.yaml
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo1" bad1.yaml
java.lang.NullPointerException
at yaml.Demo1.main(Demo1.java:20)
A NullPointerException error is _really_ bad here. Ideally, the
syntax should allow some type of a syntax error exception or error
along with the suspected line number causing the error.
Failing that, even raising an exception saying that you could not find
an expected element (and including the missing element name)
would be vastly better than just throwing a NullPointerException.
The point is that YAML is no different than JSON or a VMS logical
or most else.
If something is not configured the info is missing.
But it should fail in a more controlled manner than it does above.
Post by Arne Vajhøj
If the code explicit test for whether it is present then it can
give a user friendly error message.
The user's code should not have to test for this, it should be
checked in the library itself. The assumption should be that
the requested element is there when you use get() so it raises
an exception if it is not.

If it may not be there, then the library should implement something
like get_optional() which returns null so it can be checked in
the code. It's also a signal to future maintainers about exactly
which elements are and are not optional.

Not picking on this library specifically, but when I see something
where you get java.lang.NullPointerException because a required
element is missing in a data structure, then that immediately makes
me go "Yuck, yuck, yuck!". :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-05 18:10:10 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
Using indentation for structure may seem weird for
those familiar with begin end and { }, but that does
not necessarily make it more error prone.
I am familiar with Wirth style block structure, C style block structure
and whitespace style block structure and the whitespace style block
structure is horrible compared to the first two.
Everyone is entitled to like or not like a certain style.
But it is an observable fact that millions of people are able
to use indentation for structure.
https://www.theregister.com/2021/05/04/yaml/
(Skip the article and go straight to the comments if you wish.)
So on the internet there are 40 people that dislike something.

Impressive.

:-)
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
all good, but let us see what happens if the indentation of
the YAML gets messed up.
$ type bad1.yaml
a: 1
b: 2
c: 3
$ java -cp ..:snakeyaml-1_12.jar "yaml.Demo1" bad1.yaml
java.lang.NullPointerException
at yaml.Demo1.main(Demo1.java:20)
A NullPointerException error is _really_ bad here. Ideally, the
syntax should allow some type of a syntax error exception or error
along with the suspected line number causing the error.
Failing that, even raising an exception saying that you could not find
an expected element (and including the missing element name)
would be vastly better than just throwing a NullPointerException.
The point is that YAML is no different than JSON or a VMS logical
or most else.
If something is not configured the info is missing.
But it should fail in a more controlled manner than it does above.
Post by Arne Vajhøj
If the code explicit test for whether it is present then it can
give a user friendly error message.
The user's code should not have to test for this, it should be
checked in the library itself. The assumption should be that
the requested element is there when you use get() so it raises
an exception if it is not.
If it may not be there, then the library should implement something
like get_optional() which returns null so it can be checked in
the code. It's also a signal to future maintainers about exactly
which elements are and are not optional.
Not picking on this library specifically, but when I see something
where you get java.lang.NullPointerException because a required
element is missing in a data structure, then that immediately makes
me go "Yuck, yuck, yuck!". :-)
Now I see what you mean.

But this is not a problem with neither YAML format or
the SnakeYaml library.

This is a problem with the Java Map. Get of non-existing key
returns null instead of throwing an exception.

.NET IDictionary throws a KeyNotFoundException in that case.

In many cases the Java Map way is nice, but not in this case. In this
case it contributes a bit to the infamous billion dollar.

Arne
Dave Froble
2021-05-04 22:30:29 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
On 2021-05-04, Simon Clubley
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.
Which of course would start WW III between the
XML people, the JSON people and the YAML people.
JSON is better than XML IMHO. I just find it a lot easier to work with.
As for YAML, I've just read up about it and it looks like it was
created by the same people who created INTERCAL.
Clarification: I don't mean that the INTERCAL authors literally created
YAML which is what the above could imply. I meant it looks about as user
friendly as INTERCAL.
YAML is actually quite popular for config files today.
:-)
Which of the below are most readable?
<abc>
<ab>
<a>1</a>
<b>2</b>
</ab>
<c>3</c>
</abc>
{ "ab": {
"a": 1,
"b": 2
},
"c" : 3
}
a: 1
b: 2
c: 3
Arne
In my opinion, none of them. I recognize the XML because I've had to
work with it. The other 2 make no sense to me, most likely because I've
never seen them.

Perhaps:

$ a:==1
$ b:==2
$ C:==3

??
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-05-04 22:48:49 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
On 2021-05-04, Simon Clubley
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.
Which of course would start WW III between the
XML people, the JSON people and the YAML people.
JSON is better than XML IMHO. I just find it a lot easier to work with.
As for YAML, I've just read up about it and it looks like it was
created by the same people who created INTERCAL.
Clarification: I don't mean that the INTERCAL authors literally created
YAML which is what the above could imply. I meant it looks about as user
friendly as INTERCAL.
YAML is actually quite popular for config files today.
:-)
Which of the below are most readable?
<abc>
  <ab>
    <a>1</a>
    <b>2</b>
  </ab>
  <c>3</c>
</abc>
{ "ab": {
    "a": 1,
    "b": 2
  },
  "c" : 3
}
  a: 1
  b: 2
c: 3
Arne
In my opinion, none of them.  I recognize the XML because I've had to work
with it.  The other 2 make no sense to me, most likely because I've never
seen them.
$ a:==1
$ b:==2
$ C:==3
??
Post by Arne Vajhøj
<abc>
<ab>
<a>1</a>
<b>2</b>
</ab>
<de>
<a>3</a>
<b>4</b>
</de>
<c>5</c>
</abc>
{ "ab": {
"a": 1,
"b": 2
},
{ "de": {
"a": 3,
"b": 4
},
"c" : 5
}
a: 1
b: 2
a: 3
b: 4
c: 5
Arne Vajhøj
2021-05-04 23:55:24 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
YAML is actually quite popular for config files today.
:-)
Which of the below are most readable?
<abc>
  <ab>
    <a>1</a>
    <b>2</b>
  </ab>
  <c>3</c>
</abc>
{ "ab": {
    "a": 1,
    "b": 2
  },
  "c" : 3
}
  a: 1
  b: 2
c: 3
In my opinion, none of them.  I recognize the XML because I've had to
work with it.  The other 2 make no sense to me, most likely because I've
never seen them.
$ a:==1
$ b:==2
$ C:==3
??
Perhaps.

But this is unstructured.

Structure can be simulated by:

$ ab_a = 1
$ ab_b = 2
$ c = 3

but that is a bit hackish.

Arne
Simon Clubley
2021-05-05 12:28:29 UTC
Permalink
Post by Dave Froble
In my opinion, none of them. I recognize the XML because I've had to
work with it. The other 2 make no sense to me, most likely because I've
never seen them.
$ a:==1
$ b:==2
$ C:==3
How would you implement nested associative arrays in DCL David and
how would you iterate over the array elements when needed ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-05-05 12:46:54 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
In my opinion, none of them. I recognize the XML because I've had to
work with it. The other 2 make no sense to me, most likely because I've
never seen them.
$ a:==1
$ b:==2
$ C:==3
How would you implement nested associative arrays in DCL David and
how would you iterate over the array elements when needed ?
Hacks like:

a[i] = ...

=>

a_'i' = ...

and:

a.b = ...

=>

a_b = ...

has been seen in the wild.

But I think that when such need arise, then it is time to switch
from DCL to another language.

Arne
Dave Froble
2021-05-05 16:39:40 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
In my opinion, none of them. I recognize the XML because I've had to
work with it. The other 2 make no sense to me, most likely because I've
never seen them.
$ a:==1
$ b:==2
$ C:==3
How would you implement nested associative arrays in DCL David and
how would you iterate over the array elements when needed ?
First, I threw out that example just to show that things can be kept
sorta simple.

Second, I probably wouldn't. There is always more than one way to do
things.

I'm not exactly sure just what "nested associative arrays" might be.
Perhaps it's just the terminology. So I won't directly address that
which I do not understand.

What I will say is that I tend to keep things as simple and easily
understood as possible. At some time, someone else might need to
understand things. If they cannot, what use is the thing?

I don't like "smart people". Usually they think they are much smarter
than they actually are. All too often they just screw things up. I
really like the KISS principal.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-05-05 17:04:03 UTC
Permalink
Post by Dave Froble
I'm not exactly sure just what "nested associative arrays" might be.
Perhaps it's just the terminology.
nested array = array where at least one element is another array

associative array = array where elements are accessed via keys instead
of consecutive numerical indexes (an in-memory only index-sequential
"file").

Arne
Arne Vajhøj
2021-05-05 17:06:32 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
I'm not exactly sure just what "nested associative arrays" might be.
Perhaps it's just the terminology.
nested array = array where at least one element is another array
associative array = array where elements are accessed via keys instead
of consecutive numerical indexes (an in-memory only index-sequential
"file").
In many programming languages they are called dictionaries or maps.

Arne
Simon Clubley
2021-05-05 17:47:19 UTC
Permalink
Post by Dave Froble
I'm not exactly sure just what "nested associative arrays" might be.
Perhaps it's just the terminology. So I won't directly address that
which I do not understand.
A nested associative array is an associative array that is in a data
element of another associative array. In other words, the second
associative array is nested inside the first associative array.

You could extend this to have multiple layers of nested associative
arrays.
Post by Dave Froble
What I will say is that I tend to keep things as simple and easily
understood as possible. At some time, someone else might need to
understand things. If they cannot, what use is the thing?
I don't like "smart people". Usually they think they are much smarter
than they actually are. All too often they just screw things up. I
really like the KISS principal.
In some cases, using nested associative arrays _is_ simpler and easier
to process than the alternative approaches if the language supports
the construct.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-05 18:17:40 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
I'm not exactly sure just what "nested associative arrays" might be.
Perhaps it's just the terminology. So I won't directly address that
which I do not understand.
A nested associative array is an associative array that is in a data
element of another associative array. In other words, the second
associative array is nested inside the first associative array.
You could extend this to have multiple layers of nested associative
arrays.
Post by Dave Froble
What I will say is that I tend to keep things as simple and easily
understood as possible. At some time, someone else might need to
understand things. If they cannot, what use is the thing?
I don't like "smart people". Usually they think they are much smarter
than they actually are. All too often they just screw things up. I
really like the KISS principal.
In some cases, using nested associative arrays _is_ simpler and easier
to process than the alternative approaches if the language supports
the construct.
Simon.
Yeah, yeah, I'm aware. I just find such to be very easily difficult to
understand. As an example, my RMS_LOCKS utility uses multiple linked
and nested linked lists. No matter how hard I tried to keep it easy to
understand, the subject matter just didn't allow that. Sometimes simple
just isn't very easy, or possible.

Regardless, when setting up data, I try very hard to keep it as simple
as possible. I really didn't like any of the three things mentioned in
this thread. Maybe it's just me.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-04 20:33:08 UTC
Permalink
Post by Arne Vajhøj
YAML is actually quite popular for config files today.
:-)
And Javascript is rather popular in certain areas.

What was your point ? :-) :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-04 22:26:45 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.
Which of course would start WW III between the
XML people, the JSON people and the YAML people.
JSON is better than XML IMHO. I just find it a lot easier to work with.
Was that the first shot in the war?
Post by Simon Clubley
As for YAML, I've just read up about it and it looks like it was
created by the same people who created INTERCAL.
And the second?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2021-05-04 22:25:43 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Configuration file libraries are available for all
the modern languages also on VMS. But given how
much VMS code is still in Cobol/Pascal/Basic/Fortran/C
then a builtin native library may be nice to have.
Which of course would start WW III between the
XML people, the JSON people and the YAML people.
:-)
Arne
So, that would make me neutral, right?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-05-04 22:04:09 UTC
Permalink
Post by Phillip Helbig (undress to reply)
There are many things which people see no value in because they have
never experienced them.  Of all the things I listed, this one is
obviously of tremendous value.
There are many things that people have never experienced, or features that
a platform lacks, and thus the folks continue using problematic or
inadequate or higher-effort solutions, yes.
I see little value in logical names, and little value in file versions. Not
as compared with competing solutions. Though on OpenVMS, that's what we're
stuck with.
Not "stuck with". Having them in our tool-box, and good tools. Logical
names are very useful and file versions very convienient.
The logical name key-value store could be—for instance—replaced with LDAP.
What a complete piece of BS. Replacing a logical lookup, that is more
or less with no overhead at all, with a LDAP call? Come on...

I know you are always trying hard to find points to bash VMS,
but this one becomes just silly.
Rich Alderson
2021-05-07 00:08:48 UTC
Permalink
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
There are many things which people see no value in because they have
never experienced them. Of all the things I listed, this one is
obviously of tremendous value.
There are many things that people have never experienced, or features
that a platform lacks, and thus the folks continue using problematic or
inadequate or higher-effort solutions, yes.
I see little value in logical names, and little value in file versions.
Not as compared with competing solutions. Though on OpenVMS, that's
what we're stuck with.
The logical name key-value store could be—for instance—replaced with
LDAP. And I've long missed modern configuration file support while
working on OpenVMS.
And file versions paled as our tasks git more complex, and git tougher
to deal with, so we git other solutions. Yes, that does mean some of us
developers are mercurial.
This feels like subversion from a large drugstore chain...
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Bill Gunshannon
2021-05-04 18:13:03 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality. As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
All of them exist in some form
Yes, "in some form". But that form is not nearly as useful as the VMS
functionality. For example, tell me how to set up a logical-name table
which belongs to a given user or group but is cluster wide.
Tell me what task you are actually trying to accomplish and I can
probably tell you how to do it in Unix. But, imitating VMS is neither
doable or desired.
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
except file versions and I have
never known anyone other than VMS users who saw value in them. Sorry.
There are many things which people see no value in because they have
never experienced them. Of all the things I listed, this one is
obviously of tremendous value.
I've experienced them. Don't miss them at all. Never really
made any use of them when I had them. None of my former VMS
users at the University ever lamented t heir disappearance either.
There have always been other ways to accomplish the same job.

bill
Tad Winters
2021-05-05 04:06:11 UTC
Permalink
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality.  As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
All of them exist in some form in Unix except file versions and I have
never known anyone other than VMS users who saw value in them. Sorry.
Where I work, and they don't have VMS, someone says we're going to
perform a DR test by "virtually" pulling the power on one site. The
response is, "Wait, the active nodes of the cluster are at that site. I
need to fail them over to the other side before you pull the power."

"Active?" The "other side?" How is that a cluster? Where's the DR in
that?
Bill Gunshannon
2021-05-05 11:27:43 UTC
Permalink
Post by Tad Winters
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality.  As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
All of them exist in some form in Unix except file versions and I have
never known anyone other than VMS users who saw value in them. Sorry.
Where I work, and they don't have VMS, someone says we're going to
perform a DR test by "virtually" pulling the power on one site.  The
response is, "Wait, the active nodes of the cluster are at that site.  I
need to fail them over to the other side before you pull the power."
"Active?"  The "other side?"  How is that a cluster?  Where's the DR in
that?
Stop blaming OSes for the incompetence of the administrators. Oh wait,
we like to blame computer languages for the incompetence of programmers
so I guess it's OK after all.

bill
Tad Winters
2021-05-05 12:48:19 UTC
Permalink
Post by Tad Winters
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality.  As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
All of them exist in some form in Unix except file versions and I have
never known anyone other than VMS users who saw value in them. Sorry.
Where I work, and they don't have VMS, someone says we're going to
perform a DR test by "virtually" pulling the power on one site.  The
response is, "Wait, the active nodes of the cluster are at that site.  I
need to fail them over to the other side before you pull the power."
"Active?"  The "other side?"  How is that a cluster?  Where's the DR in
that?
Stop blaming OSes for the incompetence of the administrators.  Oh wait,
we like to blame computer languages for the incompetence of programmers
so I guess it's OK after all.
Deflection.
Dave Froble
2021-05-05 16:42:04 UTC
Permalink
Post by Tad Winters
Post by Bill Gunshannon
Post by Tad Winters
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality. As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
All of them exist in some form in Unix except file versions and I have
never known anyone other than VMS users who saw value in them. Sorry.
Where I work, and they don't have VMS, someone says we're going to
perform a DR test by "virtually" pulling the power on one site. The
response is, "Wait, the active nodes of the cluster are at that site. I
need to fail them over to the other side before you pull the power."
"Active?" The "other side?" How is that a cluster? Where's the DR in
that?
Stop blaming OSes for the incompetence of the administrators. Oh wait,
we like to blame computer languages for the incompetence of programmers
so I guess it's OK after all.
Deflection.
Bill is good at that ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-05-05 12:38:56 UTC
Permalink
Post by Tad Winters
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality.  As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
All of them exist in some form in Unix except file versions and I have
never known anyone other than VMS users who saw value in them. Sorry.
Where I work, and they don't have VMS, someone says we're going to
perform a DR test by "virtually" pulling the power on one site.  The
response is, "Wait, the active nodes of the cluster are at that site.  I
need to fail them over to the other side before you pull the power."
"Active?"  The "other side?"  How is that a cluster?  Where's the DR in
that?
I cannot follow your post.

Clusters exist in loadsharing (active/active) and failover
(active/passive) flavors.

Non-persisting nodes are practically always loadsharing.

Persisting nodes can be loadsharing or failover depending on
specific needs and software/hardware capability.

But even in a loadsharing config you may chose not to loadshare
between data centers. The feasibility of that depends
on the distance between them. If it is like 3 miles
then no problem, but if it like 3000 miles then it just
won't perform due to the latency.

It does not matter what cluster software it is. The
speed of light is a hard limit.

And the R in DR stands for Recovery, so DR does not imply
no downtime. The time it takes to recover is called RTO.
I can obviously be zero, but is not required to.

Arne
Simon Clubley
2021-05-05 12:45:41 UTC
Permalink
Post by Tad Winters
Where I work, and they don't have VMS, someone says we're going to
perform a DR test by "virtually" pulling the power on one site. The
response is, "Wait, the active nodes of the cluster are at that site. I
need to fail them over to the other side before you pull the power."
"Active?" The "other side?" How is that a cluster? Where's the DR in
that?
Show them the HP disaster-proof video and point out to them that it
was created getting on for 15 years ago.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-05 16:41:08 UTC
Permalink
Post by Tad Winters
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Trivially, any Turing machine can emulate another, so they all have the
same functionality. As for usefulness, top of the list for VMS are
logical names, clustering, fine-grained security concept, HBVS, and file
versions.
All of them exist in some form in Unix except file versions and I have
never known anyone other than VMS users who saw value in them. Sorry.
Where I work, and they don't have VMS, someone says we're going to
perform a DR test by "virtually" pulling the power on one site. The
response is, "Wait, the active nodes of the cluster are at that site. I
need to fail them over to the other side before you pull the power."
"Active?" The "other side?" How is that a cluster? Where's the DR in
that?
How many blank looks to you get to your question?

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2021-05-04 13:29:51 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
bill
I "really" should let this slide by, but ...

It all comes down to ones and zeros, if you want to get that general.
However, there are things available in VMS that are at least different,
if not unique, compared to other environments.

Different does matter, if the task is to replace one OS with another.
It's not "what could be done", it's "what is", when looking at the
differences.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-05-04 14:02:15 UTC
Permalink
Post by Dave Froble
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
I "really" should let this slide by, but ...
It all comes down to ones and zeros, if you want to get that general.
However, there are things available in VMS that are at least different,
if not unique, compared to other environments.
Different does matter, if the task is to replace one OS with another.
It's not "what could be done", it's "what is", when looking at the
differences.
It is expensive to migrate from one environment to another
environment:
* analysis and documentation of what needs to be migrated
* code migration
* operation migration
* test
* extra operational cost from new problems introduced by migration
* cost of lost opportunities from focusing on migration instead of new
business

That has probably worked in favor for VMS the last two decades.

Arne
Arne Vajhøj
2021-05-04 13:54:38 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
At a super high level an OS manage processes/threads, memory
and IO. VMS, Unix, Linux, Windows, z/OS, Multics etc. all does that.

At a more detailed level there are some differences in what they can do.
For process creation then *nix has fork and its memory & file handling
that VMS does not do, while VMS got a bunch of SYSGEN and UAF parameters
controlling limits.

But typical those differences does not prevent anything from being
done on the OS< but it can make a port to the OS more difficult
(read: more expensive).

Arne
Simon Clubley
2021-05-04 17:59:19 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
VMS is not Unix or Windows.
This is good because it has functionality that neither of them have.
I was going to let this slide by, but it just stuck in my
craw.
What "functionality" does VMS have that Unix and Windows don't?
Remember, we are talking "functionality", not just doing something
in a different manner.
Doing something in a different manner can by itself can bring additional
functionality.

For example:

Both VMS and Unix have clusters. The VMS version is unique compared
to how everyone else does it.

Everyone is used to a C language style syscall API. The VMS way is
very different and brings additional functionality but also major
restrictions due to its lower-level nature.

It's easier for someone to probe functionality if it is implemented
in the same way as on other operating systems. VMS offers a lot of
that, but it also offers functionality that is implemented in a way
that someone who is only familiar with Unix or Windows will never
have seen before.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Phillip Helbig (undress to reply)
2021-05-03 18:22:58 UTC
Permalink
Post by Simon Clubley
Huh ??? The majority of VMS users don't care about keeping their
systems up to date and fully patched ???
I am having a hard time believing that...
Do you have some numbers?

Keep in mind that some customers can only rarely reboot, and some
patches require a reboot. Maybe the system is on a private network and
security is just not an issue. I don't sleep in a suit of armour to
slightly increase my chances of survival should armed robbers break
into my home.
Post by Simon Clubley
This isn't 20 years ago and anyone who acts like it is will find
this out sooner or later.
If later is long after the machines have been retired, then not patching
was the correct decision.
Post by Simon Clubley
Please tell me David is very wrong about this and that most VMS sites
do consider themselves to be just as vulnerable as everyone else
and take all the usual precautions as a result.
My guess is that most sites won't disclose the information.
Post by Simon Clubley
If he is right about this, just think about what will happen when
one of the security researchers decide to probe x86-64 VMS. Much of
what they find, and they _will_ find vulnerabilities, will apply to
earlier architectures as well.
If x86-64 VMS becomes widespread enough that the black hats develop an
interest in it, then we can celebrate.
Arne Vajhøj
2021-05-03 18:42:38 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
Huh ??? The majority of VMS users don't care about keeping their
systems up to date and fully patched ???
I am having a hard time believing that...
Do you have some numbers?
Keep in mind that some customers can only rarely reboot, and some
patches require a reboot.
It is common for patches to require a reboot.

But well managed secure system does get rebooted occasionally.

Standards like PCI-DSS mandate patching in a timely manner
(1 month for critical security patches).

Arne
Stephen Hoffman
2021-05-03 19:51:43 UTC
Permalink
Post by Simon Clubley
Well I was talking more about simple support. Not patching etc
There are a lot of customers out there happy and content with their
current status.
They just need a hand held when something goes wrong I would say that
goes for the majority of users out there.
Huh ??? The majority of VMS users don't care about keeping their
systems up to date and fully patched ???
I am having a hard time believing that...
Whether or not the folks care, it is commonplace to encounter old
versions both internally, and publicly-exposed.

Yes, there are OpenVMS servers that are actively maintained. And
OpenVMS servers that are not actively mantained.

Old OpenVMS and old network-facing LP versions are commonplace,
including on publicly-exposed OpenVMS boxes.

There are OpenVMS servers on internal networks that are also not
current on versions and patches.

Some OpenVMS servers do get upgraded secondary to an external
requirement; a security audit, encryption requirement, or otherwise.

Others, not so much.

As of today, I see 223 publicly-visible OpenVMS Apache servers, many
(most?) of which are down-revision.

That's out of 1112 publicly-visible OpenVMS servers.

Version details from the first few spots on the list of
publicly-visible OpenVMS servers:

Apache HTTP Server 1.3.26 / OpenSSL 0.9.7d
Apache HTTP Server 2.0.52 / OpenSSL 0.9.7d
Apache HTTP Server 2.4.12 / OpenSSL 1.0.2n / PHP 5.6.10
Apache HTTP Server 2.0.65 / OpenSSL 0.9.8zb
Apache HTTP Server 2.0.63 / PHP 5.2.13

VSI Apache 2.4.38 is current for OpenVMS, while Apache HTTP Server
2.4.46 is current.

VSI SSL111 V1.1.1g is current for OpenVMS, while OpenSSL 1.1.1k is current.

PHP 7.4.18 and PHP 8.0.5 are current. I haven't looked at what VSI is
offering for PHP on OpenVMS.

I don't know the OpenVMS versions running on these servers; whether
OpenVMS is as stale as these products.

And no, I'm not going to try to access and verify these OpenVMS
servers, though the domains and IP addresses involved are widely
available.

There are 56 OpenVMS servers running SMTP. I'd expect some selection of
those are running the TCP/IP Services SMTP server, which ~lacks
connection encryption.

Most of a hundred OpenVMS servers are active on Amazon AWS across
India, Sweden, and Canada. Presumably, those are running as emulated
guests.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2021-05-03 20:03:12 UTC
Permalink
Post by Stephen Hoffman
Whether or not the folks care, it is commonplace to encounter old
versions both internally, and publicly-exposed.
Yes, there are OpenVMS servers that are actively maintained. And
OpenVMS servers that are not actively mantained.
Of course, there was a time when hobbyists had free access to patches.
Back then, I applied patches relatively quickly after they came out.
That option is now no longer available. And, yes, hobbyists were early
adopters of patches and sometimes found problems making those happy who
didn't want to install them yet.
Post by Stephen Hoffman
As of today, I see 223 publicly-visible OpenVMS Apache servers, many
(most?) of which are down-revision.
That's out of 1112 publicly-visible OpenVMS servers.
You mean 223 run Apache, and the rest don't?

1112 in the world?
Post by Stephen Hoffman
There are 56 OpenVMS servers running SMTP.
In the world? Client or server?
Phillip Helbig (undress to reply)
2021-05-03 20:05:08 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Of course, there was a time when hobbyists had free access to patches.
Back then, I applied patches relatively quickly after they came out.
Imagine you could travel back in time a quarter of a century. What
statement would most surprise the folks back then? This has to be near
the top of the list: "Not that long in the future, even probably within
your lifetime, free access to patches for VMS hobbyists will no longer
exist, but there will be practically unlimited free porn."
Loading...