filling remaining array elements with fixed value

Yeah, I probably copied the wrong part of the OPs question.

Wouter

OK. The point of my debugger, etc. reference was to call attention to the fact that you aren't *just* "processing text files" in your development effort. E.g., your "target-processor and equipment simulator" undoubtedly (?) draws on more features of the host system than a "simple" compiler that need only be concerned with read() and write() to a file system.

The richer -- and more divers -- your development environment, the tougher it will be to maintain for long periods of time. (note that "tough" may not mean "difficult" -- it may simply be *tedious*!)

How did I get fixated on 2029? :-/

Yes. This is what I did. I kept upgrading hosts -- trying to increase performance while retaining compatibility with the "legacy" tools that the host was kept to support. Why hold onto a 16MHz machine when a 100MHz machine takes the same amount of storage space?!

But, there are often little things that escape notice unless you keep the "vintage" of those tools in mind. E.g., finding *small* IDE drives quickly became difficult. Or, some "custom" battery for the NVRAM/RTC that is no longer manufactured. Or, compatible magnetic media, etc. Or, genuine serial/parallel ports, etc.

Other tool issues can be even more insidious (given that you aren't actively *using* those tools as you make these upgrades). E.g., I used to use Brief exclusively in the early 80's. Delightful on a 30MHz machine. Step up to a 200MHz machine, different host OS (etc) and suddenly its more problem than solution (e.g., keyboard repeat rate).

Understood. It's never as simple as "just use a _______".

Sounds like a good strategy. I tend to rely heavily on interactive debuggers, etc. in my troubleshooting. Though all build and regression testing is scripted (out of fear that a human may corrupt the process through carelessness, etc.)

Remember, media go out of fashion rather quickly when compared to these time scales! Don't *count* on being able to find a compatible "drive" easily. Also, mothballing spares also has to be done "professionally" and not casually/haphazard.

Then, foremost, ensure you have all of those *formats* comprehensively documented! If you can't figure out what the data *means*, you have no hope of "using" it, later.

Understood. It "costs nothing" to *ask* for outrageous goals. Purses only feel the impact when they have to *deliver* on those goals.

E.g., clients always make outlandish "demands" -- then, when confronted with the *actual* (projected) costs of those demands, they are suddenly not as "inflexible" as they were initially described! :>

As I alluded earlier, the real problem with long term support comes when you have to *guarantee* it (as opposed to "hope your solution is viable", longterm). You are at the end of a long line of dependencies and, chances are, all the folks upstream from you will make no *real* guarantees on which *you* can rely! :<

And the same could be said for C++, Java, Perl, etc. What will be the language du jour *next* year?

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.

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)

Should I try to sell them on the "beauties" of OS over OS ? 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?

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

-----^^^

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!

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?]

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. [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.]

I hate those 800 BPI drives, since they decode the byte in parallel, so if you had to read tapes written on an other drive, you have to align the read head in the same way that the tape was written. With

1600 BPI and up, each track was self clocking, so no need to have an extremely accurate read head alignment. 100 MB was a _huge_ amount of data a decade or two ago.

Since 78/45/33 rpm audio disks are still readable, and even produced today, an educated guess would be that CDs would be usable after a few decades.

I have toyed with the idea of using any modern A4 flatbed scanner to read punched cards or segments of paper tapes :-)

Well, "extremely accurate" is a relative term... :>

But, yes, you aren't going to do it yourself without a scope and a reference tape.

I guess it depends on what you are "holding onto". I still have a dozen Black Watch tapes that I've not (yet) bothered to "recover". That's ~1GB (gasp!) of data (in a cubic *foot* :< Sheesh, *core* was almost that dense! jk)

I don't know. Non Blu-ray (DVD) (consumer) players are already becoming scarce. And, the quality of most of the stuff available would leave me "anxious" as to how well it would hold up over time (even if mothballed). I wonder if any of the plastic parts would suffer from "cold flow" problems (left immobile for years)?

Oooo... *that's* an idea! Probably not as effective for the tape (which would have to be cut into strips, etc.) *but* you might be able to coax an ADF to feed Hollerith cards one at a time into it!

[Otherwise, doing one at a time may exhaust your patience -- if you've ever scanned any number of photos, slides, etc. you'll understand how tedious this can be.]

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)

There are a lot of "media" that are far less easy to "recover" data from without a functioning "mechanism". E.g., I've kept several MO drives out of fear of a reliance on *one* leaving me *screwed* in the event of its failure.

Modern discs are probably equally vulnerable; no longer possible to swap platters/controllers to rescue a failed drive. And, fixing the existing controller isn't a "customer option". :<

Not just consumer CD/DVD media. In the late 90s NIST found it effectively impossible to predict how long a given CD would last for archival purposes. The root cause was that the manufacturers simply used whatever chemicals were available that week - and that was true for nominally "good" "reliable" brands.

The 1000cps readers that spat paper tape 6 foot horizontally into a large hopper (paper cuts? what paper cuts?) had /nine/ channels. The sprocket hole acted as a clock for the 8data bits.

Actually three decades ago.

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

Despite all that, I have had remarkably good results with *all* my media (not just "optical"). But, returning to Niklas' predicament, I don't have to *guarantee* the media (or its contents)!

I may have misremembered what this thing was like. I know when it was given to me I mused over what it's purpose was -- such a "polished" and "contoured" surface between the emitter/detector pairs. And only belatedly realized. "Ah, this is a keeper!"

IIRC, you can get PPT in 5 to 8 "channels".

[Of course, with constraints on the data (and *drive*), you don't *need* a clock channel...]

It, however, does nothing for *punching* tape!

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*?"

I had an old RS08 (RK08? not sure if I recall that correctly...

128KW *fixed* head, single platter 14" "word accessible" disk) about the same time. All I can say is shipping charges must have been a LOT LESS back then!! :-/

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.

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

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 
      .      @       .

It is an awful sound :-).

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

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.

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!

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)

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.

That's the key point - and that's why it has to be a suitable filesystem.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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'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!

Beyond that there's always the "how do I decode this bit pattern" issue.