On 4/9/2024 1:18 PM, Simon Clubley wrote:
The changes to the hobbyist program have made it to The Register:
https://www.theregister.com/2024/04/09/vsi_prunes_hobbyist_prog/
A number of comments about, ermm, "ways" to bypass the VSI limitations.
I wonder what the reaction of those people will be if VSI just outright
cancels the whole program in response, while blaming "certain attitudes"
for that decision ?
At this stage of the game, does it really matter.
Welcome to the world of RT/RSTS/RSX.
bill
On 09/04/2024 20:50, bill wrote:
At this stage of the game, does it really matter.
Welcome to the world of RT/RSTS/RSX.
bill
Don't forget VAX, and presumably soon AXP and I64
The changes to the hobbyist program have made it to The Register:
https://www.theregister.com/2024/04/09/vsi_prunes_hobbyist_prog/
A number of comments about, ermm, "ways" to bypass the VSI limitations.
I wonder what the reaction of those people will be if VSI just outright cancels the whole program in response, while blaming "certain attitudes"
for that decision ?
Simon.
On 4/9/2024 9:18 PM, Dave Froble wrote:
On 4/9/2024 1:18 PM, Simon Clubley wrote:
The changes to the hobbyist program have made it to The Register:
https://www.theregister.com/2024/04/09/vsi_prunes_hobbyist_prog/
A number of comments about, ermm, "ways" to bypass the VSI limitations.
I wonder what the reaction of those people will be if VSI just outright
cancels the whole program in response, while blaming "certain attitudes" >>> for that decision ?
Simon.
Ok Simon, I took the time to read that article, and the replies. Didn't see too much about license bypassing. One mention of an existing method, and that method is much older than VSI, so nothing new to them, or anyone else.
Well, you had someone talk about taking the licenses off of the
distributed VM and using it on another.
I've wondered about the complaints about patching the CL distributions. Not sure I understand. What would stop a patch of such? Of course, there is the question of access to patches.
And, there's the rub. If they aren't planning on letting CL users
run up to date systems they are apparently not planning on them
providing valid test data. :-)
For some of us it's a little funny to think that our beloved PDP-11
may out last VMS in production systems.
bill
On 4/9/2024 9:18 PM, Dave Froble wrote:
I've wondered about the complaints about patching the CL
distributions. Not sure I understand. What would stop a patch of
such? Of course, there is the question of access to patches.
That's the complaint. The assumption is that there will be no access to patches nor new versions other than when the next CLP vmdk is released.
If the CLP stuff is only on a once-a-year vmdk distribution, then bug
fixes will be far and few between and if they are nasty ones then may
stop people from using the distribution at all.
On 4/9/2024 10:55 PM, John H. Reinhardt wrote:
On 4/9/2024 8:38 PM, bill wrote:
Well, you had someone talk about taking the licenses off of the
distributed VM and using it on another.
Been there, did that as reported by me in another thread. It kept my two
earlier x86 OpenVMS systems running without having to migrate my changes. Of
course, the vmdk licenses were fewer that what was on the previous CLP version
by 31. But a good number of them were covered by the HAOE blanket license. >> The ones that weren't were mostly odd things very few used.
And you don't see that as "license bypassing" or a license violation?
number of them were covered by the HAOE blanket license. The ones that weren't were mostly odd things very few used.Been there, did that as reported by me in another thread. It kept my two earlier x86 OpenVMS systems running without having to migrate my changes. Of course, the vmdk licenses were fewer that what was on the previous CLP version by 31. But a good
And you don't see that as "license bypassing" or a license violation?
bill
On 4/10/2024 10:08 AM, Dave Froble wrote:
On 4/10/2024 8:32 AM, bill wrote:
On 4/9/2024 10:55 PM, John H. Reinhardt wrote:
On 4/9/2024 8:38 PM, bill wrote:
Well, you had someone talk about taking the licenses off of the
distributed VM and using it on another.
Been there, did that as reported by me in another thread. It kept my two >>>> earlier x86 OpenVMS systems running without having to migrate my changes. Of
course, the vmdk licenses were fewer that what was on the previous CLP version
by 31. But a good number of them were covered by the HAOE blanket license. >>>> The ones that weren't were mostly odd things very few used.
And you don't see that as "license bypassing" or a license violation?
No! I do not!
Example: User has VMS running, legally, on a system. User decides to install
VMS on another disk, on that same system, issues the licenses using the
license issue capability in VMS, and then installs the licenses on the new VMS
disk, and then runs off that disk.
It is just moving the licenses from one system disk to another on THE SAME >> SYSTEM!
But he is not moving them from one disk to another on the same
system. He is moving them to a different system. As far back as
I can remember that required a license change and a transfer fee.
bill
2) Who said anything about a different system? I mentioned "same system".
On 2024-04-10, Dave Froble <davef@tsoft-inc.com> wrote:
2) Who said anything about a different system? I mentioned "same system". >>
It's not the same system. System 1 was hand-built from the installation
kits by the OP. System 2 was delivered to OP pre-built by VSI in a virtual image. They are very much different systems.
Simon.
On 4/10/2024 10:08 AM, Dave Froble wrote:off that disk.
On 4/10/2024 8:32 AM, bill wrote:
On 4/9/2024 10:55 PM, John H. Reinhardt wrote:
On 4/9/2024 8:38 PM, bill wrote:
Well, you had someone talk about taking the licenses off of the
distributed VM and using it on another.
Been there, did that as reported by me in another thread. It kept my two >>>> earlier x86 OpenVMS systems running without having to migrate my changes. Of
course, the vmdk licenses were fewer that what was on the previous CLP version
by 31. But a good number of them were covered by the HAOE blanket license. >>>> The ones that weren't were mostly odd things very few used.
And you don't see that as "license bypassing" or a license violation?
No! I do not!
Example: User has VMS running, legally, on a system. User decides to install VMS on another disk, on that same system, issues the licenses using the license issue capability in VMS, and then installs the licenses on the new VMS disk, and then runs
It is just moving the licenses from one system disk to another on THE SAME SYSTEM!
But he is not moving them from one disk to another on the same
system. He is moving them to a different system. As far back as
I can remember that required a license change and a transfer fee.
bill
On 4/10/2024 9:14 AM, bill wrote:
He is moving them to a different system. As far back as
I can remember that required a license change and a transfer fee.
bill
As mentioned elsewhere, those were HP(E)'s rules and for commercial
use. Even HP(E) never required Hobbyists to pay license transfer fees.
They gave you one set of PAKs per architecture and let you put them on
as many as you wanted. So long as it was non-commercial.
Did you read the Community License Agreement I posted the link to? You might want to before arguing points that don't exist.
Again, https://vmssoftware.com/community/community-license/agreement/
If you find a section that says I can't take the license PAKS from the
vmdk they supply to run another x86 OpenVMS installation as a hobbyist
then let me know. I can't see one.
The changes to the hobbyist program have made it to The Register:
https://www.theregister.com/2024/04/09/vsi_prunes_hobbyist_prog/
A number of comments about, ermm, "ways" to bypass the VSI limitations.
I wonder what the reaction of those people will be if VSI just outright cancels the whole program in response, while blaming "certain attitudes"
for that decision ?
Simon.
On 2024-04-11 8:53 p.m., David Goodwin wrote:
how many
people really want to have to setup their OpenVMS instances from scratch
every year?
A baseline canned virtual machine for an OS is often how cloud-based Continuous Integration begins each of its passes. Once that baseline VM
is running, all the customization, add-ons and unique bits then get
applied hands-free by scripts, often laid out by a yml file, or similar mechanism.
If commodity provisioning of OpenVMS instances in the cloud ever becomes
a reality, the way it has for other platforms, that provisioning would
likely work much the same way.
On 2024-04-11 8:53 p.m., David Goodwin wrote:
how many
people really want to have to setup their OpenVMS instances from scratch
every year?
A baseline canned virtual machine for an OS is often how cloud-based Continuous Integration begins each of its passes. Once that baseline VM
is running, all the customization, add-ons and unique bits then get
applied hands-free by scripts, often laid out by a yml file, or similar mechanism.
The changes to the hobbyist program have made it to The Register:
https://www.theregister.com/2024/04/09/vsi_prunes_hobbyist_prog/
A number of comments about, ermm, "ways" to bypass the VSI limitations.
I wonder what the reaction of those people will be if VSI just outright cancels the whole program in response, while blaming "certain attitudes"
for that decision ?
On 2024-04-12, mjos_examine <m6502x64@gmail.com> wrote:
On 2024-04-11 8:53 p.m., David Goodwin wrote:
how many
people really want to have to setup their OpenVMS instances from scratch >>> every year?
A baseline canned virtual machine for an OS is often how cloud-based
Continuous Integration begins each of its passes. Once that baseline VM
is running, all the customization, add-ons and unique bits then get
applied hands-free by scripts, often laid out by a yml file, or similar
mechanism.
That could be an opportunity for someone to develop, if they get too
annoyed by having to rebuild their servers every year.
Hopefully based on JSON proper and not that yaml nonsense however...
[I dislike yaml with a passion. It's way too fragile and JSON is just
as easy to read if you layout each JSON element indented on a new line.]
On 4/12/2024 8:32 AM, Simon Clubley wrote:
On 2024-04-12, mjos_examine <m6502x64@gmail.com> wrote:
On 2024-04-11 8:53 p.m., David Goodwin wrote:
how many
people really want to have to setup their OpenVMS instances from
scratch
every year?
A baseline canned virtual machine for an OS is often how cloud-based
Continuous Integration begins each of its passes. Once that baseline VM
is running, all the customization, add-ons and unique bits then get
applied hands-free by scripts, often laid out by a yml file, or similar
mechanism.
That could be an opportunity for someone to develop, if they get too
annoyed by having to rebuild their servers every year.
Hopefully based on JSON proper and not that yaml nonsense however...
[I dislike yaml with a passion. It's way too fragile and JSON is just
as easy to read if you layout each JSON element indented on a new line.]
Hmmmmm.... I wonder if this could be done with something like CFEngine?
On 4/12/2024 9:13 AM, Arne Vajhøj wrote:
On 4/12/2024 8:56 AM, bill wrote:
On 4/12/2024 8:32 AM, Simon Clubley wrote:They probably could. But industry preference seem to be for other
On 2024-04-12, mjos_examine <m6502x64@gmail.com> wrote:Hmmmmm.... I wonder if this could be done with something like CFEngine? >>
On 2024-04-11 8:53 p.m., David Goodwin wrote:
how many
people really want to have to setup their OpenVMS instances from
scratch
every year?
A baseline canned virtual machine for an OS is often how cloud-based >>>>> Continuous Integration begins each of its passes. Once that baseline VM >>>>> is running, all the customization, add-ons and unique bits then get
applied hands-free by scripts, often laid out by a yml file, or similar >>>>> mechanism.
That could be an opportunity for someone to develop, if they get too
annoyed by having to rebuild their servers every year.
Hopefully based on JSON proper and not that yaml nonsense however...
[I dislike yaml with a passion. It's way too fragile and JSON is just
as easy to read if you layout each JSON element indented on a new line.] >>>
tools.
Industry prefers other OSes, too. Are all the VMS users moving? :-)
On 4/12/2024 9:13 AM, Arne Vajhøj wrote:
On 4/12/2024 8:56 AM, bill wrote:
On 4/12/2024 8:32 AM, Simon Clubley wrote:
On 2024-04-12, mjos_examine <m6502x64@gmail.com> wrote:
A baseline canned virtual machine for an OS is often how cloud-based >>>>> Continuous Integration begins each of its passes. Once that
baseline VM
is running, all the customization, add-ons and unique bits then get
applied hands-free by scripts, often laid out by a yml file, or
similar
mechanism.
That could be an opportunity for someone to develop, if they get too
annoyed by having to rebuild their servers every year.
Hmmmmm.... I wonder if this could be done with something like CFEngine? >>They probably could. But industry preference seem to be for other
tools.
Industry prefers other OSes, too. Are all the VMS users moving? :-)
But having VMS use different tool sets than other OS will
sort of negate that positive development.
Arne Vajhøj <arne@vajhoej.dk> writes:
But having VMS use different tool sets than other OS will
sort of negate that positive development.
This is a chicken-and-egg problem: I don't expect companies like Perforce (Puppet) or RedHat (Ansible) to start work on a VMS port unless there is
a strong business case.
On 2024-04-09, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
The changes to the hobbyist program have made it to The Register:
https://www.theregister.com/2024/04/09/vsi_prunes_hobbyist_prog/
A number of comments about, ermm, "ways" to bypass the VSI limitations.
I wonder what the reaction of those people will be if VSI just outright
cancels the whole program in response, while blaming "certain attitudes"
for that decision ?
Now on Slashdot as well:
https://tech.slashdot.org/story/24/04/11/014223/vms-software-prunes-openvms-hobbyist-program
On 4/12/24 7:35 AM, Simon Clubley wrote:
On 2024-04-09, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
The changes to the hobbyist program have made it to The Register:
https://www.theregister.com/2024/04/09/vsi_prunes_hobbyist_prog/
A number of comments about, ermm, "ways" to bypass the VSI limitations.
I wonder what the reaction of those people will be if VSI just outright
cancels the whole program in response, while blaming "certain attitudes" >>> for that decision ?
Now on Slashdot as well:
https://tech.slashdot.org/story/24/04/11/014223/vms-software-prunes-openvms-hobbyist-program
and on OSNews:
https://www.osnews.com/story/139246/vms-software-guts-its-community-licensing-program/
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 435 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 148:40:10 |
| Calls: | 9,120 |
| Calls today: | 3 |
| Files: | 13,425 |
| Messages: | 6,033,768 |