9 Oct
2005
9 Oct
'05
7:50 a.m.
This whole discussion about the volatility of storage
reminds
me of a conversation I had recently with a friend who's a
professional archivist. I asked her what medium was used for
archival storage--CD-ROM, DVD, etc.?
Paper. No ifs ands or buts about it.
Sorry to steal your thread, but...
I have been talking with my state's historical archiving group. They are
very interested in some form of digital media for archiving, and are now
aware that paper (and microform) still offer the best solutions. They
are back to the issue of digital archiving for a new reason, space. They
would like to have some form of high density storage (higher than paper)
and they can accommodate a shorter shelf life if they can get it into
the 10+ year range. They are exploring a digitization program with
long-term remote storage of the original material in a storage facility
(off-line storage if you will), and a technology refresh program to
re-format the digital storage as mediums change (like the recent move
from CD-ROM to DVD-ROM).
Does anyone know if there are optical formats that can reliably deliver
10 year shelf-life? How does one achieve it (different types of cd-r
chemistry, using cd-rom, etc)?
9 Oct
9 Oct
12:06 p.m.
On 10/9/2005 at 7:50 AM James Fogg wrote:
Does anyone know if there are optical formats that can
reliably deliver
10 year shelf-life? How does one achieve it (different types of cd-r
chemistry, using cd-rom, etc)?
(Mindless rambliing) Lawrence Livermore used to have some sort of photographic data
storage unit that was pretty unique. I can't even remember the name of the thing, does
any recall it?
(Back to topic) There are manufacturers of CD-R media who claim 100-300 year shelf life, a
claim that's probably a bit overblown, but might be candidates for a 10 year life.
Mitsui is one of those making such a claim (I've always had great results with their
media):
http://www.mediasupply.com/mtc80lsgos-100.html
They're not cheap, but they're better than the average "a whole bunch for
nearly nothing" stuff.
Cheers,
Chuck
4:07 p.m.
(Mindless rambliing) Lawrence Livermore used to have
some sort of
photographic data storage unit that was pretty unique. I can't even
remember the name of the thing, does any recall it?
Don't know.
But at GSFC (Goddard Space flight Center), we used a
Stromberg-Datagraphics 4060 to do computer text
output direct to microfilm.
The only important thing that I did there was conversion routine to
send Calcomp plotter (570? 780?) data direct to the SD 4020/4060s
4:24 p.m.
...
> (Mindless rambliing) Lawrence Livermore used to
have some sort of
> photographic data storage unit that was pretty unique. I can't even
> remember the name of the thing, does any recall it?
Back in the late '60s I remember seeing a unit from IBM that used film
storage. The film was a small rectangle, maybe 1" x 2-1/2". These were
stored in magazines of some sort, IIRC. They could be individually selected
randomly.
I have one of the film rectangles somewhere. When I run across it again I
will post a link to an image. In the mean time, does this ring a bell with
anyone?
I can't remember a model number or anything, so perhaps it was a proof of
concept or something. I was working at Baylor Medical in Houston & they had
a pretty good in with IBM. We had all manner of strange devices installed on
a 360/50 from time to time. We even had one of those noodle snatchers in for
a while.
I also remember when we got our first megabyte memory - called a Large Core
Storage. It was from Ampex and was about the size of a refrigerator - maybe
a little deeper. There was a visible stack of core planes about 4' tall
inside it.
Gil
4:44 p.m.
Back in the late '60s I remember seeing a unit
from IBM that used film
storage. The film was a small rectangle, maybe 1" x 2-1/2". These were
stored in magazines of some sort, IIRC. ... does this ring a bell with
anyone?
One of those cubes was shown to me by an IBM research staffer in 1991,
he knew I was interested in computer history and arranged for me to get a
tour of the hardware archive center. The cube matched your description
quite closely, I remember it now (somewhat weakly) as being like safety
razor dispenser.
John A.
6 p.m.
Found it! -- after I posted I heard my memory saying "Photostore?"....
The IBM 1360 Photostore. Google's got plenty on it.
Cheers,
Chuck
9:05 p.m.
Chuck Guzis wrote:
Found it! -- after I posted I heard my memory saying
"Photostore?"....
The IBM 1360 Photostore. Google's got plenty on it.
There's a book, Digital Computer Analysis by James F. Turner,
which has a couple pages on it.
Data are stored on photographic film "chips" which hold 32 frames and
are 1.38 x 2.75 inches in size. 492 tracks per frame, each holding
420 bits, including check, start, sync, and line number bits. A
modulated electron beam is used to write pairs of tracks (the beam is
swept both ways).
The chips are stored in "cells", and the cells are stored in drawers
in "cell files" which are connected to the recording and reading
stations by pneumatic tubes. And yes, the idea was that you could
build one with sufficient cell files to store a terabit.
-Frank McConnell
4:12 p.m.
On Sun, 9 Oct 2005, James Fogg wrote:
Does anyone know if there are optical formats that can
reliably deliver
10 year shelf-life? How does one achieve it (different types of cd-r
chemistry, using cd-rom, etc)?
Just use hard drives. Cheap, high capacity, and reliable.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
4:39 p.m.
Vintage Computer Festival declared on Sunday 09 October 2005 03:12 pm:
On Sun, 9 Oct 2005, James Fogg wrote:
And make sure you keep them spinning, so that you can tell when they
fail, along with a redundant copy on another machine which you mirror to
periodically (even automatically once every N days is fine). Migrate to
newer media when the old stuff is pretty much obsolete.
If you manage to do that, your data will long outlast any CDRs that you
store in a filing cabinet next to the computer(s).
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Does anyone know if there are optical formats
that can reliably
deliver 10 year shelf-life? How does one achieve it (different types
of cd-r chemistry, using cd-rom, etc)?
Just use hard drives. Cheap, high capacity, and reliable. 
11 Oct
11 Oct
5:16 p.m.
[M]y state's historical archiving group [] are
back to the issue of
digital archiving for a new reason, space. They would like to have
some form of high density storage (higher than paper)
Paper may actually not be totally out of the question. With decent
printing technology you can get about 75dpi with fairly clear
readability. If you put 8x10.5 inches of data on an 8.5x11 inch page,
that gives you 8*10.5*75*75 or 472500 bits, 59062.5 bytes, per page
(or, actually, per page side).
You'd want to keep a few pages describing the encoding used in English,
but they're overhead and can be amortized over many pages of data.
With sufficient patience and a magnifier (and proper encoding algorithm
description) it could even be unpacked by hand.
Does anyone know if there are optical formats that can
reliably
deliver 10 year shelf-life?
Ummm...do pressed CDs count? (As opposed to CD-Rs and CD-RWs.) Not
many collections of data are worth doing a one-off pressed CD, but it
may not be out of the question for some data.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5:43 p.m.
At 04:16 PM 10/11/2005, der Mouse wrote:
Paper may actually not be totally out of the question.
With decent
printing technology you can get about 75dpi with fairly clear
readability.
As we've flogged many times before, "Which printing technology"?
Laser printer toner has characteristics that make it unsuitable
(such as the way it'll transfer from page to page when pressed
tightly). Ink jets are soluble. Dye sub? Wax transfer?
If you put 8x10.5 inches of data on an 8.5x11 inch
page,
that gives you 8*10.5*75*75 or 472500 bits, 59062.5 bytes, per page
(or, actually, per page side).
Or about five reams of ordinary copy paper per CD, consuming
most of an ordinary laser toner cartridge, not even counting
any overhead for error correction. Not cheap, not easy, not
even reliable - and considering you'd need to develop new
forms of paper-reading equipment and software to retrieve it.
- John
5:58 p.m.
At 04:43 PM 10/11/2005, John Foust wrote:
At 04:16 PM 10/11/2005, der Mouse wrote:
Whoops. Error in spreadsheet and operator.
Make that 92 reams per CD - or about 60 meg per ream.
- John
If you put 8x10.5 inches of data on an 8.5x11 inch
page,
that gives you 8*10.5*75*75 or 472500 bits, 59062.5 bytes, per page
(or, actually, per page side).
Or about five reams of ordinary copy paper per CD
6:55 p.m.
On Tuesday 11 October 2005 16:58, John Foust wrote:
At 04:43 PM 10/11/2005, John Foust wrote:
At 700MB/cd, it'd be about 12 reams per CD, not 92. 92 reams would get
you about 5.4GB, which is more than a (single-sided, single layer)
DVD-R holds.
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
At 04:16 PM 10/11/2005, der Mouse wrote:
Whoops. Error in spreadsheet and operator.
Make that 92 reams per CD - or about 60 meg per ream. If you put 8x10.5 inches of data on an 8.5x11 inch
page,
that gives you 8*10.5*75*75 or 472500 bits, 59062.5 bytes, per page
(or, actually, per page side).
Or about five reams of ordinary copy paper per CD
8:17 p.m.
At 05:55 PM 10/11/2005, Patrick Finnegan wrote:
At 700MB/cd, it'd be about 12 reams per CD, not 92.
92 reams would get
you about 5.4GB, which is more than a (single-sided, single layer)
DVD-R holds.
My math:
472,500 bits per page
945,000 bits per double-sided page
118,125 bytes per double-sided page
681,574,400 bytes per 650 M CD
5,452,595,200 bits per CD
46,160 pages
92 reams
59,062,500 bytes per ream
- John
10:49 p.m.
John Foust declared on Tuesday 11 October 2005 07:17 pm:
At 05:55 PM 10/11/2005, Patrick Finnegan wrote:
At 700MB/cd, it'd be about 12 reams per CD,
not 92. 92 reams would
get you about 5.4GB, which is more than a (single-sided, single
layer) DVD-R holds.
My math:
472,500 bits per page
945,000 bits per double-sided page
118,125 bytes per double-sided page
681,574,400 bytes per 650 M CD
5,452,595,200 bits per CD 46,160 pages
92 reams
59,062,500 bytes per ream
^^^
That's bytes per ream, not bits per ream.
681MByte/CD / 59MByte/ream = 11.5 reams/CD
Pat
--
Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
11:13 p.m.
Patrick Finnegan wrote:
John Foust declared on Tuesday 11 October 2005 07:17
pm:
I was looking for Fortran IV programs and got reading on the History of
FORTRAN.
In 1957 they could not punch out the 2,000 binary cards of FORTRAN II
and had to go tape instead.
Now that is about 72*12 bits per card ... you work out the math.
At 05:55 PM 10/11/2005, Patrick Finnegan wrote:
At 700MB/cd, it'd be about 12 reams per CD,
not 92. 92 reams would
get you about 5.4GB, which is more than a (single-sided, single
layer) DVD-R holds.
My math:
472,500 bits per page
945,000 bits per double-sided page
118,125 bytes per double-sided page
681,574,400 bytes per 650 M CD
5,452,595,200 bits per CD
46,160 pages
92 reams
59,062,500 bytes per ream
^^^
That's bytes per ream, not bits per ream.
681MByte/CD / 59MByte/ream = 11.5 reams/CD
Pat
12 Oct
12 Oct
12:27 a.m.
On 10/11/2005 at 9:13 PM woodelf wrote:
I was looking for Fortran IV programs and got reading
on the History of
FORTRAN.
In 1957 they could not punch out the 2,000 binary cards of FORTRAN II
and had to go tape instead.
Now that is about 72*12 bits per card ... you work out the math.
Huh? I've used a card-based 1401 FORTRAN II. Two decks--you read in the first deck,
then your source program. An intermediate deck was punched. You then read in the second
pass of the compiler, followed by the cards punched by the first pass. An object deck was
punched.
2000 cards is about a box. Not a spectacular amount at all. Tape WAS easier, however.
Cheers,
Chuck
12:30 a.m.
On Tue, 11 Oct 2005, woodelf wrote:
I was looking for Fortran IV programs and got reading
on the History of
FORTRAN.
In 1957 they could not punch out the 2,000 binary cards of FORTRAN II
and had to go tape instead.
Now that is about 72*12 bits per card ... you work out the math.
"could not punch out 2,000 binary cards"????
I've punched many decks much larger than that.
(DP of Office of Civil Rights, Space Sciences Data Center at GSFC)
You CAN refill the supply
and empty the output without stopping the punch.
But,..
tape certainly is HANDY when you are talking about more than a box of
cards.
--
Grumpy Ol' Fred cisin at xenosoft.com
1:17 a.m.
Fred Cisin wrote:
"could not punch out 2,000 binary cards"????
I've punched many decks much larger than that.
(DP of Office of Civil Rights, Space Sciences Data Center at GSFC)
Well you can read it yourself.
http://www.stanford.edu/group/mmdd/SiliconValley/Backus/backus.html
You CAN refill the supply
and empty the output without stopping the punch.
But,..
tape certainly is HANDY when you are talking about more than a box of
cards.
Looking at all the restored old software , very little seems to have
been kept in a vault
like old movies by DEC or IBM or the other computer companies. I think
this is reminding
us something important, private people need to be able to have
information that only the
today M$ and Intel are keeping private to themselves.
1:44 a.m.
Re: cards and FORTRAN II.
When it comes to stuff like FORTRAN II, the question comes up: "Whose FORTRAN
II?" There were lots and lots of variants. I seem to recall that 7090 FMS II
FORTRAN had its share of strange things, like punching a "D" in column 1 to get
double-precision arithmetic. Yet the compiler-on-cards hung around for quite a while.
The 1620 certainly had it--and I think a card-based FORTRAN was available for the 360/20,
although it may have been something like USA Basic FORTRAN.
Cheers,
Chuck
1:50 a.m.
> > In 1957 they could not punch out the 2,000
binary cards of FORTRAN II
> > and had to go tape instead.
> > Now that is about 72*12 bits per card ... you work out the math.
>"could not punch out 2,000 binary
cards"????
>I've punched many decks much larger than that.
>(DP of Office of Civil Rights, Space Sciences Data Center at GSFC)
On Tue, 11 Oct 2005, woodelf wrote:
Well you can read it yourself.
http://www.stanford.edu/group/mmdd/SiliconValley/Backus/backus.html
Thank you for the reference
It doesn't really say that they "could not" punch over 2,000 cards;
it says that THEY were having a lot of errors, and WANTED a
faster, more reliable method. In fact, it explicitly says that they
DID punch and distribute some decks.
Ten years later, when I was doing EAM and punched card data processing
with 360s with FORTRAN IV, WATFOR, and even PDQ FORTRAN on 1620, the
punches were quite a bit more reliable. and multi-box decks were not
uncommon.
2:10 a.m.
On 10/11/2005 at 10:50 PM Fred Cisin wrote:
It doesn't really say that they "could
not" punch over 2,000 cards;
it says that THEY were having a lot of errors, and WANTED a
faster, more reliable method. In fact, it explicitly says that they
DID punch and distribute some decks.
I remember that even the newer punches would warm up, particularly when binary decks were
being produced and start having problems. This was true even on the punch on the CDC
6600, which was the last system with a punch that I used (or maybe noticed that had one).
Cheers,
Chuck
11:58 a.m.
At 05:55 PM 10/11/2005, Patrick Finnegan wrote:
Without checking it (it's late, OK...) the ratio of 'about 92 reams' to
'about 12 reams' is about 8. Is there a bits/bytes mixup somewhere?
-tony
At 700MB/cd, it'd be about 12 reams per CD,
not 92. 92 reams would get
you about 5.4GB, which is more than a (single-sided, single layer)
DVD-R holds.
My math:
472,500 bits per page
945,000 bits per double-sided page
118,125 bytes per double-sided page
681,574,400 bytes per 650 M CD
5,452,595,200 bits per CD
46,160 pages
92 reams
59,062,500 bytes per ream
11 Oct
11 Oct
6:03 p.m.
On 10/11/2005 at 4:43 PM John Foust wrote:
As we've flogged many times before, "Which
printing technology"?
Laser printer toner has characteristics that make it unsuitable
(such as the way it'll transfer from page to page when pressed
tightly). Ink jets are soluble. Dye sub? Wax transfer?
Back when small printers were hard to come by, there was at least one technology that used
a "paper' made of a black layer on a paper substrate covered by a very thin layer
of aluminum. The printer burned through the aluminum, leaving the black spots exposed.
Oddly enough, this sounds like a fiarly permanent process. Was the stuff called
"electrographic" paper?
Before CD's, weren't there some experimental recording methods using phase-change
glass? Was it the Ovionics people that pioneered this?
Photographic images have a very long life, assuming careful storage. Tintypes maybe?
Cheers,
Chuck
13 Oct
13 Oct
3:42 a.m.
Chuck Guzis wrote:
Back when small printers were hard to come by, there was at least one technology
that used a "paper' made of a black layer on a paper substrate covered by a
very
thin layer of aluminum. The printer burned through the aluminum, leaving the black
spots exposed. Oddly enough, this sounds like a fiarly permanent process. Was the
stuff called "electrographic" paper?
The Canon EP151 calculator used this technique as early as 1971.
A rotating stylus is fed with 120 VDC driven by the output of an
early MOS character generator ROM.
Even earlier though: Western-Union/Seeburg TeleFax FAX machines circa 1960 used
the technique. The paper is placed on a rotating drum for scanning and output.
The output paper is similar to carbon paper with an additional aluminised coating
or an aluminum-carbon amalgam.
All tubes. Signal is analog, mechanically chopped for Pulse-Amplitude-Modulation
transmission over the telcom line.
(.. got two of them, but they don't work simply connected back-to-back, have to
figure out what was in the 'cloud' in between, someday.)
11:08 a.m.
On Thu, 13 Oct 2005, Brent Hilpert wrote:
(.. got two of them, but they don't work simply
connected back-to-back,
have to figure out what was in the 'cloud' in between, someday.)
When you figure it out, let me know and we can send old school faxes to
each other ;)
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
4:50 p.m.
On Thu, 13 Oct 2005, Brent Hilpert wrote:
(.. got two of them, but they don't work simply
connected back-to-back, have to
figure out what was in the 'cloud' in between, someday.)
power
They might also be dependent on certain "signals", such as getting a dial
tone before willing to originate a call.
14 Oct
14 Oct
1:24 a.m.
Fred Cisin wrote:
On Thu, 13 Oct 2005, Brent Hilpert wrote:
Thanks for the suggestion but.. it appears the units were intended for use over
dedicated lines, not POTS/dialup. There is some DC signalling involved for Start/End
of Transmission, ACK and c. but thats easy enough to work around. Looking for dial
tone is way more sophisticated than what these units do.
It was a while ago that I was looking at it (rev. eng. to produce schematic and
some initial experimentation), but as I recall when they were simply connected
back-to-back, the received fax ended up being a poor-quality *negative* of the
original. I think I concluded that the PAM signal needed to be
amplitude-inverted, e.g. if the AC amplitude range of the PAM signal is 0 to 10V,
then 3VAC transmitted needs to be converted to 10-3=7VAC received (not simply
polarity inverted).
I was a little perplexed as it seemed like a somewhat sophisticated/complex
transformation to accomplish for the time and application.
I presumed there must have been some sort of
line-balancing/matching/amplification/regeneration going on within the
dedicated lines / special network that they operated over which accomplished
such.
I was thinking of doing an amplitude detection on the PAM signal, feeding it
into the inverting input of an op amp, with the positive input fed from a
manually adjusted level or perhaps a maximum-level-hold sensed from the PAM.
Or else I'm way off and am missing something terribly obvious.
Vintage Computer Festival wrote:
(.. got two of them, but they don't work
simply connected back-to-back, have to
figure out what was in the 'cloud' in between, someday.)
power
They might also be dependent on certain "signals", such as getting a dial
tone before willing to originate a call.
When you figure it out, let me know and we can send old school faxes to
each other ;)
That would be fun, but the above makes connecting them over a distance
today awkward. If you actually have *two* of these units (WU Desk Fax /
Telefax 6500 / chassis 6499-A, footprint about one square foot, curved
sheet-metal cover in hammertone green, red white & green pushbuttons on left,
lamp and 4th pushbutton on right) I'll let you know what's needed to
interconnect them if I ever figure something out.
(I suppose the above is tending OT, but I like to think some limited
mention/discussion of the precursor technologies to the applications
accomplished digitally/with computers today is acceptable and of interest here.)
9:13 a.m.
New subject: Ancient faxing (was Re: Archival storage)
On Thu, 13 Oct 2005, Brent Hilpert wrote:
Vintage Computer Festival wrote:
Sounds exactly like what I have, but I only have one :(
Found some nice pictures of ancient fax machines:
http://www.hffax.de/html/hauptteil_faxhistory.htm
(Beware: that page was doing weird stuff with my desktop)
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
When you figure it out, let me know and we can send old school faxes to
each other ;)
That would be fun, but the above makes connecting them over a distance
today awkward. If you actually have *two* of these units (WU Desk Fax /
Telefax 6500 / chassis 6499-A, footprint about one square foot, curved
sheet-metal cover in hammertone green, red white & green pushbuttons on left,
lamp and 4th pushbutton on right) I'll let you know what's needed to
interconnect them if I ever figure something out.
11 Oct
11 Oct
11:39 p.m.
Paper may
actually not be totally out of the question. With decent
printing technology you can get about 75dpi with fairly clear
readability.
As we've flogged many times before, "Which printing
technology"? Laser printer toner has characteristics that make it
unsuitable (such
as the way it'll transfer from page to page when pressed tightly).
Ink jets are soluble. Dye sub? Wax transfer?
It doesn't have to be anything currently available in a mass-market
computer printer (which you didn't explicitly say, but all your
examples are).
Not cheap, not easy,
Nothing for storing that much data with anything like the durability
ink-on-paper offers will be, I suspect.
not even reliable - and considering you'd need to
develop new forms
of paper-reading equipment and software to retrieve it.
New equipment? Hardly, not as long as some kind of decent-resolution
digital photography is available. Software? Perhaps, but not very - I
have a 300dpi scanner next to my monitor, and I believe I could cobble
something together in no more than a few days to turn (scans of) such
pages into a big array o' bits. (And from there, it would depend on
the encoding algorithms, which is why I specifically mentioned
documenting them on directly human readable pages.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
11:58 p.m.
der Mouse wrote:
New equipment? Hardly, not as long as some kind of
decent-resolution
digital photography is available. Software? Perhaps, but not very - I
have a 300dpi scanner next to my monitor, and I believe I could cobble
something together in no more than a few days to turn (scans of) such
pages into a big array o' bits. (And from there, it would depend on
the encoding algorithms, which is why I specifically mentioned
documenting them on directly human readable pages.)
What about photograpic paper , the kind you print B&W photographs on?
I still like the idea of 35mm film and some sort of holograph style of data
encoding.
Ben alias woodelf
12 Oct
12 Oct
12:38 a.m.
On Tue, 11 Oct 2005, woodelf wrote:
What about photograpic paper , the kind you print
B&W photographs on?
I still like the idea of 35mm film and some sort of holograph style of data
encoding.
Kodak has discontinued manufacturing of B&W photographic paper!!!
And if you don't do an extraordinarily conscientious job of hypo
(typically sodium thiosulphate) removal, it will discolor and fade.
There are special procedures for "archival" processing; it is hard
to find a commercial lab that will do it right.
12:48 a.m.
Has anyone suggested stone tablets yet?
My idea is self-propagating storage with a nice fat error correcting
code like the one used on this project to record data to mini-dv tapes:
http://dvbackup.sourceforge.net/ Add more error correcting code to
taste.
So maybe devote 50 meg of a CD or DVD to a mini linux distro like damn
small linux that boots to a menu and can either replicate the OS and
payload to another CD/DVD or ftp/http/scp/etc. the payload to another
machine that you give it the IP address and login for.
This would be usable as long as CD or DVD drives and PCs or PC emulators
are around. It carries the code to replicate itself like a virus. Before
CD/DVD drives become archaic you just boot it up and transfer it to
another medium.
Actually with emulators, .iso images themselves are bootable, so you
could just rip the .iso file and transfer it to the medium du jour.
One snafu is that for it to work you would want the error correcting
code to also be applied to the self-replicating software. Otherwise you
could end up with a payload and no (easy, and the key here is easy)way
to unlock it. Have to look into bootable CDs and see how that works...
-- John.
1:19 a.m.
On Tue, 11 Oct 2005, John R. Hogerhuis wrote:
Has anyone suggested stone tablets yet?
Yes, but nobody remembers how to read Stonehenge.
One snafu is that for it to work you would want the
error correcting
code to also be applied to the self-replicating software. Otherwise you
could end up with a payload and no (easy, and the key here is easy)way
to unlock it. Have to look into bootable CDs and see how that works...
self replicating data storage,... DNA perhaps?
1:29 a.m.
Fred Cisin wrote
Yes, but nobody remembers how to read Stonehenge.
There is nothing there to READ. Just a big analog? computer to calculate
the seasons and stuff with the sun and moon. The problem is the program
works only for where stonehenge is today ... It is the lack of doc's that
kill ya.
10:19 a.m.
New subject: Stonehenge Documentation was: Re: Archival storage
On Tue, 11 Oct 2005 23:29:20 -0600, woodelf wrote:
For fear of driving Sellam off in nausea for keeping this thread alive :)
I will keep completely off topic, and brief,. You struck a nerve with Stonehenge
documentation
as I am currently writing a book on the subject of the documentation surrounding
stonehenge.
If you were to look closely, you would find that there is quite a lot of documentation
about stonehenge dating from the first surviving written reference to Stonehenge,
dating back to the Norman Conquest of 1066 AD.
It was not until 1719 when William Stukeley first visited Stonehenge on May 18-19th, 1719,
and
returned on many occasions to carry out fieldwork Stukeley was the first to pointed out
that
Stonehenge had solar and lunar significance.
1934 - Alexander Thom had become interested in prehistoric stone circles and their
astronomical
associations. The nature of his interests is expressed in an article he published in 1951
in the
Journal of the British Astronomical Association entitled "The solar observations of
megalithic man."
The 1960s brought the System 360 and new wave of interest in Stonehenge. Publications by
Gerald S. Hawkins and John Michell "A Little History of Astro-Archaeology"
all claiming complex geometric and astronomical alignments for the site.
An old friend and regular contributor Bill Kramer has a good read on the subject.
http://www.eclipse-chasers.com/henge1.html
"The Stonehenge Eclipse Calculator" documents the use of stonehenge as an
eclipse calculator.
As for the original topic : Re: Archival storage ?
My suggestion is to uses an Epson photo 2200 on 13x19 archival paper using archival ink at
what ever density <2800 dpi you can get away with :)
The paper and ink costs would go up a bit, but it would be many fewer reams of paper :)
I agree with Sellam and others, we are now beating the spot where the horse died
yesterday.
But for the record, in this day in age the rule is to have 3 or more copies of everything
important with at least one on the shelf, and a live backup colocated in a remote location
or data center
somewhere.
Please reply off list to this mutterings as I have wasted far too much bandwidth already
with this Google fodder ....
BTW: is there an indexed archive of this list ?
Bob Bradlee
Fred Cisin wrote
Yes, but nobody remembers how to read Stonehenge.
There is nothing there to READ. Just a big analog? computer to calculate
the seasons and stuff with the sun and moon. The problem is the program
works only for where stonehenge is today ... It is the lack of doc's that
kill ya.
14 Oct
14 Oct
4:39 p.m.
New subject: Stonehenge Documentation was: Re: Archival storage
Bob Bradlee wrote:
I agree with Sellam and others, we are now beating the
spot where the horse died yesterday.
But for the record, in this day in age the rule is to have 3 or more copies of everything
important with at least one on the shelf, and a live backup colocated in a remote location
or data center
somewhere.
And FREE documents ... I can see standards having a printing price for
paper but not online text.
10:16 p.m.
New subject: Stonehenge Documentation was: Re: Archival storage
On Wed, 12 Oct 2005, Bob Bradlee wrote:
For fear of driving Sellam off in nausea for keeping
this thread alive :)
Well at least it's about something cool like Stonehenge and not same lame
thread on car engines.
But anyway, my bile was roiling over that lame Freeman PC Museum auction
that kept getting posted over and over and over...
BTW: is there an indexed archive of this list ?
http://www.classiccmp.org/lists.html
Click on either list link, then click on the archive link at the top of
the area on the right side of the next screen.
But eEverytime I try to use the search feature it ends in abject futility.
I wish that would get fixed.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
10:33 p.m.
New subject: Stonehenge Documentation was: Re: Archival storage
Sellam wrote...
But eEverytime I try to use the search feature it ends
in abject futility.
I wish that would get fixed.
As I've said many times before... if you use it
during the day it chokes,
but in the evening it works. During the day the index is rebuilt (yes, it
takes the entire day).
I have an idea to fix this, but I'm way too busy with the classiccmp website
redesign - new features, etc. More later.
Yes, it will get fixed so that indexing is quicker. Promise.
Jay
2:45 a.m.
On Tue, 2005-10-11 at 22:19 -0700, Fred Cisin wrote:
On Tue, 11 Oct 2005, John R. Hogerhuis wrote:
Sort of. AFAIK DNA does not self replicate, that is if there is some DNA
laying around it won't just start making copies of itself. There is a
lot of supporting machinery in a cell that needs to be in place. Some
things in the cell aren't even coded for in the main DNA like
mitochondria.
So maybe the more accurate analogy would be a cell, with the DNA as
payload but with the payload containing information and description for
making all necessary machinery to decode the data and make copies.
Cell/DNA analogy only goes so far, since although it is data, bit errors
are tolerated and the organism deals with it or dies. In an engineered
system no data loss is permitted (though error correction is OK).
The issue I was seeing was that there seems to be a requirement for some
bootstrap code that is never corrupted. This bad since the whole point
of this is that we trying to tolerate errors by adding error correcting
codes.
Is it possible to make executable code which is resistant to bit errors?
Say just assume X86... is it possible to write some minimal bootstrap
code that can tolerate errors in itself, but run long enough w/out
crashing the machine to decode a secondary boot loader that is padded
with error correcting code? That initial bootstrap code can be
inefficient as hell...
-- John.
Has anyone suggested stone tablets yet?
Yes, but nobody remembers how to read Stonehenge.
One snafu is that for it to work you would want
the error correcting
code to also be applied to the self-replicating software. Otherwise you
could end up with a payload and no (easy, and the key here is easy)way
to unlock it. Have to look into bootable CDs and see how that works...
self replicating data storage,... DNA perhaps?
11:23 a.m.
John R. Hogerhuis wrote:
Is it possible to make executable code which is
resistant to bit errors?
Say just assume X86... is it possible to write some minimal bootstrap
code that can tolerate errors in itself, but run long enough w/out
crashing the machine to decode a secondary boot loader that is padded
with error correcting code? That initial bootstrap code can be
inefficient as hell...
It is not bit errors that is the problem -- It is all the windows crappy
hardware.
Before windows you only had a few real I/O devices -- broken serial port,
broken printer port, crummy Floppy , some custiom BIOS Hard Drives and
a few other HD types. Now look at all the GUI stuff you need just to
boot..
-- John.
PS -- Is computer controled RNA by a sythnetic ORGANIC computer software
software or hardware? The X-files Cell type :)
11 Oct
11 Oct
6:07 p.m.
der Mouse wrote:
Paper may actually not be totally out of the question.
With decent
printing technology you can get about 75dpi with fairly clear
readability
Umm give me the record instead -- @1200 baud :)
What ever happed to the cheap write once media , something like paper
tape or magnetic
stipe cards with I think laser holes similar to a CD. I saw it in BYTE
once but I never heard
about them again. Note Digital Paper looks like a intersting storage
medum too,
Does anyone know if there are optical formats that
can reliably
deliver 10 year shelf-life?
Ummm...do pressed CDs count? (As opposed to CD-Rs and CD-RWs.) Not
many collections of data are worth doing a one-off pressed CD, but it
may not be out of the question for some data.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
.
12 Oct
12 Oct
12:26 a.m.
On Tue, 11 Oct 2005, Chuck Guzis wrote:
How about Hollerith cards made of thin sheets of
irridium?
The Oral Tradition seems to have served some cultures well :)
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
12:41 a.m.
On Tue, 11 Oct 2005, Chuck Guzis wrote:
> How about Hollerith cards made of thin sheets of irridium?
On Tue, 11 Oct 2005, Vintage Computer Festival wrote:
The Oral Tradition seems to have served some cultures
well :)
NOTHING lasts as long as urban legends. Now, all that you need to do is
to develop the steganography to imbed your data in them.
... and NOTHING travels as fast as bad news, ...
10:36 a.m.
Vintage Computer Festival wrote:
On Tue, 11 Oct 2005, Chuck Guzis wrote:
Heck, beam your data into space. Then wait for FTL space travel to be
developed so that you can overtake it and get it back again :)
How about Hollerith cards made of thin sheets of
irridium?
The Oral Tradition seems to have served some cultures well :) 
12 Oct
12 Oct
12:25 a.m.
On Tue, 11 Oct 2005, Sridhar Ayengar wrote:
How long do Mitsui Gold CD-R's last?
We don't know yet.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
6861
days inactive
6867
days old
48 comments
18 participants
participants (18)
-
allain＠panix.com -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
Bob＠BRADLEE.ORG -
cclist＠sydex.com -
cisin＠xenosoft.com -
fmc＠reanimators.org -
gilcarrick＠comcast.net -
hilpert＠cs.ubc.ca -
James＠jdfogg.com -
jfoust＠threedee.com -
jhoger＠pobox.com -
julesrichardsonuk＠yahoo.co.uk -
jwest＠classiccmp.org -
mouse＠Rodents.Montreal.QC.CA -
pat＠computer-refuge.org -
ploopster＠gmail.com -
vcf＠siconic.com