[Info-vax] HP Integrity rx2800 i4 (2.53GHz/32.0MB) :: PAKs won't load

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 28-Feb-16 12:35 PM
> To: info-vax at info-vax.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] HP Integrity rx2800 i4 (2.53GHz/32.0MB) ::
> PAKs won't load
> 
> On 2016-02-28 16:54:00 +0000, Kerry Main said:
> 
> > I agree cluster and OpenVMS pricing / licensing  in general needs a
> > major re-visit for next gen OpenVMS V9/10+ futures ..
> 
> If by "major revisit" you mean "nuke it from orbit", sure.    Outside
> of the installed base, OpenVMS is not competitive.  Whether it's
> pricing or features or the cluster user interface "design" that you so
> desperately keep trying to drag the discussion away from.     The
> accreted "design" being the result of decades of what were very likely
> a series of reasonable decisions at the time, too.
> 

I disagree - the key differentiators of OpenVMS Cluster design is support
for either active-active or active-passive shared everything architectures.

As the links I provided by the distributed systems engineer from Twitter
show, her view of next generations systems are stateful systems where
the state is maintained centrally with the app services - not unlike what 
a shared everything file system could provide. On top of this - dynamic 
cluster membership, OS maintained consistency (volume shadowing, as 
opposed to App developers having to do themselves with each application), 
OS maintained knowledge of which systems are part of cluster (as opposed
To updating config files and shipping these around like what Catie describes
In her talks)

> "Which brings me to another point about calling bullshit. The state of
> the art in the Rails world is full of hard-won simplifications. It's
> incredibly easy to devolve and regress from that. While Java certainly
> isn't a pinnacle of language design, it took quite a few years of
> devolution to go from something relatively simple like servlets to the
> steaming pile of shit that is J2EE. And every tiny step of the way
> probably seemed somewhat reasonable at the time to reasonable
> people.
> 

Imho, Java and J2EE got to the low point where it is today because of
what I would call "to many cooks in the kitchen" syndrome .. they tried
to include whatever features and functions that all of their followers
wanted.  

The huge complexity of J2EE and constant patching are often cited as 
why many developers have given up on it.

> If we don't call bullshit loud and often against what's perceived as
> putting us on this path of devolution, which imo is the standard
> trajectory of software, then we will end up exactly where they did. In
> Kompleksistan with no map to find our way back."  — David Heinemeier
> Hansson.
> 

"Learning from the past, to plan the future .."

The Canadian version - (Wayne Gretzky)
"skate to where the puck is going to be - not where It is right now .." 

The way forward is not to copy what is available today (mostly distributed
systems view of IT), but rather take what is best from both distributed 
(*nix, Windows) and centralized (OpenVMS , z/OS) views and integrate 
them in a next generation arch that contains the best of both distributed 
and centralized architecture designs. 

Imho, removing many of the typical distributed systems App developer
worries about things Caitie highlighted like CAP (consistency, availability, 
partitioning) and moving these (or as many as possible) into the OS layer 
will allow the next generation App developers to focus on what his/her core 
competency is i.e. improving their App specific code to improve the quality 
of their service and/or application.

[snip..]

Regards,

Kerry Main
Kerry dot main at starkgaming dot com