Archiving Data
Brooke,
I disagree. Hard drive sizes have done nothing but soar over the last
30 years. So, even if you have to replace them every 10 years, you
only have to buy 1/10th the number of drives every decade.
This is exactly my data retention strategy. Every time I get a new
computer, I copy my data files from the old one to the new one. I
still have stuff on my hard drive from the 1980s, but it takes up such
a tiny amount of space I don't care. I have to back it up, of course,
but I back up to another hard drive (stored offline and offsite).
I've tried tapes before, but the only thing that can "keep up" with
drive growth and speed is another drive.
Paper - I lose that stuff within a matter of hours of getting it! :-)
Thanks,
-JP
On Fri, Jan 7, 2011 at 4:41 PM, Brooke Clarke brooke@pacific.net wrote:
Hi Perry:
It's a real problem. Modern movies are edited and in some cases sent to
theaters as digital data. Last I heard the specified lifetime of data on a
hard disk is 10 years (although probably much longer). It's very expensive
to transfer data every ten years to a new drive. Modern movie prints are
archival, but some earlier color movies are not. I've heard that a small
number of CD - DVD brands/models are archival quality.
Have Fun,
Brooke Clarke
http://www.PRC68.com
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I'm looking at building a LORAN-A simulator to run a vintage display.
I used to design stuff with gates and counters by hand, and can still do
so, but it's tedious.
Does anyboby know of any freeware that can be used to draw up logic and
simulate its operation, including propagation delays? I don't need exotic
chips or any analog functions. A library of common 74... and 40.. would
be nice.
Freeware strongly preferred.
Thanks,
-John
===============
You are 100% correct that no digital media is "archival" and all of it
will fail or there will be no machine that can read it. Certainly
everything we have will be junk in 100 years. But digital data is
not the same as digital media. Data can be perfectly copied. We can
make many copies. For example at work we have a disk array. This
device spreads data over many drives in such a way that if several
disk drives fail no data is lost. But we have three of these arrays
in three different cities and they are kept in sync with each other
usig high speed data lines. So if there were two natural disasters
and both Denver and Los Angeles were wiped out we'd still have one
disk array. On top of this they make periodic copys of the array to
tape and send the tape copys to different locations. The tapes get
re-used and don't have to last forever
Before long EVERYONE'S data will be on devices like these. The trend
is to move data to the "cloud". It really is better because then my
data is accessible from any computer. We are moving to hand held
computers at a very fast rate. These machines are connected t the
'net 24x7.
I can't afford three disk arrays for my personal data but I to have a
system where I make incremental backups (never over writing old data)
and I rotate my disk drive through an off-site location. I retire
disk drives after a few years and replace them with newer larger
drives. I really do not care to much how long media lasts. I figure
it has a 3 to 5 year lifespan. Mostly I retire the media before it
fails although I did have a disk fail last year while in use.
Yes there will be a short historic period from the late 80's to maybe
the end of this decade where much data was "managed" by technically
illiterate consumers in there own desktop computers. But those days
are numberedand soon most data will be in the "cloud" where it is
replicated to the point where and atomic war would not cause it to be
lost.
Technically all that has to happen to keep data forever is that the
rate of replication is greater than the rate of media failure.
I just saw an ad today for a 2TB disk for $99. Buy a few of these
every years and make a goal to replicate your data twice was fast as
you expect the media to fail.
Please do not argue that one type of media lasts longer then some
other. If your plan requires long lasting physical media if will
fail. No media lasts long in a fire or major earthquake or to
vandalism. The top reasons for lost data is actually theft of the
equipment and human error. "archival" media does not even address the
top reasons for loss
On Fri, Jan 7, 2011 at 12:59 PM, Perry Sandeen sandeenpa@yahoo.com wrote:
List,
I apologize in advance for my long posting
Several weeks ago I posted what were my attempts to save data and my school-of hard-knocks learning curve. Unfortunately several posters just had to nit-pick the process I had used and started a long series of posts and counter-posts about the process while totally missing the message. So I’m going to walk through this again hopefully for the edification of the majority.
Just several days ago a 10 year old Canadian girl discovered a super-nova while studying photographic images. Observations by the world’s two most powerful earth based telescopes confirmed here discovery.
Now consider the case of the Antikythera mechanism. It was close to 2,000 years ahead of what was eventually developed in Europe. Most likely we never knew about it was that the library in Alexandria Egypt was joyfully burned three times by religious idiots [see Wikipedia].
This mechanism was so complicated and accurate that as least passing knowledge, if not some or all of its drawings, would have been there. In context to the science of that time, it ranked up with what the Hubble telescope accomplished for science today.
Which brings us here to today.
Governments and private businesses are storing millions of tons of written documents in the evacuated chambers of salt mines of the world [see Wikipedia]. This does beg the question of where the inventory lists are stored. The reason for this is that no other archival grade of mass storage really exists. The last method that I’m aware of is black & white polyester microfilm which is rated at 500 years. With the almost total transition to digital cameras, there is no financial incentive to produce the necessary film stock to continue that process.
NASA has lost large amounts of acquired data as no equipment now exists to read the information.
Current CD/ DVD media is no solution. A 2004 report published in the Journal of Research of the National Institute of Standards and Technology entitled "Stability Comparison of Recordable Optical Discs-A Study of Error Rates in Harsh Conditions." You can read it yourself at http://nvl-p.nist.gov/pub/nistpubs/jres/109/5/j95sla.pdf.
Until someone invents a stabilized glass DVD and perhaps a holographic laser beam to create the needed pits W/O chemicals (embedded gold maybe?) archival data storage W/O paper is a crap-shoot.
So where am I going with all this? Glad you asked.
No one knows if their or others data will lead to a new discovery or process. Da Vinci certainly didn’t. It can however; lead to learning that can then can be taken to the next level of knowledge and invention.
Words cannot express my gratefulness to those who have taken the considerable effort and expense to post science information and support technical lists such as this on the net as well as the posters who have kindly shared their knowledge with us.
I just hope it doesn’t get lost.
End of Rant. I now get off my soapbox and return you to your normal programming.
Regards,
Perrier
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
On 08/01/11 03:28, J. Forster wrote:
I'm looking at building a LORAN-A simulator to run a vintage display.
Hmm. Generating blips programmed in repetition rate and delay as steps
of a 10 MHz clock should be sufficient and fairly straight forward. A
lower clock such as 1 MHz would probably work well (and simplify the
design). A programmable delay (needs to be 19 bit for 10 MHz and 15 bit
for 1 MHz) using standard synchronous counters should not be too hard.
Once designed it's a matter of deciding how many slaves shall be
supported. A PIC or AVR could do the NMEA position to delay conversions
needed, and I mostly worry about the math-support on them, which only
shows that I haven't done any real project on any of them.
I used to design stuff with gates and counters by hand, and can still do
so, but it's tedious.
Does anyboby know of any freeware that can be used to draw up logic and
simulate its operation, including propagation delays? I don't need exotic
chips or any analog functions. A library of common 74... and 40.. would
be nice.
Freeware strongly preferred.
Eagle, GEDA/GNUCAP, Electric and KICAD would be my main suspects.
Cheers,
Magnus
John I did the Loran C simulator. But it acted as a single station and its
only goal was to allow austrons and such to do phase comparison of
oscillators. Took only a few chips simple and small.
I was at the tail end of loran A in the navy. Really do not remember
anything about the theory any more.
I was going to speculate on a solution but its to late at night.
Regards
On Fri, Jan 7, 2011 at 10:54 PM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
On 08/01/11 03:28, J. Forster wrote:
I'm looking at building a LORAN-A simulator to run a vintage display.
Hmm. Generating blips programmed in repetition rate and delay as steps of a
10 MHz clock should be sufficient and fairly straight forward. A lower clock
such as 1 MHz would probably work well (and simplify the design). A
programmable delay (needs to be 19 bit for 10 MHz and 15 bit for 1 MHz)
using standard synchronous counters should not be too hard. Once designed
it's a matter of deciding how many slaves shall be supported. A PIC or AVR
could do the NMEA position to delay conversions needed, and I mostly worry
about the math-support on them, which only shows that I haven't done any
real project on any of them.
I used to design stuff with gates and counters by hand, and can still do
so, but it's tedious.
Does anyboby know of any freeware that can be used to draw up logic and
simulate its operation, including propagation delays? I don't need exotic
chips or any analog functions. A library of common 74... and 40.. would
be nice.
Freeware strongly preferred.
Eagle, GEDA/GNUCAP, Electric and KICAD would be my main suspects.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Magnus,
See my post of a few minutes ago.
The GRI and Delay counters need to be 5 decimal digits. My current
thinking is manual entry of the numbers via BCD coded thumbwheel switches.
LORAN-A has 24 possible GRIs; in three blocks of 33 PPS; 25 PPS; and 20
PPS. It also has 4 RF frequencies.
Currently I plan only one Slave, but a second would be an easy addition.
-John
==============
On 08/01/11 03:28, J. Forster wrote:
I'm looking at building a LORAN-A simulator to run a vintage display.
Hmm. Generating blips programmed in repetition rate and delay as steps
of a 10 MHz clock should be sufficient and fairly straight forward. A
lower clock such as 1 MHz would probably work well (and simplify the
design). A programmable delay (needs to be 19 bit for 10 MHz and 15 bit
for 1 MHz) using standard synchronous counters should not be too hard.
Once designed it's a matter of deciding how many slaves shall be
supported. A PIC or AVR could do the NMEA position to delay conversions
needed, and I mostly worry about the math-support on them, which only
shows that I haven't done any real project on any of them.
I used to design stuff with gates and counters by hand, and can still do
so, but it's tedious.
Does anyboby know of any freeware that can be used to draw up logic and
simulate its operation, including propagation delays? I don't need
exotic
chips or any analog functions. A library of common 74... and 40.. would
be nice.
Freeware strongly preferred.
Eagle, GEDA/GNUCAP, Electric and KICAD would be my main suspects.
Cheers,
Magnus
Paul,
How did you do the GRI counter? I'd like to use an N8290A chip as a
programmable decade counter, but they are obsolete.
Best,
-John
===============
John I did the Loran C simulator. But it acted as a single station and its
only goal was to allow austrons and such to do phase comparison of
oscillators. Took only a few chips simple and small.
I was at the tail end of loran A in the navy. Really do not remember
anything about the theory any more.
I was going to speculate on a solution but its to late at night.
Regards
On Fri, Jan 7, 2011 at 10:54 PM, Magnus Danielson <
magnus@rubidium.dyndns.org> wrote:
On 08/01/11 03:28, J. Forster wrote:
I'm looking at building a LORAN-A simulator to run a vintage display.
Hmm. Generating blips programmed in repetition rate and delay as steps
of a
10 MHz clock should be sufficient and fairly straight forward. A lower
clock
such as 1 MHz would probably work well (and simplify the design). A
programmable delay (needs to be 19 bit for 10 MHz and 15 bit for 1 MHz)
using standard synchronous counters should not be too hard. Once
designed
it's a matter of deciding how many slaves shall be supported. A PIC or
AVR
could do the NMEA position to delay conversions needed, and I mostly
worry
about the math-support on them, which only shows that I haven't done any
real project on any of them.
I used to design stuff with gates and counters by hand, and can still
do
so, but it's tedious.
Does anyboby know of any freeware that can be used to draw up logic and
simulate its operation, including propagation delays? I don't need
exotic
chips or any analog functions. A library of common 74... and 40..
would
be nice.
Freeware strongly preferred.
Eagle, GEDA/GNUCAP, Electric and KICAD would be my main suspects.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Well, Perry, you were right. The thread has drifted into technology
when the real challenge is the catalog for all that has gone before.
But perhaps that is not within this group's charter.
History Channel did a reasonable presentation of the Knights Templar,
within their tabloid guidelines, tonight. Talk about massive amounts
of information being concealed before and especially after 1307.
Time (the subject of this group) keeps on slipping into the future,
leaving hints of things lost in its wake.
Sorry I couldn't work any chips or programs into this posting.
At least we do have an archive, although the subjects do mutate from
the subject lines.
Bill Hawkins
-----Original Message-----
From: Perry Sandeen
Sent: Friday, January 07, 2011 2:59 PM
------- big Snip -------- %< -------
So where am I going with all this? Glad you asked.
No one knows if their or others data will lead to a new discovery
or process. Da Vinci certainly didn't. It can however; lead to
learning that can then can be taken to the next level of knowledge
and invention.
John,
On 08/01/11 05:04, J. Forster wrote:
Magnus,
See my post of a few minutes ago.
The GRI and Delay counters need to be 5 decimal digits. My current
thinking is manual entry of the numbers via BCD coded thumbwheel switches.
If you only need a static location that will be fine. Naturally you tune
it up to the ships current (final?) position. Good exercise for the
visitors. :)
LORAN-A has 24 possible GRIs; in three blocks of 33 PPS; 25 PPS; and 20
PPS. It also has 4 RF frequencies.
I did a fashinating read-up here:
http://www.jproc.ca/hyperbolic/loran_a.html
GRI is a LORAN-C term if I get it correctly, where as PRR is used
together with frequency indication in LORAN-A.
Currently I plan only one Slave, but a second would be an easy addition.
Indeed. Considering the chain that used to be there, you could allow for
two chains to be setup on the same frequency (1H chains).
Cheers,
Magnus
On 08/01/11 06:54, Magnus Danielson wrote:
John,
On 08/01/11 05:04, J. Forster wrote:
Magnus,
See my post of a few minutes ago.
The GRI and Delay counters need to be 5 decimal digits. My current
thinking is manual entry of the numbers via BCD coded thumbwheel
switches.
If you only need a static location that will be fine. Naturally you tune
it up to the ships current (final?) position. Good exercise for the
visitors. :)
LORAN-A has 24 possible GRIs; in three blocks of 33 PPS; 25 PPS; and 20
PPS. It also has 4 RF frequencies.
I did a fashinating read-up here:
http://www.jproc.ca/hyperbolic/loran_a.html
GRI is a LORAN-C term if I get it correctly, where as PRR is used
together with frequency indication in LORAN-A.
Pondering some more on this, doing some calculations (spread-sheets) the
actual scheme emerge... the range of 0 to 7 is not selected by accident.
The base pulse repetition rate is 30 ms, 40 ms and 50 ms. The pulse
repetition rate modifiers modifies the repetition rate by -100 us per
step. It would only take two (or possibly three) wheels to select PRR.
This explains the high rate starts with 33 3/9... it also makes the
receiver design easier to understand.
So a 10 kHz source would suffice for PRR settings. A phantastron divider
from a 100 kHz standard should do it in those days technology, if not a
10 kHz standard was used directly.
Only the delayed pulse would need the full set of thumb-wheels.
Cheers,
Magnus