[Info-vax] OpenVMS servers and clusters as a cloud service

[DaveFroble]

Stephen Hoffman wrote:
> On 2018-01-10 05:54:50 +0000, Grant Taylor said:
> 
>> On 01/09/2018 11:11 AM, Scott Dorsey wrote:
>>> There's no reason not to do it, other than coding time.
>>
>> The biggest reason I've seen, is one word, "ignorance".  Ignorance of 
>> <wildcard>.  (I've seen more than I want to admit to.)
> 
> "Blame the user".

Well, sometimes ....

> We are in the world where an increasing number of folks do not have the 
> knowledge or do not the time to acquire and develop that knowledge, or 
> lack the schedule time or the budget to create more robust applications, 
> and more secure configurations.
> 
> We are in the world where implementing robust solutions commonly does 
> not happen.
> 
> We are in the world where long-running processes routinely do not 
> checkpoint.

O, we live in an imperfect world.  That still doesn't excuse people from using 
due diligence.  That still doesn't excuse not "doing the right thing".

Consider:

Three Mile Island, new power station, inadequately trained operators.  See how 
bad things can get when not done properly?

And after writing that, yes, if things can be done better, that would be a good 
thing.  But we're never going to be able to cure stupidity and ignorance.

> Now...
> 
> Think hard here, all you fine readers.  Think.  Really think.
> 
> What will the best response to this sorry state of affairs be?   If it's 
> "blame the users" or "blame the developers" or "I could have done that 
> with first principles", look around.  Yes, that might be an answer, but 
> is it a viable answer?   Is it a good answer?   Is it an answer that any 
> of us can really work with?  Or is it a cop-out, or a 
> makes-me-feel-superior, or a palliative?  Is it an answer that's part of 
> something that an existing or new product can use in its designs and 
> marketing?

If such help can be provided, it should be.  Not everything will ever be 
available.  Not everything should be available.

> Sure, ignoring the problem and shifting the blame onto the end-users or 
> the ISVs or the system managers can work for some incumbent businesses. 
> For a while.   That doesn't work for businesses that want or need to 
> expand their customer bases.  It doesn't work for the rest of us either, 
> as our data and our systems and our servers are increasingly 
> interconnected, and increasingly exposed.   Arcane skills — such as 
> cryptography — become increasingly central to all of our processing.  
> Where a developer mistake with cryptography or a developer that hasn't 
> kept current with what's known and available, or a patch is delayed or 
> ignored or omitted, can get really expensive.
> 
> If providing more robust processing doesn't get easier and simpler and 
> more capable on OpenVMS, then it's not going to happen with OpenVMS.  
> Because it hasn't happened.  And it's not now going to suddenly start 
> happen.  And because potential new customers are either going to 
> continue to buy what they already have and are familiar with — which is 
> not OpenVMS — or they're going to look elsewhere for their options and 
> alternatives, it's not something that VSI can use to differentiate.   
> Worse, iIf your current or new product — VSI OpenVMS or otherwise — 
> requires more training, or acquiring new skills, or porting efforts, or 
> changing tools or moving to what are lesser development and management 
> and other tools, and/or you can't easily host instances in common 
> places, then you're already operating at a competitive disadvantage.
> 
> Going first-principles or blame-the-user in your product approach or in 
> your API designs?  That's unlikely to be the basis of any successful 
> product development or product marketing campaign.

Agreed, but, the users need to have some responsibility.

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