filling remaining array elements with fixed value

On 6/15/14, 7:09 PM, Don Y wrote:
> 
> Somewhere, I have a nice little 8 channel photointerrupter module
> *designed* for paper tape (to be read at very high speed).  Put a
> bit of "drag" on the tape supply and then just *pull* it through
> the array (i.e., its speed would be relatively constant in the short
> term so you could even detect "no punch" positions)
> 

My memory was they used a *9* channel photo-interrupter module, the 9th
channel being on the sprocket holes, and that provided the clock channel
to sample the data on, thus getting around the problem of the blank row.
It also says that the computer doesn't need to massively over-sample to
read the tape.

On Sun, 15 Jun 2014 23:45:46 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> wrote:

>On 14-06-15 21:30 , David Brown wrote:
>> But you should make a point of sticking to mature and stable filesystems
>> - prefer ext3 rather than btrfs, for example (FreeBSD will work with
>> ext3, albeit without journalling, giving you a second source).
>
>Are we sure that ext3 will be supported in 2040? Possibly not in the
>native 2040 OS, but hopefully in our emulator.


ext3 may not be supported in 2040, but I'd bet money FAT will be...
;-)

On 14-06-16 02:09 , Don Y wrote:
> On 6/15/2014 3:43 PM, upsidedown@downunder.com wrote:

>> I have toyed with the idea of using any modern A4 flatbed scanner to
>> read punched cards or segments of paper tapes :-)
> 
> Oooo... *that's* an idea! ...
> 
> Somewhere, I have a nice little 8 channel photointerrupter module
> *designed* for paper tape (to be read at very high speed).  Put a
> bit of "drag" on the tape supply and then just *pull* it through
> the array (i.e., its speed would be relatively constant in the short
> term so you could even detect "no punch" positions)

Some decades ago, when I was peripherally (:-)) involved with an
astronomical photopolarimeter instrument that produced paper tape, I
started building a manually pulled reader like that.

The data were clocked by the sprocket holes. I assembled the photodiode
row myself. The photodiode for the sprocket holes was offset a bit to
produce a clock edge in the middle of the data-hole signal.

Friction was provided by bits of short-nap velvet cloth pressing on one
side of the tape. As one pulled the tape, the nap of the velvet tilted a
bit in the "forward" direction, which made the friction asymmetric and
prevented inadvertent reversal of the tape movement, because the tilted
nap strongly opposed movement in the "backward" direction. But I didn't
finish the device, unfortunately -- the electronic parts were a bit
beyond my skills, then.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

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 :-). 

After that you start to listen to the various drives to hear any
abnormal sounds.

On 15/06/14 21:09, upsidedown@downunder.com wrote:
> On Sun, 15 Jun 2014 20:30:10 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 13/06/14 20:35, Niklas Holsti wrote:
>>> (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.
>>
>> If the day comes when we can't get a computer to read a simple file of 
>> bytes, there will be lots of bigger problems than your particular case! 
> 
> For a long time, I used 1/2 inch 9 track 1600 bpi (no need for head
> alignment as with 800 bpi) open reel ANSI magnetic tapes for storing
> source files. No file archives or compressing, just plain sequential
> text files. These could be readable on any mainframe or minicomputer
> of the time and I assumed also in the future.
> 
> Unfortunately I was wrong, for instance in Finland, there is only a
> single functioning 1/2 inch tape drive in a computer museum, but how
> long is it going to be working.
> 
> So in reality, you need to do the copying to any mature technology
> about every 10 years.
> 
>>  I know windows tries to make that sort of thing more difficult with 
>> each generation, but fortunately we have Linux, the BSD's, and other 
>> Unix systems - these are going to be around for a long time to come, and 
>> old versions can still run fine on new hardware.
>>
>> But you should make a point of sticking to mature and stable filesystems 
>> - prefer ext3 rather than btrfs, for example (FreeBSD will work with 
>> ext3, albeit without journalling, giving you a second source).
> 
> Realistically CDROM (and DVD/BlueRay) file systems on physical disks
> would be the most likely media to be readable in 2040. How would you
> connect any current magnetic or SSD  to a computer in 2040 ? 
> 
> The question is as relevant today, when I have 5 or 8 channel paper
> tapes or 1/2 magnetic tapes, into which holes on my modern laptop do I
> feed these tapes ? :-)
> 

My reference was to being able to read a file of bytes logically - not
read any given media type.

Regarding media types and storage of these files, you have to have a few
independent copies of the files, and make sure you regularly copy and
check them onto more modern media.  You can't rely on a particular type
of disk still being usable that long - it is unlikely that computers in
2040 will have SATA interfaces (though it is conceivable that they will
still have USB interfaces, and that you will still be able to get a
SATA-to-USB converter).  CD and DVD players will probably still be
available - but only in the audiophool market :-)

Also, don't forget that you get gradual bit-rot on the files even if the
media is still accessible - for files on a disk, you should regularly
"scrub" them (reading the files will trigger automatic disk sector
re-location if there are correctable errors in the sector).  For
CD/DVD's, burn new copies every few years.

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.

Hi Niklas,

On 6/15/2014 10:59 PM, Niklas Holsti wrote:
> Some decades ago, when I was peripherally (:-)) involved with an
> astronomical photopolarimeter instrument that produced paper tape, I
> started building a manually pulled reader like that.
>
> The data were clocked by the sprocket holes. I assembled the photodiode
> row myself. The photodiode for the sprocket holes was offset a bit to
> produce a clock edge in the middle of the data-hole signal.
>
> Friction was provided by bits of short-nap velvet cloth pressing on one
> side of the tape. As one pulled the tape, the nap of the velvet tilted a
> bit in the "forward" direction, which made the friction asymmetric and
> prevented inadvertent reversal of the tape movement, because the tilted
> nap strongly opposed movement in the "backward" direction. But I didn't

Ah, that makes sense.  My photointerrupter had a pretty wide slot
(i.e., distance between emitters and detectors) so I assume it
expected the tape to "fly" through.  (no contact)

> finish the device, unfortunately -- the electronic parts were a bit
> beyond my skills, then.

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.

Dunno.  Last time I *used* PPT was in the late 60's (and, even then,
only for "week to week" offline backups).  And, the ASR33 is just
gathering dust, here (too busy to crate it up and put it on eBay;
shipping would be ridiculously expensive!)

I know I had a new box (2000?) of Hollerith cards in my junk pile
at one point -- they were handy for "scrap paper" (less likely to
get lost due to their rigidity)

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.

On 15/06/14 22:45, Niklas Holsti wrote:
> On 14-06-15 21:30 , David Brown wrote:
>> On 13/06/14 20:35, Niklas Holsti wrote:
>>> (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.
>>
>> If the day comes when we can't get a computer to read a simple file of
>> bytes, there will be lots of bigger problems than your particular case!
> 
> 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.

> 
>> I know windows tries to make that sort of thing more difficult with
>> each generation, but fortunately we have Linux, the BSD's, and other
>> Unix systems - these are going to be around for a long time to come, and
>> old versions can still run fine on new hardware.
> 
> I'm doubtful that 2040's hardware will run 2014's Linux/x86 without an
> emulator like QEMU. With an emulator, yes, but the emulator must emulate
> a computer system with peripherals, complete enough to run the tools we
> need.

Certainly it is a bit optimistic to think an off-the-shelf Linux from
2014 will run directly on an off-the-shelf PC in 2040, though there is
surprisingly good backwards compatibility (as long as you don't need
fast graphics, sound, cameras, etc.).  I would be surprised if you would
need a cpu emulator like QEMU to run a 2014 x86 Linux in 2040 - I think
x86 based PC's will still be available (though not dominant) in 2040.
But making sure the VM works with QEMU is a good safety measure.

Maybe it would be fun to collect peoples predictions for 2040, and see
how many are accurate :-)

> 
>> But you should make a point of sticking to mature and stable filesystems
>> - prefer ext3 rather than btrfs, for example (FreeBSD will work with
>> ext3, albeit without journalling, giving you a second source).
> 
> Are we sure that ext3 will be supported in 2040? Possibly not in the
> native 2040 OS, but hopefully in our emulator.

I expect 2040 Linux will support ext3 directly.  It is possible that it
will no longer be in the default kernel configuration by that time, but
it will still be supported.  The kernel today supports plenty
filesystems for computers and OS's that are seldom found outside of museums.

> 
>>> As I understand your suggestion, it involves the following steps that I
>>> should do to set up a long-term maintenance system that does not assume
>>> survival of the current host-PC architecture and OS until 2040:
>>>
>>> 1. Find a virtual HW composition, probably based on x86, that:
>>>     a) QEMU can emulate, and
>>>     b) is supported by the OSes on which our tools run, and
>>>     c) runs our tools, too.
>>>
>>> 2. Configure KVM+QEMU to emulate this virtual HW.
>>>
>>> 3. Install our OSes and tools on a VM using this virtual, emulated HW.
>>>
>>> 4. Maintain KVM and QEMU, using their source code, to keep them working
>>> on future host PCs, and preserving their ability to emulate the HW
>>> composition defined in step 1.
>>>
>>> This looks possible in principle. Far from easy, though.
>>
>> If it were easy, your customers would not be paying you big money to
>> solve the problem!  But yes, that's pretty much what I had in mind.
> 
> Ok. (But the "big money" is not really there, because -- as I said in
> another post -- the long-term maintenance requirement was descoped from
> tender phase to contract phase.)
> 

Different people and different projects have different ideas of when
money is "big", of course.  But if the money is gone, then a simple VM
image and an archived old computer should still be in budget.

On 16/06/14 00:34, Don Y wrote:
> Hi David,
> 
> On 6/15/2014 1:48 PM, David Brown wrote:
> 
>> I agree that it's a bad idea for developers to just pick whatever tools
>> they fancy. There are many reasons why I and several others recommend
>> Python - it is not just a random tool that I happen to like. It's
>> benefits include being strongly cross-platform (as it has always been,
>> right from its inception), very easy to learn, very powerful for string
>> manipulation and formatting, a large standard library with excellent
>> documentation (all in one place), solid support from big companies (the
>> key Python developers work at Google), fast and interactive development
>> for scripts, and it is very well known among a range of users.
> 
> 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.

Of course people (and groups, companies and other organisations) have
their favourite languages.  And of course new languages come and go.

But I believe Python stands out amongst other languages in this regard -
just as C stands out for embedded programming (though you /could/ use
Ada, Forth, C++, Pascal, etc.).

And I think many development environments and build systems can be
improved if you have a "glue language" available for handling small
tasks.  Python is my recommendation for that glue.

> 
>> So yes, if you have a client that is addicted to MS software, then you
>> can tell him that Python is a perfectly solid tool for his systems - he
>> can even install the Python tools for Visual Studio, which is written by
>> MS.
> 
> Why should I assume the role of evangelist?  My job is to provide
> a solution to a particular problem.  Not advise clients on how they
> should structure their engineering departments, the skillsets they
> should stress with job candidates, etc.  When asked to *train*
> clients' new hires *or* help in the hiring process, I smile
> graciously and decline -- that's not where my interests lie.

My job is also to help clients - and if I think a client would be helped
by using Python, then I will tell him that.  I won't try to force him
into it, of course, and I also don't get involved in clients' staff.

But if a client asks me to write some code, and that process involves
scripts, then unless the client has asked specifically for something
else, I write these scripts in Python and deliver them as part of the
code.  That is what gives the client the best value for money that I can
provide.  A recent example I did involved a module for calculating sine
waves with a particular balance between speed and accuracy, and
particular formats and scalings.  The lookup tables were generated by a
Python script.


> 
> I have to make a case for the implementation *I* have chosen,
> nothing more.  If that implementation requires convincing the
> client of the merits of *several* tools, it's more work for
> me than if I can point to a smaller set of tools and show the
> same results.  A client feeling "forced" into taking on
> specific skillsets, tools, equipment, etc. isn't usually a
> *happy* client ("*You* are costing me money...")
> 
> I don't think you have very broad experience with the sorts of
> "developers" typically encountered, here -- nor the firms and
> policies/politics of their employers.  It is often a battle to move
> from component supplier X to supplier Y -- even moreso processor
> family A to processor family B ("But all of our staff already
> are familiar with processor A's architecture, conventions, tools,
> etc.").
> 
> Small firms are always pinching pennies -- new tools (even free ones)
> cost tangible dollars (if *the* software developer is unproductive
> for a month, that's 8% of their development budget "wasted").  Big
> firms are often entrenched in policy and procedures so doing anything
> *different* requires an act of God (often, projects are done "off
> the books" -- at least to the proof of concept stage -- simply to
> avoid dealing with the "machinery" involved; easier to "force"
> a design decision by pointing to an accomplished feat than to
> try to convince them to go in a new direction a priori)

Clearly I do not advocate trying to force clients into using my
particular favourite tools!  You are exaggerating to the point of
absurdity here.

But when a client comes to you asking for help with processor A, and you
know that processor B is a much better choice, then you are not doing
your job if you do not discuss the merits of processor B with the
client.  It is the client's decision in the end, but part of the
consultants' job is to advise and inform, and to recommend alternative
ideas for consideration.  Just as that applies to processors, so it
applies to programming languages and other tools.

> 
> Should I try to sell them on the "beauties" of OS <whatever>
> over OS <currently_used>?  Or, why this slightly more expensive
> shipset is a better choice for their project GIVEN MY EXPERT
> OPINION ON WHERE THE PRODUCT IS LIKELY TO EVOLVE?
> 

You don't try to "sell" them on the ideas, you try to give a balanced
and reasoned view of your recommendations.  And normally (not in all
cases) you /do/ have a reasonable opinion on where the product is likely
to evolve - you have listened to the customer describe it, and have
thought it through yourself.

> *State* your opinions; then, move on to the job for which you were
> hired.

My clients don't hire me merely for my ability to bang out C code - and
I don't think your clients are any different when they hire you.  Yes,
the final decision is always the customer's.  But usually there is a
space for brainstorming, ideas, suggestions and recommendations for
fresh thoughts around the whole project.  That is part of the reason why
they hire /you/ (or me), and not just farm out the project to an
anonymous code factory somewhere.  Sometimes there is more scope for
such wider discussions, other times you are tightly focused on a small
part of the problem - but your opinions should be important to the client.

> 
>> Or you and he can continue to keep one foot nailed to the floor by
> 
> -----^^^
> 
>> thinking that anything free or open source must be so amateurish that no
>> sane company would use them, and that every problem must be beaten to
>> death by a hammer because no other tools are allowed.
> 
> FOR THE RECORD, I probably use and *deploy* more FOSS than anything
> *you* use/deploy.  All of *my* software development work is done with
> FOSS tools (I rely on Solaris and Windows based "proprietary" tools
> for certain documentation, test, and hardware design tasks for which
> the available FOSS tools *pale*).
> 
> The fact that *EVERYTHING* I am currently writing (software and docs)
> and designing (hardware) will be available under an unencumbered
> (*non*-GPL) license demonstrates my commitment to the concept of
> "Open" hardware/software.
> 
> How many *thousands* of hours of *your* time are you GIVING AWAY?
> 
> "Nailed to the floor"?  Hardly!

That's great - but why do you continually refer to FOSS so disparagingly?

"Look at some of the FOSS projects and the hodgepodge of tools
they (somewhat arbitrarily) rely upon for proof of this.  I.e.,
it's *fine* -- if you want to drink the koolade..."

Now, I certainly won't contest that /some/ FOSS projects are a
hodgepodge, or "amateurish" or "hobbyest", as you also describe them.

I feel I am getting a lot of mixed messages here.  I am hearing that you
wouldn't recommend Python (or other tools) because they are a
"hodgepodge of tools" written by amateur hobbyests, and not suitable for
serious use - and I am also hearing that you are a strong FOSS supporter.

Clearly you /are/ a strong FOSS supporter - but, at least in this
thread, you are coming across as being against it in principle.

So I am sorry if I misread or misinterpreted here (and even sorrier if I
mixed things up somehow), but that is how your posts appeared to me.

> 
> Furthermore, I have been "on the record" as having used and contributed
> to same for at least 20 years (USENET search shows patches back to '93;
> I've not looked back further than that).
> 
> You can probably benefit from taking your own advice in return:
> thinking that [FOSS] tools are the ONLY solution to EVERY problem!
> [Perhaps you don't have a budget capable of *buying* all those tools?]

No, FOSS is not the only solution to every problem - I try to judge
software and solutions on their own merits.  Being FOSS is often an
advantage - but it is not often the deciding issue in a comparison.  In
the choice of a "script language" to generate C code as part of a build
process, however, then FOSS is an absolute requirement, as is being
solidly cross-platform (i.e., a native Windows port, not a "cygwin" port).

Usually my budget stretches to whatever tools make most sense - and if a
tool saves hours of work, it is worth significant investment.  For many
tools, it is the flexibility of FOSS licensing that is more relevant
than the actual monetary cost - I can install it on my two work PC's
(one Windows, one Linux), my laptop, my home machine, customers'
machines, test machines, etc., without any worries about purchasing,
licensing, node locking, and so on.  Sometimes with paid software, it
costs (in time) more to handle the purchase and licensing than the price
of the software.

> 
> Projecting *your* opinions (regardless of how well conceived you
> *think* they may be) onto someone else's (i.e., client) priorities,
> capabilities and resources speaks of arrogance.

Making recommendations based on /your/ knowledge and experience is
something customers want and need.  Trying to shoehorn your opinions
over the customers' would be arrogance.  There is a balance here.

I suspect that in reality we have fairly similar attitudes to all this -
we just seem to be arguing from opposite sides, which makes it appear
that we are different.

> 
> [I'll tell my neighbors of problems they are likely to encounter in
> their homes (based on first-hand experience, here, and observations
> of building styles prevalent for this vintage home).  But, I won't
> harp on them to fix them -- even when there are significant risks
> to *not* fixing them!  I may *think* I "know better" but they have
> their own priorities, plans, resources, etc.]
> 
>> As you say, YMMV.

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:
   - stopped dead within 1 character
   - 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.