Java 8 Now Available for OpenVMS Integrity

Post by Kerry Main
Fyi .
< <https://www.hpe.com/global/java/download/ivms/1.8.0>
https://www.hpe.com/global/java/download/ivms/1.8.0>

Great news!

IanD

2017-04-06 17:43:35 UTC

Post by Kerry Main
Fyi .
< <https://www.hpe.com/global/java/download/ivms/1.8.0>
https://www.hpe.com/global/java/download/ivms/1.8.0>
Regards,
Kerry Main
Kerry dot main at starkgaming dot com

I shall disseminate tis information at my workplace.

Even if they have no interest in deploying this, it will help to send the message that VMS is alive and updating. Every little bit helps

Arne Vajhøj

2017-04-06 18:05:29 UTC

Post by IanD

Post by Kerry Main
https://www.hpe.com/global/java/download/ivms/1.8.0>

I shall disseminate tis information at my workplace.
Even if they have no interest in deploying this, it will help to send the message that VMS is alive and updating. Every little bit helps

Exactly.

The value of this goes far beyond those really interested in Java 8.

Arne

Simon Clubley

2017-04-06 18:30:26 UTC

Post by IanD
I shall disseminate tis information at my workplace.
Even if they have no interest in deploying this, it will help to send the message that VMS is alive and updating. Every little bit helps

Exactly.
The value of this goes far beyond those really interested in Java 8.

But it can also work the other way if this is still the current Java 8
version on VMS 6 months from now.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

David Froble

2017-04-06 20:21:20 UTC

Exactly.
The value of this goes far beyond those really interested in Java 8.

But it can also work the other way if this is still the current Java 8
version on VMS 6 months from now.
Simon.

VSI is a small company, with a huge amount of work to accomplish. Not sure if
HPE was involved in the Java 8 stuff. Regardless, haven't you been pounding
just a bit too hard on "I want everything, right now, or even yesterday"?

It seems that for some people, no matter what does get released, they might as
well not have bothered. Well, should they have bothered ???????????????

Simon Clubley

2017-04-06 20:23:39 UTC

Post by Simon Clubley
But it can also work the other way if this is still the current Java 8
version on VMS 6 months from now.

VSI is a small company, with a huge amount of work to accomplish. Not sure if
HPE was involved in the Java 8 stuff. Regardless, haven't you been pounding
just a bit too hard on "I want everything, right now, or even yesterday"?
It seems that for some people, no matter what does get released, they might as
well not have bothered. Well, should they have bothered ???????????????

Because it's a very nice stepping stone towards where VMS should be,
but that's all it is: a stepping stone. We now need all the other
stepping stones to be laid down.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Kerry Main

2017-04-07 13:40:35 UTC

-----Original Message-----
Simon Clubley via Info-vax
Sent: April 6, 2017 4:24 PM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity

Post by Simon Clubley
But it can also work the other way if this is still the current

Java

Post by Simon Clubley
8 version on VMS 6 months from now.

VSI is a small company, with a huge amount of work to accomplish.

Not

Post by David Froble
sure if HPE was involved in the Java 8 stuff. Regardless, haven't

you

Post by David Froble
been pounding just a bit too hard on "I want everything, right

now,

or even yesterday"?

Post by David Froble
It seems that for some people, no matter what does get released,

they

Post by David Froble
might as well not have bothered. Well, should they have bothered

???????????????
Because it's a very nice stepping stone towards where VMS should be,
but that's all it is: a stepping stone. We now need all the other

stepping

stones to be laid down.
Simon.

That's what the roadmap does ... lays out the other stepping stones.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

David Froble

2017-04-07 14:35:14 UTC

Post by Simon Clubley
But it can also work the other way if this is still the current Java 8
version on VMS 6 months from now.

VSI is a small company, with a huge amount of work to accomplish. Not sure if
HPE was involved in the Java 8 stuff. Regardless, haven't you been pounding
just a bit too hard on "I want everything, right now, or even yesterday"?
It seems that for some people, no matter what does get released, they might as
well not have bothered. Well, should they have bothered ???????????????

Because it's a very nice stepping stone towards where VMS should be,
but that's all it is: a stepping stone. We now need all the other
stepping stones to be laid down.
Simon.

Rome wasn't built in a day. At least VSI is trying, and I for one am glad they
are doing so. Being a realist, I'm going to congratulate them for what they do,
not hammer them for what they didn't do. YMMV ....

IanD

2017-04-15 00:48:06 UTC

Post by Simon Clubley
But it can also work the other way if this is still the current Java 8
version on VMS 6 months from now.

VSI is a small company, with a huge amount of work to accomplish. Not sure if
HPE was involved in the Java 8 stuff. Regardless, haven't you been pounding
just a bit too hard on "I want everything, right now, or even yesterday"?
It seems that for some people, no matter what does get released, they might as
well not have bothered. Well, should they have bothered ???????????????

Because it's a very nice stepping stone towards where VMS should be,
but that's all it is: a stepping stone. We now need all the other
stepping stones to be laid down.
Simon.

I didn't see his post that way

I saw the point that if you neglect fundamentals like keeping open source software up to date, it negatively impacts on you and your credibility wanes

VMS is not seen as relevant in todays market - that is the harsh reality

To restore VMS to even a state where it can compete in a platform for open source development yet alone deployment, a sh*t load of work is needed and continually needed

The unspoken question that needs to be asked is what tools and frameworks are being put in place to help foster VMS be relevant into the current world, yet alone in 5 years time

What frameworks are being implemented, what is happening to assist VMS builds of open source get out the door quicker?

It not enough to build the odd occasional release of an open source product now and then, it needs to be a fluid happening.

Jenkins grew out of a need in the open source world for people to be able to get quick access to current builds versus roll your own all the time. Repeatable processes is the name of game - where is this for VMS? Everything is still in the roll your own mentality or waiting with cup in hand for VSI (who by your own admission are a small company and cannot do everything)

If they cannot do everything (and they can't and shouldn't) then they need to put in frameworks and/or processes that assist the greater community in getting builds out as fast as possible to keep the platform relevant

Point in question. We heard how the original VMS code cannot be open sourced due to license agreements. What about all the work done with LLVM for VMS? What about the work done for booting? What about the code that was re-written in C or adapted for x86 specific?
Surely not all of this code (that I read was developed from scratch some of it) is tied to HPE licensing? What about this code being released to the wider audience so that VSI can attract a larger audience?

Even the MS devil has open sourced key components, like .net, powershell. It also has opened up it's vidual studio to intergrade with the likes of GitHub and recently announced it was closing it's code repository and acknowledged that GitHub rules them all at present. Linux won, open source has won, VMS needs to get on the bandwagon and incorporate as many of the winning components these two used to gain success or perish (putting it more hard, rise from the dead)

I really don't think anyone was discrediting the great work VSI has put in, it's just some folk realise the greater picture and what's needed to continue moving VMS forward because let's face it, we are many years behind currently

Kerry Main

2017-04-15 01:56:17 UTC

-----Original Message-----
via Info-vax
Sent: April 14, 2017 8:48 PM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity

Post by Simon Clubley
But it can also work the other way if this is still the current Java 8
version on VMS 6 months from now.

VSI is a small company, with a huge amount of work to accomplish.

Not sure if

Post by David Froble
HPE was involved in the Java 8 stuff. Regardless, haven't you

been

pounding

Post by David Froble
just a bit too hard on "I want everything, right now, or even

yesterday"?

Post by David Froble
It seems that for some people, no matter what does get released,

they might as

Post by David Froble
well not have bothered. Well, should they have bothered

???????????????

Post by Simon Clubley
Because it's a very nice stepping stone towards where VMS should

be,

Post by Simon Clubley
but that's all it is: a stepping stone. We now need all the other
stepping stones to be laid down.
Simon.

Rome wasn't built in a day. At least VSI is trying, and I for one

am glad

they

Post by David Froble
are doing so. Being a realist, I'm going to congratulate them for

what

they do,

Post by David Froble
not hammer them for what they didn't do. YMMV ....

Depends on the market, but no one will argue it needs to expand.

To restore VMS to even a state where it can compete in a platform for
open source development yet alone deployment, a sh*t load of work is
needed and continually needed

Agree, but so does VSI as shown in their roadmaps.

The unspoken question that needs to be asked is what tools and
frameworks are being put in place to help foster VMS be relevant into
the current world, yet alone in 5 years time
What frameworks are being implemented, what is happening to assist
VMS builds of open source get out the door quicker?
It not enough to build the odd occasional release of an open source
product now and then, it needs to be a fluid happening.
Jenkins grew out of a need in the open source world for people to be
able to get quick access to current builds versus roll your own all

the

time. Repeatable processes is the name of game - where is this for

VMS?

Everything is still in the roll your own mentality or waiting with cup

hand for VSI (who by your own admission are a small company and
cannot do everything)

Jenkins and OpenVMS:
<https://www.slideshare.net/ecubemarketing/why-nxtware-remote-for-jenkin
s>
"Learn how NXTware Remote brings Continuous Integration and Build
Automation to OpenVMS"

If they cannot do everything (and they can't and shouldn't) then they
need to put in frameworks and/or processes that assist the greater
community in getting builds out as fast as possible to keep the

platform

relevant
Point in question. We heard how the original VMS code cannot be open
sourced due to license agreements. What about all the work done with
LLVM for VMS? What about the work done for booting? What about the
code that was re-written in C or adapted for x86 specific?
Surely not all of this code (that I read was developed from scratch

some

of it) is tied to HPE licensing? What about this code being released

to the

wider audience so that VSI can attract a larger audience?

You assume Open Source would be a good thing.

There are pro's and con's, and this argument has been going on for
decades.

However, many Cust's want one throat to choke when it comes to support
agreements in mission critical environments.

Some Customers do not want their senior IT folks in the mud dealing with
OS level patches and/or troubleshooting. They prefer to leave that low
level activity to vendors and instead have their senior IT folks spend
more time working with business groups helping them adopt new
technologies and application integration that can be used to improve the
companies competitiveness.

At some point in the future, I would like to see a "right sourcing"
model adopted which provides partners the ability to submit certain TBD
code as part of an official VSI release cycle, but that's another
discussion. A good example is the LD driver which is now part of the
official VSI release cycle.

Even the MS devil has open sourced key components, like .net,
powershell. It also has opened up it's vidual studio to intergrade

with the

likes of GitHub and recently announced it was closing it's code

repository

and acknowledged that GitHub rules them all at present. Linux won,
open source has won, VMS needs to get on the bandwagon and
incorporate as many of the winning components these two used to gain
success or perish (putting it more hard, rise from the dead)

Check out the roadmap. Many of these are in the plans, but one needs to
remember that Rome was not built in a day. Check out slide 6 for the
Open Source update.
<http://www.vmssoftware.com/pdfs/VSI_Roadmap_20170306.pdf>

Note - While GitHub's heavily distributed network based model is popular
now, the world is rapidly moving to IT models which re-evaluate what is
better done centralized vs. what is done distributed.

Data Centers are being massively consolidated, new high end storage
solutions (60TB Seagate SSD drives announced, 10TB drives are available
today for less than USD $500), very high speed, ultra low latency
interconnects, NV memory in TB range, centralized hyper-converged
virtualization strategies and much improved security models etc. are all
going to place pressures on the legacy distributed network models.

I really don't think anyone was discrediting the great work VSI has

put in,

it's just some folk realise the greater picture and what's needed to
continue moving VMS forward because let's face it, we are many years
behind currently

You are under estimating VSI.

As the roadmap shows, there is lots to do, but as Clair and others have
stated many times, VSI is a small company who needs to balance keeping
current Cust's happy (revenue coming in), vs. allocating resources on
new features development.

A good example is the recent Alpha support work. It likely has slowed
down and/or impacted the X86-64 work somewhat, but at the same time,
made many Alpha Customers very happy that they are getting the features
and enhancements in V8.4-2L1. That means more support agreement revenue
for VSI in the short term.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Arne Vajhøj

2017-04-15 03:24:18 UTC

Post by IanD
The unspoken question that needs to be asked is what tools and
frameworks are being put in place to help foster VMS be relevant into
the current world, yet alone in 5 years time
What frameworks are being implemented, what is happening to assist
VMS builds of open source get out the door quicker?
It not enough to build the odd occasional release of an open source
product now and then, it needs to be a fluid happening.
Jenkins grew out of a need in the open source world for people to be
able to get quick access to current builds versus roll your own all

the

Post by IanD
time. Repeatable processes is the name of game - where is this for VMS?
Everything is still in the roll your own mentality or waiting with cup in
hand for VSI (who by your own admission are a small company and
cannot do everything)

<https://www.slideshare.net/ecubemarketing/why-nxtware-remote-for-jenkins>
"Learn how NXTware Remote brings Continuous Integration and Build
Automation to OpenVMS"

It is obviously better than nothing.

But an integration product (costly??) to do something that works out
of the box on other platforms (free) is not going to make VMS
competitive.

Post by IanD
Point in question. We heard how the original VMS code cannot be open
sourced due to license agreements. What about all the work done with
LLVM for VMS? What about the work done for booting? What about the
code that was re-written in C or adapted for x86 specific?
Surely not all of this code (that I read was developed from scratch some
of it) is tied to HPE licensing? What about this code being released to the
wider audience so that VSI can attract a larger audience?

The picture you paint of open source approach sounds very mid 90's.

The vast majority of companies do not chose open source because
they want to use the source code.

They chose it because they are less dependent one a single
company and because the builtin competitive state of
support market ensures a reasonable cost for support.

Post by IanD
Even the MS devil has open sourced key components, like .net,
powershell. It also has opened up it's vidual studio to intergrade with the
likes of GitHub and recently announced it was closing it's code repository
and acknowledged that GitHub rules them all at present. Linux won,
open source has won, VMS needs to get on the bandwagon and
incorporate as many of the winning components these two used to gain
success or perish (putting it more hard, rise from the dead)

Note - While GitHub's heavily distributed network based model is popular
now, the world is rapidly moving to IT models which re-evaluate what is
better done centralized vs. what is done distributed.
Data Centers are being massively consolidated, new high end storage
solutions (60TB Seagate SSD drives announced, 10TB drives are available
today for less than USD $500), very high speed, ultra low latency
interconnects, NV memory in TB range, centralized hyper-converged
virtualization strategies and much improved security models etc. are all
going to place pressures on the legacy distributed network models.

????

Github is a distributed VCS. But it is a centralized system, so
centralization really strengthens the move to that type of service.

Arne

Kerry Main

2017-04-15 13:22:32 UTC

-----Original Message-----
Vajhøj via Info-vax
Sent: April 14, 2017 11:24 PM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity
IanD

the

Post by IanD
time. Repeatable processes is the name of game - where is this for

VMS?

Post by IanD
Everything is still in the roll your own mentality or waiting with cup in
hand for VSI (who by your own admission are a small company and
cannot do everything)

<https://www.slideshare.net/ecubemarketing/why-nxtware-remote-

for-jenkins>

Post by Kerry Main
"Learn how NXTware Remote brings Continuous Integration and Build
Automation to OpenVMS"

It is obviously better than nothing.
But an integration product (costly??) to do something that works out
of the box on other platforms (free) is not going to make VMS
competitive.

Post by IanD
Point in question. We heard how the original VMS code cannot be

open

Post by IanD
sourced due to license agreements. What about all the work done

with

Post by IanD
LLVM for VMS? What about the work done for booting? What about

the

Post by IanD
code that was re-written in C or adapted for x86 specific?
Surely not all of this code (that I read was developed from scratch

some

Post by IanD
of it) is tied to HPE licensing? What about this code being

released to

the

Post by IanD
wider audience so that VSI can attract a larger audience?

You assume Open Source would be a good thing.
There are pro's and con's, and this argument has been going on for
decades.
However, many Cust's want one throat to choke when it comes to

support

Post by Kerry Main
agreements in mission critical environments.
Some Customers do not want their senior IT folks in the mud dealing

with

Post by Kerry Main
OS level patches and/or troubleshooting. They prefer to leave that low
level activity to vendors and instead have their senior IT folks spend
more time working with business groups helping them adopt new
technologies and application integration that can be used to improve

the

Post by Kerry Main
companies competitiveness.

The picture you paint of open source approach sounds very mid 90's.
The vast majority of companies do not chose open source because
they want to use the source code.
They chose it because they are less dependent one a single
company and because the builtin competitive state of
support market ensures a reasonable cost for support.

Talk about a 90's view?

Why do so many companies choose Microsoft Windows?

Heck, over the last couple of years, MS has been raising licenses costs
significantly (core based now) and yet while they jump up and down
screaming, there are very few Cust's that will switch from Windows
because of this.

What happens if RH decides to do the same with their RH Linux per OS
monthly support costs?

Do you seriously think Cust's will change from RH support to a 2nd tier
support provider?

Many Cust's are tired of multiple vendor finger pointing when it comes
to solving issues. They want "one throat to choke".

Post by IanD
Even the MS devil has open sourced key components, like .net,
powershell. It also has opened up it's vidual studio to intergrade

with

the

Post by IanD
likes of GitHub and recently announced it was closing it's code

repository

Post by IanD
and acknowledged that GitHub rules them all at present. Linux won,
open source has won, VMS needs to get on the bandwagon and
incorporate as many of the winning components these two used to

gain

Post by IanD
success or perish (putting it more hard, rise from the dead)

Note - While GitHub's heavily distributed network based model is

popular

Post by Kerry Main
now, the world is rapidly moving to IT models which re-evaluate what is
better done centralized vs. what is done distributed.
Data Centers are being massively consolidated, new high end storage
solutions (60TB Seagate SSD drives announced, 10TB drives are

available

Post by Kerry Main
today for less than USD $500), very high speed, ultra low latency
interconnects, NV memory in TB range, centralized hyper-converged
virtualization strategies and much improved security models etc. are all
going to place pressures on the legacy distributed network models.

????
Github is a distributed VCS. But it is a centralized system, so
centralization really strengthens the move to that type of service.
Arne

Moving and coordinating by everyone involved in the dev team massive
amounts of code back and forth over the Internet between the client
desktop/WS and the server is not my idea of a centralized system.
Especially when you are dealing with large images and/or code bases.

Yes, GitHub works today for many environments, but, imho, the already
occurring rapid changes in technology are going to make this heavily
distributed model much less attractive in the future.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-04-15 23:13:31 UTC

Post by Kerry Main
Yes, GitHub works today for many environments, but, imho, the already
occurring rapid changes in technology are going to make this heavily
distributed model much less attractive in the future.

One of a series of postings from folks working on gaming software...

https://engineering.riotgames.com/news/running-online-services-riot-part-iii-part-deux

Some folks certainly have apps that aren't suited for distribution or
that don't (yet?) beed to, but other apps used by those same folks and
by others can be using those same services.

I don't see any reasonable path relinquishing what DVCS packages
provide, short of geographic and network colocation of developers
and/or adding dependencies on always-active network links and always-up
servers, either. Even in a development small shop, using a DVCS is
really handy — just as soon as there's more than a couple of developers
and more than a couple of development systems involved, bespoke code
shoveling source code around increasingly approaches the task of
rolling your own DVCS.

--
Pure Personal Opinion | HoffmanLabs LLC

Kerry Main

2017-04-16 01:00:19 UTC

-----Original Message-----
Stephen Hoffman via Info-vax
Sent: April 15, 2017 7:14 PM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity

Post by Kerry Main
Yes, GitHub works today for many environments, but, imho, the

already

Post by Kerry Main
occurring rapid changes in technology are going to make this heavily
distributed model much less attractive in the future.

One of a series of postings from folks working on gaming software...
https://engineering.riotgames.com/news/running-online-services-riot-
part-iii-part-deux
Some folks certainly have apps that aren't suited for distribution or
that don't (yet?) beed to, but other apps used by those same folks and
by others can be using those same services.
I don't see any reasonable path relinquishing what DVCS packages
provide, short of geographic and network colocation of developers
and/or adding dependencies on always-active network links and always-
up
servers, either. Even in a development small shop, using a DVCS is
really handy — just as soon as there's more than a couple of developers
and more than a couple of development systems involved, bespoke code
shoveling source code around increasingly approaches the task of
rolling your own DVCS.

All to often the big reason why some teams use a DVCS is "we can continue working if the central server is down".

The issue in the past was that Dev environments were not treated as critical Production systems, so a DVCS made sense because the single central server could be down for any number of reasons.

They do not typically consider a centralized VCS solution which is actually a multi-site cluster with multiple servers in each site that can be added transparently to the cluster as the builds and/or numbers of developers increase. This multi-site cluster looks like a single system to the dev community i.e. an active-active tightly coupled cluster whereby developers are directed to the least busy system in the multi-site cluster.

As the code base gets very large, maintaining history on the client becomes a big challenge as well. As does working with code that has lots of large graphic images.

Again - pro's and con's, but in a secure environment, I just do not think having all (or most) of the code on every developers workstation to be the right strategy for the future.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Paul Sture

2017-04-17 11:33:43 UTC

Post by Kerry Main
All to often the big reason why some teams use a DVCS is "we can
continue working if the central server is down".

Don't underestimate the ability to work offline. The shift to working
with mobile devices brings connectivity considerations to the fore.

Post by Kerry Main
The issue in the past was that Dev environments were not treated as
critical Production systems, so a DVCS made sense because the single
central server could be down for any number of reasons.

There's a fair bit of truth in that. Most development systems I worked
on were on straight office hours support contracts rather than the
substantially more expensive cover taken out on production systems.

I'm also surely not the only one who back in the day had the idea of
"stealing" development systems for production use as part of an
contingency plan should the production systems go pear shaped.

<snip>

Post by Kerry Main
Again - pro's and con's, but in a secure environment, I just do not
think having all (or most) of the code on every developers workstation
to be the right strategy for the future.

Define "secure environment" in an open source context.

--
The First of April: The only day of the year that people critically
evaluate news stories before believing them.

Kerry Main

2017-04-17 12:30:38 UTC

-----Original Message-----
Sture via Info-vax
Sent: April 17, 2017 7:34 AM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity

Post by Kerry Main
All to often the big reason why some teams use a DVCS is "we can
continue working if the central server is down".

Don't underestimate the ability to work offline. The shift to working
with mobile devices brings connectivity considerations to the fore.

With developers around the globe, increasing pressures to get new
services in place, imho, one has to look at Dev systems as simply being
an extension of critical production systems.

When you think about it, if you have a multi-site cluster infrastructure
for production, other than perhaps being a bit smaller from a number of
systems perspective, how much more difficult would it be to introduce a
second, but separate multi-site cluster focussed on Dev/staging? It
would also provide a more realistic Dev environment i.e. dev/test on a
single system vs. dev/test on a multi-site Dev cluster.

I'm also surely not the only one who back in the day had the idea of
"stealing" development systems for production use as part of an
contingency plan should the production systems go pear shaped.

Agree - that is very common DR strategy for what I would refer to a
legacy IT thinking. When planning DR, one should always assume that the
primary DC may not only be disabled for a short period, but gone -
period.

Hence, one should ensure that the DR plan deal with this. Can you deal
with Dev being offline for months while additional servers, storage,
networking etc. are requested, purchased, commissioned, restored
(assuming OPS had the foresight to ensure Dev backups also went
offsite)? Can the Prod loads actually even be run on the limited number
of Dev servers? A common mistake is to not take into account things like
loads, latency etc. with Dev vs Prod server locations.

<snip>

Post by Kerry Main
Again - pro's and con's, but in a secure environment, I just do not
think having all (or most) of the code on every developers

workstation

Post by Kerry Main
to be the right strategy for the future.

Define "secure environment" in an open source context.

While open source may be a small component of the overall company code,
I refer to secure environment as the overall internal custom/embedded
open source code.

Imho, there is no bigger security risk than your Dev environment being
hacked or code examined by hackers because it is not only a loss of
critical IP, but also once deployed, the vulnerability is buried deep
into production.

While open source has its pro's and con's, there is the very real danger
where hackers can review and analyze the code, discover weaknesses and
then exploit it.

As what happened with blockchain last year:
<http://fortune.com/2016/06/18/blockchain-vc-fund-hacked/>
Quote from hacker "I have carefully examined the code of The DAO and
decided to participate after finding the feature where splitting is
rewarded with additional ether. I have made use of this feature and have
rightfully claimed 3,641,694 ether, and would like to thank the DAO for
this reward."

Imho, there are better ways to secure your code than the traditional
binary decision of 1. making it all public or 2. relying only on
internal resources.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-04-17 15:04:39 UTC

Post by Kerry Main
With developers around the globe, increasing pressures to get new
services in place, imho, one has to look at Dev systems as simply being
an extension of critical production systems.
When you think about it, if you have a multi-site cluster
infrastructure for production, other than perhaps being a bit smaller
from a number of systems perspective, how much more difficult would it
be to introduce a second, but separate multi-site cluster focussed on
Dev/staging? It would also provide a more realistic Dev environment
i.e. dev/test on a single system vs. dev/test on a multi-site Dev
cluster.

Compared with what a DVCS brings, that environment — I'm *very*
familiar with source code control in that sort of an environment — was
a {long string of expletives} to develop source code in, too.
Also massively expensive for little or no benefit, and with much more
work to maintain and extend and replicate the tooling, too.
Because there's more to what a DVCS provides than what can be
replicated with (expensive) brute-force server and network uptime.
Call me back when VSI has a proprietary competitor to Hg, git or fossil
or suchlike, with equivalent and variously better features, too.

--
Pure Personal Opinion | HoffmanLabs LLC

Kerry Main

2017-04-17 13:17:29 UTC

-----Original Message-----
Sture via Info-vax
Sent: April 17, 2017 7:34 AM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity

Post by Kerry Main
All to often the big reason why some teams use a DVCS is "we can
continue working if the central server is down".

Don't underestimate the ability to work offline. The shift to working
with mobile devices brings connectivity considerations to the fore.

Btw, another advantage of a properly config'ed clustered Dev or even
Prod solution is that the loss of a single system HW makes it possible
to adopt less expensive, mote flexible support contracts because the
loss of a single system is not as critical. This logic assumes that the
cluster is configured such that the loss of a single system does not
hamper the clusters ability to handle peak loads.

Rather than a 24x7 critical contract for critical systems, perhaps a
16x7 contract might be more cost effective? Over 3+ years of a typical
support contract, this could be a significant cost savings.

[snip]

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-04-17 14:42:19 UTC

Post by Kerry Main
All to often the big reason why some teams use a DVCS is "we can
continue working if the central server is down".

That's one of the reasons. So too can be the network. So too can
the ability to operate offline, and remotely. So too can be the
ability to check in in-progress development work locally, then push the
whole change to the repository once the development and testing work is
completed. The ability to reset the local environment and effectively
start over again is really handy for experimenting, too.

Just as soon as there are multiple developers active in a project, DVCS
packages are increasingly useful and desirable — even if the production
servers and the networks are up.

Post by Kerry Main
They do not typically consider a centralized VCS solution which is
actually a multi-site cluster with multiple servers in each site that
can be added transparently to the cluster as the builds and/or numbers
of developers increase. This multi-site cluster looks like a single
system to the dev community i.e. an active-active tightly coupled
cluster whereby developers are directed to the least busy system in the
multi-site cluster.

Sure, if you want to throw a ton of resources at a non-problem.

Post by Kerry Main
As the code base gets very large, maintaining history on the client
becomes a big challenge as well. As does working with code that has
lots of large graphic images.

That's not how a DVCS works.

You're going to have a fun time selling that approach to any
experienced developers that might be involved, though. Logging into a
central server to manually check in and check out and transfer source
code is an error-prone slog. Which means your whole approach with
highly reliable central servers and highly reliable networks and
always-online developers — all of which tend to be expensive, too —
doesn't address one of the nicer features that a typical DVCS provides
out of the box. I've worked at sites with substantial
locally-designed and maintained and built-up tooling that replicates
available packages. Variously incompletely, and sometimes badly.
Tooling which burns through budget, and uses staff time that could be
spent elsewhere. For staff and servers are increasingly geographically
distributed. Not knowing and using the appropriate tools is an
increasingly expensive mistake,

--
Pure Personal Opinion | HoffmanLabs LLC

Craig A. Berry

2017-04-18 00:06:07 UTC

Post by Kerry Main
All to often the big reason why some teams use a DVCS is "we can
continue working if the central server is down".

That's one of the reasons. So too can be the network. So too can the
ability to operate offline, and remotely. So too can be the ability to
check in in-progress development work locally, then push the whole
change to the repository once the development and testing work is
completed. The ability to reset the local environment and effectively
start over again is really handy for experimenting, too.

Just as soon as there are multiple developers active in a project, DVCS
packages are increasingly useful and desirable — even if the production
servers and the networks are up.

Sure, if you want to throw a ton of resources at a non-problem.

Post by Kerry Main
As the code base gets very large, maintaining history on the client
becomes a big challenge as well. As does working with code that has
lots of large graphic images.

That's not how a DVCS works.

You're going to have a fun time selling that approach to any experienced
developers that might be involved, though. Logging into a central
server to manually check in and check out and transfer source code is an
error-prone slog. Which means your whole approach with highly reliable
central servers and highly reliable networks and always-online
developers — all of which tend to be expensive, too — doesn't address
one of the nicer features that a typical DVCS provides out of the box.
I've worked at sites with substantial locally-designed and maintained
and built-up tooling that replicates available packages. Variously
incompletely, and sometimes badly. Tooling which burns through budget,
and uses staff time that could be spent elsewhere. For staff and
servers are increasingly geographically distributed. Not knowing and
using the appropriate tools is an increasingly expensive mistake,

There are some challenges with extremely large DVCS repositories, but
most people don't have those situations. The people that do are not
about to give up using DVCSs. Microsoft now hosts the Windows source
code in a 300GB git repository, but they invented a custom file system
to make it possible:

<https://arstechnica.com/information-technology/2017/02/microsoft-hosts-the-windows-source-in-a-monstrous-300gb-git-repository/>

Facebook scaled up differently by customizing Mercurial:

<https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/>

But their solution assumes a fast local network rather than operating
over the internet.

So people with unlimited resources and way too much code to manage are
not going back to centralized code repositories. Quite the opposite:
they will go to extreme lengths such as building a virtual file system
in order to hang onto the DVCS features they consider essential.

Arne Vajhøj

2017-04-18 01:24:47 UTC

Post by Craig A. Berry
There are some challenges with extremely large DVCS repositories, but
most people don't have those situations. The people that do are not
about to give up using DVCSs. Microsoft now hosts the Windows source
code in a 300GB git repository, but they invented a custom file system
<https://arstechnica.com/information-technology/2017/02/microsoft-hosts-the-windows-source-in-a-monstrous-300gb-git-repository/>
<https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/>
But their solution assumes a fast local network rather than operating
over the internet.
So people with unlimited resources and way too much code to manage are
they will go to extreme lengths such as building a virtual file system
in order to hang onto the DVCS features they consider essential.

Most companies work with some open source today.

DVCS's like Git are really great at handling that.

Arne

Bob Koehler

2017-04-18 13:27:08 UTC

An interesting appraoch, since Linus considers git to be a file
system, not a CM system.

Arne Vajhøj

2017-04-18 01:22:39 UTC

-----Original Message----- From: Info-vax
I don't see any reasonable path relinquishing what DVCS packages
provide, short of geographic and network colocation of developers
and/or adding dependencies on always-active network links and
always- up servers, either. Even in a development small shop,
using a DVCS is really handy — just as soon as there's more than a
couple of developers and more than a couple of development systems
involved, bespoke code shoveling source code around increasingly
approaches the task of rolling your own DVCS.

All to often the big reason why some teams use a DVCS is "we can
continue working if the central server is down".

I would hope not.

As a 1:1 replacement of SVN with Git provides almost no additional
availability.

SVN down Git down
CI (build and test) runs no no
code being backed up no no
developers can work yes yes
developers can label change sets no yes

Post by Kerry Main
Again - pro's and con's, but in a secure environment, I just do not
think having all (or most) of the code on every developers
workstation to be the right strategy for the future.

True.

But there is no difference between a VCS and DVCS in that regard.

Arne

Arne Vajhøj

2017-04-18 01:16:21 UTC

-----Original Message-----
Vajhøj via Info-vax

Post by Kerry Main
Some Customers do not want their senior IT folks in the mud dealing with
OS level patches and/or troubleshooting. They prefer to leave that low
level activity to vendors and instead have their senior IT folks spend
more time working with business groups helping them adopt new
technologies and application integration that can be used to improve the
companies competitiveness.

The picture you paint of open source approach sounds very mid 90's.
The vast majority of companies do not chose open source because
they want to use the source code.
They chose it because they are less dependent one a single
company and because the builtin competitive state of
support market ensures a reasonable cost for support.

Lots if customers has switched from Windows to Linux for servers.

Not so much for desktop. But there is probably reasons for that.

Post by Kerry Main
What happens if RH decides to do the same with their RH Linux per OS
monthly support costs?
Do you seriously think Cust's will change from RH support to a 2nd tier
support provider?

Absolutely.

If RH does not provide value for money, then customers would
switch to something else.

If not then RH would increase the price!

Very basic economics.

Post by Kerry Main
Data Centers are being massively consolidated, new high end storage
solutions (60TB Seagate SSD drives announced, 10TB drives are available
today for less than USD $500), very high speed, ultra low latency
interconnects, NV memory in TB range, centralized hyper-converged
virtualization strategies and much improved security models etc. are all
going to place pressures on the legacy distributed network models.

????
Github is a distributed VCS. But it is a centralized system, so
centralization really strengthens the move to that type of service.

It is an observable fact that it works.

Nope. Distributed models will become even more attractive.

More and more stuff will move to true centralized systems.

Arne

John E. Malmberg

2017-04-15 19:38:08 UTC

the

<https://www.slideshare.net/ecubemarketing/why-nxtware-remote-for-jenkins>
"Learn how NXTware Remote brings Continuous Integration and Build
Automation to OpenVMS"

It is obviously better than nothing.
But an integration product (costly??) to do something that works out
of the box on other platforms (free) is not going to make VMS
competitive.

Jenkins Costly? Hard to learn?

https://sourceforge.net/p/vms-ports/wiki/UsingJenkinsCi/

Yes, no native port of Jenkins to VMS yet, but a Linux Jenkins can
manage VMS builds back to at least VAX/VMS 7.3.

Screenshots at:

https://sourceforge.net/projects/gnv/

For all the updated GNV projects, a build is kicked off with in 24 hours
of a commit to that GNV repository.

For GNU Awk, a build is run with in 24 hours of a commit to the stable
v4.x branch.

Regards,
-John

Arne Vajhøj

2017-04-16 00:51:35 UTC

Post by John E. Malmberg

Post by Kerry Main
"Learn how NXTware Remote brings Continuous Integration and Build
Automation to OpenVMS"

It is obviously better than nothing.
But an integration product (costly??) to do something that works out
of the box on other platforms (free) is not going to make VMS
competitive.

Jenkins Costly?

No. Jenkins is free. The NXT think that Kerry linked to, which
I suspect is commercial.

Post by John E. Malmberg
Yes, no native port of Jenkins to VMS yet, but a Linux Jenkins can
manage VMS builds back to at least VAX/VMS 7.3.

Again - it works.

But for VMS to be a first class citizen, then Jenkins
(and bunch of other stuff) need to be able to run on VMS.

Arne

2017-04-17 09:48:50 UTC

Post by Arne VajhÃ¸j
But for VMS to be a first class citizen, then Jenkins
(and bunch of other stuff) need to be able to run on VMS.

Dunno much about Jenkins, but with Java 8 being available for VMS,
shouldn't it be as easy as ...

$ wget
http://mirror.yannic-bonenberger.com/apache/tomcat/tomcat-8/v8.0.43/bin/apache-tomcat-8.0.43.tar.gz
...
$ gunzip -d apache-tomcat-8.0.43.tar.gz
$ tar -xf apache-tomcat-8.0.43.tar
$ set def [.apache-tomcat-8^.0^.43]

Get to https://wiki.apache.org/tomcat/TomcatOnOpenVMS and extract the
command files catalina.com, startup.com, shutdown.com, version.com and
java$config_setup.com (or your own one) into the bin subdirectory.
Adjust catalina.com and version.com for Java 8: essentially change
java$60_setup to java$80_setup.

$ @[.bin]version
Server version: Apache Tomcat/8.0.43
Server built: Mar 28 2017 14:42:59 UTC
Server number: 8.0.43.0
OS Name: OpenVMS
OS Version: V8.4
Architecture: ia64
JVM Version: 1.8.0.03-vms-rc1
JVM Vendor: Hewlett-Packard Enterprise
$

$ @[.bin]startup
%DCL-S-SPAWNED, process USER_32393 spawned
$
17-Apr-2017 11:04:45.382 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server version:
Apache Tomcat/8.0.43
...

$ wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war
...
$ rena jenkins.war [.webapps]
$
...
17-Apr-2017 11:30:58.276 INFO [localhost-startStop-2]
org.apache.catalina.startup.HostConfig.deployWAR Deploying web application a
rchive /disk$user/user/jenkins/apache-tomcat-8.0.43/webapps/jenkins.war
...

Now try http://your-node:8080/jenkins
and jenkins asks you to

Unlock Jenkins

To ensure Jenkins is securely set up by the administrator, a password
has been written to the log (not sure where to find it?) and this file
on the server:
...

John E. Malmberg

2017-04-17 13:29:19 UTC

Post by hb

Post by Arne VajhÃ¸j
But for VMS to be a first class citizen, then Jenkins
(and bunch of other stuff) need to be able to run on VMS.

I would like that. However, I wanted to use the tool and did not want
to take the time to figure out why it just did not work out of the box
on VMS.

Post by hb
Dunno much about Jenkins, but with Java 8 being available for VMS,
shouldn't it be as easy as ...
$ wget
http://mirror.yannic-bonenberger.com/apache/tomcat/tomcat-8/v8.0.43/bin/apache-tomcat-8.0.43.tar.gz
...
$ gunzip -d apache-tomcat-8.0.43.tar.gz
$ tar -xf apache-tomcat-8.0.43.tar
$ set def [.apache-tomcat-8^.0^.43]
Get to https://wiki.apache.org/tomcat/TomcatOnOpenVMS and extract the
command files catalina.com, startup.com, shutdown.com, version.com and
java$config_setup.com (or your own one) into the bin subdirectory.
Adjust catalina.com and version.com for Java 8: essentially change
java$60_setup to java$80_setup.
Server version: Apache Tomcat/8.0.43
Server built: Mar 28 2017 14:42:59 UTC
Server number: 8.0.43.0
OS Name: OpenVMS
OS Version: V8.4
Architecture: ia64
JVM Version: 1.8.0.03-vms-rc1
JVM Vendor: Hewlett-Packard Enterprise
$
%DCL-S-SPAWNED, process USER_32393 spawned
$
17-Apr-2017 11:04:45.382 INFO [main]
Apache Tomcat/8.0.43
...
$ wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war
...
$ rena jenkins.war [.webapps]
$
...
17-Apr-2017 11:30:58.276 INFO [localhost-startStop-2]
org.apache.catalina.startup.HostConfig.deployWAR Deploying web application a
rchive /disk$user/user/jenkins/apache-tomcat-8.0.43/webapps/jenkins.war
...
Now try http://your-node:8080/jenkins
and jenkins asks you to
Unlock Jenkins
To ensure Jenkins is securely set up by the administrator, a password
has been written to the log (not sure where to find it?) and this file
...

Where you able to connect to http://your-node:8080/jenkins?

When I tried with the older Java, I got no response, and nothing in any
of the logs that I looked at.

Regards,
-John
***@qsl.net_work

2017-04-17 14:16:26 UTC

Post by John E. Malmberg

Post by hb
Now try http://your-node:8080/jenkins
and jenkins asks you to
Unlock Jenkins
To ensure Jenkins is securely set up by the administrator, a password
has been written to the log (not sure where to find it?) and this file
...

Where you able to connect to http://your-node:8080/jenkins?

Yes. The "Unlock Jenkins..." output was a cut and paste from the browser.

Post by John E. Malmberg
When I tried with the older Java, I got no response, and nothing in any
of the logs that I looked at.

As far as I understood, Jenkins requires Java 8 (or later) and Tomcat 8
(or later), which in turn requires Java 7 (or later).

Jan-Erik Soderholm

2017-04-15 09:27:56 UTC

Post by Kerry Main
A good example is the recent Alpha support work. It likely has slowed
down and/or impacted the X86-64 work somewhat, but at the same time,
made many Alpha Customers very happy that they are getting the features
and enhancements in V8.4-2L1.

I couldn't care less about 2L1. For us it is *the* way to get our
8.2 systems a bit more up-to-date.

Now, we have got the quotes. But there are still some open questions
and VSI are not *that* quick to answer. Such as that the datasheet for
the "VSI Alpha" version refers to a "Detailed Layered Products" list
that is not on their web site and I have asked for it several times
directly from VSI, but nothing.

I also have business friend that is very interested in beeing a
reseller for the VSI Alpha support and licenes. He also struggles to
get any replies on the questions he sends to VSI. He has 2-3 potential
customers for the Alpha offer, but there are some unclear points that
needs answers from VSI before he can approach them seriously.

Post by Kerry Main
That means more support agreement revenue for VSI in the short term.

Maybe, but then VSI might need to show a little more interest.

Finaly, and to be fair, I'm also waiting for the end-user (my own
customer) to decide on the offer from VSI. In that specific case,
I can cover for any lack of information from VSI.

As I see it, VSI is a little behind when it comes to administration,
admin of the web site and similar "dull" things. I understand the focus
on the technical issues they are working with, but if they do not keep
the boring things working also, there is a risk that there is not much
use of the technical things later...

Craig A. Berry

2017-04-15 13:09:45 UTC

Post by Jan-Erik Soderholm
I also have business friend that is very interested in beeing a
reseller for the VSI Alpha support and licenes.

They said from the outset that there would be only two ways to get VSI
software: either buy a new Integrity system from HP or get it directly
from VSI. That was before the Alpha release but I think if something
changed for Alpha they would have said so.

Post by Jan-Erik Soderholm
struggles to get any replies on the questions he sends to VSI.

Yeah, they seem a bit overwhelmed lately. Hopefully that will even out
as the flood of people scrambling to get Alpha support settles down, but
regardless, what alternative is there?

Jan-Erik Soderholm

2017-04-15 16:37:48 UTC

Post by Jan-Erik Soderholm
I also have business friend that is very interested in beeing a
reseller for the VSI Alpha support and licenes.

I don't think "buy a new" is that relevant for Alpha.

Post by Jan-Erik Soderholm
struggles to get any replies on the questions he sends to VSI.

Yeah, they seem a bit overwhelmed lately. Hopefully that will even out
as the flood of people scrambling to get Alpha support settles down, but
regardless, what alternative is there?

Craig A. Berry

2017-04-15 19:02:11 UTC

Post by Jan-Erik Soderholm
I also have business friend that is very interested in beeing a
reseller for the VSI Alpha support and licenes.

They said from the outset that there would be only two ways to get
VSI software: either buy a new Integrity system from HP or get it
directly from VSI. That was before the Alpha release but I think if
something changed for Alpha they would have said so.

I don't think "buy a new" is that relevant for Alpha.

It's relevant if selling it themselves and letting HP sell it are the
only things they are allowed to do under their license agreement with
HP. Just because HP won't sell you a new Alpha with VSI software on it
doesn't mean VSI can let other people sell their software. I don't know
for certain they can't but that was my impression.

Jan-Erik Soderholm

2017-04-15 20:24:23 UTC

Post by Jan-Erik Soderholm
I also have business friend that is very interested in beeing a
reseller for the VSI Alpha support and licenes.

They said from the outset that there would be only two ways to get
VSI software: either buy a new Integrity system from HP or get it
directly from VSI. That was before the Alpha release but I think if
something changed for Alpha they would have said so.

I don't think "buy a new" is that relevant for Alpha.

I don't understand what your point is. I have got quotes on "VSI Alpha"
licenses and why would I expect that VSI is not allowed to issue those
quotes?

Or, are you talking about that VSI would not use "resellers"?
But that is fully up to VSI to decide on, not? Does HPE have
anything to do with that? Yes, I see now by looking at the
actual part you quoted from me above. Well, I cannot go into
details, but let me just say that you don't have to worry.

It is still VSI who sells the licenses, it i just someone else
who do the actual "selling"to the end-customer. So I guess I'm
back to not understanding your point... :-)

c***@gmail.com

2017-04-17 20:01:56 UTC

Post by Jan-Erik Soderholm
I also have business friend that is very interested in beeing a
reseller for the VSI Alpha support and licenes.

They said from the outset that there would be only two ways to get
VSI software: either buy a new Integrity system from HP or get it
directly from VSI. That was before the Alpha release but I think if
something changed for Alpha they would have said so.

I don't think "buy a new" is that relevant for Alpha.

VSI currently has half a dozen resellers.

BTW: So far, HP has chosen not to sell our Alpha release, but that could change at any time.

Dirk Munk

2017-04-15 13:26:50 UTC

I couldn't care less about 2L1. For us it is *the* way to get our
8.2 systems a bit more up-to-date.
Now, we have got the quotes. But there are still some open questions
and VSI are not *that* quick to answer. Such as that the datasheet for
the "VSI Alpha" version refers to a "Detailed Layered Products" list
that is not on their web site and I have asked for it several times
directly from VSI, but nothing.
I also have business friend that is very interested in beeing a
reseller for the VSI Alpha support and licenes. He also struggles to
get any replies on the questions he sends to VSI. He has 2-3 potential
customers for the Alpha offer, but there are some unclear points that
needs answers from VSI before he can approach them seriously.

Post by Kerry Main
That means more support agreement revenue for VSI in the short term.

Maybe, but then VSI might need to show a little more interest.
Finaly, and to be fair, I'm also waiting for the end-user (my own
customer) to decide on the offer from VSI. In that specific case,
I can cover for any lack of information from VSI.
As I see it, VSI is a little behind when it comes to administration,
admin of the web site and similar "dull" things. I understand the focus
on the technical issues they are working with, but if they do not keep
the boring things working also, there is a risk that there is not much
use of the technical things later.

VSI is a rather small company of course (we all hope it will grow). So
how will they give support in Europe? On-site support may be a bit
difficult, support by phone from the US is possible, but the different
time zones are not helping.

Robert A. Brooks

2017-04-15 13:33:20 UTC

VSI is a rather small company of course (we all hope it will grow). So how will
they give support in Europe? On-site support may be a bit difficult, support by
phone from the US is possible, but the different time zones are not helping.

We've just (this week) added a support person in France.

Homi Faris, ex-DEC/CPQ/HP, is now on our team.

--
-- Rob

Jan-Erik Soderholm

2017-04-15 16:37:10 UTC

I couldn't care less about 2L1. For us it is *the* way to get our
8.2 systems a bit more up-to-date.
Now, we have got the quotes. But there are still some open questions
and VSI are not *that* quick to answer. Such as that the datasheet for
the "VSI Alpha" version refers to a "Detailed Layered Products" list
that is not on their web site and I have asked for it several times
directly from VSI, but nothing.
I also have business friend that is very interested in beeing a
reseller for the VSI Alpha support and licenes. He also struggles to
get any replies on the questions he sends to VSI. He has 2-3 potential
customers for the Alpha offer, but there are some unclear points that
needs answers from VSI before he can approach them seriously.

Post by Kerry Main
That means more support agreement revenue for VSI in the short term.

Maybe, but then VSI might need to show a little more interest.
Finaly, and to be fair, I'm also waiting for the end-user (my own
customer) to decide on the offer from VSI. In that specific case,
I can cover for any lack of information from VSI.
As I see it, VSI is a little behind when it comes to administration,
admin of the web site and similar "dull" things. I understand the focus
on the technical issues they are working with, but if they do not keep
the boring things working also, there is a risk that there is not much
use of the technical things later.

VSI is a rather small company of course (we all hope it will grow). So how
will they give support in Europe? On-site support may be a bit difficult,
support by phone from the US is possible, but the different time zones are
not helping.

I don't think I care much for the support as such. I want a licensed
version of VMS that we can run. And besides, there is a VSI office
in Sweden, FWIW...

Arne Vajhøj

2017-04-15 17:42:41 UTC

Post by Jan-Erik Soderholm
As I see it, VSI is a little behind when it comes to administration,
admin of the web site and similar "dull" things. I understand the focus
on the technical issues they are working with, but if they do not keep
the boring things working also, there is a risk that there is not much
use of the technical things later...

I think that is what can happen with a small company.

Hopefully they will catch up.

Arne

c***@gmail.com

2017-04-17 19:56:35 UTC

I think that is what can happen with a small company.
Hopefully they will catch up.
Arne

"A little behind"? Very diplomatic. Thank you. How about pathetic? That might be a little closer to reality. However, given our very limited resources, I'll take looking ugly and watching our revenues continue to grow any day.

Dirk Munk

2017-04-17 20:50:40 UTC

I think that is what can happen with a small company.
Hopefully they will catch up.
Arne

Perhaps you should hire a few extra people to catch up with the
administrations etc.? Wouldn't surprise if if it pays for itself in
increased revenue. Just a thought.....

c***@gmail.com

2017-04-18 00:22:56 UTC

Post by Dirk Munk

I think that is what can happen with a small company.
Hopefully they will catch up.
Arne

Perhaps you should hire a few extra people to catch up with the
administrations etc.? Wouldn't surprise if if it pays for itself in
increased revenue. Just a thought.....

Wouldn't surprise me at all. We have to weigh that sort of thing every day.

David Froble

2017-04-18 00:42:05 UTC

Post by Dirk Munk

I think that is what can happen with a small company.
Hopefully they will catch up.
Arne

"A little behind"? Very diplomatic. Thank you. How about pathetic?
That might be a little closer to reality. However, given our very
limited resources, I'll take looking ugly and watching our revenues
continue to grow any day.

Perhaps you should hire a few extra people to catch up with the
administrations etc.? Wouldn't surprise if if it pays for itself in
increased revenue. Just a thought.....

There are times when you cannot just "throw people" at a problem. In the short
term you can actually fall further behind, because they would need to be
trained. Sometimes you just got to muddle through ....

Dirk Munk

2017-04-18 07:37:50 UTC

Post by Dirk Munk

I think that is what can happen with a small company.
Hopefully they will catch up.
Arne

"A little behind"? Very diplomatic. Thank you. How about pathetic?
That might be a little closer to reality. However, given our very
limited resources, I'll take looking ugly and watching our revenues
continue to grow any day.

Perhaps you should hire a few extra people to catch up with the
administrations etc.? Wouldn't surprise if if it pays for itself in
increased revenue. Just a thought.....

There are times when you cannot just "throw people" at a problem. In
the short term you can actually fall further behind, because they
would need to be trained. Sometimes you just got to muddle through ....

In principle you are right David. However these people don't have to be
highly skilled VMS software engineers. They have to be able to write
proper documentation and proper websites. Affinity with and some
knowledge of VMS would be nice of course, but any one who is interested
in learning VMS (for instance by reading existing documentation, SPDs
etc.) and knows how to do this kind of job is fine as well.

Don't underestimate the importance of proper documentation and websites.
These are the kind of things that may highly influence people how to
look at a company. In the past VMS documentation was excellent,
certainly when you compare it with other OSses. That is what people
expect from VSI as well !

David Froble

2017-04-18 00:39:45 UTC

I think that is what can happen with a small company.
Hopefully they will catch up.
Arne

The "true believers" will wait for you, but, hurry it up, huh?

:-)

Kerry Main

2017-04-15 13:50:04 UTC

-----Original Message-----
via Info-vax
Sent: April 14, 2017 8:48 PM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity

[snip..]

Jenkins grew out of a need in the open source world for people to be
able to get quick access to current builds versus roll your own all

the

time. Repeatable processes is the name of game - where is this for

VMS?

Everything is still in the roll your own mentality or waiting with cup

hand for VSI (who by your own admission are a small company and
cannot do everything)
If they cannot do everything (and they can't and shouldn't) then they
need to put in frameworks and/or processes that assist the greater
community in getting builds out as fast as possible to keep the

platform

relevant

[snip]

Are you looking for free or willing to spend $'s on a good commercial
offering based on industry Eclipse based framework?

Reference testimonial:

Advanced editor:

And deck which shows how to integrate CMS, Jenkins and OpenVMS:
<https://www.slideshare.net/ecubemarketing/continuous-integration-for-op
envms-with-jenkins>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Bob Koehler

2017-04-17 12:54:17 UTC

I saw the point that if you neglect fundamentals like keeping open source s=
oftware up to date, it negatively impacts on you and your credibility wanes

And if you're working with systems that don't include any open source
software?

Arne Vajhøj

2017-04-18 00:41:37 UTC

Post by Bob Koehler

I saw the point that if you neglect fundamentals like keeping open source s=
oftware up to date, it negatively impacts on you and your credibility wanes

And if you're working with systems that don't include any open source
software?

Then that aspect is of course irrelevant.

But the vast majority of systems today use some open source.

Arne

David Froble

2017-04-18 00:44:58 UTC

Post by Bob Koehler

I saw the point that if you neglect fundamentals like keeping open source s=
oftware up to date, it negatively impacts on you and your credibility wanes

And if you're working with systems that don't include any open source
software?

Oh, now you've done it! As if a dagger right thru Ian's heart! How dare you
tarnish the alter of open source?

:-)

On the other hand, not sure how to characterize SSL, but, I'm another that
doesn't use open source ....

:-)

Arne Vajhøj

2017-04-18 01:06:42 UTC

Post by David Froble
On the other hand, not sure how to characterize SSL, but, I'm another
that doesn't use open source ....
:-)

SSL (used in the broad sense to cover all versions of SSL and TLS) is a
protocol. But OpenSSL is open source.

I would be very surprised if the TCP/IP stack does
not contain some open source for various utilities.

LLVM to be used by future compilers is open source.

X11 is open source.

Arne

David Froble

2017-04-18 03:17:04 UTC

Post by David Froble
On the other hand, not sure how to characterize SSL, but, I'm another
that doesn't use open source ....
:-)

SSL (used in the broad sense to cover all versions of SSL and TLS) is a
protocol. But OpenSSL is open source.
I would be very surprised if the TCP/IP stack does
not contain some open source for various utilities.
LLVM to be used by future compilers is open source.
X11 is open source.
Arne

Well, some things to consider. If VSI takes a product and uses it, even
distributes it with VMS, then they are assuming the responsibility for updates
and such. And then, from up thread, yes, it's important to keep up to date.

It's another thing for individual sites to use open source.

Arne Vajhøj

2017-04-19 00:45:57 UTC

Post by David Froble
On the other hand, not sure how to characterize SSL, but, I'm another
that doesn't use open source ....
:-)

SSL (used in the broad sense to cover all versions of SSL and TLS) is a
protocol. But OpenSSL is open source.
I would be very surprised if the TCP/IP stack does
not contain some open source for various utilities.
LLVM to be used by future compilers is open source.
X11 is open source.

Well, some things to consider. If VSI takes a product and uses it, even
distributes it with VMS, then they are assuming the responsibility for
updates and such. And then, from up thread, yes, it's important to keep
up to date.

Yes.

One reason why it may be better to let the open source project add VMS
support and distribute.

Arne

Bob Koehler

2017-04-18 13:31:20 UTC

Post by Bob Koehler

I saw the point that if you neglect fundamentals like keeping open source s=
oftware up to date, it negatively impacts on you and your credibility wanes

And if you're working with systems that don't include any open source
software?

Oh, now you've done it! As if a dagger right thru Ian's heart! How dare you
tarnish the alter of open source?

It's hard to find open source solutions to one-off problems. But
those solutions are often developed using platforms that use open
source tools. emacs comes to mind. Not part of the solution, but
part of the development platform.

Arne Vajhøj

2017-04-19 00:40:14 UTC

Post by Bob Koehler
It's hard to find open source solutions to one-off problems. But
those solutions are often developed using platforms that use open
source tools. emacs comes to mind. Not part of the solution, but
part of the development platform.

It is hard probably impossible to find complete open source solutions
for a one off problem.

But it is very common to develop a custom solution on top of a number
of open source components to solve a one off problem.

Arne

IanD

2017-04-21 16:08:44 UTC

On Tuesday, April 18, 2017 at 10:44:59 AM UTC+10, David Froble wrote:

<snip>

Post by David Froble
Oh, now you've done it! As if a dagger right thru Ian's heart! How dare you
tarnish the alter of open source?
:-)
On the other hand, not sure how to characterize SSL, but, I'm another that
doesn't use open source ....
:-)

My vest of opensource'ness protects me from such evil blows, it has a +10 armor protection you know - I can show you were to get some but you'll have to remove that old rusty VMS armor first ;-)

I guess part of the point I keep banging on about is that open source is important and if VMS ignores it, it does so to its peril. It's no longer a nice to have but a must have

If you don't have current open source builds available, no one will even consider using it as a platform from which to spring from

Now scripting languages are pushing further towards removing side-effects, hence the rise of Functional languages. What development outside of open source are currently happening in the Functional language space?
One would be hard pressed to find one.

How can VMS even hope to offer these types of solutions and be part of the next wave of scripting languages?
Even Erlang on VMS has fallen into disrepute and that's with Brett C. being a VSI employee! (yeah I know, he's a busy man. Actually, is he still at VSI? I have not seen much in the way of communication with his name on it)

On top of open source foundations a whole foundation of technology is built. Message queues (Rabbit for example has surge ahead in popularity), blockchain, DB's (both relational and NOSQL) etc etc etc

Browse the following list and see how pervasive open source has become, it touches every conceivable base out there and many of these software packages are mainstream and/or rival commercial offerings. A lot of open source has moved beyond the poor man's alternative crippled crap it used to be

https://en.wikipedia.org/wiki/List_of_free_and_open-source_software_packages

Multiple this list by probably a 10000's to get a module count and your now at a level where you can put together most offerings rapidly and use glue languages like Python to stitch it together

One of the hottest buzzword systems today is Salesforce. Guess what, it uses open source to a great extent

https://medium.com/salesforce-open-source/salesforce-is-powered-by-open-source-a00dfb9ea95b

I've said before that I don't believe open source is the answer to Life the Universe and Everything but it is important, far more important that a lot of people seem to think

On Wednesday, April 19, 2017 at 11:40:09 AM UTC+10, Kerry Main wrote:

<snip>

Post by David Froble
"Can be a problem?" .. What a huge understatement.
It is a huge problem and is one of the reasons why "patch-n-pray"
strategies are so prevalent in todays IT environments.
Especially with VM sprawl becoming such a big challenge in many
environments today.
Even 10 years ago - we did a DC discovery of a US Govt Agency as part of
an IT Assessment / Strategy with quite a bit of Linux OS's (approx. 400
V/P instances) and discovered 23 different versions of Linux. Windows
was not much better - there was in the neighbourhood of 15 different
versions / SP's etc. All across 5 different divisions who each ran their
dept. relatively independently.
So, in todays terms - when you have 20-30 security patches per month
released, the SysAdmin needs to review all these different versions and
flavours to determine what OS instance gets what patch. Yes, tools help
with deployment, but the SysAdmin needs to configure the tools to deploy
who gets what.
Regards,
Kerry Main
Kerry dot main at starkgaming dot com

And I agree

I just came from an IT outsource company and in the linux space it was patch patch patch patch and in your spare time, patch

HOWEVER...

With VM's and cloud, the business almost don't care

They don't see a disruption to business in patch deployment. These technologies hides that pain for them. As someone posted further back in another post, pain for the admin is where it's felt

Years ago we used to build a full server along side the old one and switch over just to reduce downtime, now we simply migrate 9 times out of 10 virtually or transaction queue and play them forward when the patched systems come back online

As IT heads towards being a commodity like electricity, all the need for getting one's hands dirty gets pushed further and further down the technology stack to where the business now merely answer a Yes/No tick box for an approval to upgrade/patch and 'NO, This CR will not incur any downtime or business impact'

Will there come a day of reckoning as far as poor organisational IT spend goes? Maybe, but until business stop the stupid practice of of slicing businesses into functional units instead of a Deming's Systems approach, costs of running the shop will remain in the Operations space and remain 'someone else's problem'

John Reagan

2017-04-21 17:05:38 UTC

Post by IanD
How can VMS even hope to offer these types of solutions and be part of the next wave of scripting languages?
Even Erlang on VMS has fallen into disrepute and that's with Brett C. being a VSI employee! (yeah I know, he's a busy man. Actually, is he still at VSI? I have not seen much in the way of communication with his name on it)

Yes, still at VSI. I spoke to him yesterday and have been exchanging info with him within the last few hours.

Jan-Erik Soderholm

2017-04-21 22:34:52 UTC

Post by John Reagan

Post by IanD
How can VMS even hope to offer these types of solutions and be part of
the next wave of scripting languages? Even Erlang on VMS has fallen
into disrepute and that's with Brett C. being a VSI employee! (yeah I
know, he's a busy man. Actually, is he still at VSI? I have not seen
much in the way of communication with his name on it)

Yes, still at VSI. I spoke to him yesterday and have been exchanging
info with him within the last few hours.

"Director of Applications & Open Source Services"

http://www.vmssoftware.com/about_kmgr.html

It was told at a meeting last fall that Brett C. would lead
a new group located at the Swedish VSI office...

David Froble

2017-04-21 18:55:33 UTC

Post by Paul Sture
<snip>

My vest of opensource'ness protects me from such evil blows, it has a +10
armor protection you know - I can show you were to get some but you'll have
to remove that old rusty VMS armor first ;-)

My VMS armor isn't rusty ....

Post by Paul Sture
I guess part of the point I keep banging on about is that open source is
important and if VMS ignores it, it does so to its peril. It's no longer a
nice to have but a must have

Nice? For some maybe. Must have? What have you been snorting? I'm aware of
quite a few VMS systems which do not need open source.

Post by Paul Sture
If you don't have current open source builds available, no one will even
consider using it as a platform from which to spring from

Guess me and a bunch of others are "no ones" ....

Post by Paul Sture
Now scripting languages are pushing further towards removing side-effects,
hence the rise of Functional languages. What development outside of open
source are currently happening in the Functional language space? One would be
hard pressed to find one.
How can VMS even hope to offer these types of solutions and be part of the
next wave of scripting languages? Even Erlang on VMS has fallen into
disrepute and that's with Brett C. being a VSI employee! (yeah I know, he's a
busy man. Actually, is he still at VSI? I have not seen much in the way of
communication with his name on it)

Perhaps "scripting languages" are the choice of those who cannot do better?
While the definitions can be rather vague, just about anything can be claimed to
be a scripting language, or not such, I'm rather happy with that which "just works".

Post by Paul Sture
On top of open source foundations a whole foundation of technology is built.
Message queues (Rabbit for example has surge ahead in popularity),
blockchain, DB's (both relational and NOSQL) etc etc etc
Browse the following list and see how pervasive open source has become, it
touches every conceivable base out there and many of these software packages
are mainstream and/or rival commercial offerings. A lot of open source has
moved beyond the poor man's alternative crippled crap it used to be

See, you recognize the crap ....

Post by Paul Sture
https://en.wikipedia.org/wiki/List_of_free_and_open-source_software_packages
Multiple this list by probably a 10000's to get a module count and your now
at a level where you can put together most offerings rapidly and use glue
languages like Python to stitch it together

Gluing things together is not the best thing to do.

Post by Paul Sture
One of the hottest buzzword systems today is Salesforce. Guess what, it uses
open source to a great extent

Never heard of it, unless you're fering to the "Sales Force Automation" I helped
design back in the early 90s. Wasn't open source neither ...

Post by Paul Sture
https://medium.com/salesforce-open-source/salesforce-is-powered-by-open-source-a00dfb9ea95b
I've said before that I don't believe open source is the answer to Life the
Universe and Everything but it is important, far more important that a lot of
people seem to think

Or not ....

Better upgrade that armor ..

Steven Schweda

2017-04-21 20:36:52 UTC

[...] I'm aware of quite a few VMS systems which do not
need open source.

I'm curious. How do those systems deal with patches which
are distributed as self-extracting zip archives? For
example:

ALP $ mcr ALP$DKC0:[PATCH.v8r4]VMS84A_SYS-V0100.ZIPEXE -v
UnZipSFX 5.42 of 14 January 2001, by Info-ZIP (Zip-***@lists.wku.edu).
Valid options are -tfupcz; modifiers are -abjnoqCLMVX. Quote uppercase options.

I'm fairly confident that the Info-ZIP Zip and UnZip
programs (even obsolete ones like UnZip 5.42) are "open
source". Do these system managers have some special
arrangement with HPE to obtain such software on 9-track tape
in raw form? Is it possible that your reliance on
open-source software might be slightly greater than you claim
(repeatedly)?

David Froble

2017-04-21 22:54:01 UTC

[...] I'm aware of quite a few VMS systems which do not
need open source.

I'm curious. How do those systems deal with patches which
are distributed as self-extracting zip archives? For
ALP $ mcr ALP$DKC0:[PATCH.v8r4]VMS84A_SYS-V0100.ZIPEXE -v
Valid options are -tfupcz; modifiers are -abjnoqCLMVX. Quote uppercase options.
I'm fairly confident that the Info-ZIP Zip and UnZip
programs (even obsolete ones like UnZip 5.42) are "open
source". Do these system managers have some special
arrangement with HPE to obtain such software on 9-track tape
in raw form? Is it possible that your reliance on
open-source software might be slightly greater than you claim
(repeatedly)?

Well ...... maybe .....

:-)

Ok, ZIP is in use, now and then. Not on a daily basis.

OpenSSL is in use, though that is provided by HP, not downloaded and built.
Same with the stuff bundled with TCP/IP.

Not much choice in today's communications. Many will not accept an unencrypted
connection. But for the vast majority of the applications, we wrote them, we
didn't cobble together a bunch of open source stuff.

But I'll still maintain that the use of open source on any system, not just VMS,
sure isn't as critical as Ian seems to think.

Steven Schweda

2017-04-21 23:39:42 UTC

Post by David Froble
But I'll still maintain that the use of open source on any
system, not just VMS, sure isn't as critical as Ian seems to
think.

I don't doubt that you will, but this statement is about
as valid as all the previous "do not need open source"
statements were. Define "any system". I want to see the
GNU/Linux system which works without much open-source
software.

This is getting more and more like listening to the
president's press secretary explain the fine points of the
use of chemical weapons around WWII. Sometimes it's simply
easier to admit being wrong about something, especially when
admitting the validity of contrary evidence.

David Froble

2017-04-22 00:22:37 UTC

Post by David Froble
But I'll still maintain that the use of open source on any
system, not just VMS, sure isn't as critical as Ian seems to
think.

I don't doubt that you will, but this statement is about
as valid as all the previous "do not need open source"
statements were. Define "any system". I want to see the
GNU/Linux system which works without much open-source
software.
This is getting more and more like listening to the
president's press secretary explain the fine points of the
use of chemical weapons around WWII. Sometimes it's simply
easier to admit being wrong about something, especially when
admitting the validity of contrary evidence.

Now you strike a low blow ....

:-)

Ok, I'll admit it, I can be wrong. I thought I was wrong once, but I was wrong
about that.

Kerry Main

2017-04-22 16:09:50 UTC

-----Original Message-----
David Froble via Info-vax
Sent: April 21, 2017 8:23 PM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity

Post by David Froble
But I'll still maintain that the use of open source on any
system, not just VMS, sure isn't as critical as Ian seems to
think.

I don't doubt that you will, but this statement is about
as valid as all the previous "do not need open source"
statements were. Define "any system". I want to see the
GNU/Linux system which works without much open-source
software.
This is getting more and more like listening to the
president's press secretary explain the fine points of the
use of chemical weapons around WWII. Sometimes it's simply
easier to admit being wrong about something, especially when
admitting the validity of contrary evidence.

Now you strike a low blow ....
:-)
Ok, I'll admit it, I can be wrong. I thought I was wrong once, but I was wrong
about that.

Ok, using a Trump or WH apology is just wrong.

Different version of Trump / WH apology "When I last admitted I was wrong, I was mistaken"

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

David Froble

2017-04-23 00:26:18 UTC

-----Original Message-----
David Froble via Info-vax
Sent: April 21, 2017 8:23 PM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity

Post by David Froble
But I'll still maintain that the use of open source on any
system, not just VMS, sure isn't as critical as Ian seems to
think.

I don't doubt that you will, but this statement is about
as valid as all the previous "do not need open source"
statements were. Define "any system". I want to see the
GNU/Linux system which works without much open-source
software.
This is getting more and more like listening to the
president's press secretary explain the fine points of the
use of chemical weapons around WWII. Sometimes it's simply
easier to admit being wrong about something, especially when
admitting the validity of contrary evidence.

Now you strike a low blow ....
:-)
Ok, I'll admit it, I can be wrong. I thought I was wrong once, but I was wrong
about that.

Ok, using a Trump or WH apology is just wrong.
Different version of Trump / WH apology "When I last admitted I was wrong, I was mistaken"

Lighten up. Laugh at least 10-20 times a day.

Steven Schweda

2017-04-22 16:57:40 UTC

[...] I thought I was wrong once, but I was wrong
about that.

You were definitely wrong when you thought that. You
weren't "wrong once", you were wrong many times. Or did you
mean that you once thought that you were wrong, or that you
thought once that you were wrong? Or were you wrong when you
put "once" in the wrong place? Or are you just wrong most of
the time (and adamantly so), which hypothesis would seem to
cover the known facts?

David Froble

2017-04-23 00:32:35 UTC

[...] I thought I was wrong once, but I was wrong
about that.

Now you've done it, I'm SO confused ....

:-)

Yes, I've been wrong to be so anti open source. I can only say it was a
response to the equally absurd claims of Ian. At least that's how they struck me.

If there is an open source app that does a job well, and as needed, that's one
thing. As for something that does a job poorly, and with much manual and / or
glue, well, that's not how I do things.

There have been several claims in c.o.v that if VSI didn't do such and such, VMS
was doomed. I don't agree with any that I've seen. Including the embracing of
open source.

Arne Vajhøj

2017-04-21 23:54:39 UTC

Post by Steven Schweda
I'm fairly confident that the Info-ZIP Zip and UnZip
programs (even obsolete ones like UnZip 5.42) are "open
source".

I believe that 5.41 and newer are under INFO-ZIP license
which is a BSD-like open source license, while the license
situation 5.40 and older was a mess but still open source.

Arne

Stephen Hoffman

2017-04-21 21:15:11 UTC

Post by David Froble
Nice? For some maybe. Must have? What have you been snorting? I'm
aware of quite a few VMS systems which do not need open source.

OpenSSL is embedded in networking, as well as within PCSI. BIND DNS
services. NTP time services. X. zip and unzip. Kerberos.
Apache. php and Perl and Python and bash. libxml2 is used to build
OpenVMS. UEFI is used to boot OpenVMS I64. llvm and other giblets
are be used going forward, too. There are other bits around, too.

But then we're also not going back to the world where everybody rolled
all their own bespoke software, and from scratch. Nor are the folks
that are maintaining and enhancing their own bespoke software going to
be walking away from using compatibly-licensed open source, where
that's available. That's way too much code, and that approach is way
too expensive. Better to spend time on the code that really matters.

Or are we having the discussion about what is or isn't integrated into
OpenVMS itself? Because dinking around installing and troubleshooting
and upgrading various semi-integrated semi-distinct semi-current and
overlapping layered products is such a joy, of course. That lack of
integration and that pick-and-choose approach is part of what makes
TCP/IP Services and other should-be-part-of-the-OpenVMS-base-distro
components such a mess to deal with, too. (And I'm not discussing how
TCP/IP Services is co-resident on the same installer disk, nor how zip
and unzip are inexplicably not and not included.) I (obviously) don't
consider IP networking a separate piece. That approach ended circa
1995, if not earlier. Except on OpenVMS.

--
Pure Personal Opinion | HoffmanLabs LLC

Arne Vajhøj

2017-04-21 23:40:28 UTC

Post by IanD
I guess part of the point I keep banging on about is that open source is
important and if VMS ignores it, it does so to its peril. It's no longer a
nice to have but a must have

Nice? For some maybe. Must have? What have you been snorting? I'm
aware of quite a few VMS systems which do not need open source.

There are probably some systems.

But not the type of systems with a future.

Post by IanD
Now scripting languages are pushing further towards removing
side-effects,
hence the rise of Functional languages. What development outside of open
source are currently happening in the Functional language space? One would be
hard pressed to find one.
How can VMS even hope to offer these types of solutions and be part of the
next wave of scripting languages? Even Erlang on VMS has fallen into
disrepute and that's with Brett C. being a VSI employee! (yeah I know, he's a
busy man. Actually, is he still at VSI? I have not seen much in the way of
communication with his name on it)

Perhaps "scripting languages" are the choice of those who cannot do
better? While the definitions can be rather vague, just about anything
can be claimed to be a scripting language, or not such, I'm rather happy
with that which "just works".

So do you use a LOGIN.EXE instead of a LOGIN.COM where you do all the
stuff in Basic or Pascal instead of DCL?

No? DCL is a script language. So why do you use it when you "can do better"?

Probably because one size does not fit all for programming languages.

DCL is simply better to some things than Basic or Pascal.

You would not want to write your new RDBMS in DCL though. For that
task Basic or Pascal would be much better.

You choose the right tool for the job.

Scripting languages surely has their place.

Post by IanD
Multiple this list by probably a 10000's to get a module count and your now
at a level where you can put together most offerings rapidly and use glue
languages like Python to stitch it together

Gluing things together is not the best thing to do.

It is often the lowest TCO.

Application sizes are growing like crazy. In the +25% per year
magnitude.

Writing everything from scratch is becoming astronomical expensive.

Post by IanD
One of the hottest buzzword systems today is Salesforce. Guess what, it uses
open source to a great extent

Never heard of it,

Salesforce is a SaaS CRM solution. They are selling for almost 7 B$ per
year.

Arne

Bob Koehler

2017-04-24 12:56:12 UTC

Post by David Froble
Nice? For some maybe. Must have? What have you been snorting? I'm
aware of quite a few VMS systems which do not need open source.

There are probably some systems.
But not the type of systems with a future.

That depends very much on what kind of computing you do. The kind
of computing I do does not appear to be ending anytime soon. The
kind of computing I'm most lilely to use VMS for does not appear
to be going away.

The many kinds of computing you can hire any kid frssh out of
college, yeah, lots of those need open source. And they don't need
me.

Arne Vajhøj

2017-04-21 23:43:41 UTC

Post by IanD
One of the hottest buzzword systems today is Salesforce. Guess what,
it uses open source to a great extent
https://medium.com/salesforce-open-source/salesforce-is-powered-by-open-source-a00dfb9ea95b
I've said before that I don't believe open source is the answer to
Life the Universe and Everything but it is important, far more
important that a lot of people seem to think

It is not just Salesforce.

All the big internet companies Google, Facebook, Amazon etc.
are using lots of open source.

All the traditional big software companies IBM, Oracle,
Microsoft etc. are using lots of open source in their
commercial offerings.

Apple as well.

Arne

Paul Sture

2017-04-22 15:03:09 UTC

It is not just Salesforce.
All the big internet companies Google, Facebook, Amazon etc.
are using lots of open source.
All the traditional big software companies IBM, Oracle,
Microsoft etc. are using lots of open source in their
commercial offerings.
Apple as well.

And various of them have open-sourced stuff they have developed
in-house.

--
Everybody has a testing environment. Some people are lucky enough enough
to have a totally separate environment to run production in.

j***@yahoo.co.uk

2017-04-18 16:25:38 UTC

Post by IanD

Post by Simon Clubley
But it can also work the other way if this is still the current Java 8
version on VMS 6 months from now.

VSI is a small company, with a huge amount of work to accomplish. Not sure if
HPE was involved in the Java 8 stuff. Regardless, haven't you been pounding
just a bit too hard on "I want everything, right now, or even yesterday"?
It seems that for some people, no matter what does get released, they might as
well not have bothered. Well, should they have bothered ???????????????

Because it's a very nice stepping stone towards where VMS should be,
but that's all it is: a stepping stone. We now need all the other
stepping stones to be laid down.
Simon.

I didn't see his post that way
I saw the point that if you neglect fundamentals like keeping open source software up to date, it negatively impacts on you and your credibility wanes
VMS is not seen as relevant in todays market - that is the harsh reality
To restore VMS to even a state where it can compete in a platform for open source development yet alone deployment, a sh*t load of work is needed and continually needed
The unspoken question that needs to be asked is what tools and frameworks are being put in place to help foster VMS be relevant into the current world, yet alone in 5 years time
What frameworks are being implemented, what is happening to assist VMS builds of open source get out the door quicker?
It not enough to build the odd occasional release of an open source product now and then, it needs to be a fluid happening.
Jenkins grew out of a need in the open source world for people to be able to get quick access to current builds versus roll your own all the time. Repeatable processes is the name of game - where is this for VMS? Everything is still in the roll your own mentality or waiting with cup in hand for VSI (who by your own admission are a small company and cannot do everything)
If they cannot do everything (and they can't and shouldn't) then they need to put in frameworks and/or processes that assist the greater community in getting builds out as fast as possible to keep the platform relevant
Point in question. We heard how the original VMS code cannot be open sourced due to license agreements. What about all the work done with LLVM for VMS? What about the work done for booting? What about the code that was re-written in C or adapted for x86 specific?
Surely not all of this code (that I read was developed from scratch some of it) is tied to HPE licensing? What about this code being released to the wider audience so that VSI can attract a larger audience?
Even the MS devil has open sourced key components, like .net, powershell. It also has opened up it's vidual studio to intergrade with the likes of GitHub and recently announced it was closing it's code repository and acknowledged that GitHub rules them all at present. Linux won, open source has won, VMS needs to get on the bandwagon and incorporate as many of the winning components these two used to gain success or perish (putting it more hard, rise from the dead)
I really don't think anyone was discrediting the great work VSI has put in, it's just some folk realise the greater picture and what's needed to continue moving VMS forward because let's face it, we are many years behind currently

This open source software you refer to, and which is undoubtedly
an important part of the modern IT landscape (much as DECUS
software used to be, back in the day): does it come with a single
unified voice, or is it fragmented in a way which will leave
individual vendors (such as VSI) unable to please everybody?

Does that matter, to IT departments, to VSI, to application
developers, to users?

It's great to support open source. In principle. But the devil
is in the detail.

Linux's systemd, for example, is finding its way into more and
more places where it *really* doesn't belong, but where RedHat
would very much like it to be.

Just for background: post-DECUS, I probably started my open
source connections in the 1990s with RedHat4 at work. Probably
around the same time that LaserMoon were working on a
POSIX-certifiable Linux (hmm, is it standards that matter, or
implementations)?

For a little while at work I was even designing with MontaVista
Linux on SonOfStrongARM (Intel IXP422?), till the IT people said
"if it ain't Dell and Windows it ain't connecting to our network".

At home there were a zillion different Linuxes (and friends) to
play with, all not quite identical.

Obviously the One True Linux Way was then, is now, and always
will be, some flavour of Suse [terms and conditions apply, the
value of your IT department may go down as well as up, etc]).

But Linux is not VMS, and vice versa. Some cross fertilisation
might well be welcome in some aspects - but which bits to do,
and which bits to do *first*, and how to develop, deliver, and
support them?

Have a lot of fun (and funds :)).

Arne Vajhøj

2017-04-19 00:49:43 UTC

Post by j***@yahoo.co.uk
This open source software you refer to, and which is undoubtedly
an important part of the modern IT landscape (much as DECUS
software used to be, back in the day): does it come with a single
unified voice, or is it fragmented in a way which will leave
individual vendors (such as VSI) unable to please everybody?
At home there were a zillion different Linuxes (and friends) to
play with, all not quite identical.

Linux is a rather unusual case with the many distros.

But it is not a big problem for software. And it is not a
big problem for users.

It can be a problem for the sysadm.

Arne

Kerry Main

2017-04-19 01:37:11 UTC

-----Original Message-----
Vajhøj via Info-vax
Sent: April 18, 2017 8:50 PM
Subject: Re: [Info-vax] Java 8 Now Available for OpenVMS Integrity

Linux is a rather unusual case with the many distros.
But it is not a big problem for software. And it is not a
big problem for users.
It can be a problem for the sysadm.
Arne

"Can be a problem?" .. What a huge understatement.

It is a huge problem and is one of the reasons why "patch-n-pray"
strategies are so prevalent in todays IT environments.

Especially with VM sprawl becoming such a big challenge in many
environments today.

Even 10 years ago - we did a DC discovery of a US Govt Agency as part of
an IT Assessment / Strategy with quite a bit of Linux OS's (approx. 400
V/P instances) and discovered 23 different versions of Linux. Windows
was not much better - there was in the neighbourhood of 15 different
versions / SP's etc. All across 5 different divisions who each ran their
dept. relatively independently.

So, in todays terms - when you have 20-30 security patches per month
released, the SysAdmin needs to review all these different versions and
flavours to determine what OS instance gets what patch. Yes, tools help
with deployment, but the SysAdmin needs to configure the tools to deploy
who gets what.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-04-19 00:17:02 UTC

Buried in the April Oracle patch advisory... Oracle Java SE
CVE-2017-3514 Remote Security Vulnerability. Details on the
vulnerability are sketchy. Requires running untrusted code — some
open-source project that contains malware and that gets downloaded and
run, for instance — so not an immediate problem for many sites. (But
I'm certainly not alone in having to deal with running code that wasn't
developed internally, or otherwise running potentially-untrusted code,
unfortunately.)

--
Pure Personal Opinion | HoffmanLabs LLC

Arne Vajhøj

2017-04-19 00:36:50 UTC