Re: netbsd on vax 11/730; booting in sim

[Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>]

On Sun, 11 Jan 2009 13:22:18 -0500
Dave McGuire <mcguire%neurotica.com@localhost> wrote:

>    This is utter nonsense.  I recognize it as a particularly
> American brand of well-trained consumerism.  As you're in Germany,
> I'm absolutely shocked to hear it.  But either way, it's utter
> nonsense. "Thing v1" doesn't automatically stop working just because
> "Thing v2" has been introduced.  Or, more specifically, "Thing
> Design" doesn't automatically stop being viable because "Other Thing
> Design" has been let out of the stable.
This is true. It seems like you misunderstood me. In 1992 (1993?), when
Alpha hit the market, the VAX was still a viable platform. But it was
clear that the days of the VAX where counted. It's, at the time, over 15
years old 32 bit CISC design showed its age and limitations. Instead of
kludging up the VAX, like intel and AMD did with ia32 => amd64, DEC did
the one and only right thing: Introduced a new, well engeered platform
and migrated all of its efforts to it. The day that Alpha hit the
street was the day VAX stated to die.

Look at the situation today: Only that old, legacy PeeCee cruft is
still 32 bit. It slowly moves to a pimped up 64 bit kludge of that
insane "architecture". The whole rest of the industry completed the 32
to 64 bit move over a decade ago. We are now in the situation that
there are still 32 bit systems and that they hit the 32 bit limit. DEC
saw this happening a looong time ago and went 64 bit with the Alpha.
And Alpha is a very viable platform even in 2009, about 20 years after
its design started. I asume it would be still viable in 2019, if HP
wasn't eager to kill Alpha.

As Andrew pointed out: To keep a computer system[1] running over a long
period of time (several years to decades) you have to migrate the whole
system constantely to a new platform. It is the same as digital
archiving. In a digital archive you don't archive the media, you don't
even archive the actual data. You archive the content of the archive by
constantly copying the content to new media and in most cases this
involves converting the actual data to new file formats. A digital
archive is useless if you can't read the media because the media has
degenerated, or because there is no working drive left to read the
media. It is also useless if you can still read the media but the
actual data can't be processed anymore because the old file format was
undocumented and no current software is able to read the old file
format.

Many people are afraid of the change or simply lazzy. There strategy
"if its not broken, don't fix it" works at first sight. But one day it
_will_ break. And then you can't fix it anymore because there are no
spare parts available, source code got lost, nobody has the magic
knowledge to fix the old core memory or what else. You can't get the
old system fixed again. You have to rebuild a completely new system
from scratch. But you will go bankrupt before the new system is
operational. And there it is: A complete desaster. 

We are back at the term evolution: The world is alive. Live is change.
You have to go with the change or you will hit a dead end.

Therefore, as a responsible system administrator, software
engeneer, ... I have to deploy new technics, systems, ...
If I don't do this constant migration, I am in the wrong job.

[1] computer system in the sense of "backend server" or how ever you
will call it. Somthing that provides a service independent of the
actual physical machine or its underlying system architecture.

> > A SS1 or DS3100 runs circles around a VS3100m76. You probably need
> > at least a VS4k60 to beat a SS1.
>    I have to take a very slight exception to this.  From running
> most of these machines side-by-side, I can say that a 4000/60 is
> *quite a bit* faster than an SS1.  In fact, to me, it feels
> noticeably faster than an SS1+.
I didn't say the opposite: I said that you will need at least a VS4k60
to outperform a SS1 as a VS3k1m76 can't. You confirmed my assumtion. :-)
-- 


tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/