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.

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

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

Don't forget VAX, and presumably soon AXP and I64

--
Chris

On 10/4/24 08:51, Chris Townley wrote:
> 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

Just on a whim, I went looking for Alpha workstations/servers on eBay.
Given that VMS is dead on those now, you'd be mad to pay that much money
just to run tru64 or something on them.

--
motk

On 4/9/2024 6:51 PM, Chris Townley wrote:
> On 09/04/2024 20:50, bill 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 ?
>>>
>>
>> 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
>

That's pretty much what I was hinting at. And I think x86-64 VMS is
not far behind. People are already talking about how they can get
around the cancellation of hobbyist licenses. The light at the end
of the tunnel is in view and it's an oncoming train.

bill

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.

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.

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

On 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 8:38 PM, bill wrote:
> 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.
>

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.

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

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

--
John H. Reinhardt

On 4/9/2024 10:55 PM, John H. Reinhardt wrote:
>> 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.

I think of this differently.

Hobbyists may not care so much about bugs. Unless of course
it directly impacts them.

But having hobbyists run old version instead of either
latest and greatest release version or field test version
means that VSI miss out on free testing.

The CLP users has found a lot of compiler bugs in compiler FT.

Arne

On 4/9/2024 10:55 PM, John H. Reinhardt wrote:
> On 4/9/2024 8:38 PM, bill wrote:
>> 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.
>>
>
> 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?

>
>>>
>>> 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.
>
>>
>>
>> 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/10/2024 7:32 AM, bill wrote:
>> 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?

I can see no part of the Community License Agreement that this violates. If VSI changes it the future, then that is something to deal with when it happens.

https://vmssoftware.com/community/community-license/agreement/

>>>
>>>
>>> bill
>>>
>>>
>>
>

--
John H. Reinhardt

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!

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

On 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

On 4/10/2024 10:14 AM, bill wrote:
> 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
>

1) Those were DEC's rules. Not sure what rules VSI has.

2) Who said anything about a different system? I mentioned "same system".

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

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

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

On 4/10/2024 1:16 PM, Simon Clubley wrote:
> 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.
>

Back in the day licenses were assigned to a particular computer, read hardware.
So when this old dog writes "system", he's talking about hardware.

I don't know what I'd call a installation of VMS. Maybe I'll continue
considering a system hardware.

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

On 4/10/2024 9:14 AM, bill wrote:
> 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
>

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.

--
John H. Reinhardt

On 4/10/24 9:45 PM, John H. Reinhardt wrote:
> 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/

I had pointed him to that as well and he flatly refused to read it, yet
continues to spread FUD about what it doesn't say. If someone really
prefers their ignorance, there's only so much you can do to acquaint
them with the truth.

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

Me either.

In article <uv3t89$bl4h$1@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...
>
> 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.

They've already canceled the whole program. What we have now is just the
student kit relabeled as the community license. I guess they could still
get rid of that but I'm not sure it would be much of a loss - how many
people really want to have to setup their OpenVMS instances from scratch
every year?

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 4/12/2024 6:17 AM, mjos_examine 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.
>
> 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.

True.

But the VMS world is very far from IaaC. It is far from a given that
VMS will ever get there (the small size of the VMS market makes the
business case for advanced and expensive tooling difficult). And even if
it does happen then it will take many years.

Arne

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

Simon.

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

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

Simon.

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

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

It will be very hard to get the common tool sets ported to VMS,
but it will be totally unrealistic to create VMS specific tool sets.

So it will be ports of existing tool sets. And to large extent
that means YAML. Enjoy. :-)

Arne

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?

bill