> Redundancy helps to recover partially damaged data. Redundancy 1:5 means that for every 5 consecutive data blocks, if one block is completely unreadable, PaperBack will be able to restore it. To reduce damages caused by coffee pots and other common dangers, blocks are distributed around the page. Higher redundancy decreases page capacity but improves reliability.
Please do study error correcting codes. Most of them can offer much better error correction with less overhead. Take a look at Wolfram's MathWorld article [1]. This topic is heavily covered in most information theory books.
I don't know how many people remember this, but this reminds me of a technology in the mid-to-early 80s where computer magazines offered a gigantic QR-like code that could be scanned (if you bought the device) so that you wouldn't have to spend any time typing in the BASIC source code.
Software was published via standard one-dimensional bar codes, and instead of typing in the code from a book or magazine, you'd manually scan line after line of barcodes using a specially designed hand scanner.
There was this small Casio musical keyboard at home, bought in the 80s (made in Japan I think)
It came with a scanning pen, you could scan a song (from a book) made up of several barcodes (just like the links posted here) and it would play the song.
Baking informaiton into clay tablets isprobably the best bit-per-year-of-rentention technique that mankind has invented. Not sure what's second best -- ink on archival paper?
[I don't count the recordings attached to the Voyager probes. We can't easily retrieve those.]
Oh goodness gracious no, if you're going to measure in linear bit-years it isn't even remotely close. It's hard drives, because the amount of bits stored on hard drives is just so staggeringly enormous it dwarfs the faint traces of fragments of bits and pieces of the ancient world that we've managed to barely save. Orders and orders of magnitude off, even if you decide to count things like raw scans of the ancient stuff as opposed to merely the bits of information in the text and the other handful of useful details like the carbon dating.
You need to do some sort of correction that nonlinearly accounts for lasting more than a few years.
I'm sure we can do better; we just haven't tested the newer alternatives over a long enough time span to be sure. Take a look, for example, at the Long Now Foundation's Rosetta disk:
They made a disk of sturdy, corrosion-resistant metal, micro-etched thousands of pages of text on one side, and covered the other side with a design of words spiraling into the center and getting smaller, until they were no longer visible with the naked eye -- meant to suggest at a glance what the disk was, and how to read it. The text is a record of thousands of existing languages, like a modern, souped-up version of the original Rosetta stone.
Acid free archival paper kept in a dark, fire proof box is to my knowledge the single best technology we've invented and easily at our disposal for long-term storage.
I think I might totally start 'printing out' photos I want to theoretically have available in fifty years and place them in a safety deposit box…
How stable would the various colors of ink needed for pictures be? I suppose you could also print out a separate B/W version of each color channel for later reconstruction.
Maybe you could print out a color calibration strip with known values, and then use that as a benchmark so you could reverse fading via software? Kind of like what NASA/JPL does so they can color-correct photos taken by planetary landers.
(I know that this isn't what the OP meant, but it's interesting to try and mitigate the limitations of the more common backup solution -- i.e., just printing the photos themselves).
Next to paper or parchment (mentioned below), there is a technique, that uses microform. Here in Germany a lot of long-term archival work is done with this material. The information is scanned and "printed" on microfiches. In one image, there can be stored a lot (i think up to 16) pages and a lot of images are on one roll of film. Then these rolls are transferred into special containers and put in an old mine in the German "Black Forest".
There are to date more than 28.000 kilometers of microfilm with round about 850.000.000 images. They estimate, that even in 500 years there will be no information loss on these images.
Very true. Acid-free paper has a expected life of over 1000 years. Think about how long paper documents like the Magna Carta, ancient illuminated bibles from the 700's, Shakespeare's plays have survived without special climate-controlled environments.
Also paper in bulk is hard to destroy. A stack of paper is pretty dense and can survive to some degree a house fire or flood.
If the room the clay tablet is in survives, the clay tablet survives. You can't say the same about hard drives and burned DVDs. Pressed DVDs are probably fine though.
The longevity of clay tablets would be biased by the limited technology of the time. Even engraved granite would be a better choice today, since we can easily machine it now.
"bitmaps produced by PaperBack are also human-readable (with the small help of any decent microscope). I'm joking"
Actually, tiny human-readable text is incredibly useful for verifying the data was backed up correctly (at least for text-based files). I read about this paper backup technique a while ago, and that was touted as one of the main benefits.
Reminds me of a proposal I read about once for a time capsule -- the kind intended to survive the fall of civilization and to help reboot it. It would be plain human-readable text and diagrams engraved into a hard disc of some stable material, starting out big and legible at the edges and gradually getting smaller and smaller as it spirals towards the center, until it's microscopic.
The text would start out as a Rosetta Stone type of thing, to try to establish a common language. Then as it got smaller, it would describe how to grind a hand lens so you can read further. Then even smaller text describes how to build a microscope. Maybe somewhat further on it talks about CD-ROM drives, and eventually transitions to /that/ format...
Very funny. And not so impractical - send a letter with one side as description and other as full data.
For backups I can imagine such situation:
"OMG! My HDD crashed!!!
Ha! No panic! I made backups!
Now I just need to restore them from this bunch of scheets.
And my restore program is on this sheet.
Now ..
Erm..
Hm.."
Three color will take three times as many bits as input and store three times as many bits. Each pixel cell will have eight possible values, but that is just three times the information.
... at a cost of durability. Tho some sort of error recovery algorithm (along the lines of parity archive) could be used.. adding redundancy at a lower rate than what is gained from additional colors..
Color might be useful as redundancy: For example, one could read the data into HSV; the bit being stored could be replicated three times, once in Hue, once in Saturation, and once in Value. I'm not sure how practical this actually is, especially on the radical end of those values. Also, this kind of redundancy doesn't help against coffee spills, just printing errors, and not even well against those.
The color of the ink usually changes much faster, so it could be a problem to try to read it later. If the information is stored digitally, probably it is still possible to read it with the right calibration. But if the information is stored analogously it is really a big problem: for example http://secrethistoryofstarwars.com/savingstarwars.html
I used to run backups onto VHS tapes using a PCI/ISA card adaptor. IIRC, you could get about 2GB on a tape, with a SVHS recorder, or 1GB on a normal drive. Something like this: http://en.wikipedia.org/wiki/ArVid
Of course, it was absolutely useless. Might as well have piped the data to /dev/null.
Also, potential data-corruption issues with color laser printers that add spurious yellow watermarking dots [1], though perhaps a sufficiently robust error-correction scheme would be able to work around that.
I guess this would be useful in the case of an apocalypse scenario involving mass EM pulses (assuming anyone is still around to build new computers with OCR to reload the code). Better use good acid-fee paper stored at near-vacuum though.
If I can find a computer survived the EM pulses to scan the paper, then most likely I don't need this paper back up anyway. On the other hand if all my data is dead upon the EM pulses attack, I won't put too much faith on the chance of getting hold of any surviving computer.
And so with the RepRap (and some power source/converter) inside a faraday cage (with other physical protections as well), you're saying that this is the ultimate backup system for worst case scenarios? Do you have any links to provide more information about such a setup?
Yes, the Faraday cage protects against EM interference. But so does turning your computer off. Your main computer is fried? Pull out your old laptop and dust it off...
Would turning your computer off, help? I can see it helping for normal EM interference, but in an apocalyptic EM pulses scenario I thought the induced current would be enough to damage components.
Regarding degradation: CD-Rs degrade because you write them by using a laser to effect chemical changes, and the chemicals can break down. Commercially-produced CDs, on the other hand, are pressed; they are physically molded by being pressed against a "glass master", and the physical pits are much more durable. Making the glass master is expensive, but the incremental cost of pressing is tiny compared to burning CDs.
So, if you could figure out a way to etch CDs instead of burning them, or make the pressing process cheap enough, you could make very durable CDs. Or if you want to make lots of durable copies of one CD, you can do that now with a glass master.
It sounds like it is possible to make longer lasting CDs using a glass master, but it is only practical if I am making lots of copies. So, for purely archival purposes, optical media doesn't really have a process for extending longevity.
That's why I write all my crucial data onto stone tablets.
The write speed and data density are terrible, the drive, media and storage space cost a fortune, but dang if the data won't last a couple thousand years.
I can imagine how difficult source control would be when using paper: "Hey Fred, I need sheet 7 thru 9 from revision 2.6.3!" "Which filing cabinet is it in?"
Punch cards were not that hard to sort after dropping them.
Once you have a deck, draw some thing on the deck edges with a permanent marker making sure that all the card edges have been marked.
If the deck is dropped, first of all it doesn't usually scatter that much (cards tend to stick to neighbor) and the marks on the edge help visually sort the deck pretty fast.
Actually punch cards could have indexes. Several programming languages did not not use the last columns of the cards and reserved them for a number which could be used by card sorting machines.
Punch cards were generally created by hand so the ability to cut and paste new punch cards was considered a significant advantage. This on the other hand is created by a computer and not human readable so a simple index is easy enough to add.
The striping actually is redundancy -- it's a redundant ordering indicator for the deck. The nominal ordering is ... the card order. But should that be disturbed, the stripe (a diagonal marking across the edge of the cards) will indicate which cards are out of sequence.
I first encountered this trick in a college library with a physical card catalog. Having been pranked once too often by students re-arranging the drawers, the fronts of the catalogs were crossed with multiple bands of different colored tape. Any out of sequence drawers could be immediately noticed and quickly sorted visually.
I will be nothing less than disappointed if I do not see someone on HN implement 'papernode 0.1' by the end of this weekend. Maybe some more literal multithreading action. Why not do the whole system... servers from fax machine arrays!
Please tell me this is a troll?
I mean, I know the author acknowledges the fact this is completely unnecessary, but still - I'm no environmentalist, but this seems to be an incredibly silly idea..
The author did all that work as a joke? I hardly think so.
I looked at the source code. It's 5,575 lines of original C code. (I excluded the AES encryption, bzip2, Reed-Solomon, and CRC16 source code from my count.)
I imagine that he wrote the words "open source joke" as a defense mechanism against people who would mock his efforts with lines like "please tell me this is a troll", "that is completely unnecessary", and "an incredibly silly idea".
Lots of people make self-effacing remarks when they introduce a work that they know will draw criticism: "It's just a first draft, it needs a lot more work." "I hacked it up during lunch [when it really took two weeks]." Etc.
