filling remaining array elements with fixed value

On 16/06/14 08:44, David Brown wrote:
> On 15/06/14 22:45, Niklas Holsti wrote:
>> I'm sure that the file of bytes can be *read*, but can it be interpreted
>> correctly?
>
> That's the key point - and that's why it has to be a suitable filesystem.

Er no. If the filesystem can't be read then the file can't be read. Consider
whether you will be able to interpret the contents of a perfectly preserved
file foo.xah

On 2014-06-15, Don Y <this@is.not.me.com> wrote:
>
> Yeah, when I was in school, I used to have access to the "junk
> room" at DEC's facility (Maynard?).

If you are talking about the Mill, then yes it's in Maynard.

Did you ever climb the clock tower ?

Some memories for you in case you did:

	http://web.maynard.ma.us/history/millclocktour/index.htm

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2014-06-16, David Brown <david.brown@hesbynett.no> wrote:
> On 16/06/14 00:34, Don Y wrote:
>> 
>> And the same could be said for C++, Java, Perl, etc.  What will be the
>> language du jour *next* year?
>
> That's a valid point - but Python has been a common "language du jour"
> for such uses for the last ten years, and shows no sign of being replaced.
>

No, but it's been through a incompatible language revision.

(Which is probably a sign of language maturity. :-))

Don't forget as well that a decade ago Perl was very popular and now
it's a legacy language.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 14-06-14 09:28 , John Devereux wrote:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> 
>>> (I tried to change the Subject to something more appropriate, hope it
>>> works.)
>>>
>>> On 14-06-13 10:23 , David Brown wrote:
>>>> On 13/06/14 06:05, Niklas Holsti wrote:
>>>>> On 14-06-13 03:09 , Mark Curry wrote:
>>>>>> In article <lnd9ll$nja$1@dont-email.me>,
>>>>>
>>>>>> ...thread drift...
>>>>>
>>>>>> We currently have a setup to do nightly builds of all our code.  We've 
>>>>>> seriously considered, but haven't pulled the trigger yet, on also setting
>>>>>> up a build on a virtual machine.  This build on the virtual machine 
>>>>>> wouldn't happen as often, but the virtual machine snapshot would theoretically
>>>>>> capture "everything".  The virtual machine snapshot could then be
>>>>>> checked into revision control.   
>>>>>>
>>>>>> Sounds like overkill, but it some industries, being able to faithfuly rebuild 
>>>>>> something 5, 10, 15+ years down the line could be useful...
>>>>>
>>>>> How sure are you that your virtual machine snapshot, taken in 2014 on
>>>>> your current PC and hypervisor, will run on your brand-new PC in the
>>>>> year 2029?
>>>>>
>>>>> As I understand them, what are called "virtual machines" on PCs only
>>>>> virtualize as little of the machine as is necessary to support multiple
>>>>> OS's on the same hardware, but are not full emulations of the PC
>>>>> processor and I/O. I have not seen any promises from hypervisor vendors
>>>>> to support 15-year-old VM snapshots on future PC architectures, which
>>>>> may be quite different.
>>>>>
>>>>> This question is of interest to me because I am working on projects with
>>>>> maintenance foreseen until the 2040's. Some people have suggested
>>>>> virtual machines as the solution for keeping the development tools
>>>>> operational so long, but I am doubtful.
>>>>>
>>>>
>>>> I would recommend a few things here.
>>>
>>> Thanks, David, for your helpful answer.
>>>
>>>> First, consider using raw hard
>>>> disk images rather than specific formats and containers - the tools for
>>>> working with raw images will always be around (a loopback mount in Linux
>>>> is usually all you need).  Most hypervisors and virtual machines can
>>>> work with that.
>>>
>>> Today they will... but will they, in 2029, or 2040? I am unsure.
>> 
>> In the event of your virtualization software no longer running the VM,
>> or no longer running on the hardware of the day...
>> 
>> Could you not run the obselete virtualization software as a virtual
>> machine on the new virtualization software? :)
>
> I see the smiley, but as you probably know, such chains of simulations
> have been used in the past, typically when a computer manufacturer (say
> IBM) comes out with a new architecture but wants to keep its current
> customers happy by running their old programs without recompilation. The
> most recent such case was perhaps when Apple switched from PowerPC to
> Intel for its PCs.

Yes the smiley was because I thought the concept amusing, but at the
same time I am serious about it being perfectly feasible.

> Can we expect that the machines in 2040 will be able to run today's x86
> executables, or will backward compatibility break at some point, perhaps
> because of Moore's law coming to a stop? The first break will certainly
> be covered by SW to simulate the old architecture (x86) on the new
> (whatever it is), but that simulation SW may not widely used for more
> than a few years, and will then perhaps rot.

I expect it will be OK, I can and do still run *DOS* compilers under
dosemu or dosbox on modern system. There is still active development I
believe for the "vintage games" market I think. And software is a lot
more important today, there will be that much more incentive to have a
virtualization solution for todays niche applications IMO. Even if x86
binaries cannot be run directly under the emulator of the day, I would
bet it would need no more than one more "level" of virtualization to do
so.

> Some professional or industrial organization could define a "long term
> persistent" architecture that is designed to be simple to simulate and
> simple for porting tools, letting performance suffer as it will. This
> would be "deep time" thinking in the computer domain. But perhaps the
> x86 architecture already plays this role, de facto.
>
> Returning to John's suggestion and smiley, I believe it would be easier
> to maintain a single simulator of a very old machine, running on new
> machines, than a chain of simulators of a series of different
> machines.

Yes but then *you* might have to do the maintaining, porting some open
source simulator to newer architectures. I can't do that, but I can make
sure I can still compile my old stuff when I move to a new system, and
make a virtual machine using available tools if I can't.


-- 

John Devereux

Hi Simon,

On 6/16/2014 5:18 AM, Simon Clubley wrote:
> On 2014-06-15, Don Y<this@is.not.me.com>  wrote:
>>
>> Yeah, when I was in school, I used to have access to the "junk
>> room" at DEC's facility (Maynard?).
>
> If you are talking about the Mill, then yes it's in Maynard.

"Mill" is probably an appropriate name for the place -- it sat
*on* the water (probably a waterwheel somewhere), was built from
large wooden beams, etc.

> Did you ever climb the clock tower ?

No, can't even recall there *being* one.  It was a long trek from
Cambridge out past 128 (25 miles?).  By the time I could get my car,
drive there, park and find my way into the "basement" (it felt
like I was headed *down* to the junk room), more than an hour
would have passed.  The same for the return trip.

In between, lots of fun crawling through Gayloards full of PCB's,
power supplies, "flip chips", core planes, etc.  Then, trying to
get all the goodies back out to the car.  And, having to get them
*out* of the car when I got back to Cambridge...

Of course, this had to happen in the middle of a *weekday* (when
they were open for business) which meant finding time in my class
schedule to accommodate the trip.

And, eventually, making time to dig through all the goodies and
figure out what the hell I had acquired!  :>

> Some memories for you in case you did:
>
> 	http://web.maynard.ma.us/history/millclocktour/index.htm

Cool!  Had I known something like that was there, I undoubtedly would
have availed myself of the opportunity.  (sigh)

In article <lnm4p7$uhi$1@speranza.aioe.org>, Don Y  <this@is.not.me.com> wrote:
>On 6/15/2014 11:53 PM, upsidedown@downunder.com wrote:
>> On Sun, 15 Jun 2014 16:48:40 -0700, Don Y<this@is.not.me.com>  wrote:
>>
>>>> While installing a 300 MB 14" SMD drive (the same size of an washing
>>>> machine), my toe went under this device and it was not very well for a
>>>> month or two :-).
>>>
>>> Yeah, when I was in school, I used to have access to the "junk
>>> room" at DEC's facility (Maynard?).  It was always amusing to
>>> imagine what the "events" were like that led to those machines
>>> being trashed (disk *crash*).
>>>
>>>     "Holy Sh*t!  Did you hear *that*?"
>>
>> It is an awful sound :-).
>
> From the damage done to the enclosure, it must be *really* violent!
>But, then again, there's a sh*tload of mass moving at a pretty
>high (angular) velocity!
>
>> After that you start to listen to the various drives to hear any
>> abnormal sounds.

Was it an RP07?

At my Alma Mater there was an RP07 disk crash that was so violent
they evacuated the campus because they thought it was a bomb that
went off. It was situated right next to a beam bearing of the
9 floors of the administrative building, and there was ample 
resonance in the 8 floors above it.

It thrashed the immediate surroindings quite well too, the DEC20
was saved by the same beam, being behind it.

Evidently the RP07 has the head arms in a different configuration
relative to the spinning platters, different from 99% of all other
drives out there, so it had a failure mode where
the heads just dug into the platters (instead of gently skirting them), 
thereby making a ripple to all the other heads doing the same, and
stopping the pack instantly. Or, rather, transferring the 3600 rpm
volume of a 20 kg package to the disk drive itself, in a matter
of milliseconds, making it trash wildly about in the computer room.

The DEC20 it was attached to did not crash, the disk was not hold
swap or PS:, but several processes hung for a while before dying.

I was editing in emacs at the time, and was connected to a 
directory at the rp07. It hung for a few minutes, and then 
recovered. (I was logged on from the other end of campus).

I was able to save the document before being evacuated.

-- mrr

Hi Morten,

On 6/16/2014 12:40 PM, Morten Reistad wrote:
>>> It is an awful sound :-).
>>
>> From the damage done to the enclosure, it must be *really* violent!
>> But, then again, there's a sh*tload of mass moving at a pretty
>> high (angular) velocity!
>>
>>> After that you start to listen to the various drives to hear any
>>> abnormal sounds.
>
> Was it an RP07?

That's the same class of device we're discussing.  *Literally*
the size of a washing machine (USA) probably weighing upwards
of several *hundred* pounds!  It supported a *removable* "disk
cartridge" that consisted of *multiple* (9 or 10?) 14 inch
diameter platters all revolving on the same spindle.

I.e., the same thing that you find in a "modern" disc drive
but significantly larger (because the heads couldn't be
made as small as current technology).

[hint:  a 14 inch platter has some significant weight to it
as it has to be *rigid* across those entire 14 inches lest
it wobble/wiggle and hit the head assembly that *slides*
between the platters.  I don't recall how much the "pack"
weighed but installing/removing one wasn't something you did
"casually" -- they were heavy!]

To keep the total access time low, the platters want to rotate
very quickly as a request can arrive at any relative angular
position of the platters wrt the *desired* angular position.

Concurrently, a "comb" of heads have to move in or out to the
correct cylinder.  Simple when the distances involved are an
inch or two *and* the mechanism being moved is insubstantial.

But, when the head assembly has some mass to it and you want to
be able to drive it in/out "at will", there's a lot more
kinetic energy involved.

The relative velocity at the periphery of the platters -- contrasted
to the "stationary" head assembly -- invites some interesting
conflicts!  :>

> At my Alma Mater there was an RP07 disk crash that was so violent
> they evacuated the campus because they thought it was a bomb that
> went off. It was situated right next to a beam bearing of the
> 9 floors of the administrative building, and there was ample
> resonance in the 8 floors above it.
>
> It thrashed the immediate surroindings quite well too, the DEC20
> was saved by the same beam, being behind it.

Wow!  The crashes I've seen (after the fact) "simply" beat the
hell out of the drive itself.  Like some imaginary beast was
trapped inside and started beating on the enclosure FROM THE
INSIDE with an *axe*.  Think of the _Forbidden Planet_ scene
in which the "Monster (from the id)" is trying to pound its
way through the Krell metal shield around Morbious' home...

["Um, why didn't the monster 'materialize' *inside* the house??
Seems silly to have to walk *to* the house when you it could
just as easily have come into existence anywhere on the planet!"]

> Evidently the RP07 has the head arms in a different configuration
> relative to the spinning platters, different from 99% of all other
> drives out there, so it had a failure mode where
> the heads just dug into the platters (instead of gently skirting them),
> thereby making a ripple to all the other heads doing the same, and
> stopping the pack instantly. Or, rather, transferring the 3600 rpm
> volume of a 20 kg package to the disk drive itself, in a matter
> of milliseconds, making it trash wildly about in the computer room.

Usually, the head assembly gets "violently relocated".  I've heard
claims of platters shattering (which would have to be REALLY
impressive) but never saw anything like that.

> The DEC20 it was attached to did not crash, the disk was not hold
> swap or PS:, but several processes hung for a while before dying.
>
> I was editing in emacs at the time, and was connected to a
> directory at the rp07. It hung for a few minutes, and then
> recovered. (I was logged on from the other end of campus).
>
> I was able to save the document before being evacuated.

<grin>  Somehow, I suspect your document wasn't very high on
their priorities, at the time!

On 16/06/14 11:46, Tom Gardner wrote:
> On 16/06/14 08:44, David Brown wrote:
>> On 15/06/14 22:45, Niklas Holsti wrote:
>>> I'm sure that the file of bytes can be *read*, but can it be interpreted
>>> correctly?
>>
>> That's the key point - and that's why it has to be a suitable filesystem.
> 
> Er no. If the filesystem can't be read then the file can't be read.
> Consider
> whether you will be able to interpret the contents of a perfectly preserved
> file foo.xah
> 

We are mixing up levels here.  There are files (such as code for the
product, and other files within the virtual machine) on a filesystem,
and that filesystem is on an virtual machine image file, which is on the
host's filesystem.  All the files need to be readable at all levels to
get access to the data.

A point I made a few posts up was that it was best to store the virtual
machine disk image as a single straight file containing the filesystem,
rather than a disk container format specific to the virtual machine
system (such as a ".vdi" disk for VirtualBox).  Such container formats
are usually more efficient - but there is the possibility that future
emulation software will not support the older formats.

On Mon, 16 Jun 2014 10:41:59 +0100, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 16/06/14 08:13, Don Y wrote:
>> I think when driving with a motor, you have more control over
>> whether or not the tape ever "backs up".  Relying on the sprocket
>> holes to control the motor (speed) would be problematic as there
>> is no guarantee that the tape won't buckle, fold, fall out of the
>> slot, etc. so you've already got to have some local feedback on the
>> motor/drive.
>
>I'm not sure what you mean by that. The 1000cps readers that
>spat the tape 6' across a room into a hopper:

I have used one with capacitive sensing.

>   - stopped dead within 1 character

Guess what happens to the feed reel ?

It continues to rotate, spiting tape all around the room ahead of the
reader :-).

>   - the motor speed is uncritical if the sprocket hole is
>     used to clock the data. Who cares if it is 900cps or
>     1100cps: the reels weren't long enough for it to be
>     a significant difference!
>
>> Given how commonplace all these media *were*, it seems sorta
>> foolish to expect any *current* media to have "staying power"
>> (8/5/3" floppies, umpteen quintillion tape styles, Benoulli
>> boxes, MO/WORM, Orb drives, JAZ, 9T (7T!!), *drum*, etc.
>
>Beyond that there's always the "how do I decode this
>bit pattern" issue.

The nice thing about paper tape that you don't necessary need a reader
to find out what is on the tape. I once was quite fluent with the
ASCII character table, so reading the paper tape visually was not that
hard, although slower than the TTY.

On Mon, 16 Jun 2014 19:40:39 +0000, Morten Reistad <first@last.name>
wrote:

>In article <lnm4p7$uhi$1@speranza.aioe.org>, Don Y  <this@is.not.me.com> wrote:
>>On 6/15/2014 11:53 PM, upsidedown@downunder.com wrote:
>>> On Sun, 15 Jun 2014 16:48:40 -0700, Don Y<this@is.not.me.com>  wrote:
>>>
>>>>> While installing a 300 MB 14" SMD drive (the same size of an washing
>>>>> machine), my toe went under this device and it was not very well for a
>>>>> month or two :-).
>>>>
>>>> Yeah, when I was in school, I used to have access to the "junk
>>>> room" at DEC's facility (Maynard?).  It was always amusing to
>>>> imagine what the "events" were like that led to those machines
>>>> being trashed (disk *crash*).
>>>>
>>>>     "Holy Sh*t!  Did you hear *that*?"
>>>
>>> It is an awful sound :-).
>>
>> From the damage done to the enclosure, it must be *really* violent!
>>But, then again, there's a sh*tload of mass moving at a pretty
>>high (angular) velocity!
>>
>>> After that you start to listen to the various drives to hear any
>>> abnormal sounds.
>
>Was it an RP07?
>
>At my Alma Mater there was an RP07 disk crash that was so violent
>they evacuated the campus because they thought it was a bomb that
>went off. It was situated right next to a beam bearing of the
>9 floors of the administrative building, and there was ample 
>resonance in the 8 floors above it.
>
>It thrashed the immediate surroindings quite well too, the DEC20
>was saved by the same beam, being behind it.
>
>Evidently the RP07 has the head arms in a different configuration
>relative to the spinning platters, different from 99% of all other
>drives out there, so it had a failure mode where
>the heads just dug into the platters (instead of gently skirting them), 
>thereby making a ripple to all the other heads doing the same, and
>stopping the pack instantly. Or, rather, transferring the 3600 rpm
>volume of a 20 kg package to the disk drive itself, in a matter
>of milliseconds, making it trash wildly about in the computer room.
>
>The DEC20 it was attached to did not crash, the disk was not hold
>swap or PS:, but several processes hung for a while before dying.

The RP07 was  non-removable (Winchester style) drive with a
replaceable HDA (Head Disk Assembly). The rotating platters might have
been a few kilograms, the whole HDA perhaps 20 kg and the whole drive
much more than that. If the platters really stopped in a millisecond
i.e. 1/16 of a rotation, transferring the angular momentum to the HDA,
which no doubt broke loose from the drive starting to rotate.

Apparently there were no people in the room, since there would have
been injuries. 

Computing was dangerous in the past with shrapnels from failing disks,
deep scars due to fast paper tapes, crushed limbs due to heavy
equipment, electrocution from anode and mains voltages etc.