[Info-vax] Unix on A DEC Vax?

[MG]

On 18-jan-2013 15:36, David Froble wrote:
> Stephen Hoffman wrote:
>> On 2013-01-18 03:49:30 +0000, Howard S Shubs said:
>>
>>> In article <kda3ji$9a0$1 at dont-email.me>,
>>>  Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>>
>>>> As for the emulation market, the folks that are choosing emulation will
>>>> likely continue to use it until the application(s) age out, or the
>>>> management involved ages out, or the organization gets clobbered by
>>>> competition.  But those folks are probably not going to be doing very
>>>> much with the applications running under emulation, as that's usually
>>>> viewed as a dead-end for new investments, even within the
>>>> organizations.
>>>>
>>>> Hardware emulation is computing's version of the cover band.  Sometimes
>>>> fun.  Variously useful.  But not really what most folks want.
>>>
>>> Perhaps not, but sometimes it's all you can have.  Such as when the
>>> software manufacturer has gone defunct, or might as well have (VMS port
>>> to x86, anyone?).  Unless someone can get HP to release source code.
>>
>> Or in another way of looking at this, your organization decided to use
>> non-portable features and/or platform-specific software, and for your
>> own code you decided not to isolate the use of platform-specific
>> features, and you decided to not invest in maintaining and updating
>> and portability; you decided that an external dependency was an
>> acceptable risk.
>>
>> You're asking about DSSI disks for VAX servers in another recent
>> posting.  If that's related to this, then consider the proverbial
>> writing was on the wall for VAX in 1992 or so, with the advent of
>> Alpha.  There's very little business-critical "stuff" that can't be
>> ported in twenty years.
>>
>> Sure.  Folks get themselves into this condundrum, and with various
>> associated justifications.  Which is why we're having this discussion.
>> And this is why there's a market for emulators, even though few folks
>> really want to use those.
>>
>> Steve Jobs wasn't fond of dependencies on outside organizations and
>> entities, as the other vendors could choose to cancel or retarget the
>> products[1], or potentially held ransom.  If your dependencies are
>> more portable or are available from multiple sources, you're much
>> harder to derail.  Is that the cheapest approach over the short term?
>> No.  But is this the cheapest over a longer term?  Very possibly yes.
>>
>> Look at how you got where you are with the old gear, and why, and
>> consider if repeating that same decision process is a sequence you
>> would want to repeat going forward, or if you would have preferred a
>> different (non-emulated) outcome.  Then look at what your business is
>> going to encounter going forward, and what you have for resources.
>> Like jack-posts and scaffolding and temporary bracing used in
>> construction, emulation is a temporary stop-gap or intermediate
>> measure.  It's not going to be a preferred end-state.  OK; so now
>> you're running emulation.  How do you get out of that configuration,
>> and into a simpler and more maintainable configuration?  How do you
>> avoid adding more emulation?  How do you migrate your data, or your apps?
>>
>> ————
>> [1]Haven't folks been commenting on the Windows 8 UI?  That Microsoft
>> is seemingly not headed where you want to be today?
>>
>>
>
> That's one hell of a rationalization !!!!!!!!!!!!!!
>
> We should not have lived in caves because houses are better ...
>
> We should not have used sod roofs on houses ...
>
> We should not be living on planet Earth because sooner or later Sol will
> go nova ...
>
> Specifically about computers:
>
> We should never have used any DEC product, and most other manufacturer's
> products, because they (the companies) weren't going to survive ...
>
> We should never have used any language besides C since they were not
> going to survive ...
>
> We should never have used 4, 8, 16, and 32 bit computers since for the
> most part they weren't going to survive ...
>
> DEC didn't survive because of management, not the products.  Many of the
> products and ideas developed by DEC are still in wide use today, just
> not produced by DEC any more.
>
> The problem with things such as VMS, DEC BASIC, and others is that the
> current owner of the products has little regard for them.  It didn't
> have to end this way.
>
> Now, it's easy today to embrace some things such as Unix and Linux
> because there is not a single entity that can deprecate them the way HP
> is doing with some (all?) of the former DEC products.  I'm beginning to
> see that light.  Not saying I like it.  But would such exist today
> without that which preceded it?  I have my doubts.
>
> To me, the real problem was the lack of insistence by customers in the
> past that they have some protection.  A refusal to purchase VMS (and
> therefore DEC computers) without some assurance that the software could
> survive the company might have provided a totally different outcome.
> Using 20/20 hindsight, I can imagine this software being available for
> maintenance, development, and such similar to today's "open" software.

That was beautiful, thanks!

  - MG