Discussion:
Should GNV / Nix tools be supplied / installed on VMS by default
(too old to reply)
IanD
2017-05-11 17:22:31 UTC
Permalink
Raw Message
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default

Nix'y stuff cannot be ignored IMO. Many of the tools (AWK, SED immediately come to mind) are powerful and can greatly improve day to day productivity when compared to doing many of the same tasks in crippled DCL

Even MS now supply Bash as part of windows which you can enable if you want, such is the encroachment of unix related things

How about languages like Python while we are at it (once V3 can run on VMS) too?

I don't hold the old excuse of lack of disk space as a credible excuse anymore. Disk space is cheap and when the new file system shows its head, lack of disk space excuses will be even more irrelevant than they already are

What other must have nix type utilities / goodies that should be part of the new VMS?

WASD webserver for web documentation perhaps? (it already has conan the librarian)
David Froble
2017-05-11 19:19:49 UTC
Permalink
Raw Message
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
I'm going to say no. With the exception of software VSI has vetted and feels
will not be a problem.
Post by IanD
Nix'y stuff cannot be ignored IMO. Many of the tools (AWK, SED immediately
come to mind) are powerful and can greatly improve day to day productivity
when compared to doing many of the same tasks in crippled DCL
A production system may not use much DCL. It will be running applications. No
need, or desire, for anything that might be detrimental to the usage of the system.

I've got to wonder what your environment is like, if you got people constantly
mucking with things manually? If it is a requirement, it should be automated.
If it is not a requirement, it shouldn't be there.

Development can be a different story.
Post by IanD
Even MS now supply Bash as part of windows which you can enable if you want,
such is the encroachment of unix related things
How about languages like Python while we are at it (once V3 can run on VMS) too?
I don't hold the old excuse of lack of disk space as a credible excuse
anymore. Disk space is cheap and when the new file system shows its head,
lack of disk space excuses will be even more irrelevant than they already are
What other must have nix type utilities / goodies that should be part of the new VMS?
WASD webserver for web documentation perhaps? (it already has conan the librarian)
I don't think calling WASD unixy stuff is appropriate ???
t***@glaver.org
2017-05-11 21:21:52 UTC
Permalink
Raw Message
Post by David Froble
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
I'm going to say no. With the exception of software VSI has vetted and feels
will not be a problem.
Many commercial software vendors provide "contributed software", either in their main distribution kits or as optional add-ons which can be downloaded from the vendor's site. These usually come with a disclaimer that the contributed software is not covered by support agreements, comes without warranty, etc.

Having this sort of thing available from the official keepers of VMS might go a good distance toward getting the VMS-specific changes included in the upstream versions, which would make things easier for everyone who wants to use a particular tool, regardless of whether they want a pre-built version from VSI or if they want to download the source from the upstream and build it themselves.

Having support from VSI for things like free VMS developer licenses or free access to a VSI-hosted development system would also help, as one of the reasons that VMS support was removed from various open source projects was because the upstream maintainers didn't have a system to build and test on. A VSI-hosted system would also solve the problem for Itanium, as few open source maintainers are going to go out and buy an Itanium system.
John E. Malmberg
2017-05-12 13:29:54 UTC
Permalink
Raw Message
Post by t***@glaver.org
Post by David Froble
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
I'm going to say no. With the exception of software VSI has vetted and feels
will not be a problem.
Having this sort of thing available from the official keepers of VMS
might go a good distance toward getting the VMS-specific changes
included in the upstream versions, which would make things easier for
everyone who wants to use a particular tool, regardless of whether
they want a pre-built version from VSI or if they want to download
the source from the upstream and build it themselves.
That really has nothing to do with getting the VMS-specific changes
included in the upstream versions.

All that is needed in most cases is for someone to submit them to the
upstream in the format that the upstream wants. This can take quite a
bit of time.

In addition, for GNU stuff, the upstream usually wants an agreement on
file with the FSF if the submissions contain significant code.

And the upstream usually wants active feedback and participation in
their forums. If they see no notices in their forums for a platform for
a while, then they usually ping the last known contributors, and if they
do not get a positive answer, the platform is slated for removal.

The Bash upstream is very willing to look at the VMS specific code and
bring it into the upstream. None of the GNV developers had have time to
bring that about.

The GNU Make project is also willing to get changes, and that project
needs a lot of work to get it merged with the GNV Make fork.
It still needs a lot of fixes for its VMS mode. I had all the self
tests working locally, but not merged into the upstream.
They are sitting at https://sourceforge.net/p/gnv/make/ci/default/tree/

It has been about 2 years, so they may now need updates to match the
current GNU Make source.
Post by t***@glaver.org
Having support from VSI for things like free VMS developer licenses
or free access to a VSI-hosted development system would also help, as
one of the reasons that VMS support was removed from various open
source projects was because the upstream maintainers didn't have a
system to build and test on. A VSI-hosted system would also solve the
problem for Itanium, as few open source maintainers are going to go
out and buy an Itanium system.
I have an Jenkins system set up that can build from commits to public
repositories on the Internet. If a GNV developer submits an update to
one of the updated project, the Jenkins system will build it with in 24
hours.

The GNV gawk source is actually hosted by the GNU Awk project, so every
time any gawk maintainer commits a patch to the 4.1 stable branch, with
in 24 hours I have a VMS build for it on VAX, Alpha, and IA64.

My ISP prevents me from hosting a server. I have a set up a snapshot
(currently 1 week old) of my Jenkins environment on a free container on
a floating address as an experiment.

It can be reached by following the link at
http://encompasserve.org/~malmberg/vms-jenkins.html (The auto redirect
does not work so click on it)

That container Jenkins crashes occasionally apparently from lack of
memory. My system checks it once an hour and attempts a restart.
Not all things from that beta container provider are working as
advertised. But it is free.

I think that a public live Jenkins dashboard instance, particularly
hosted on VMS Itanium system would be a great publicity tool.

Again Hartmut Becker got a Jenkins web page to display on an Itanium,
which indicates that Jenkins may be working at least well enough to be a
dashboard.

Regards
-John
***@qsl.net_work
Bob Koehler
2017-05-12 13:48:05 UTC
Permalink
Raw Message
Post by David Froble
A production system may not use much DCL. It will be running applications. No
need, or desire, for anything that might be detrimental to the usage of the system.
Other production systems depend heavily on DCL to set up and initiate
thier applications.

But VSI should get thier x86 port into porfit making teritory before
they invest heavily in a DCL replacement.
David Froble
2017-05-12 18:18:55 UTC
Permalink
Raw Message
Post by Bob Koehler
Post by David Froble
A production system may not use much DCL. It will be running applications. No
need, or desire, for anything that might be detrimental to the usage of the system.
Other production systems depend heavily on DCL to set up and initiate
thier applications.
But Bob, isn't that all automated?

We also use DCL to automate some things. What we don't do is have people having
to manually futz around in DCL every day, just to get things done.
Post by Bob Koehler
But VSI should get thier x86 port into porfit making teritory before
they invest heavily in a DCL replacement.
I'm not advocating any replacement.
Bob Koehler
2017-05-15 11:29:10 UTC
Permalink
Raw Message
Post by David Froble
Post by Bob Koehler
Post by David Froble
A production system may not use much DCL. It will be running applications. No
need, or desire, for anything that might be detrimental to the usage of the system.
Other production systems depend heavily on DCL to set up and initiate
thier applications.
But Bob, isn't that all automated?
No. I've seen a lot of user interaction written in DCL. Often as
"menus".
Post by David Froble
We also use DCL to automate some things. What we don't do is have people having
to manually futz around in DCL every day, just to get things done.
Post by Bob Koehler
But VSI should get thier x86 port into porfit making teritory before
they invest heavily in a DCL replacement.
I'm not advocating any replacement.
I am. But profits first.
Jan-Erik Soderholm
2017-05-15 11:41:13 UTC
Permalink
Raw Message
Post by Bob Koehler
Post by David Froble
Post by Bob Koehler
Post by David Froble
A production system may not use much DCL. It will be running applications. No
need, or desire, for anything that might be detrimental to the usage of the system.
Other production systems depend heavily on DCL to set up and initiate
thier applications.
But Bob, isn't that all automated?
No. I've seen a lot of user interaction written in DCL. Often as
"menus".
Not only menus or automation. Some user tools for simpler task such as for
example downloading printer forms to Zebra label printers (just to take
one task from our environment), can easily be made in DCL. A few questions
and a COPY command. KISS.

But yes, no users (apart from us in the support team) has access to the
$-prompt, of course!
Post by Bob Koehler
Post by David Froble
We also use DCL to automate some things. What we don't do is have people having
to manually futz around in DCL every day, just to get things done.
Post by Bob Koehler
But VSI should get thier x86 port into porfit making teritory before
they invest heavily in a DCL replacement.
I'm not advocating any replacement.
I am. But profits first.
Paul Sture
2017-05-15 15:09:50 UTC
Permalink
Raw Message
Post by Bob Koehler
Post by David Froble
Post by Bob Koehler
But VSI should get thier x86 port into porfit making teritory before
they invest heavily in a DCL replacement.
I'm not advocating any replacement.
I am. But profits first.
Meanwhile there's nothing stopping the rest of us looking at other
scripting languages for ideas, both good and bad. There's nothing more
frustrating than seeing a software team putting a lot of effort into
some cool idea that you know will never get used in practice.
--
Everybody has a testing environment. Some people are lucky enough to
have a totally separate environment to run production in.
IanD
2017-05-14 19:28:37 UTC
Permalink
Raw Message
Post by David Froble
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
I'm going to say no. With the exception of software VSI has vetted and feels
will not be a problem.
What problems could result in having additional helpful utilities available?

<snip>
Post by David Froble
A production system may not use much DCL. It will be running applications. No
need, or desire, for anything that might be detrimental to the usage of the system.
Production systems need to increasingly integrate with systems across the enterprise

Have you used any of the linux type tools that are available? AWK? tr? comm? sed? etc. How did you find them compared to writing tasks in DCL?

How many lines would it take to do the following in DCL for example?

For every record in a csv file who's first field is smiths, do a rolling sum of the 3rd record. Do this for 4 files consecutively

In awk its a one liner, in DCL I shudder to think

awk "-F" "," "$1 == ""smiths"" {sum += $3} END {print sum}" infile1 infile2 infile3 infile4 (including the annoying need to double quote every parameter and text string in VMS)

These types of tools were developed specifically to be very flexible and the Swiss-army knife for a given situation. DCL is the equivalent of a hammer, you use it as a general tool but it is horribly inadequate for many tasks

As to the Bash shell, I was not advocating it replacing DCL, I was more focused on some of the incredibly useful unix tools but the Bash shell would bring even more productivity gains

Everyone but the ostrich believes DCL is up to the task of taking VMS forward. Until such time as we get a functional replacement, why not compliment DCL with tools that can work around much of its short-falls?

Then there is the need to cater for new VMS admins with little or no VMS experience who are continually being asked to look after VMS systems. They reach for many of the linux tools they are used to and what do they find? Nothing, not even an included C compiler for that matter (side topic).
After a while negative feedback about the 'VMS system' being 'hard to maintain' peculates upwards and its another negative nail in the coffin for a VMS system

This negative press is not helping VMS. In outsourcing companies (i.e. very large companies), VMS is already on the nose as it represents a system difficult to integrate into the enterprise mix, it requires specific skills to administer, so giving it tools others are already familiar with is a positive instead of VMS always being seen as the system lacking

Even MS has seen the need to adopt linux functionality in certain areas. It has even incorporated a bash shell now.
Either learn from what others are doing (others who have been more successful at staying relevant than VMS has) or continue on the VMS march of death
Post by David Froble
I've got to wonder what your environment is like, if you got people constantly
mucking with things manually? If it is a requirement, it should be automated.
If it is not a requirement, it shouldn't be there.
Who said things are mucked about manually?

Even on systems that run modern applications, say SAP Hanna deployments, there are quantities of glue type scripts helping facilitate things and tie things together. How will these enterprise wide apps have a hope of running on VMS without these tool sets that other platforms take for granted as being available?

Then in the arena of the enterprise, we see global unification across an organisation and there tool sets. Many are looking to unify tool sets and scripting languages, DCL isn't even on the radar and in its current state would never make the cut either.
These companies build internal libraries of scripts and help-functions and they consolidate on common tools and languages, like Python, sed, AWK used for things like global monitoring or mass code roll-outs and deployments.

It seems to me from various comments you've made that your environment is pretty much turn-key with little need for global integration. This is not the type of future market VMS will need to compete in going forward. DCL will simply not carry VMS forward

Until we have a replacement language for DCL, why not compliment DCL with many of the tools out there that are supporting other far more successful platforms
Post by David Froble
Development can be a different story.
Development, testing, production, apart from scale these environments should be as closely aligned as possible to remove the chance of side-effects

Install on all for consistency
David Froble
2017-05-14 20:11:40 UTC
Permalink
Raw Message
Post by IanD
Post by David Froble
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
I'm going to say no. With the exception of software VSI has vetted and feels
will not be a problem.
What problems could result in having additional helpful utilities available?
Security issues ???
Post by IanD
Post by David Froble
A production system may not use much DCL. It will be running applications. No
need, or desire, for anything that might be detrimental to the usage of the system.
Production systems need to increasingly integrate with systems across the enterprise
Yes, sometimes. And what is the methods used? Possibly TCP/IP communications?
What's at the bottom of every TCP/IP connection? Maybe a socket? If a
general utility will suffice, then I use it. Otherwise, I got no problem with
custom apps using socket communications.
Post by IanD
Have you used any of the linux type tools that are available? AWK? tr? comm? sed? etc. How did you find them compared to writing tasks in DCL?
Nope. no need for such. Nor will I use DCL for any but the simple tasks.
Post by IanD
How many lines would it take to do the following in DCL for example?
For every record in a csv file who's first field is smiths, do a rolling sum of the 3rd record. Do this for 4 files consecutively
How many "understandable" lines in Basic? Not so many.
Post by IanD
In awk its a one liner, in DCL I shudder to think
awk "-F" "," "$1 == ""smiths"" {sum += $3} END {print sum}" infile1 infile2 infile3 infile4 (including the annoying need to double quote every parameter and text string in VMS)
Good for you, if you understand that gibberish. I don't. They would not help
me. They would hinder me.
Post by IanD
These types of tools were developed specifically to be very flexible and the Swiss-army knife for a given situation. DCL is the equivalent of a hammer, you use it as a general tool but it is horribly inadequate for many tasks
As to the Bash shell, I was not advocating it replacing DCL, I was more focused on some of the incredibly useful unix tools but the Bash shell would bring even more productivity gains
Everyone but the ostrich believes DCL is up to the task of taking VMS
forward.
Until such time as we get a functional replacement, why not compliment DCL with
tools that can work around much of its short-falls?

Go ahead, nobody is stopping anyone from using what they feel they need.
Post by IanD
Then there is the need to cater for new VMS admins with little or no VMS
experience who are continually being asked to look after VMS systems. They reach
for many of the linux tools they are used to and what do they find? Nothing, not
even an included C compiler for that matter (side topic).

No C? Sounds like a good thing, to me.
Post by IanD
After a while negative feedback about the 'VMS system' being 'hard to
maintain' peculates upwards and its another negative nail in the coffin for a
VMS system
Post by IanD
This negative press is not helping VMS. In outsourcing companies (i.e. very
large companies), VMS is already on the nose as it represents a system difficult
to integrate into the enterprise mix, it requires specific skills to administer,
so giving it tools others are already familiar with is a positive instead of VMS
always being seen as the system lacking

If you're going to drive a car, you need to be proficient in that operation. If
you're going to fly an airplane, you had better not hope your skills in a car
are adequate. If you're going to pilot a starship, perhaps knowing FTL
navigation might be a bit more realistic than just having your Garman GPS, don't
cha think?

The thing is, whatever the job, people need to be proficient, not just a point
and click weenie.
Post by IanD
Even MS has seen the need to adopt linux functionality in certain areas. It
has even incorporated a bash shell now.
Post by IanD
Either learn from what others are doing (others who have been more successful
at staying relevant than VMS has) or continue on the VMS march of death
Post by IanD
Post by David Froble
I've got to wonder what your environment is like, if you got people
constantly mucking with things manually? If it is a requirement, it should
be automated. If it is not a requirement, it shouldn't be there. >>
Who said things are mucked about manually?
Even on systems that run modern applications, say SAP Hanna deployments, there are quantities of glue type scripts helping facilitate things and tie things together. How will these enterprise wide apps have a hope of running on VMS without these tool sets that other platforms take for granted as being available?
Then in the arena of the enterprise, we see global unification across an organisation and there tool sets. Many are looking to unify tool sets and scripting languages, DCL isn't even on the radar and in its current state would never make the cut either.
These companies build internal libraries of scripts and help-functions and they consolidate on common tools and languages, like Python, sed, AWK used for things like global monitoring or mass code roll-outs and deployments.
It seems to me from various comments you've made that your environment is pretty much turn-key with little need for global integration. This is not the type of future market VMS will need to compete in going forward. DCL will simply not carry VMS forward
Isn't that how you're suppose to design apps?
Jan-Erik Soderholm
2017-05-14 21:12:14 UTC
Permalink
Raw Message
Post by IanD
Production systems need to increasingly integrate with systems across the enterprise
Don't see what communication had to do with AWK. And if I get a file, why
would it be required from the sender that AWK must be used to read it?
Post by IanD
How many lines would it take to do the following in DCL for example?
For every record in a csv file who's first field is smiths, do a rolling
sum of the 3rd record. Do this for 4 files consecutively...
I guess you ment to write "a rolling sum of the 3rd *field*", not?

In my case, I'd expect that a little later someone wuld like to have
all "brown" summed and maybe to sum some other field then the 3rd.
So I'd load the files into a table in the database and use SQL to
do the processing.

If this is some repeated production use, a proper application might
be better.
Post by IanD
In awk its a one liner,...
Is "a one liner" = "better"? In many coding style guides I have read,
I have seeen recomendations to not write "to much" on each line, since
it just makes the code harder to maintain.
Post by IanD
awk "-F" "," "$1 == ""smiths"" {sum += $3} END {print sum}" infile1
infile2 infile3 infile4 (including the annoying need to double quote
every parameter and text string in VMS)
I used awk on VMS in the 90's. I do not get your point.
Just use it if you like it. I did not like it at that time.
Arne Vajhøj
2017-05-15 00:12:27 UTC
Permalink
Raw Message
Post by IanD
Post by David Froble
Post by IanD
As per the title..., Should GNV / Nix tools be supplied /
installed on VMS by default
I'm going to say no. With the exception of software VSI has vetted
and feels will not be a problem.
What problems could result in having additional helpful utilities available?
Having the available for installation: none.

Always installing: increases the amount of stuff on the system
which usually increases security risk.

Arne
Jason Howe
2017-05-11 19:26:36 UTC
Permalink
Raw Message
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
Nix'y stuff cannot be ignored IMO. Many of the tools (AWK, SED immediately
come to mind) are powerful and can greatly improve day to day productivity
when compared to doing many of the same tasks in crippled DCL
Even MS now supply Bash as part of windows which you can enable if you want,
such is the encroachment of unix related things
How about languages like Python while we are at it (once V3 can run on VMS) too?
I don't hold the old excuse of lack of disk space as a credible excuse
anymore. Disk space is cheap and when the new file system shows its head, lack
of disk space excuses will be even more irrelevant than they already are
What other must have nix type utilities / goodies that should be part of the new VMS?
WASD webserver for web documentation perhaps? (it already has conan the librarian)
I installed GNV on my Alpha for the sole purpose of compiling python (Dear lord
that took forever on a 225Mhz EV4.5). Then I started playing around with some
of the other stuff that the Open Source VMS guys were messing around with. Then
I found that it made certain kinds of file operations much much easier,
especially selective deletes through subdirectories. Still though, I don't end
up in a bash shell unless it's for a specific purpose.


I think an official python on VMS would be a Great Thing. Tons of modern tools
and software are build with/on python and an interpreter is out there for all
major OSes and architectures.

An actual modern webserver would be great too. I've only ever used the apache
port (which I think dates to the Compaq days) and it's goofy as hell to try and
use and configure...This is coming from someone who manages dozens of apache web
servers and can write an apache config with his eyes closed. I'd be happy to
see the port perhaps get a rework so it's less confusing to work with. While
we're dreaming, an updated MySQL/Mariadb or, dare I suggest Postgresql would be
almost unthinkable.
--
Jason
John E. Malmberg
2017-05-12 12:52:57 UTC
Permalink
Raw Message
Post by Jason Howe
I installed GNV on my Alpha for the sole purpose of compiling python (Dear lord
that took forever on a 225Mhz EV4.5). Then I started playing around with some
of the other stuff that the Open Source VMS guys were messing around with. Then
I found that it made certain kinds of file operations much much easier,
especially selective deletes through subdirectories. Still though, I don't end
up in a bash shell unless it's for a specific purpose.
The https://sourceforge.net/p/vms-ports/cpython/ci/default/tree/ used to
build the current development cPython 3.x with GNV.

It does not contain the whole cPython 3.x tree, just the parts that are
needed to get the upstream to build on VMS.

I have not tried to build it since they moved to github, so it may be
out of date.

Since I was not aware anyone else was trying to use it, I have not been
motivated to add it to my Jenkins builds to make sure what has been
ported keeps working.

As I have posted before, it got blocked because it requires (in spite of
the documentation saying it is optional) a working port of libffi.

Hartmut Becker has posted code on Encompasserve.org that should allow
getting the Alpha portion of Libffi to work.

I do not know if I updated libffi with the IA64 version. I have been
concentrating on GNV components.

The goal of this cPython build is to be able to use all the Python3
tools including pip3.

Regards,
-John
***@qsl.net_work
Jason Howe
2017-05-13 14:31:09 UTC
Permalink
Raw Message
Post by Jason Howe
I installed GNV on my Alpha for the sole purpose of compiling python (Dear
lord that took forever on a 225Mhz EV4.5). Then I started playing around
with some of the other stuff that the Open Source VMS guys were messing
around with. Then I found that it made certain kinds of file operations much
much easier, especially selective deletes through subdirectories. Still
though, I don't end up in a bash shell unless it's for a specific purpose.
The https://sourceforge.net/p/vms-ports/cpython/ci/default/tree/ used to build
the current development cPython 3.x with GNV.
It does not contain the whole cPython 3.x tree, just the parts that are needed
to get the upstream to build on VMS.
I have not tried to build it since they moved to github, so it may be out of
date.
Since I was not aware anyone else was trying to use it, I have not been
motivated to add it to my Jenkins builds to make sure what has been ported
keeps working.
As I have posted before, it got blocked because it requires (in spite of the
documentation saying it is optional) a working port of libffi.
Hartmut Becker has posted code on Encompasserve.org that should allow getting
the Alpha portion of Libffi to work.
I do not know if I updated libffi with the IA64 version. I have been
concentrating on GNV components.
The goal of this cPython build is to be able to use all the Python3 tools
including pip3.
...I really need to get my storage situation figured on on this box. Only have
a couple small hard drives and the Python2 disk images has me pretty maxed out.
I've been looking for a cheap Storageworks BA353 3-slot enclosure for a while.

-- Jason
David Froble
2017-05-13 15:50:38 UTC
Permalink
Raw Message
Post by Jason Howe
Post by Jason Howe
I installed GNV on my Alpha for the sole purpose of compiling python (Dear
lord that took forever on a 225Mhz EV4.5). Then I started playing around
with some of the other stuff that the Open Source VMS guys were messing
around with. Then I found that it made certain kinds of file operations much
much easier, especially selective deletes through subdirectories. Still
though, I don't end up in a bash shell unless it's for a specific purpose.
The https://sourceforge.net/p/vms-ports/cpython/ci/default/tree/ used to build
the current development cPython 3.x with GNV.
It does not contain the whole cPython 3.x tree, just the parts that are needed
to get the upstream to build on VMS.
I have not tried to build it since they moved to github, so it may be out of
date.
Since I was not aware anyone else was trying to use it, I have not been
motivated to add it to my Jenkins builds to make sure what has been ported
keeps working.
As I have posted before, it got blocked because it requires (in spite of the
documentation saying it is optional) a working port of libffi.
Hartmut Becker has posted code on Encompasserve.org that should allow getting
the Alpha portion of Libffi to work.
I do not know if I updated libffi with the IA64 version. I have been
concentrating on GNV components.
The goal of this cPython build is to be able to use all the Python3 tools
including pip3.
...I really need to get my storage situation figured on on this box. Only have
a couple small hard drives and the Python2 disk images has me pretty maxed out.
I've been looking for a cheap Storageworks BA353 3-slot enclosure for a while.
-- Jason
You want one that might be disassembled? I'd have to look to see if it is still
here.
Jason Howe
2017-05-13 17:38:18 UTC
Permalink
Raw Message
Post by David Froble
Post by Jason Howe
Post by John E. Malmberg
Post by Jason Howe
I installed GNV on my Alpha for the sole purpose of compiling python (Dear
lord that took forever on a 225Mhz EV4.5). Then I started playing around
with some of the other stuff that the Open Source VMS guys were messing
around with. Then I found that it made certain kinds of file operations
much much easier, especially selective deletes through subdirectories.
Still though, I don't end up in a bash shell unless it's for a specific
purpose.
The https://sourceforge.net/p/vms-ports/cpython/ci/default/tree/ used to
build the current development cPython 3.x with GNV.
It does not contain the whole cPython 3.x tree, just the parts that are
needed to get the upstream to build on VMS.
I have not tried to build it since they moved to github, so it may be out of
date.
Since I was not aware anyone else was trying to use it, I have not been
motivated to add it to my Jenkins builds to make sure what has been ported
keeps working.
As I have posted before, it got blocked because it requires (in spite of the
documentation saying it is optional) a working port of libffi.
Hartmut Becker has posted code on Encompasserve.org that should allow
getting the Alpha portion of Libffi to work.
I do not know if I updated libffi with the IA64 version. I have been
concentrating on GNV components.
The goal of this cPython build is to be able to use all the Python3 tools
including pip3.
...I really need to get my storage situation figured on on this box. Only
have a couple small hard drives and the Python2 disk images has me pretty
maxed out. I've been looking for a cheap Storageworks BA353 3-slot enclosure
for a while.
-- Jason
You want one that might be disassembled? I'd have to look to see if it is
still here.
Sure! I don't mind screwing things backtogether. I have 5 or 6 of the disk
trays, just been missing the enclosure.
--
Jason
John E. Malmberg
2017-05-13 16:58:52 UTC
Permalink
Raw Message
Post by Jason Howe
Post by Jason Howe
I installed GNV on my Alpha for the sole purpose of compiling python (Dear
lord that took forever on a 225Mhz EV4.5). Then I started playing around
with some of the other stuff that the Open Source VMS guys were messing
around with. Then I found that it made certain kinds of file operations much
much easier, especially selective deletes through subdirectories. Still
though, I don't end up in a bash shell unless it's for a specific purpose.
The https://sourceforge.net/p/vms-ports/cpython/ci/default/tree/ used to build
the current development cPython 3.x with GNV.
It does not contain the whole cPython 3.x tree, just the parts that are needed
to get the upstream to build on VMS.
I have not tried to build it since they moved to github, so it may be out of
date.
Since I was not aware anyone else was trying to use it, I have not been
motivated to add it to my Jenkins builds to make sure what has been ported
keeps working.
As I have posted before, it got blocked because it requires (in spite of the
documentation saying it is optional) a working port of libffi.
Hartmut Becker has posted code on Encompasserve.org that should allow getting
the Alpha portion of Libffi to work.
I do not know if I updated libffi with the IA64 version. I have been
concentrating on GNV components.
The goal of this cPython build is to be able to use all the Python3 tools
including pip3.
...I really need to get my storage situation figured on on this box. Only have
a couple small hard drives and the Python2 disk images has me pretty maxed out.
I've been looking for a cheap Storageworks BA353 3-slot enclosure for a while.
As documented somewhere in the VMS-PORTS wiki, I am using NFS served
storage for the source files.

I am serving files from both Cygwin NFS (32 bit) and Fedora/22 NFS with
mostly success.

Sources are contiguously backed up to a free DropBox account.

Regards,
-John
***@qsl.net_work
Jason Howe
2017-05-13 17:43:25 UTC
Permalink
Raw Message
Post by Jason Howe
Post by John E. Malmberg
Post by Jason Howe
I installed GNV on my Alpha for the sole purpose of compiling python (Dear
lord that took forever on a 225Mhz EV4.5). Then I started playing around
with some of the other stuff that the Open Source VMS guys were messing
around with. Then I found that it made certain kinds of file operations
much much easier, especially selective deletes through subdirectories.
Still though, I don't end up in a bash shell unless it's for a specific
purpose.
The https://sourceforge.net/p/vms-ports/cpython/ci/default/tree/ used to
build the current development cPython 3.x with GNV.
It does not contain the whole cPython 3.x tree, just the parts that are
needed to get the upstream to build on VMS.
I have not tried to build it since they moved to github, so it may be out of
date.
Since I was not aware anyone else was trying to use it, I have not been
motivated to add it to my Jenkins builds to make sure what has been ported
keeps working.
As I have posted before, it got blocked because it requires (in spite of the
documentation saying it is optional) a working port of libffi.
Hartmut Becker has posted code on Encompasserve.org that should allow
getting the Alpha portion of Libffi to work.
I do not know if I updated libffi with the IA64 version. I have been
concentrating on GNV components.
The goal of this cPython build is to be able to use all the Python3 tools
including pip3.
...I really need to get my storage situation figured on on this box. Only
have a couple small hard drives and the Python2 disk images has me pretty
maxed out. I've been looking for a cheap Storageworks BA353 3-slot enclosure
for a while.
As documented somewhere in the VMS-PORTS wiki, I am using NFS served storage
for the source files.
I am serving files from both Cygwin NFS (32 bit) and Fedora/22 NFS with mostly
success.
Sources are contiguously backed up to a free DropBox account.
Interesting. I haven't been able to get NFS mounts to work since I switched
from TCP/IP Services to Multinet. I did the switch because TCP/IP serivces was
broken in some way (I can no longer remember how) which was giving me fits and
preventing me from getting something else done.

Maybe I'll re-evaluate the situation and see if I can come up with a reasonable
question to ask to get me pointed in the right direction.
--
Jason
Bob Koehler
2017-05-16 17:25:46 UTC
Permalink
Raw Message
Post by Jason Howe
Interesting. I haven't been able to get NFS mounts to work since I switched
from TCP/IP Services to Multinet. I did the switch because TCP/IP serivces was
broken in some way (I can no longer remember how) which was giving me fits and
preventing me from getting something else done.
Only problem I ever had with Multinet NFS was that classic MacOS did
not fail over to earlier protocols as it claimed. Multinet was
running the previous rev, and I had to specifically tell my Mac to
use it.
Post by Jason Howe
Maybe I'll re-evaluate the situation and see if I can come up with a reasonable
question to ask to get me pointed in the right direction.
Post detailed information here next time you try, and you're likely to find
someone with an answer.
Jan-Erik Soderholm
2017-05-11 19:30:26 UTC
Permalink
Raw Message
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
No, not in general.
Post by IanD
Nix'y stuff cannot be ignored IMO. Many of the tools (AWK, SED
immediately come to mind) are powerful and can greatly improve day to
day productivity when compared to doing many of the same tasks in
crippled DCL.
Let the actual need decide that. If you're helped by any tool (a unix
tool or not), by all means, use it!
Post by IanD
Even MS now supply Bash as part of windows which you can enable if you
want, such is the encroachment of unix related things
How about languages like Python while we are at it (once V3 can run on VMS) too?
Python is a nice language/tool/utility. It complements DCL well
but will of course never replace DCL or make DCL go away.
Post by IanD
I don't hold the old excuse of lack of disk space as a credible excuse
anymore. Disk space is cheap and when the new file system shows its
head, lack of disk space excuses will be even more irrelevant than they
already are
What other must have nix type utilities / goodies that should be part of the new VMS?
It is a sliding scale. Tools as zip/unzip are on the "a must" end of the
scale, other tools are probably on the "if you need it" end of the scale.

I would not complain if zip/unzip was installed by default.
Post by IanD
WASD webserver for web documentation perhaps? (it already has conan the librarian)
As David commented, not a "unix tool". But the best webserver anyway. :-)
Stephen Hoffman
2017-05-11 21:49:15 UTC
Permalink
Raw Message
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
More than a little of the software in GNV is GPL with current bits of
tools variously either GPL2 or GPL3, so GNV supplied separately with
the release would be nice and likely feasible, but having GNV embedded
might be impractical as the copyrights can preclude that sort of
inclusion. This barring porting over BSD-licensed tools, and
replacing the GPL pieces.

As for practical options, probably better to offer up some cycles to
help with GNV and related, as it's a large project.

The embedded support for GNV within OpenVMS has some issues, as I
suspect there's a FID-handling error in the ROOT bits, and there's the
variously-discussed (and variously lacking) SSIO support.

Copyrights allowing, integrating Python, php, Perl, Apache, SQLite,
PostgreSQL and other pieces — not the least of which is VSI IP itself —
with OpenVMS would also be useful, yes. The current
everything-is-its-own-kit is a big of a dog's breakfast, and just makes
OpenVMS more difficult to deal with. Don't light it all off by
default, but do include what's common on other server operating
systems. Helps with integration, testing and particularly with
dependencies.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2017-05-11 22:01:55 UTC
Permalink
Raw Message
...
ps:
https://www.engadget.com/amp/2017/05/11/microsoft-will-offer-3-flavors-of-linux-on-the-windows-store/
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Sorenson
2017-05-11 23:32:45 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
More than a little of the software in GNV is GPL with current bits of
tools variously either GPL2 or GPL3, so GNV supplied separately with
the release would be nice and likely feasible, but having GNV embedded
might be impractical as the copyrights can preclude that sort of
inclusion. This barring porting over BSD-licensed tools, and
replacing the GPL pieces.
As for practical options, probably better to offer up some cycles to
help with GNV and related, as it's a large project.
The embedded support for GNV within OpenVMS has some issues, as I
suspect there's a FID-handling error in the ROOT bits, and there's the
variously-discussed (and variously lacking) SSIO support.
Copyrights allowing, integrating Python, php, Perl, Apache, SQLite,
PostgreSQL and other pieces — not the least of which is VSI IP itself —
with OpenVMS would also be useful, yes. The current
everything-is-its-own-kit is a big of a dog's breakfast, and just makes
OpenVMS more difficult to deal with. Don't light it all off by
default, but do include what's common on other server operating
systems. Helps with integration, testing and particularly with
dependencies.
--
Pure Personal Opinion | HoffmanLabs LLC
I'm not a fan of the GPL as a license but bundling GPL bits shouldn't be a problem as long as you include a copy of the license and VMS specific patches are available on anonymous FTP somewhere. Mac OS X includes Bash. Even Solaris ships Bash not just Ksh.
Stephen Hoffman
2017-05-12 14:57:39 UTC
Permalink
Raw Message
Post by Bill Sorenson
I'm not a fan of the GPL as a license but bundling GPL bits shouldn't
be a problem as long as you include a copy of the license and VMS
specific patches are available on anonymous FTP somewhere. Mac OS X
includes Bash. Even Solaris ships Bash not just Ksh.
Any sort of bundling or redistribution has to be done in compliance
with the applicable licensing.

Lawyers representing closed-source vendors tend to be very careful
around inclusion of and compliance with GPL code, both for GPL2 and
particularly GPL3. This if the GPL code is even permitted to be
included with the closed-source package, which it often isn't.

Posted just yesterday, coincidentally:
https://qz.com/981029/a-federal-court-has-ruled-that-an-open-source-license-is-an-enforceable-contract/


As for your examples, XNU is open source.
https://opensource.apple.com/source/xnu/ Other parts of macOS are not
open-source. Most of the frameworks and the user interface and the
apps are closed source. macOS was (is) using a GPL2 version of bash,
where GNV was using the newer and GPL3 version.

Solaris was open-source for a while as OpenSolaris and the illumos fork
of OpenSolaris still is available. I've not looked at bash inclusion
in Solaris. Solaris was using Bourne, ksh and some other shells last
I checked (and not bash), not that I've been particularly following
Solaris features and capabilities in the era since Oracle acquired Sun.

I'd be surprised if there were GPL3 code incorporated in macOS or Solaris.

Most closed-source entities treat GPL code with due care. Okay to
use, okay to redistribute separately and with source, not okay to
incorporate. Which is how the GPL is intended.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2017-05-13 00:05:18 UTC
Permalink
Raw Message
Post by Bill Sorenson
I'm not a fan of the GPL as a license but bundling GPL bits shouldn't
be a problem as long as you include a copy of the license and VMS
specific patches are available on anonymous FTP somewhere. Mac OS X
includes Bash. Even Solaris ships Bash not just Ksh.
Any sort of bundling or redistribution has to be done in compliance with
the applicable licensing.
That is rather obvious. One need to comply with licenses. Period.
Open source or closed source.
https://qz.com/981029/a-federal-court-has-ruled-that-an-open-source-license-is-an-enforceable-contract/

That should not surprise anyone.
Lawyers representing closed-source vendors tend to be very careful
around inclusion of and compliance with GPL code, both for GPL2 and
particularly GPL3. This if the GPL code is even permitted to be
included with the closed-source package, which it often isn't.
A few places still have the blanket "no GPL" policy.

But most places today have actually looked into the matter and let
the usage determine whether GPL is acceptable or not.
As for your examples, XNU is open source.
https://opensource.apple.com/source/xnu/ Other parts of macOS are not
open-source. Most of the frameworks and the user interface and the
apps are closed source. macOS was (is) using a GPL2 version of bash,
where GNV was using the newer and GPL3 version.
Solaris was open-source for a while as OpenSolaris and the illumos fork
of OpenSolaris still is available. I've not looked at bash inclusion
in Solaris. Solaris was using Bourne, ksh and some other shells last I
checked (and not bash), not that I've been particularly following
Solaris features and capabilities in the era since Oracle acquired Sun.
I'd be surprised if there were GPL3 code incorporated in macOS or Solaris.
I don't think there is a big difference in GPL 2 and 3 in this regard.

It all depends on the usage.

What does "incorporated" mean.

I am pretty sure that a recent version of GCC under GPL 3 will be
present on those systems.

But it will be hard to argue that the OS is linked to the GCC
compilers.
Most closed-source entities treat GPL code with due care. Okay to use,
okay to redistribute separately and with source, not okay to
incorporate. Which is how the GPL is intended.
Distributing separately does probably not make a difference.

Whether you distribute the source day 1 or on request does not
matter at all.

The key aspect is the linking. Is the closed source "linked"
to the GPL software or not.

Arne
Stephen Hoffman
2017-05-13 18:55:59 UTC
Permalink
Raw Message
Post by Arne Vajhøj
Post by Stephen Hoffman
I'd be surprised if there were GPL3 code incorporated in macOS or Solaris.
I don't think there is a big difference in GPL 2 and 3 in this regard.
There are a couple that seem to have caught the attention of the legal
departments, though,
Post by Arne Vajhøj
What does "incorporated" mean.
"Incorporated" is a perfectly cromulent word.
Post by Arne Vajhøj
I am pretty sure that a recent version of GCC under GPL 3 will be
present on those systems.
Quite possibly on Solaris, though macOS moved away from GCC some years ago.
Post by Arne Vajhøj
But it will be hard to argue that the OS is linked to the GCC compilers.
Ayup. But then I'd be surprised if there was GPL3 code embedded
directly into macOS or Solaris.
Post by Arne Vajhøj
Post by Stephen Hoffman
Most closed-source entities treat GPL code with due care. Okay to
use, okay to redistribute separately and with source, not okay to
incorporate. Which is how the GPL is intended.
Distributing separately does probably not make a difference.
Whether you distribute the source day 1 or on request does not matter at all.
The key aspect is the linking. Is the closed source "linked" to the GPL
software or not.
Which is what I am referring to, and apparently in a far too cryptic fashion.

GPL exists to force open source code, and the folks with closed-source
products are aware of and are generally averse to that happening with
their packages and products.
--
Pure Personal Opinion | HoffmanLabs LLC
Norman F Raphael
2017-05-13 19:52:02 UTC
Permalink
Raw Message
Stephen Hoffman via Info-vax <info-***@info-vax.com> wrote
"Incorporated" is a perfectly cromulent word.

Love it!



cromulent


adjective

Appearing legitimate but actually being spurious: These citations are indeed cromulent

[a word used by the schoolteacher, Miss Hoover, in an episode of The Simpsons, in which she defended one made-up word by making up another]





Norman F. Raphael
"Everything worthwhile eventually
degenerates into real work." -Murphy
David Froble
2017-05-13 20:42:18 UTC
Permalink
Raw Message
Post by Stephen Hoffman
GPL exists to force open source code,
Ayep! And I could use up considerable bandwidth calling them names, but one
word will suffice.

Thieves
Arne Vajhøj
2017-05-13 23:58:11 UTC
Permalink
Raw Message
Post by David Froble
Post by Stephen Hoffman
GPL exists to force open source code,
Ayep! And I could use up considerable bandwidth calling them names, but
one word will suffice.
Thieves
????

It is their code. You want to use their code. They let you
use it for free. You just need to comply with some license
terms, which in most cases where GPL is used just means that
if you modify/enhance their code and distribute it then your
modifications/enhancements need to also be open source
under GPL.

Calling them thieves because they do not want you to take
their code for free, modify/enhance it and distribute the result
as closed source seems a bot far fetched to me.

Arne

PS: There are a few cases (like 100 out of a 100000) where the
author has chose to make a library GPL which makes it
impossible to use for closed source. But that is not
the common scenario.
David Froble
2017-05-14 02:13:03 UTC
Permalink
Raw Message
Post by Arne Vajhøj
Post by David Froble
Post by Stephen Hoffman
GPL exists to force open source code,
Ayep! And I could use up considerable bandwidth calling them names, but
one word will suffice.
Thieves
????
It is their code. You want to use their code. They let you
use it for free. You just need to comply with some license
terms, which in most cases where GPL is used just means that
if you modify/enhance their code and distribute it then your
modifications/enhancements need to also be open source
under GPL.
Calling them thieves because they do not want you to take
their code for free, modify/enhance it and distribute the result
as closed source seems a bot far fetched to me.
Always ready to be corrected. I've been wrong many times, I doubt that will stop.

My understanding, maybe wrong, is that if you use any software under the GPL
license with some private software, then all the software, including your
private software just became open.
IanD
2017-05-14 02:35:14 UTC
Permalink
Raw Message
On Sunday, May 14, 2017 at 12:13:05 PM UTC+10, David Froble wrote:

<snip>
Post by David Froble
Always ready to be corrected. I've been wrong many times, I doubt that will stop.
Join the club :-)
Post by David Froble
My understanding, maybe wrong, is that if you use any software under the GPL
license with some private software, then all the software, including your
private software just became open.
That was my believe too, then I read that the following holds (at least what I understood of it)

- Any open code code you redistribute must be published
- Any open code you modify must be published
- Code you develop independently can remain closed if you choose to do so

Just because you distribute your code with open source code doesn't mean your code then has to be open sourced

Open source code doesn't 'contaminate' closed source code, so to speak

It's the code and the license of the code that is key, not the packaging / distribution method

That's my layman's understanding
Arne Vajhøj
2017-05-14 20:13:59 UTC
Permalink
Raw Message
Post by David Froble
Post by Arne Vajhøj
Post by David Froble
Post by Stephen Hoffman
GPL exists to force open source code,
Ayep! And I could use up considerable bandwidth calling them names, but
one word will suffice.
Thieves
????
It is their code. You want to use their code. They let you
use it for free. You just need to comply with some license
terms, which in most cases where GPL is used just means that
if you modify/enhance their code and distribute it then your
modifications/enhancements need to also be open source
under GPL.
Calling them thieves because they do not want you to take
their code for free, modify/enhance it and distribute the result
as closed source seems a bot far fetched to me.
Always ready to be corrected. I've been wrong many times, I doubt that will stop.
My understanding, maybe wrong, is that if you use any software under the
GPL license with some private software, then all the software, including
your private software just became open.
While technical correct it is very misleading.

If any code get "linked" with GPL code, then it has to also be
available under GPL.

But you need to think about applications versus libraries.

You do typical not link your application with another
application. So for all the GPL applications out there
the GPL clause just mean that if you modify/enhance the
application and distribute the result then your
modifications/enhancements would need to be GPL.

GPL for libraries is a huge problem as ones
applications do get linked with those. But there
are extremely few libraries under GPL (they do
exist and are a nuisance, but they are rare
exceptions). Instead of GPL then libraries
are under either LGPL or "GPL with linking exception",
which basically mean that you can link closed
source code with them.

Let us imagine that HP instead of selling VMS to VSI
had decided to open source it and had decided to use
GPL and LGPL.

Then:
* VMS core, DCL, compilers etc.
would have gone under GPL
* Runtime libraries both general and language
specific would have gone under LGPL

And your closed source would be fine, because even
though you use VMS, DCL and compilers then your code
does not get linked with them. Your code only get linked
with the libraries under LGPL.

Arne
Bill Sorenson
2017-05-15 02:45:51 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Bill Sorenson
I'm not a fan of the GPL as a license but bundling GPL bits shouldn't
be a problem as long as you include a copy of the license and VMS
specific patches are available on anonymous FTP somewhere. Mac OS X
includes Bash. Even Solaris ships Bash not just Ksh.
Any sort of bundling or redistribution has to be done in compliance
with the applicable licensing.
Lawyers representing closed-source vendors tend to be very careful
around inclusion of and compliance with GPL code, both for GPL2 and
particularly GPL3. This if the GPL code is even permitted to be
included with the closed-source package, which it often isn't.
https://qz.com/981029/a-federal-court-has-ruled-that-an-open-source-license-is-an-enforceable-contract/
As for your examples, XNU is open source.
https://opensource.apple.com/source/xnu/ Other parts of macOS are not
open-source. Most of the frameworks and the user interface and the
apps are closed source. macOS was (is) using a GPL2 version of bash,
where GNV was using the newer and GPL3 version.
Solaris was open-source for a while as OpenSolaris and the illumos fork
of OpenSolaris still is available. I've not looked at bash inclusion
in Solaris. Solaris was using Bourne, ksh and some other shells last
I checked (and not bash), not that I've been particularly following
Solaris features and capabilities in the era since Oracle acquired Sun.
I'd be surprised if there were GPL3 code incorporated in macOS or Solaris.
Most closed-source entities treat GPL code with due care. Okay to
use, okay to redistribute separately and with source, not okay to
incorporate. Which is how the GPL is intended.
--
Pure Personal Opinion | HoffmanLabs LLC
Bash has been bundled with Solaris long before Solaris was open-sourced. And the CDDL used by Solaris is decidedly NOT GPL compatible (on purpose allegedly) to keep ZFS out of Linux mainline.
Stephen Hoffman
2017-05-15 16:29:25 UTC
Permalink
Raw Message
Post by Bill Sorenson
Post by Stephen Hoffman
Solaris was open-source for a while as OpenSolaris and the illumos fork
of OpenSolaris still is available. I've not looked at bash inclusion
in Solaris. Solaris was using Bourne, ksh and some other shells last
I checked (and not bash), not that I've been particularly following
Solaris features and capabilities in the era since Oracle acquired Sun.
I'd be surprised if there were GPL3 code incorporated in macOS or Solaris.
Bash has been bundled with Solaris long before Solaris was open-sourced.
Bourne shell, or bash shell? And any GPL3 code?
--
Pure Personal Opinion | HoffmanLabs LLC
b***@nevelex.com
2017-05-15 19:43:56 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Bill Sorenson
Post by Stephen Hoffman
Solaris was open-source for a while as OpenSolaris and the illumos fork
of OpenSolaris still is available. I've not looked at bash inclusion
in Solaris. Solaris was using Bourne, ksh and some other shells last
I checked (and not bash), not that I've been particularly following
Solaris features and capabilities in the era since Oracle acquired Sun.
I'd be surprised if there were GPL3 code incorporated in macOS or Solaris.
Bash has been bundled with Solaris long before Solaris was open-sourced.
Bourne shell, or bash shell? And any GPL3 code?
--
Pure Personal Opinion | HoffmanLabs LLC
Bash specifically. The version that comes with Solaris is GPLv2. If I recall correctly Bash prior to 4.0 is "GPLv2 or later" licensed. Looking at what Solaris included, Bash 3.2.48, Binutils 2.15, Gtar 1.26, ggrep 2.5, Wget 1.12, GNU make 3.82, Samba 3.6.8. Of course like macOS its loaded with lots of BSD goodies unrelated to the GNU GPL parts.

There isn't anything prohibiting redistribution as long as like always with the GPL source code is available. The main issue you'd have is if you incorporated a GPL'd source file into a proprietary piece of software. Nothing stops you from shipping GPL software along side proprietary software.
Arne Vajhøj
2017-05-15 23:35:59 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Bill Sorenson
Post by Stephen Hoffman
Solaris was open-source for a while as OpenSolaris and the illumos
fork of OpenSolaris still is available. I've not looked at bash
inclusion in Solaris. Solaris was using Bourne, ksh and some other
shells last I checked (and not bash), not that I've been particularly
following Solaris features and capabilities in the era since Oracle
acquired Sun.
I'd be surprised if there were GPL3 code incorporated in macOS or Solaris.
Bash has been bundled with Solaris long before Solaris was open-sourced.
Bourne shell, or bash shell?
I will definitely expect bash to be there.
Post by Stephen Hoffman
And any GPL3 code?
GCC switched to V3 about a decade ago.

And bash also switched to V3 at some point in time (not quite sure when).

I would expect there to be more.

Arne
Arne Vajhøj
2017-05-12 01:17:57 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
More than a little of the software in GNV is GPL with current bits of
tools variously either GPL2 or GPL3, so GNV supplied separately with the
release would be nice and likely feasible, but having GNV embedded might
be impractical as the copyrights can preclude that sort of inclusion.
I don't think GPL tools will be a problem.

It would be a problem if VMS code was linked with it.

But that is not the case. These tools are standalone
applications.

Nothing is linked with them.

Arne
Arne Vajhøj
2017-05-12 01:19:02 UTC
Permalink
Raw Message
Post by Arne Vajhøj
Post by Stephen Hoffman
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
More than a little of the software in GNV is GPL with current bits of
tools variously either GPL2 or GPL3, so GNV supplied separately with the
release would be nice and likely feasible, but having GNV embedded might
be impractical as the copyrights can preclude that sort of inclusion.
I don't think GPL tools will be a problem.
It would be a problem if VMS code was linked with it.
But that is not the case. These tools are standalone
applications.
Nothing is linked with them.
Obviously VSI would need to consult a lawyer specializing
in this area before actually doing anything.

Arne
John E. Malmberg
2017-05-12 13:43:15 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
More than a little of the software in GNV is GPL with current bits of
tools variously either GPL2 or GPL3, so GNV supplied separately with the
release would be nice and likely feasible, but having GNV embedded might
be impractical as the copyrights can preclude that sort of inclusion.
This barring porting over BSD-licensed tools, and replacing the GPL pieces.
The main issue is that closed source VMS supplied utilities can not link
or dynamically load a GPL licensed shared image.
Post by Stephen Hoffman
As for practical options, probably better to offer up some cycles to
help with GNV and related, as it's a large project.
Yes, it really needs help.

Ironically, the stuff that has existing VMS ports with expected VMS
behavior under DCL is the hardest to update, as one of my goals is one
binary for both DCL and GNV.

I usually find that there are bugs in the DCL/VMS mode that I have to
fix before being able to complete the port.

The older updated packages were usually 32 bit pointer builds only. The
packages I am updating now will support 64 bit pointers where possible
and where they supply a shared image, I am trying to provide both flavors.
Post by Stephen Hoffman
The embedded support for GNV within OpenVMS has some issues, as I
suspect there's a FID-handling error in the ROOT bits, and there's the
variously-discussed (and variously lacking) SSIO support.
Copyrights allowing, integrating Python, php, Perl, Apache, SQLite,
PostgreSQL and other pieces — not the least of which is VSI IP itself —
with OpenVMS would also be useful, yes. The current
everything-is-its-own-kit is a big of a dog's breakfast, and just makes
OpenVMS more difficult to deal with. Don't light it all off by
default, but do include what's common on other server operating
systems. Helps with integration, testing and particularly with
dependencies.
The updated GNV components no longer require the older GNV components to
be installed.

I have not had time to work out how to build a package that references
the current versions of the upstream components, and a zip file that
contains everything for a single download.

Or add building a logical disk with the current versions of the upstream
components.

I have not yet set up my local Jenkins to be able to differentiate a
release build from a build from a work in progress update, which is what
I would want to use to keep such a package up to date.

Regards,
-John
***@qsl.net_work
Arne Vajhøj
2017-05-12 01:15:43 UTC
Permalink
Raw Message
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
How about languages like Python while we are at it (once V3 can run on VMS) too?
I don't hold the old excuse of lack of disk space as a credible
excuse anymore. Disk space is cheap and when the new file system
shows its head, lack of disk space excuses will be even more
irrelevant than they already are
The VMS installation kit should definitely contain a large
library of useful stuff. That is what people are expecting
now a days.

But I think the installation should start by asking if it is a
production system or a development system.

If production systems then default should be no extras
and all extras should be explicitly selected. Just to
keep the software that need to be secure and kept
uptodate is minimal.

If development system then default should include
all the common stuff but uncommon stuff van be added
or common stuff removed explicit.

Arne
Bob Koehler
2017-05-12 13:45:15 UTC
Permalink
Raw Message
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
Nix'y stuff cannot be ignored IMO. Many of the tools (AWK, SED immediately come to mind) are powerful and can greatly improve day to day productivity when compared to doing many of the same tasks in crippled DCL
If you want crytic UNIX stuff, get UNIX.

I will be happy with optional GNV and GNU stuff if I want them on my
system.
George Cornelius
2017-05-13 20:38:17 UTC
Permalink
Raw Message
Post by Bob Koehler
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
Nix'y stuff cannot be ignored IMO. Many of the tools (AWK, SED immediately come to mind) are powerful and can greatly improve day to day productivity when compared to doing many of the same tasks in crippled DCL
If you want crytic UNIX stuff, get UNIX.
I will be happy with optional GNV and GNU stuff if I want them on my
system.
No one seems to be mentioning this, but if you are fluent in
Unix speak _and_ VMS speak, how do you keep your fingers from
typing, say, sys$library without thinking that (a) it won't
do what you want it to, and (b) you may actually do some damage
somewhere, depending on whether there is an environment variable
(symbol? logical?) called library. Even if there is not you
are still exposed because in some contexts there is a need for
a logical named sys .

Lest you think this is purely theoretical, something much
like this happened to a dba here who happened to be running
gnv tools with privileges enabled. We had to do some scrambling
to restore missing and damaged files in sys$sysroot:[whatever] .

George
Bill Gunshannon
2017-05-13 21:08:58 UTC
Permalink
Raw Message
Post by George Cornelius
Post by Bob Koehler
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
Nix'y stuff cannot be ignored IMO. Many of the tools (AWK, SED immediately come to mind) are powerful and can greatly improve day to day productivity when compared to doing many of the same tasks in crippled DCL
If you want crytic UNIX stuff, get UNIX.
I will be happy with optional GNV and GNU stuff if I want them on my
system.
No one seems to be mentioning this, but if you are fluent in
Unix speak _and_ VMS speak, how do you keep your fingers from
typing, say, sys$library without thinking that (a) it won't
do what you want it to, and (b) you may actually do some damage
somewhere, depending on whether there is an environment variable
(symbol? logical?) called library. Even if there is not you
are still exposed because in some contexts there is a need for
a logical named sys .
As someone who is fairly fluent in both, I can not tell you
why I don't have a problem with confusing the two. I just don't.
Might be in part due to the fact that I have never tried to make
one look like the other (which was quite common practice when VMS
still had a place at the University where I used to work.)
Post by George Cornelius
Lest you think this is purely theoretical, something much
like this happened to a dba here who happened to be running
gnv tools with privileges enabled. We had to do some scrambling
to restore missing and damaged files in sys$sysroot:[whatever] .
As I said, might have a lot to do with not trying to make one
look ike the other.

bill
Arne Vajhøj
2017-05-13 23:52:10 UTC
Permalink
Raw Message
Post by George Cornelius
No one seems to be mentioning this, but if you are fluent in
Unix speak _and_ VMS speak, how do you keep your fingers from
typing, say, sys$library without thinking that (a) it won't
do what you want it to, and (b) you may actually do some damage
somewhere, depending on whether there is an environment variable
(symbol? logical?) called library. Even if there is not you
are still exposed because in some contexts there is a need for
a logical named sys .
Lest you think this is purely theoretical, something much
like this happened to a dba here who happened to be running
gnv tools with privileges enabled. We had to do some scrambling
to restore missing and damaged files in sys$sysroot:[whatever] .
I am not sure that I understand the problem.

I would expect almost all IT professionals today to work
with more than one OS.

Somehow one need to keep things separate.

In many ways keeping VMS and *nix separate must be
easier than to keep two *nix flavors separate.

Arne
George Cornelius
2017-05-21 05:59:48 UTC
Permalink
Raw Message
Post by Arne Vajhøj
Post by George Cornelius
No one seems to be mentioning this, but if you are fluent in
Unix speak _and_ VMS speak, how do you keep your fingers from
typing, say, sys$library without thinking that (a) it won't
do what you want it to, and (b) you may actually do some damage
somewhere, depending on whether there is an environment variable
(symbol? logical?) called library. Even if there is not you
are still exposed because in some contexts there is a need for
a logical named sys .
Lest you think this is purely theoretical, something much
like this happened to a dba here who happened to be running
gnv tools with privileges enabled. We had to do some scrambling
to restore missing and damaged files in sys$sysroot:[whatever] .
I am not sure that I understand the problem.
I suppose I should have qualified my comments. I don't mind
Unix-like environments in a non-Unix world. In fact, under
RSX11M I was thrilled to have the Lawrence Berkeley Tools
"virtual operating system" and was able to use it for various
system administration tasks. I also like Cygwin under
Windows.

The problem is that a system administrator will find it
dangerous because he must read and write using file,
directory, and logical names that contain dollar signs,
and due to the radically different quoting styles
between DCL and a Unix shell, will find himself making
inadvertent errors.

A nonprivileged user, or a privileged user without
privileges turned on, will probably find the risks
to be manageable. In fact, if you think of the dollar
sign as owned by DEC/Compaq/HPE, then you as a
nonprivileged user may not have much need for dollar
signs in names except for read access (sys$library,
sys$share, etc.), although there are a few cases
where ordinary users will use dollar sign logicals
and file/directory names for writing (sys$login,
sys$scratch,net$server.log...).

The real risks involve privileged access and
the likelihood of making inadvertent errors.

Oh, and I am a Unix/Linux/VMS administrator,
but in the VMS case I no longer have anything
production to manage.

George
Post by Arne Vajhøj
I would expect almost all IT professionals today to work
with more than one OS.
Somehow one need to keep things separate.
In many ways keeping VMS and *nix separate must be
easier than to keep two *nix flavors separate.
Arne
Bob Koehler
2017-05-16 17:36:26 UTC
Permalink
Raw Message
Post by George Cornelius
Lest you think this is purely theoretical, something much
like this happened to a dba here who happened to be RUNNING
gnv tools WITH PRIVILEGES ENABLED.
Here's your sign!
Simon Clubley
2017-05-13 19:44:20 UTC
Permalink
Raw Message
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
They should be supplied as part of the installation media and it should
be a simple PCSI command to install them. It should also be easy to
update them when a new version is released.

However, they should not be installed automatically so that you can
reduce the security footprint down to what is needed (and no more)
on systems where this matters.

I'd also potentially like to see them split between several install
packages as well in order to help with this security footprint issue.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2017-05-13 20:07:09 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by IanD
As per the title..., Should GNV / Nix tools be supplied / installed on VMS by default
They should be supplied as part of the installation media and it should
be a simple PCSI command to install them. It should also be easy to
update them when a new version is released.
I wouldn't mind seeing something akin to nix available on OpenVMS and
it does fit in this context, but I'm going to assume that this was a
reference to Unix and not to nix that was intended.

http://nixos.org/nix/about.html

I've already commended else-thread that incorporating compatibly- and
particularly BSD-licensed tools into the base distro — along with fully
integrating VSI IP — would be welcome, too. I've certainly ported
various BSD and Apache-licensed software pieces over to OpenVMS, as
have others. But I digress.
Post by Simon Clubley
However, they should not be installed automatically so that you can
reduce the security footprint down to what is needed (and no more) on
systems where this matters.
I'd rather see a different approach used here, with a default
installation with all the parts, and that then allows something akin to
the traditional tailoring mechanism (VMSTAILOR.COM et al) to reduce the
footprint where that's necessary. While defaulting the configuration
to more permutations and to forcing everybody to deal with the corner
cases and the dependences and the what-version-is-installed certainly
does have a long history on OpenVMS, it's a less-than-optimal
approach. Let the folks that tailor the configuration deal with the
hassles of having a smaller deployment or an overstuffed SSD.
Post by Simon Clubley
I'd also potentially like to see them split between several install
packages as well in order to help with this security footprint issue.
If the packages aren't started up, they generally aren't vulnerable.
If there's a single install and single patch mechanism — whether that's
some descendant of PCSI, or using nix or otherwise — that's less work
for many folks involved, and more likely to be current and secure, than
If the packages are separate with separate patches; there's a better
chance that some of the various packages are down-revision than not.
Or the installers and maintainers and end-users and the third-party
product providers are dealing with more permutations and a more varied
testing matrix. In short, why make things more difficult? Saving
SSD space isn't as much of a problem as it used to be in the era of
gigabyte-sized HDDs, after all. If some folks need a specific
configuration that'll introduce complexity, then place that cost over
onto the folks that need the particular savings. Figuring out which IP
stack or which SSL library or which DECnet phase or whether ENCRYPT was
installed (that's now fixed) is around is already a dumpster fire.

Yes, I know that simpler and easier and more automated approaches are
an anathema to some folks — some folks among us do like our knobs and
buttons and tweaks — but the ensuing permutations and packaging and
dependencies are a far bigger issue than many realize.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...