Discussion:
Some HP and VSI OpenVMS material.
(too old to reply)
Jan-Erik Soderholm
2016-12-31 13:51:29 UTC
Permalink
Raw Message
Hi.

A few links to PDFs and MPEGs provided by the
Swedish HP-Connect office. Note that some of the
documents can be a year or a little more old...

Most of the MPEG presentations are in Swedish but
usually using English slides.

There are also some slides from the IKEA presentation.

Have a good new Year!

Jan-Erik.



PDF slides

VSI Multivendor Storage PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HAkUADUwNAVE

VSI OpenVMS Alpha PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HA0UADUwNAVE

Java 1.8 (Java 8) Update PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBEUADUwNAVE

VMS File System Update PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBUUADUwNAVE

VSI TCP/IP Stack & VCI 2.0 PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBkUADUwNAVE

OpenVMS Rolling Roadmap PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HB0UADUwNAVE

IKEAs presentation PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HCEUADUwNAVE


Videos
HPE IL / Hadoop MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4HCUUADUwNAVE

The portable C Compiler - PCC MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EAEUADUwNAVE

OpenVMS runs on Integrity I4 MPEG4
Short intro in SWedish, talk and slides in English (Ken Surplice)
http://www.hp-connect.se/lists/lt.php?id=cE4EAUUADUwNAVE

OpenVMS roadmap MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EAkUADUwNAVE

Porting OpenVMS to x86-64 MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EA0UADUwNAVE

Heartbleed bug OpenVMS MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4FAkUADUwNAVE

HP OneView MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4ECEUADUwNAVE

Migrering till Linux MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EBEUADUwNAVE

VMS Software Incs - VSI MPEG4
Swedish talk, Englinsh slides.
By Johan Gedda, Chairman of VSI and main investor.
http://www.hp-connect.se/lists/lt.php?id=cE4EBUUADUwNAVE

VMS Technical update - VSI MPEG4
English talk and slides, Clair Grant.
http://www.hp-connect.se/lists/lt.php?id=cE4EBkUADUwNAVE
Craig A. Berry
2016-12-31 16:28:11 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
VSI Multivendor Storage PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HAkUADUwNAVE
Very interesting. Does anyone know and can say whether NetApp is one of
the "5 additional partners" under consideration?
IanD
2017-01-02 09:15:23 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Hi.
A few links to PDFs and MPEGs provided by the
Swedish HP-Connect office. Note that some of the
documents can be a year or a little more old...
Most of the MPEG presentations are in Swedish but
usually using English slides.
There are also some slides from the IKEA presentation.
Have a good new Year!
Jan-Erik.
PDF slides
VSI Multivendor Storage PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HAkUADUwNAVE
VSI OpenVMS Alpha PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HA0UADUwNAVE
Java 1.8 (Java 8) Update PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBEUADUwNAVE
VMS File System Update PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBUUADUwNAVE
VSI TCP/IP Stack & VCI 2.0 PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBkUADUwNAVE
OpenVMS Rolling Roadmap PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HB0UADUwNAVE
IKEAs presentation PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HCEUADUwNAVE
Videos
HPE IL / Hadoop MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4HCUUADUwNAVE
The portable C Compiler - PCC MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EAEUADUwNAVE
OpenVMS runs on Integrity I4 MPEG4
Short intro in SWedish, talk and slides in English (Ken Surplice)
http://www.hp-connect.se/lists/lt.php?id=cE4EAUUADUwNAVE
OpenVMS roadmap MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EAkUADUwNAVE
Porting OpenVMS to x86-64 MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EA0UADUwNAVE
Heartbleed bug OpenVMS MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4FAkUADUwNAVE
HP OneView MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4ECEUADUwNAVE
Migrering till Linux MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EBEUADUwNAVE
VMS Software Incs - VSI MPEG4
Swedish talk, Englinsh slides.
By Johan Gedda, Chairman of VSI and main investor.
http://www.hp-connect.se/lists/lt.php?id=cE4EBUUADUwNAVE
VMS Technical update - VSI MPEG4
English talk and slides, Clair Grant.
http://www.hp-connect.se/lists/lt.php?id=cE4EBkUADUwNAVE
Awesome - thanks

Maybe VSI should put you on the marketing payroll...
Simon Clubley
2017-01-03 02:24:51 UTC
Permalink
Raw Message
Post by IanD
Awesome - thanks
Maybe VSI should put you on the marketing payroll...
VSI has a _marketing_ payroll ??? Are you sure about that ?

I wonder how much it would cost for them to produce a little trinket
or a badge and send them out to potential customers ?

(This latter question was prompted by the fact I recently found (buried
in a cupboard at home) a blue DECnet OSI badge which must be at least
20 years old. I also still have the VMS umbrella and bouncing ball
that Sue sent out back in the Compaq days.)

So what badge or trinket do you think it might be a good idea for
VSI to start sending out ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Simon Clubley
2017-01-03 02:32:39 UTC
Permalink
Raw Message
Post by Simon Clubley
I wonder how much it would cost for them to produce a little trinket
or a badge and send them out to potential customers ?
(This latter question was prompted by the fact I recently found (buried
in a cupboard at home) a blue DECnet OSI badge which must be at least
20 years old. I also still have the VMS umbrella and bouncing ball
that Sue sent out back in the Compaq days.)
I've just dug out the bouncing ball. The card inside the package says:

"Compaq OpenVMS on AlphaServer systems

Enterprise computing in motion

One of our customers recently reminded me that Compaq OpenVMS
on AlphaServer systems requires such little management that
you can spend some time having a little fun.

Enjoy!"

The card is signed by Rich Marcello. Perhaps VSI could send out
a modern version of that card with a message addressing today's needs ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bill Gunshannon
2017-01-03 02:39:11 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Simon Clubley
I wonder how much it would cost for them to produce a little trinket
or a badge and send them out to potential customers ?
(This latter question was prompted by the fact I recently found (buried
in a cupboard at home) a blue DECnet OSI badge which must be at least
20 years old. I also still have the VMS umbrella and bouncing ball
that Sue sent out back in the Compaq days.)
"Compaq OpenVMS on AlphaServer systems
Enterprise computing in motion
One of our customers recently reminded me that Compaq OpenVMS
on AlphaServer systems requires such little management that
you can spend some time having a little fun.
Enjoy!"
The card is signed by Rich Marcello. Perhaps VSI could send out
a modern version of that card with a message addressing today's needs ?
My bouncing ball says COMPAQ OpenVMS on it. The batteries in the
flasher died ages ago but my grandson has a blast bouncing the
ball around my home office.

bill
Kerry Main
2017-01-03 04:04:20 UTC
Permalink
Raw Message
-----Original Message-----
Of Simon Clubley via Info-vax
Sent: 02-Jan-17 9:25 PM
Earth.UFP>
Subject: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.
Post by IanD
Awesome - thanks
Maybe VSI should put you on the marketing payroll...
VSI has a _marketing_ payroll ??? Are you sure about that ?
I wonder how much it would cost for them to produce a little
trinket or a badge and send them out to potential customers ?
(This latter question was prompted by the fact I recently found
(buried in a cupboard at home) a blue DECnet OSI badge which
must be at least
20 years old. I also still have the VMS umbrella and bouncing
ball
that Sue sent out back in the Compaq days.)
So what badge or trinket do you think it might be a good idea
for
VSI to start sending out ?
Simon.
Fyi - not trinkets, but nice "leave behind" materials for
Customer visits and/or conferences and/or proposals etc.:

"VSI OpenVMS V8.4-2L1 operating environments" - August 2016
http://h20195.www2.hpe.com/v2/GetPDF.aspx/4AA6-4476ENW.pdf

"Exceed business expectations VSI OpenVMS V8.4-2L1" - October
2016
http://h20195.www2.hpe.com/V2/getpdf.aspx/4AA6-5039ENW.pdf

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
IanD
2017-01-03 04:27:49 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by IanD
Maybe VSI should put you on the marketing payroll...
VSI has a _marketing_ payroll ??? Are you sure about that ?
I was going to say something a little more harsh but decided to keep tings light instead

I don't know why information such as what was posted is not on their main website because it's good. I would not have asked half the questions I did about the new file system had i seen this material and I have only looked at 2 items so far!

Marketing may be a black hole but I think more marketing than what we have seen to date is sorely needed

As to memorabilia owned...

My wife had a Digital umbrella up until the point where I borrowed it and accidentally left it on a train. That loss hurt for a long time...

I remember getting a set of Digital Golf Balls which I gave away to someone who played gold at the time. If I remember rightly, they were Dunlop brand. In a box of 12 I think. too long ago to remember properly

I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)
j***@yahoo.co.uk
2017-01-03 07:00:10 UTC
Permalink
Raw Message
Post by IanD
Post by Simon Clubley
Post by IanD
Maybe VSI should put you on the marketing payroll...
VSI has a _marketing_ payroll ??? Are you sure about that ?
I was going to say something a little more harsh but decided to keep tings light instead
I don't know why information such as what was posted is not on their main website because it's good. I would not have asked half the questions I did about the new file system had i seen this material and I have only looked at 2 items so far!
Marketing may be a black hole but I think more marketing than what we have seen to date is sorely needed
As to memorabilia owned...
My wife had a Digital umbrella up until the point where I borrowed it and accidentally left it on a train. That loss hurt for a long time...
I remember getting a set of Digital Golf Balls which I gave away to someone who played gold at the time. If I remember rightly, they were Dunlop brand. In a box of 12 I think. too long ago to remember properly
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)
I have an HP Invent coffee mug. Well, I think that's what it
was. Over the years, through relatively infrequent use, the
whole printed logo has vanished, perhaps as though it was a
mirage. Maybe it wasn't properly specified and tested, good
job computer systems aren't built like that. Or are they?

Also mirage-like, over the years, the alleged benefits of
switching to "low cost" software (Windows etc) in critical
cases have sometimes vanished. London Ambulance Service
were reminded of this on New Years Eve when their ambulance
dispatch service fell over and manual (paper) operation
was required for five hours, on the busiest night of the
year.

Sadly for LAS, it wasn't the first time this has happened
with their implementation of Northrop Grumman's CommandPoint
system, and it likely won't be the last. I don't suppose
the supplier will end up with any meaningful financial
penalty though; a system that's defective by design seems
to be acceptable modern practice.

London's Metropolitan Police were luckier, in a way, with
their implementation of CommandPoiunt. They didn't get as
far as rolling out CommandPoint before cancelling the
project (2016).

Isn't there some nice shiny AI tool out there yet that can
readily specify, design, rollout, and manage these critical
systems in a robust secure trustworthy and idiot-resistant
manner?

I left out "test" deliberately, the modern approach seems to
be to let the customer do the testing, preferably after the
system is paid for. Real testing seems to be a bit "20th
century". As for coding: any idiot can do that given a decent
IDE, can't they. No knowledge or understanding required,
neither of the business requirements nor of the appropriate
implementation technologies.
Kerry Main
2017-01-03 15:17:04 UTC
Permalink
Raw Message
-----Original Message-----
Of johnwallace4--- via Info-vax
Sent: 03-Jan-17 2:00 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.
On Tuesday, January 3, 2017 at 1:26:23 PM UTC+11, Simon
Post by Simon Clubley
Post by IanD
Maybe VSI should put you on the marketing payroll...
VSI has a _marketing_ payroll ??? Are you sure about that ?
I was going to say something a little more harsh but decided
to
keep
tings light instead
I don't know why information such as what was posted is not
on
their main website because it's good. I would not have asked
half
the questions I did about the new file system had i seen this
material and I have only looked at 2 items so far!
Marketing may be a black hole but I think more marketing than
what we
have seen to date is sorely needed
As to memorabilia owned...
My wife had a Digital umbrella up until the point where I
borrowed it and accidentally left it on a train. That loss hurt
for a
long time...
I remember getting a set of Digital Golf Balls which I gave
away
to
someone who played gold at the time. If I remember rightly,
they were
Dunlop brand. In a box of 12 I think. too long ago to
remember
properly
I still have a Digital coffee cup. Blue, with a white spiral
type
pattern on it (not the traditional Digital maroon color)
I have an HP Invent coffee mug. Well, I think that's what it
was.
Over the years, through relatively infrequent use, the whole
printed logo has vanished, perhaps as though it was a mirage.
Maybe it wasn't properly specified and tested, good job
computer systems aren't built like that. Or are they?
Also mirage-like, over the years, the alleged benefits of
switching
to "low cost" software (Windows etc) in critical cases have
sometimes vanished. London Ambulance Service were reminded
of this on New Years Eve when their ambulance dispatch service
fell over and manual (paper) operation was required for five
hours, on the busiest night of the year.
Sadly for LAS, it wasn't the first time this has happened with
their
implementation of Northrop Grumman's CommandPoint system,
and it likely won't be the last. I don't suppose the supplier
will end
up with any meaningful financial penalty though; a system
that's
defective by design seems to be acceptable modern practice.
London's Metropolitan Police were luckier, in a way, with their
implementation of CommandPoiunt. They didn't get as far as
rolling out CommandPoint before cancelling the project (2016).
Isn't there some nice shiny AI tool out there yet that can
readily
specify, design, rollout, and manage these critical systems in
a
robust secure trustworthy and idiot-resistant manner?
I left out "test" deliberately, the modern approach seems to be
to let the customer do the testing, preferably after the system
is
paid for. Real testing seems to be a bit "20th century". As for
coding: any idiot can do that given a decent IDE, can't they.
No
knowledge or understanding required, neither of the business
requirements nor of the appropriate implementation
technologies.
No platform is 100% secure (yes, including OpenVMS), but due to
the sheer volume of 20-30+ security patches per month associated
with commodity OS platforms, the decades old best practice of
testing important apps before patching (especially security
patching) has been thrown out the window. Even if a vendor does
all the security patching before it goes live, it is up to the
Customer to keep on top of the heavily distributed (large VMware
farms are also distributed computing) world of commodity OS
security patching.

Hence, we now live in a world of "patch-n-pray".

Some lottery folks a few years back told me very directly - they
have regulatory rules that state all vendor security patches
above a certain level (important?) must be installed within 45
days. While their OpenVMS systems are rock solid from a known and
published security threats perspective, with their production
commodity OS's, they really have no options - they need to patch
their prod systems, reboot (there are always a few kernel
security issues in the monthly batch) and pray nothing breaks.

Welcome to the new world of mission critical computing.

Yes, OpenVMS needs lots of security improvements (including
recent discussions here like security bug reporting etc.), but if
OpenVMS ever gets to the point where it needs 20-30+ security
patches each and every month, then we are all in for some
extremely tough times.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Stephen Hoffman
2017-01-03 16:33:16 UTC
Permalink
Raw Message
No platform is 100% secure (yes, including OpenVMS), but due to the
sheer volume of 20-30+ security patches per month associated with
commodity OS platforms, the decades old best practice of testing
important apps before patching (especially security patching) has been
thrown out the window. Even if a vendor does all the security patching
before it goes live, it is up to the Customer to keep on top of the
heavily distributed (large VMware farms are also distributed computing)
world of commodity OS security patching.
Hence, we now live in a world of "patch-n-pray".
Ayup. More than a few folks are still approaching this problem as DEC
did too, back in the 1990s. Folks looking at these issues are working
to automate the patch distribution, and working on improving software
scanning — source code, fuzzers, etc — and on isolating breaches —
sandboxes/jails, SGX, etc — and other efforts. Work on coordinating
responses and on distributed logging and related efforts is also
underway. Toward expecting and responding to breaches. Toward
working across clusters, and across whole networks, and toward
isolating networks into smaller hunks and bastion hosts. Containers
and VM guests for faster reloads and restarts, while sorting out
whatever the issue was. The OpenVMS patch notification, distribution
and installation sequences are just absurdly manual processes, too.

Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems
Some lottery folks a few years back told me very directly - they have
regulatory rules that state all vendor security patches above a certain
level (important?) must be installed within 45 days. While their
OpenVMS systems are rock solid from a known and published security
threats perspective, with their production commodity OS's, they really
have no options - they need to patch their prod systems, reboot (there
are always a few kernel security issues in the monthly batch) and pray
nothing breaks.
This is not particularly different on OpenVMS. More than a few of us
defer updates because of the fear of breakage — UPDATE patches have
gotten pretty good, but more than a few of us still have concerns
around those — and there are times when we still have to patch OpenVMS
and test what we can and roll out quickly. That 45 day window for
applying patches is exceptionally generous, too. I've seen more than
a few attacks arrive ahead of the patches, and that's only going to
become more common.

Just counting CVEs doesn't provide a clear picture of any platform.
There are quite a few bugs that exist in software used on OpenVMS that
haven't been patched (on OpenVMS), too. Those cross-platform CVEs
aren't difficult to locate, for anyone inclined to do a little basic
research. CVEs can also mask larger numbers of errors — I'm aware of a
case where a vendor used one CVE to cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.
Welcome to the new world of mission critical computing.
Ayup. OpenVMS or otherwise.
--
Pure Personal Opinion | HoffmanLabs LLC
Kerry Main
2017-01-03 18:38:49 UTC
Permalink
Raw Message
-----Original Message-----
Of Stephen Hoffman via Info-vax
Sent: 03-Jan-17 11:33 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.
Post by Kerry Main
No platform is 100% secure (yes, including OpenVMS), but due
to the
Post by Kerry Main
sheer volume of 20-30+ security patches per month associated
with
Post by Kerry Main
commodity OS platforms, the decades old best practice of
testing
Post by Kerry Main
important apps before patching (especially security patching)
has been
Post by Kerry Main
thrown out the window. Even if a vendor does all the security
patching before it goes live, it is up to the Customer to keep on
top
Post by Kerry Main
of the heavily distributed (large VMware farms are also
distributed
Post by Kerry Main
computing) world of commodity OS security patching.
Hence, we now live in a world of "patch-n-pray".
Ayup. More than a few folks are still approaching this problem as DEC
did too, back in the 1990s. Folks looking at these issues are working
to automate the patch distribution, and working on improving
software scanning — source code, fuzzers, etc — and on isolating
breaches —
sandboxes/jails, SGX, etc — and other efforts.
Security zoning has been around for decades with FW's. The challenge with FW's is increased complexity with TCPIP mgmt. (each zone has different subnet) and difficulty in change management associated with adding, maintaining and deleting rules (ok, deleting rules takes an act of CEO level, but that’s another discussion).

Of course tools help with distribution of patches (once tested), but they do not help with change mgmt. or testing of important applications. CAB meetings and chg mgmt. processes paperwork to implement a change (even with a tool) are on par with getting teeth pulled with no antiseptic. Add a rule - get a chg request in place, get it approved, scheduled, implemented and tested.
Work on
coordinating
responses and on distributed logging and related efforts is also
underway. Toward expecting and responding to breaches.
Distributed logging is nothing new. An OpenVMS based lottery currently bringing in about $2B/year has this implemented today. Every key entered on a system is sent (along with logs) to a different system maintained by an outside auditing group separate from Operations.
Toward
working across clusters, and across whole networks, and toward
isolating networks into smaller hunks and bastion hosts.
Again, while I generally agree with zoning as a means to limit risks, there is also a trade-off as to many zones results in support complexity which will likely decrease the overall security.

I do agree there needs to be more directory based / identity management security controls and auditing which is multi-platform, multi-vendor based.
Containers
and VM guests for faster reloads and restarts, while sorting out
whatever the issue was. The OpenVMS patch notification,
distribution
and installation sequences are just absurdly manual processes,
too.
Agree there is room for improvement.
Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems
Highly experimental UNIX only relying on open source participation - no mention of what impact it would have on Applications and App designs. They do infer that devices DMA should be turned OFF unless it is a trusted device, so I am not sure what to make of that aspect.
Post by Kerry Main
Some lottery folks a few years back told me very directly - they
have
Post by Kerry Main
regulatory rules that state all vendor security patches above a
certain level (important?) must be installed within 45 days.
While
Post by Kerry Main
their OpenVMS systems are rock solid from a known and
published
Post by Kerry Main
security threats perspective, with their production commodity
OS's,
Post by Kerry Main
they really have no options - they need to patch their prod
systems,
Post by Kerry Main
reboot (there are always a few kernel security issues in the
monthly
Post by Kerry Main
batch) and pray nothing breaks.
This is not particularly different on OpenVMS. More than a few of us
defer updates because of the fear of breakage — UPDATE
patches have gotten pretty good, but more than a few of us still
have concerns around those — and there are times when we still
have to patch OpenVMS
and test what we can and roll out quickly. That 45 day window for
applying patches is exceptionally generous, too. I've seen more than
a few attacks arrive ahead of the patches, and that's only going to
become more common.
Just counting CVEs doesn't provide a clear picture of any
platform.
There are quite a few bugs that exist in software used on
OpenVMS that haven't been patched (on OpenVMS), too. Those
cross-platform CVEs aren't difficult to locate, for anyone inclined
to do a little basic research. CVEs can also mask larger numbers of
errors — I'm aware of a case where a vendor used one CVE to
cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.
Again - OpenVMS is not 100% secure (NO platform is), but the number of *documented* (read published) security issues with OpenVMS is far, far less than commodity OS's. It's about the VOLUME that causes "patch-n-pray" processes. Documented security issues are what Customers have to address for legal and/or auditing purposes - not might, or could be or what-if scenarios (no matter if valid or not).
Post by Kerry Main
Welcome to the new world of mission critical computing.
Ayup. OpenVMS or otherwise.
Because it is a different culture, I highly doubt many OpenVMS shops would employ patch-n-pray policies with their production environments. Likely the same could be said for Solaris, NonStop, z/OS and other, what I would call "enterprise", platforms.

Patch-n-pray is specific to commodity OS platforms.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-01-03 20:11:28 UTC
Permalink
Raw Message
Post by Kerry Main
-----Original Message-----
Of Stephen Hoffman via Info-vax
Sent: 03-Jan-17 11:33 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.
Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems
Highly experimental UNIX only relying on open source participation -
no mention of what impact it would have on Applications and App
designs. They do infer that devices DMA should be turned OFF unless it
is a trusted device, so I am not sure what to make of that aspect.
It's not Unix. It's a capability based microkernel which can run a
Unix personality but can also run other personalities.

The DMA issue is a known issue in computer security when you can't
be sure if the hardware can be trusted.
Post by Kerry Main
Just counting CVEs doesn't provide a clear picture of any
platform.
There are quite a few bugs that exist in software used on
OpenVMS that haven't been patched (on OpenVMS), too. Those
cross-platform CVEs aren't difficult to locate, for anyone inclined
to do a little basic research. CVEs can also mask larger numbers of
errors — I'm aware of a case where a vendor used one CVE to
cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.
Again - OpenVMS is not 100% secure (NO platform is), but the number
of *documented* (read published) security issues with OpenVMS is far,
far less than commodity OS's. It's about the VOLUME that causes
"patch-n-pray" processes. Documented security issues are what
Customers have to address for legal and/or auditing purposes - not
might, or could be or what-if scenarios (no matter if valid or not).
Have any VMS security issues ever been "quietly fixed" over the years
without any public CVEs being issued for them ? That's a question, not
an accusation, BTW.

Illusion of security is not the same thing as actual security.
A low patch count could simply be one of:

1) People not probing VMS at the same rate and intensity as they do
other operating systems.

2) Patches not being issued at the same rate as issues are discovered
(TCP/IP comes to mind here.)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2017-01-03 21:21:23 UTC
Permalink
Raw Message
Post by Simon Clubley
Have any VMS security issues ever been "quietly fixed" over the years
without any public CVEs being issued for them ? That's a question, not
an accusation, BTW.
For a recent and public example of security-relevant fixes without
OpenVMS-associated CVEs, the VSI port of the Apache 2.4.14 version
would have fixed a number of Apache CVEs in the older version, but
AFAIK those Apache CVEs were not updated to reflect applicability of
OpenVMS nor the fix, and no associated OpenVMS-specific CVEs were
issued; they'd not show up in OpenVMS-related CVE counts. For
additional examples with various open CVEs — few or none of which track
OpenVMS, and I'd expect that at least the denial-of-service and similar
bugs with CVEs to (also) apply to OpenVMS — have a look at the version
of ISC BIND integrated into TCP/IP Services, or the NTP server. There
are also security reports against SMH citing other SMH-supported
platforms, and — where there have been reproducers — I've verified some
also effect SMH on OpenVMS.

No CVE listed in the following OpenVMS fixes, either:

http://www.securityfocus.com/advisories/8174
http://www.securityfocus.com/advisories/3630
http://seclists.org/bugtraq/2012/Apr/115
https://cxsecurity.com/issue/WLB-2010120174

Or search for security-related discussions here in the comp.os.vms
newsgroup involving Andrew Harrison.

It only takes one open hole — associated CVE or otherwise — to ruin
your whole day, too. Or one slow-to-arrive or slow-to-be-applied
patch, for that matter.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2017-01-03 20:28:22 UTC
Permalink
Raw Message
Post by Kerry Main
-----Original Message-----
Of Stephen Hoffman via Info-vax
Sent: 03-Jan-17 11:33 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.
Post by Kerry Main
...
...More than a few folks are still approaching this problem as DEC did
too, back in the 1990s. Folks looking at these issues are working to
automate the patch distribution, and working on improving software
scanning — source code, fuzzers, etc — and on isolating breaches —
sandboxes/jails, SGX, etc — and other efforts.
Security zoning has been around for decades with FW's. The challenge
with FW's is increased complexity with TCPIP mgmt. (each zone has
different subnet) and difficulty in change management associated with
adding, maintaining and deleting rules (ok, deleting rules takes an act
of CEO level, but that’s another discussion).
The challenge with firewalls is increasingly that the attacks have
evolved, and that firewalls and traditional network design increasingly
isn't effective — well, firewalls do demarcate the edge of the network.
Zones are proliferating. Anti-virus is in roughly the same state,
too. Folks think they need that, but antivirus can itself end up being
a much bigger target for attackers — more than a few AV packages have
complex code and even parsers running in kernel mode processing
untrusted input, and which is just nuts — and increasingly doesn't
provide what folks want and install the package for.

Then there are the associated discussions around not having information
around, and how sometimes breaches can hose internal and variously
external folks; groups of folks that the IT organization either ignored
or might even have never contemplated the results of breaches.

And if it takes a CEO-level decision to delete a firewall rule? The
CEO has either just found another project to deal with and delegate, or
the board needs to re-focus or replace the CEO. Now the CEO probably
should be working to expunge data, and to age out and remove firewall
rules. To make that whole review and deprecation and expungement
process easier, and — in more complex and larger organizations — even
automatic.
Post by Kerry Main
Of course tools help with distribution of patches (once tested), but
they do not help with change mgmt. or testing of important
applications. CAB meetings and chg mgmt. processes paperwork to
implement a change (even with a tool) are on par with getting teeth
pulled with no antiseptic. Add a rule - get a chg request in place, get
it approved, scheduled, implemented and tested.
Bad management is bad management. Bad management can hose a business
without the assistance of computers and software. Computers can just
make it easier for management to hose a business.
Post by Kerry Main
Work on coordinating responses and on distributed logging and related
efforts is also underway. Toward expecting and responding to breaches.
Distributed logging is nothing new. An OpenVMS based lottery currently
bringing in about $2B/year has this implemented today. Every key
entered on a system is sent (along with logs) to a different system
maintained by an outside auditing group separate from Operations.
Write-up on detecting admin breaches:
https://medium.com/starting-up-security/learning-from-the-expedia-heist-6cf8a0069ce0


Logging is not something that OpenVMS does well and doesn't play at all
well with others. Various of us have written work-arounds, ported
loggers or whatever. OpenVMS itself doesn't play at all, between
Apache and other tools and OpenVMS itself, nor across non-clustered
OpenVMS servers, nor across clusters, nor with firewalls or otherwise.
Post by Kerry Main
Toward working across clusters, and across whole networks, and toward
isolating networks into smaller hunks and bastion hosts.
Again, while I generally agree with zoning as a means to limit risks,
there is also a trade-off as to many zones results in support
complexity which will likely decrease the overall security.
We're headed toward individual hosts and smaller subnets, which means
we have to get better about automating and managing those.
Post by Kerry Main
I do agree there needs to be more directory based / identity management
security controls and auditing which is multi-platform, multi-vendor
based.
That needs to be the primary and preferred path. Whether running
self-hosted, or hosted on Active Directory or Open Directory or other
LDAP and Kerberos servers. Not via SYSUAF, et al.
Post by Kerry Main
Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems
Highly experimental UNIX only relying on open source participation - no
mention of what impact it would have on Applications and App designs.
They do infer that devices DMA should be turned OFF unless it is a
trusted device, so I am not sure what to make of that aspect.
OpenVMS is also using open source, and there's little choice other than
to get better about that. As for securing across boxes, have a look
at the discussions around Qubes, around Rowhammer, and around SGX.
This hardware stuff is really gnarly, when trusted and untrusted (or
breached) software is mixed on the box. OpenVMS hasn't had to deal
with this in the past (beyond vulnerable services), but we're all
headed in that direction with more than a few OpenVMS servers.

Visit the about page. "seL4 is a high-assurance, high-performance
microkernel developed, maintained and formally verified by NICTA and
owned by General Dynamics C4 Systems."
Post by Kerry Main
Just counting CVEs doesn't provide a clear picture of any platform.
There are quite a few bugs that exist in software used on OpenVMS that
haven't been patched (on OpenVMS), too. Those cross-platform CVEs
aren't difficult to locate, for anyone inclined to do a little basic
research. CVEs can also mask larger numbers of errors — I'm aware of a
case where a vendor used one CVE to cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.
Again - OpenVMS is not 100% secure (NO platform is), but the number of
*documented* (read published) security issues with OpenVMS is far, far
less than commodity OS's. It's about the VOLUME that causes
"patch-n-pray" processes. Documented security issues are what Customers
have to address for legal and/or auditing purposes - not might, or
could be or what-if scenarios (no matter if valid or not).
One hole is enough. Sometimes one hole in another box in the same
subnet, and as is surprisingly common. Which then opens up access to
supposedly "protected systems". Which means it's as much about
whether the vendor plugs the holes expeditiously. Again, when one of
the premier OpenVMS network storage transports (NI SCS) is unencrypted
and unauthenticated, and when DECnet is similarly problematic, you
don't even need CVEs to gain further access into supposedly-protected
systems. No CVE required.

Given what I know of CVEs, I'd be very wary about any marketing and any
claims around CVEs and vendor security, too. From any vendor. Much
like other metrics used to mismanage and mis-goal individuals and
organizations, measuring CVEs doesn't tell a particularly useful story.
CVE counts quite commonly mislead. Which might be good for vendor
marketing — in the short-term, at least — but not so good for the
end-users, or for the long-term marketing for the vendor.
Post by Kerry Main
Post by Kerry Main
Welcome to the new world of mission critical computing.
Ayup. OpenVMS or otherwise.
Because it is a different culture, I highly doubt many OpenVMS shops
would employ patch-n-pray policies with their production environments.
Likely the same could be said for Solaris, NonStop, z/OS and other,
what I would call "enterprise", platforms.
Patch-n-pray is specific to commodity OS platforms.
It's increasingly arising with OpenVMS, too. Because we're all under
pressure to reduce overhead, to reduce staff, to reduce hardware and
licensing costs, to automate, to deploy patches much more quickly, and
related. A team of six might have once supervised a dozen systems
from one or two vendors, now that team is five people and supervising a
hundred systems from a dozen different vendors. We ain't headed any
other way unfortunately, which means everybody has to get better about
avoiding regressions, and about dealing with regressions when they
arise. Again. the HPE UPDATE patches have been pretty around not
introducing regressions, too. As that trust — an opportunity for VSI,
and for future VSI marketing — increases, folks will be more willing to
roll out patches more quickly, and with fewer checks, too.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2017-01-03 20:44:59 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by Kerry Main
Again - OpenVMS is not 100% secure (NO platform is), but the number of
*documented* (read published) security issues with OpenVMS is far, far
less than commodity OS's. It's about the VOLUME that causes
"patch-n-pray" processes. Documented security issues are what Customers
have to address for legal and/or auditing purposes - not might, or
could be or what-if scenarios (no matter if valid or not).
One hole is enough. Sometimes one hole in another box in the same
subnet, and as is surprisingly common. Which then opens up access to
supposedly "protected systems". Which means it's as much about
whether the vendor plugs the holes expeditiously. Again, when one of
the premier OpenVMS network storage transports (NI SCS) is unencrypted
and unauthenticated, and when DECnet is similarly problematic, you
don't even need CVEs to gain further access into supposedly-protected
systems. No CVE required.
To emphasise that: once you compromise any general purpose OS based
system on the same LAN, you can now start attacking and monitoring
the various LAN only protocols that the VMS systems might be running.

When I briefly looked at DECnet Phase IV the other month, my research
was limited to affecting VMS operations by throwing various malformed
packets at the test system. I simply wasn't interested in other goals
such as password or data gathering because I already knew that DECnet
Phase IV was totally compromised in that area once you had that level
of access.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Johnny Billquist
2017-01-03 21:43:33 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Stephen Hoffman
Post by Kerry Main
Again - OpenVMS is not 100% secure (NO platform is), but the number of
*documented* (read published) security issues with OpenVMS is far, far
less than commodity OS's. It's about the VOLUME that causes
"patch-n-pray" processes. Documented security issues are what Customers
have to address for legal and/or auditing purposes - not might, or
could be or what-if scenarios (no matter if valid or not).
One hole is enough. Sometimes one hole in another box in the same
subnet, and as is surprisingly common. Which then opens up access to
supposedly "protected systems". Which means it's as much about
whether the vendor plugs the holes expeditiously. Again, when one of
the premier OpenVMS network storage transports (NI SCS) is unencrypted
and unauthenticated, and when DECnet is similarly problematic, you
don't even need CVEs to gain further access into supposedly-protected
systems. No CVE required.
To emphasise that: once you compromise any general purpose OS based
system on the same LAN, you can now start attacking and monitoring
the various LAN only protocols that the VMS systems might be running.
When I briefly looked at DECnet Phase IV the other month, my research
was limited to affecting VMS operations by throwing various malformed
packets at the test system. I simply wasn't interested in other goals
such as password or data gathering because I already knew that DECnet
Phase IV was totally compromised in that area once you had that level
of access.
I definitely had some issues with that research, though.

It was on the level of knocking in open doors. Very similar to, for
example, ARP cache poisoning in IP. It is trivial to take down IPv4 by
poisoning the ARP cache.
You can obviously disrupt network traffic in any number of ways if you
can inject packets on a local network.
DECnet or IP makes no difference.

You can also disrupt processing by just pulling the plug.
What does that prove?

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Simon Clubley
2017-01-03 21:57:48 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by Simon Clubley
To emphasise that: once you compromise any general purpose OS based
system on the same LAN, you can now start attacking and monitoring
the various LAN only protocols that the VMS systems might be running.
When I briefly looked at DECnet Phase IV the other month, my research
was limited to affecting VMS operations by throwing various malformed
packets at the test system. I simply wasn't interested in other goals
such as password or data gathering because I already knew that DECnet
Phase IV was totally compromised in that area once you had that level
of access.
I definitely had some issues with that research, though.
It was on the level of knocking in open doors. Very similar to, for
example, ARP cache poisoning in IP. It is trivial to take down IPv4 by
poisoning the ARP cache.
Yes, I know. As I've said multiple times, I didn't spend a lot of time
on it so that's about as deep as I got.
Post by Johnny Billquist
You can obviously disrupt network traffic in any number of ways if you
can inject packets on a local network.
DECnet or IP makes no difference.
The major surprise for me was that the VMS DECnet Phase IV
implementation running on the target node trusts external packets
with a source address that claims to be the address of the
target node. _That_ I was not expecting to see.

When you do ARP cache poisoning, you are poisoning the cache as
it relates to other nodes on the network (as seen from the
target node) and not the target node itself.
Post by Johnny Billquist
You can also disrupt processing by just pulling the plug.
What does that prove?
That you should have put a lock on your computer room door. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Johnny Billquist
2017-01-03 22:22:59 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Johnny Billquist
You can obviously disrupt network traffic in any number of ways if you
can inject packets on a local network.
DECnet or IP makes no difference.
The major surprise for me was that the VMS DECnet Phase IV
implementation running on the target node trusts external packets
with a source address that claims to be the address of the
target node. _That_ I was not expecting to see.
Well, that is better than ARP, which trust any packet from anywhere,
claiming anything. You can put *anything* as a source in an ARP packet,
and it will be accepted. And you can put *anything* in the various
fields of the ARP packet, and that will be placed in the cache.
Post by Simon Clubley
When you do ARP cache poisoning, you are poisoning the cache as
it relates to other nodes on the network (as seen from the
target node) and not the target node itself.
Uh? You are fooling the target node to send packets destined for one
host to be sent to someone completely different, possibly a black hole.
Why is it that is being hurt? I'd say the target node.

A similar issue is poisoning the routing table by sending RIP packets.
No checking at all is done. So you don't even have to fake any source
addresses there either.

Your DECnet injection did the same. Fooling the target node how to reach
next hops by messing up the routing table.

Very many protocols, for different network stacks, at some point just
accepts packets from neighbors. I fail to see that DECnet is either
better or worse than anything else here.
Post by Simon Clubley
Post by Johnny Billquist
You can also disrupt processing by just pulling the plug.
What does that prove?
That you should have put a lock on your computer room door. :-)
Indeed. :-)

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Stephen Hoffman
2017-01-03 22:02:32 UTC
Permalink
Raw Message
...once you compromise any general purpose OS based system on the same
LAN, you can now start attacking and monitoring...
FWIW, who needs to start the server compromise with a general-purpose
operating system? Just use a (now down-revision) printer for that...




One bad PDF sent to an internal user and then printed on a
down-revision printer, and network deflagration commences.

There are other and equally clever attacks against other network boxes
— all sorts of stuff "behind a firewall" can be vulnerable.
--
Pure Personal Opinion | HoffmanLabs LLC
j***@yahoo.co.uk
2017-01-03 21:41:24 UTC
Permalink
Raw Message
Post by Stephen Hoffman
No platform is 100% secure (yes, including OpenVMS), but due to the
sheer volume of 20-30+ security patches per month associated with
commodity OS platforms, the decades old best practice of testing
important apps before patching (especially security patching) has been
thrown out the window. Even if a vendor does all the security patching
before it goes live, it is up to the Customer to keep on top of the
heavily distributed (large VMware farms are also distributed computing)
world of commodity OS security patching.
Hence, we now live in a world of "patch-n-pray".
Ayup. More than a few folks are still approaching this problem as DEC
did too, back in the 1990s. Folks looking at these issues are working
to automate the patch distribution, and working on improving software
scanning — source code, fuzzers, etc — and on isolating breaches —
sandboxes/jails, SGX, etc — and other efforts. Work on coordinating
responses and on distributed logging and related efforts is also
underway. Toward expecting and responding to breaches. Toward
working across clusters, and across whole networks, and toward
isolating networks into smaller hunks and bastion hosts. Containers
and VM guests for faster reloads and restarts, while sorting out
whatever the issue was. The OpenVMS patch notification, distribution
and installation sequences are just absurdly manual processes, too.
Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems
Some lottery folks a few years back told me very directly - they have
regulatory rules that state all vendor security patches above a certain
level (important?) must be installed within 45 days. While their
OpenVMS systems are rock solid from a known and published security
threats perspective, with their production commodity OS's, they really
have no options - they need to patch their prod systems, reboot (there
are always a few kernel security issues in the monthly batch) and pray
nothing breaks.
This is not particularly different on OpenVMS. More than a few of us
defer updates because of the fear of breakage — UPDATE patches have
gotten pretty good, but more than a few of us still have concerns
around those — and there are times when we still have to patch OpenVMS
and test what we can and roll out quickly. That 45 day window for
applying patches is exceptionally generous, too. I've seen more than
a few attacks arrive ahead of the patches, and that's only going to
become more common.
Just counting CVEs doesn't provide a clear picture of any platform.
There are quite a few bugs that exist in software used on OpenVMS that
haven't been patched (on OpenVMS), too. Those cross-platform CVEs
aren't difficult to locate, for anyone inclined to do a little basic
research. CVEs can also mask larger numbers of errors — I'm aware of a
case where a vendor used one CVE to cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.
Welcome to the new world of mission critical computing.
Ayup. OpenVMS or otherwise.
--
Pure Personal Opinion | HoffmanLabs LLC
Re seL4:
Any paper which talks about proof of correctness of any
non-trivial software system without acknowledging the
existence of the famous quote "Beware of bugs in the
above code; I have only proved it correct, not tried it"
is likely to get a thumbs down from people with a clue.

Same for something which references a "proof of
correctness of a realistic compiler". My first
employer spent many years in safety critical embedded
software which could do non-trivial things using simple
(testable, sometimes provable) combinations of provable
and testable components, without the unprovable and
untestable complexities of a compiler.

These days the compiler trustworthiness topic is likely
to be conveniently (and silently) ignored.


There are some interesting bits in the paper though. E.g.
some of the starting points: keep the attack surface
small and well characterised (arguably applies to much
of VMS, less so to commodity OSes), build bigger systems
from a collection of smaller trusted components (did that
in the 1980s thank you), microkernel approach (not
widely applicable in general, exceptions may apply, and
beware of some 'modern' approaches which appear to use
the words 'hypervisor' and 'microkernel' interchangeably,
as though they meant the same - but do they?).

The endgame is also laudable: "strong, code/machine level
guarantees as table stakes for highly critical systems."

This bit: "Leveraging separation kernels to create high
assurance architectures with formally verified software
components, as outlined in this paper, provides a means
to implement such systems with measurable security
enhancements." is interesting. It's the one which
Dilbert might generally replace with "a miracle occurs
here".

There's at least one major builder of aircraft safety
critical systems who would like to build their near-future
systems built using model-based engineering techniques
including model based software engineering. And why not.

What's less obviously satisfactory is that this company
would like to be testing (and maybe proving) the behaviour
of the *model* of the system. So a component swap (from,
say, one GCC version to another) doesn't have any
implications, as long as the changed components have
equivalent formal specifications and formal proofs.

Not that GCC or any other significant code generator is
meaningfully provable, but that's another story (see
the opening quote re proof vs testing, and Thompson's
tales on "Trusting Trust", amongst others).

Don't take my word for this, have a look at this
analysis of some of the claims of the Qubes and
seL4 folk:
http://theinvisiblethings.blogspot.co.uk/2010/05/on-formally-verified-microkernels-and.html

Some people/organisations might even want to look at
(say) a modernised Orange Book-style system as well as
new unproven (sic) allegedly-from-scratch stuff like
seL4, Qubes, etc.

The devil is in the detail, not in the Powerpoint or
the white papers or even the bogs (but I could quite
like ones like the one from theinvisiblethings above).
Bob Koehler
2017-01-04 14:34:40 UTC
Permalink
Raw Message
Post by j***@yahoo.co.uk
These days the compiler trustworthiness topic is likely
to be conveniently (and silently) ignored.
That depends on the field. I've worked with some that required
certified versions of the OS, the compiler, the chip, ...
j***@yahoo.co.uk
2017-01-04 15:15:08 UTC
Permalink
Raw Message
Post by Bob Koehler
Post by j***@yahoo.co.uk
These days the compiler trustworthiness topic is likely
to be conveniently (and silently) ignored.
That depends on the field. I've worked with some that required
certified versions of the OS, the compiler, the chip, ...
Certification and trustworthiness are unfortunately
not entirely the same thing - as you say, maybe
it depends on the field, the regulatory rules, etc.

I don't know where your experience is, but e.g.
avionic systems certified to DO178 (SW) and DO254
(electronic hardware) etc cannot be trusted to be
defect free and to do the right thing, despite
the certification paperwork.

I'll be delighted to hear that other sectors take
this more seriously.
Bob Koehler
2017-01-04 22:02:21 UTC
Permalink
Raw Message
Post by j***@yahoo.co.uk
Certification and trustworthiness are unfortunately
not entirely the same thing - as you say, maybe
it depends on the field, the regulatory rules, etc.
I don't know where your experience is, but e.g.
avionic systems certified to DO178 (SW) and DO254
(electronic hardware) etc cannot be trusted to be
defect free and to do the right thing, despite
the certification paperwork.
I'll be delighted to hear that other sectors take
this more seriously.
I dabbled in manned space flight when I ran into the requirement.
It's part of making sure there's a quite high likelyhood of success.
It's a small part of a very serious undertaking, which newbies like
SpaceX are trying to streamline.
David Froble
2017-01-03 15:48:20 UTC
Permalink
Raw Message
Post by j***@yahoo.co.uk
Post by IanD
Post by Simon Clubley
Post by IanD
Maybe VSI should put you on the marketing payroll...
VSI has a _marketing_ payroll ??? Are you sure about that ?
I was going to say something a little more harsh but decided to keep tings light instead
I don't know why information such as what was posted is not on their main website because it's good. I would not have asked half the questions I did about the new file system had i seen this material and I have only looked at 2 items so far!
Marketing may be a black hole but I think more marketing than what we have seen to date is sorely needed
As to memorabilia owned...
My wife had a Digital umbrella up until the point where I borrowed it and accidentally left it on a train. That loss hurt for a long time...
I remember getting a set of Digital Golf Balls which I gave away to someone who played gold at the time. If I remember rightly, they were Dunlop brand. In a box of 12 I think. too long ago to remember properly
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)
I have an HP Invent coffee mug. Well, I think that's what it
was. Over the years, through relatively infrequent use, the
whole printed logo has vanished, perhaps as though it was a
mirage. Maybe it wasn't properly specified and tested, good
job computer systems aren't built like that. Or are they?
Also mirage-like, over the years, the alleged benefits of
switching to "low cost" software (Windows etc) in critical
cases have sometimes vanished. London Ambulance Service
were reminded of this on New Years Eve when their ambulance
dispatch service fell over and manual (paper) operation
was required for five hours, on the busiest night of the
year.
Sadly for LAS, it wasn't the first time this has happened
with their implementation of Northrop Grumman's CommandPoint
system, and it likely won't be the last. I don't suppose
the supplier will end up with any meaningful financial
penalty though; a system that's defective by design seems
to be acceptable modern practice.
London's Metropolitan Police were luckier, in a way, with
their implementation of CommandPoiunt. They didn't get as
far as rolling out CommandPoint before cancelling the
project (2016).
Isn't there some nice shiny AI tool out there yet that can
readily specify, design, rollout, and manage these critical
systems in a robust secure trustworthy and idiot-resistant
manner?
I left out "test" deliberately, the modern approach seems to
be to let the customer do the testing, preferably after the
system is paid for. Real testing seems to be a bit "20th
century". As for coding: any idiot can do that given a decent
IDE, can't they. No knowledge or understanding required,
neither of the business requirements nor of the appropriate
implementation technologies.
Now, now, no reason to be so bitter ....

On second thought ....
Bob Koehler
2017-01-03 15:33:53 UTC
Permalink
Raw Message
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)
I still have a Chrlie Matco cup.
Johnny Billquist
2017-01-03 21:36:05 UTC
Permalink
Raw Message
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
IanD
2017-01-04 05:04:11 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol
I didn't realise this - thanks

I always thought it was this

https://goo.gl/images/DSfycR

I'm trying to think when I first started all those years ago what colour the manuals were. I think they were that ghastly orange

Clearly i don't go back far enough lol. I was fairly young back then, about 10+ years younger than most people in the Dec world at the time
Johnny Billquist
2017-01-04 09:49:38 UTC
Permalink
Raw Message
Post by IanD
Post by Johnny Billquist
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol
I didn't realise this - thanks
I always thought it was this
https://goo.gl/images/DSfycR
That is the new logo Palmer introduced in the 90s. Ugly one... :-)
Post by IanD
I'm trying to think when I first started all those years ago what colour the manuals were. I think they were that ghastly orange
Clearly i don't go back far enough lol. I was fairly young back then, about 10+ years younger than most people in the Dec world at the time
Yeah. You must be young... :-D

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Bill Gunshannon
2017-01-04 12:57:59 UTC
Permalink
Raw Message
Post by IanD
Post by Johnny Billquist
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol
I didn't realise this - thanks
I always thought it was this
https://goo.gl/images/DSfycR
I'm trying to think when I first started all those years ago what colour the manuals were. I think they were that ghastly orange
Nope, Blue came first. I still have my Blue RT-11 and RSTS manuals
right next to my Orange RSTS/E manuals. :-)
Post by IanD
Clearly i don't go back far enough lol. I was fairly young back then, about 10+ years younger than most people in the Dec world at the time
And I happily admit that in this world I am truly a dinosaur.

bill
Arne Vajhøj
2017-01-10 01:15:38 UTC
Permalink
Raw Message
Post by IanD
Post by Johnny Billquist
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern
on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.
I didn't realise this - thanks
I always thought it was this
https://goo.gl/images/DSfycR
Clearly i don't go back far enough lol. I was fairly young back then, about
10+ years younger than most people in the Dec world at the time
I remember when they sent out a letter to all customers saying that
they were changing the color from blue illustrating cold hardware
focus to red illustrating warm people focus.

I think many VMS people almost fall of the chair reading such crap.

Arne
Kerry Main
2017-01-10 01:28:37 UTC
Permalink
Raw Message
-----Original Message-----
Arne Vajhøj via Info-vax
Sent: January 9, 2017 8:16 PM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.
On Wednesday, January 4, 2017 at 8:36:05 AM UTC+11, Johnny
Post by Johnny Billquist
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral
type
Post by Johnny Billquist
Post by IanD
pattern
on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.
I didn't realise this - thanks
I always thought it was this
https://goo.gl/images/DSfycR
Clearly i don't go back far enough lol. I was fairly young back
then,
about
10+ years younger than most people in the Dec world at the time
I remember when they sent out a letter to all customers saying that
they were changing the color from blue illustrating cold hardware
focus
to red illustrating warm people focus.
I think many VMS people almost fall of the chair reading such crap.
Arne
Real reason was the marketecture gurus at the time thought blue was
too close to "Big Blue" - the other computer company.

They wanted a way to differentiate DEC as IBM was who DEC was chasing
for the long term.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-01-10 18:26:10 UTC
Permalink
Raw Message
Post by Arne Vajhøj
I remember when they sent out a letter to all customers saying that
they were changing the color from blue illustrating cold hardware
focus to red illustrating warm people focus.
I think many VMS people almost fall of the chair reading such crap.
The one I remember shaking my head in disbelief at was when they
went from the grey wall for the V5 documentation set to the bound
books for V6 and they included a sheet in the V6 doc kit claiming
they were doing it to be green (or words to that effect).

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-01-04 07:21:32 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type
pattern on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.
Johnny
Back in 1973 our PDP 11/40 was not blue. I seem to remember red and black, but,
it's my memory, and such cannot be counted on anymore.

:-)

The PDP-6 at the University of Pittsburgh was grey, I believe ....
Johnny Billquist
2017-01-04 09:52:03 UTC
Permalink
Raw Message
Post by David Froble
Post by Johnny Billquist
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type
pattern on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.
Johnny
Back in 1973 our PDP 11/40 was not blue. I seem to remember red and
black, but, it's my memory, and such cannot be counted on anymore.
:-)
The PDP-6 at the University of Pittsburgh was grey, I believe ....
The computers all used different color schemes. PDP-11s usually had some
maroon/magenta scheme. PDP-12 were green. The list goes on...

However, the official DEC logo, and colors used on all material, and so
on, was blue. For a long, long time... And the dots above the i in
"Digital" were square. Until Palmer messed everything up.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
IanD
2017-01-04 23:28:20 UTC
Permalink
Raw Message
On Wednesday, January 4, 2017 at 8:52:05 PM UTC+11, Johnny Billquist wrote:

<snip>
Post by Johnny Billquist
The computers all used different color schemes. PDP-11s usually had some
maroon/magenta scheme. PDP-12 were green. The list goes on...
However, the official DEC logo, and colors used on all material, and so
on, was blue. For a long, long time... And the dots above the i in
"Digital" were square. Until Palmer messed everything up.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol
Now it's things like this that I find fascinating

Some may think it trivial but I find it interesting to know that not only the colours changes but even dots used on the i's - truly fascinating what people remember :-)

I wonder if those square dots were because of a font limitation or whether it was due to a translation from dot matrix design or for some other reason?

Seems to me that engineering folk back then took even little things like this into account
Simon Clubley
2017-01-05 01:11:17 UTC
Permalink
Raw Message
Post by IanD
Now it's things like this that I find fascinating
Some may think it trivial but I find it interesting to know that not
only the colours changes but even dots used on the i's - truly
fascinating what people remember :-)
If you like trival things :-), did you pick up on the fact that
the old blue logo is monospaced while the new Palmer logo is
proportional ?

A couple of other items of trivia that I thought every one else
around here knew, but since you didn't know about the blue logo,
here goes... :-)

The entrance to the old VMS facility in Nashua used to have a
two dimensional barcode sign. One day some management type
discovered that the two dimensional array of blocks they were
travelling past each day actually had meaning and ordered the
message to be changed to some inane marketing message.

Going back further, the various levels at the Mill had the
resistor colour codes painted on the walls so if you knew your
resistor colour codes, you could tell which level you were on
by looking at the colour painted on the wall.

Going back even further, I've seen claims that the PDPs were
called PDPs so that the word computer didn't appear anywhere
within the product's title. It was apparently a marketing
thing as in those days "computers" were perceived as big
expensive things...

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Alan Frisbie
2017-01-05 02:05:06 UTC
Permalink
Raw Message
Post by Simon Clubley
The entrance to the old VMS facility in Nashua used to have a
two dimensional barcode sign. One day some management type
discovered that the two dimensional array of blocks they were
travelling past each day actually had meaning and ordered the
message to be changed to some inane marketing message.
And when the bars were put back up, two of them were accidentally
(I assume) swapped, changing two letters. If anyone cares, I can
dig up photos of it, with the errors identified.

In late 1980s, the exterior of the DEC office building in Culver City
(Calif.) was refurbished. This required removing and re-installing
the "digital" letters near the top of the building. When they were
re-installed, they read "dgiital" for a few days. I have photos.

Alan Frisbie
Bob Koehler
2017-01-06 14:42:32 UTC
Permalink
Raw Message
Post by Alan Frisbie
In late 1980s, the exterior of the DEC office building in Culver City
(Calif.) was refurbished. This required removing and re-installing
the "digital" letters near the top of the building. When they were
re-installed, they read "dgiital" for a few days. I have photos.
Had a manager once who had a sign in his office:

HTE
IDIGATL
IDFFRENEEC
Simon Clubley
2017-01-06 18:17:13 UTC
Permalink
Raw Message
Post by Alan Frisbie
And when the bars were put back up, two of them were accidentally
(I assume) swapped, changing two letters. If anyone cares, I can
dig up photos of it, with the errors identified.
In late 1980s, the exterior of the DEC office building in Culver City
(Calif.) was refurbished. This required removing and re-installing
the "digital" letters near the top of the building. When they were
re-installed, they read "dgiital" for a few days. I have photos.
I would very much like to see both sets of photographs if it's
not too much work for you to post them.

Thanks,

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Alan Frisbie
2017-01-06 23:39:54 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Alan Frisbie
And when the bars were put back up, two of them were accidentally
(I assume) swapped, changing two letters. If anyone cares, I can
dig up photos of it, with the errors identified.
In late 1980s, the exterior of the DEC office building in Culver City
(Calif.) was refurbished. This required removing and re-installing
the "digital" letters near the top of the building. When they were
re-installed, they read "dgiital" for a few days. I have photos.
I would very much like to see both sets of photographs if it's
not too much work for you to post them.
I will dig them out and scan them, but it may take a while.

Alan
Simon Clubley
2017-01-09 00:03:41 UTC
Permalink
Raw Message
Post by Alan Frisbie
Post by Simon Clubley
Post by Alan Frisbie
And when the bars were put back up, two of them were accidentally
(I assume) swapped, changing two letters. If anyone cares, I can
dig up photos of it, with the errors identified.
In late 1980s, the exterior of the DEC office building in Culver City
(Calif.) was refurbished. This required removing and re-installing
the "digital" letters near the top of the building. When they were
re-installed, they read "dgiital" for a few days. I have photos.
I would very much like to see both sets of photographs if it's
not too much work for you to post them.
I will dig them out and scan them, but it may take a while.
Thank you, I appreciate that.

(However, although it would be nice to see them, I don't want you
to go to any major effort on my account, so I will gladly wait
until as and when it is convenient for you to scan them.)

Thanks once again,

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
j***@yahoo.co.uk
2017-01-05 09:14:58 UTC
Permalink
Raw Message
Post by IanD
<snip>
Post by Johnny Billquist
The computers all used different color schemes. PDP-11s usually had some
maroon/magenta scheme. PDP-12 were green. The list goes on...
However, the official DEC logo, and colors used on all material, and so
on, was blue. For a long, long time... And the dots above the i in
"Digital" were square. Until Palmer messed everything up.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol
Now it's things like this that I find fascinating
Some may think it trivial but I find it interesting to know that not only the colours changes but even dots used on the i's - truly fascinating what people remember :-)
I wonder if those square dots were because of a font limitation or whether it was due to a translation from dot matrix design or for some other reason?
Seems to me that engineering folk back then took even little things like this into account
As some people said at the time re the reshaping of the dot
on the 'i', "truly fascinating what some board-level people
will waste money on".

I don't recall a technical reason for it (fonts etc were all
custom anyway).
Paul Sture
2017-01-05 09:57:30 UTC
Permalink
Raw Message
Post by j***@yahoo.co.uk
Post by IanD
Some may think it trivial but I find it interesting to know that not
only the colours changes but even dots used on the i's - truly
fascinating what people remember :-)
I wonder if those square dots were because of a font limitation or
whether it was due to a translation from dot matrix design or for
some other reason?
Seems to me that engineering folk back then took even little things
like this into account
As some people said at the time re the reshaping of the dot
on the 'i', "truly fascinating what some board-level people
will waste money on".
A former colleague observed that in a large organisation, the closer you
get to Headquarters, the more money gets wasted.
Post by j***@yahoo.co.uk
I don't recall a technical reason for it (fonts etc were all
custom anyway).
My guess is that there was a proposal and accompanying study into a
completely new logo, which met much resistance. The change to the
dot will have been used to justify the cost.
--
"History does not repeat itself, but it does rhyme" -- Mark Twain
Stephen Hoffman
2017-01-05 14:18:07 UTC
Permalink
Raw Message
Post by IanD
Now it's things like this that I find fascinating
Some may think it trivial but I find it interesting to know that not
only the colours changes but even dots used on the i's - truly
fascinating what people remember :-)
And if you think folks remembering this DEC stuff is fascinating, find
and ask some other folks about steam trains. 2-5-2 has an entirely
different meaning over in that domain. Or ask about vintage
automobiles. Or needlepoint. Or chess. Or sporting teams. Or
clothing fashions. Or Mesoamerican cultures and constructions. Or
family histories. Or politics. Or.... People are like that in
areas that interest them, and remember a whole lot. Or at least think
they remember a whole lot. Sometimes. Maybe. I forget. What was
the discussion?
Post by IanD
I wonder if those square dots were because of a font limitation or
whether it was due to a translation from dot matrix design or for some
other reason?
Seems to me that engineering folk back then took even little things like this into account
Start here for some details of the bricks logo:
http://nedbatchelder.com/blog/200712/ancient_history_the_digital_logo.html
and then follow the metafilter link at the bottom of that through to
more arcana. BTW, the Maynard Mill was brick.

The Palmer-era burgundy bricks logo rework had more than a few
associated stories around its origins and costs, and a few wags
referred to that then-new burgundy logo color as "the color of dried
blood", alluding to the changes then happening in the company.

For some time, the pattern of the ZKO "bars" — the DEC Nashua site
located on Spit Brook Road, and not the concessionary at the Zurich
Chamber Orchestra — translated as:
digitalsoftwa
reengineering

DEC had standards for a whole lot of things, with copies of a few of
those now posted around the network. DEC Standard 32 was the VAX
architecture, and there were part-numbering standards and Unibus
standards and printer and terminal standards and... Lots and lots of
tech specs to read through. The OpenVMS documentation "wall" didn't
come from anywhere strange; DEC's preferred user interface was chapters
and chapters of detailed, technical prose, and matrix managers and
committees. The Engineering Handbook (1990 edition was the last) was
the introduction to the internal organization of the company.

http://bitsavers.trailing-edge.com/pdf/dec/vax/archSpec/EL-00032-00-decStd32_Jan90.pdf


DEC, however, is long gone, the competitive world that DEC operated in
is also long gone, and trying to mimic what DEC did will fail. Parts
of the DEC business model and organization and processes can be
salvaged and reused, but other parts and practices are best be avoided.
Avoid the fondness for creating what were sometimes known as Product
Prevention Committees, for one. VSI will be keeping the best bits of
DEC, but necessarily forgetting parts of DEC and even necessarily
discarding some of the good-but-dated DEC bits, if they are to succeed.
But I digress. There are books on DEC around, various of which have
been discussed here in the comp.os.vms newsgroup before. DEC is Dead
Long Live Dec is one that's been published, though I've not read it.
--
Pure Personal Opinion | HoffmanLabs LLC
Scott Dorsey
2017-01-05 14:27:20 UTC
Permalink
Raw Message
Post by Stephen Hoffman
DEC, however, is long gone, the competitive world that DEC operated in
is also long gone, and trying to mimic what DEC did will fail. Parts
of the DEC business model and organization and processes can be
salvaged and reused, but other parts and practices are best be avoided.
Avoid the fondness for creating what were sometimes known as Product
Prevention Committees, for one. VSI will be keeping the best bits of
DEC, but necessarily forgetting parts of DEC and even necessarily
discarding some of the good-but-dated DEC bits, if they are to succeed.
But I digress. There are books on DEC around, various of which have
been discussed here in the comp.os.vms newsgroup before. DEC is Dead
Long Live Dec is one that's been published, though I've not read it.
I highly recommend the book if you are curious about what went wrong with
DEC.

DEC's biggest competitor for a long time was itself, which was a problem.
When the killer micros came out they had actual third-party competition and
that was even more of a problem..
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Kerry Main
2017-01-05 15:49:04 UTC
Permalink
Raw Message
-----Original Message-----
Of Scott Dorsey via Info-vax
Sent: 05-Jan-17 9:27 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.
Post by Stephen Hoffman
DEC, however, is long gone, the competitive world that DEC
operated in
Post by Stephen Hoffman
is also long gone, and trying to mimic what DEC did will fail.
Parts
Post by Stephen Hoffman
of the DEC business model and organization and processes can
be
Post by Stephen Hoffman
salvaged and reused, but other parts and practices are best be
avoided.
Post by Stephen Hoffman
Avoid the fondness for creating what were sometimes known
as Product
Post by Stephen Hoffman
Prevention Committees, for one. VSI will be keeping the best
bits of
Post by Stephen Hoffman
DEC, but necessarily forgetting parts of DEC and even
necessarily
Post by Stephen Hoffman
discarding some of the good-but-dated DEC bits, if they are to
succeed.
Post by Stephen Hoffman
But I digress. There are books on DEC around, various of
which
have
Post by Stephen Hoffman
been discussed here in the comp.os.vms newsgroup before.
DEC is Dead
Post by Stephen Hoffman
Long Live Dec is one that's been published, though I've not
read
it.
I highly recommend the book if you are curious about what went
wrong with DEC.
DEC's biggest competitor for a long time was itself, which was
a
problem.
When the killer micros came out they had actual third-party
competition and that was even more of a problem..
--scott
Fyi -

Shortened Amazon url:
DEC Is Dead, Long Live DEC: The Lasting Legacy of Digital
Equipment Corporation

http://amzn.to/2iTXYAk

Original (will wrap)
https://www.amazon.com/DEC-Dead-Long-Live-Corporation/dp/15767530
50/ref=sr_1_1?ie=UTF8&qid=1483631061&sr=8-1&keywords=DEC-dead

On a similar vein:
http://www.sigcis.org/files/Goodwin_paper.pdf
"In 1987 Digital Equipment Corporation (DEC) was the number two
computer manufacturer in the world with its founder being named
the "'most successful entrepreneur in the history of American
business" by Fortune magazine. This paper looks at the later
history of Digital Equipment Corporation and asks how an
organization that was so successful in 1988 could sink to become
a takeover target for a PC hardware company ten years later. The
management styles and company culture have been extensively
described in Edgar Schein's book "DEC is dead, long live DEC" but
there is much more to the story. The technology that the company
developed and the business decisions made in the development and
the direction of that technology had a major bearing on the fate
of the company. Many mistakes were made over the last fifteen
years of the company's existence and this paper offers a
suggestion as to what those mistakes were."


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Bob Koehler
2017-01-06 14:35:44 UTC
Permalink
Raw Message
Post by IanD
I wonder if those square dots were because of a font limitation or whether it was due to a translation from dot matrix design or for some other reason?
Back in the 60's folks wanted their computers to look futuristic and
high tech. So they used fonts inspired by what actually showed up on
band and drum printers. This changed a bit when dot-matrix printers
came out.

Lots of the fonts used in the 60s were designed to be optically
scanable, even though very few working OCR systems were deployed back
then.
Bob Koehler
2017-01-04 15:29:23 UTC
Permalink
Raw Message
Post by David Froble
Post by Johnny Billquist
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type
pattern on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.
Johnny
Back in 1973 our PDP 11/40 was not blue. I seem to remember red and black, but,
it's my memory, and such cannot be counted on anymore.
PDP 11/70 tended to be purple data processors.
Bob Koehler
2017-01-04 14:32:20 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)
Uh. Blue is the traditional DEC color, not maroon.
That seemed to vary over time. Both in coffee cups and in computer
cabinet tops.
Bob Koehler
2017-01-03 15:32:54 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by IanD
Awesome - thanks
Maybe VSI should put you on the marketing payroll...
VSI has a _marketing_ payroll ??? Are you sure about that ?
I wonder how much it would cost for them to produce a little trinket
or a badge and send them out to potential customers ?
(This latter question was prompted by the fact I recently found (buried
in a cupboard at home) a blue DECnet OSI badge which must be at least
20 years old. I also still have the VMS umbrella and bouncing ball
that Sue sent out back in the Compaq days.)
So what badge or trinket do you think it might be a good idea for
VSI to start sending out ?
I have a little flashy badgy thingy that says something about VMS
and still lights up, decades later.
Phillip Helbig (undress to reply)
2017-01-03 19:49:03 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by IanD
Maybe VSI should put you on the marketing payroll...
VSI has a _marketing_ payroll ??? Are you sure about that ?
Which payroll is Sue on?
Post by Simon Clubley
I wonder how much it would cost for them to produce a little trinket
or a badge and send them out to potential customers ?
(This latter question was prompted by the fact I recently found (buried
in a cupboard at home) a blue DECnet OSI badge which must be at least
20 years old. I also still have the VMS umbrella and bouncing ball
that Sue sent out back in the Compaq days.)
I lost the umbrella on a train but still have the ball. And a DECUS
Copenhagen mouse pad. And a "call me anytime" button ("call" refers to
the RTL). And some "VAX at 20" bumper stickers. And a Compaq mug I got
when I made a pilgrimage to Nashua.
Post by Simon Clubley
So what badge or trinket do you think it might be a good idea for
VSI to start sending out ?
A 1-year license.
Alan Greig
2017-01-05 00:40:17 UTC
Permalink
Raw Message
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
Post by IanD
Maybe VSI should put you on the marketing payroll...
VSI has a _marketing_ payroll ??? Are you sure about that ?
Which payroll is Sue on?
Post by Simon Clubley
I wonder how much it would cost for them to produce a little trinket
or a badge and send them out to potential customers ?
(This latter question was prompted by the fact I recently found (buried
in a cupboard at home) a blue DECnet OSI badge which must be at least
20 years old. I also still have the VMS umbrella and bouncing ball
that Sue sent out back in the Compaq days.)
I lost the umbrella on a train but still have the ball. And a DECUS
Copenhagen mouse pad. And a "call me anytime" button ("call" refers to
the RTL). And some "VAX at 20" bumper stickers. And a Compaq mug I got
when I made a pilgrimage to Nashua.
Post by Simon Clubley
So what badge or trinket do you think it might be a good idea for
VSI to start sending out ?
A 1-year license.
One of my balls split in half. The other gave up flashing a long time ago. However my umbrella still gets actual use occasionally (I tell people who recognise only the Compaq name it's wifi enabled :-) and I just found my "VMS bigot" badge that I completely forgot about. And the less said about the flashing pens (I think that was Compaq), that would light you up like a Christmas tree at airport security, the better :-)
Jerome Ibanes
2017-01-03 03:22:38 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
IKEAs presentation PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HCEUADUwNAVE
Found this one very interesting, thanks for sharing, would like to find additional
documentation on the ikea implementation.

J
u***@gmail.com
2017-01-09 08:14:07 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Hi.
A few links to PDFs and MPEGs provided by the
Swedish HP-Connect office. Note that some of the
documents can be a year or a little more old...
Most of the MPEG presentations are in Swedish but
usually using English slides.
There are also some slides from the IKEA presentation.
Have a good new Year!
Jan-Erik.
PDF slides
VSI Multivendor Storage PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HAkUADUwNAVE
VSI OpenVMS Alpha PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HA0UADUwNAVE
Java 1.8 (Java 8) Update PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBEUADUwNAVE
VMS File System Update PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBUUADUwNAVE
VSI TCP/IP Stack & VCI 2.0 PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBkUADUwNAVE
OpenVMS Rolling Roadmap PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HB0UADUwNAVE
IKEAs presentation PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HCEUADUwNAVE
Videos
HPE IL / Hadoop MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4HCUUADUwNAVE
The portable C Compiler - PCC MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EAEUADUwNAVE
OpenVMS runs on Integrity I4 MPEG4
Short intro in SWedish, talk and slides in English (Ken Surplice)
http://www.hp-connect.se/lists/lt.php?id=cE4EAUUADUwNAVE
OpenVMS roadmap MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EAkUADUwNAVE
Porting OpenVMS to x86-64 MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EA0UADUwNAVE
Heartbleed bug OpenVMS MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4FAkUADUwNAVE
HP OneView MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4ECEUADUwNAVE
Migrering till Linux MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EBEUADUwNAVE
VMS Software Incs - VSI MPEG4
Swedish talk, Englinsh slides.
By Johan Gedda, Chairman of VSI and main investor.
http://www.hp-connect.se/lists/lt.php?id=cE4EBUUADUwNAVE
VMS Technical update - VSI MPEG4
English talk and slides, Clair Grant.
http://www.hp-connect.se/lists/lt.php?id=cE4EBkUADUwNAVE
OpenVMS apps can all be made SECURE simply by not giving them
system access. Mandatory use of ACLs should be implimented for all
software on the x86 platform. Keep your apps in a secure box and
no security threats.
Stephen Hoffman
2017-01-09 17:46:07 UTC
Permalink
Raw Message
OpenVMS apps can all be made SECURE simply by not giving them system
access. Mandatory use of ACLs should be implimented for all software
on the x86 platform. Keep your apps in a secure box and no security
threats
Note: Examples in this reply are based on your comments posted elsewhere.

If you're solving the 1990s-era computing with 1990s-era requirements, sure.

If you're trying to solve the problems that folks such as the US
political parties and other individuals and organizations that are
high-value targets tend to have, then ACLs are only a very small part
of the total security requirements. All modern systems also already
have ACLs, and these systems also tend to offer ASLR, app sandboxing,
signed binaries, VPNs, encrypted and signed mail messages, and many
other mechanisms and defenses. In many cases, defenses that OpenVMS
doesn't offer quite yet, too.

If you're looking to solve what happened to the DNC servers as you've
commented elsewhere, that access was gained via phishing and entirely
unrelated to the platform security. (I fully expect that the RNC and
other political and governmental entities are also already breached,
too.) With authenticated access into mail stores or into servers,
further passwords can be found or phished and ACLs and mandatory access
controls can be bypassed and — in the absence of network isolation and
network encryption in the effected networks — network traffic can be
monitored, and further access can be gained.

You can bet that Google mail is locked down, too. Any other major
email provider, for that matter. Any major provider has already been
attacked, and Google in particular has become quite experienced dealing
with these attacks. Easier to trick folks into exposing their own
credentials, or compromising somebody that's trusted. Or just "black
bag" the servers, if you're inclined and sufficiently funded.

In the case of high-value targets, one mistake and you're scrod, too.
Mistakes here are really easy, too. OpenVMS or otherwise. The Sony
data dump was reportedly phishing, too. Everybody here has their iLO
firmware and printer firmware and the rest all current, right?

For generic servers including and beyond running a mail server, expect
to need IPsec, TLS, web-facing tools for managing services, certificate
integration, encryption, logging and a whole host of other areas.
Rapid detection of breaches and extensive network isolation, too.
OpenVMS can work here, but it's a whole lot of effort in comparison to
using Google Mail, or attempting to self-host mail services without
also investing in security-savvy folks. For integrating with common
client tools such as Microsoft Office, expect some issues integrating
with OpenVMS, too; Samba is down-revision, and various services
available from Windows Server configurations that folks want and need
are just not available via OpenVMS; services they want and need
including sharepoint and otherwise.

As for some of the suggestions you've made to other folks elsewhere,
please ponder how those suggestions may not work out exactly as
intended. Ask the folks from Macy's and Boeing about that.

For folks that are defending against nation state and well-funded
attackers, there's a whole long discussion of implications and
requirements, not the least of which involves locking down and
protecting employees and employee computers and increasingly even
employee family members and friends. Far beyond locking down a server
with discretionary security tools such as ACLs. This is a really
nasty problem, and ACLs aren't even remotely a solution to what
happened to DNS (and likely also RNC), and ACLs largely aren't even
relevant to the associated efforts and the discussions.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...