[TUHS] Why did PDPs become so popular?

[gtaylor@tnetconsulting.net (Grant Taylor)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3938 bytes --]

On 12/27/2017 02:02 PM, Alec Muffett wrote:
> There is a story - as I have heard it told - that PDPs established their 
> place (and popularity) in the marketplace by pointedly *not* advertising 
> themselves as "computers", but instead as "programmed data processors".

That jives with what I understand as well.

> This was because - so the story goes - that everyone in corporations of 
> the time simply *knew* that "computers" came only from IBM, lived in big 
> datacentres, had million-dollar price-tags, and required extensive 
> project management to purchase; whereas nobody cared enough about a 
> thing called a "programmed data processor" to bother bikeshedding the 
> few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an 
> inevitable death. Thus, they flitted under the purchasing radar, and 
> sold like hotcakes.

I don't agree with "…only came from IBM…".  Please point your web 
browser to your preferred search engine and ask it for Snow White and 
the Seven Dwarfs as it relates to the computer industry.

It's my (mis?)understanding that PDPs had a significant advantage that 
they came in with a significantly lower price tag which allowed them to 
get through finance / bursar office with less scrutiny.

> I wonder: does this story have substance, please?

It mostly jive with what I've heard / read a number of places.  Further, 
I'm not aware of any stories countermanding it.

> Aside from anything else: I draw parallels to the adoption of Linux by 
> Wall St, and the subsequent adoption of virtualisation / AWS by business

I don't know that I agree with that assessment.  -  Though as sure as I 
say that, what I start typing sort of parallels it.

I think Linux broke into traditionally non-Unix shops as play things on 
old retired machines.  Then as time moved on and things evolved, Linux 
started doing more to carry less-critical production load.  More time 
passes with more evolution and Linux often picks up a non-trivial 
portion of the production work load from non-Linux systems.

The other similar thing that I have seen, and think I will see more of, 
is that people play with Linux at home, learn some things, and realize 
that it can do things at work too.  In which case it will likely more 
overtly take on production loads more directly.

As for virtualization, I think that's evolution and people trying to 
avoid physical server sprawl.  I think AWS (et al) are simply additional 
forms of virtualization.

> now reflected in companies explaining to ISO27001 auditors that "well, 
> we don't actually possess any physical servers..."

Okay.  How does (the lack of) physical servers actually impact ISO 27001 
compliance?  -  From my read of the Wikipedia article I don't see how 
(the lack of) physical on premise servers changes anything.

I feel like ISO 27001 is more a business plan / policy / procedure type 
check than a technical to-do list.  As such, I feel like such plans / 
policies / procedures would still apply to the infrastructure that 
people are using, be it physical on prem or virtual in the cloud. 
Someone still owns the equipment and is responsible for it.  Further, 
businesses outsourcing to the cloud still have a responsibility to 
ensure that said infrastructure is secured / updated / managed to the 
same standards.

Granted, virtual ~> AWS does make it a LOT simpler for people to start 
projects and do things that may be against company policy.  But that's a 
matter of initial economics.  For the project to continue, it will need 
to fall back in line with stated policies, be it physical on prem or 
virtual in the cloud.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171227/c78fbced/attachment.bin>