Actually, I haven't seen any data at all. My father told me that he had seen that in a magazine article. I am quoting him.
The point of that was that CD-Rs were not a good storage medium for programs. For graphics or uncompressed music, they are fine. They're also fine for text files, where you can repair a broken bit with a spell-checker. At the same time, though, 1 bit per 100k Bytes per year is still a darn good rate when compared with data transmission. So if you have a program that stores data on CD-Rs *recursively* -- that is, in two or three different directories -- and with checksums on small parts of each program (ie, the way IOMEGA's zip drives work) then there shouldn't be a problem with that. One interesting way of doing this would also be to mark things according to data-critical level, and things that are highly critical (such as programs or compressed data) get stored recursively, and near the center of the disk. Other data that is not critical gets stored only one time, and any recursion gets stuck at the edge of the disk. But the best idea I can think of so far is the one that I said before. Because for the most part, people's major storage isn't their own work -- it is standard programs that are the same from system to system, bitmap images of one form or another [including sound files]. Nor does it change extensively from day to day. But backups are best made regularly. So a good backup program should be able to store a minimum of data, store it recursively, and retrieve any system or part of a system or data, as of a certain date. And CD-R's are fine for that, as long as it is done recursively. I could well even see an automated system with automated CD changer that used about 50 CDs a day (cost: $25/day) and could successfully back up a whole university faculty's worth of computers. Daily, over the network. In the background, when a person saves a file, that file and its location gets stored in a "daily update" file on the local system. If it gets deleted, it gets taken off the "daily update". Once a day -- at a different time for each computer -- when the computer is typically not in use, it gets polled, and it uploads first the file map, and then the files. The files are checked against preexisting versions, and then stored, along with the directory structure (directories simply being files in their own right.) Since the recursion is crash-resistant, files could also be stored in LZW-style trees, making the entire storage job much simpler, and more compressed: programs written with the same libraries would have a greater storage efficiency. However, the pointers and file references would *not* be stored in LZW style, since that has to be the most crash-resistant. So now your typical Computing Services specialist simply loads a spindle of CDs into the CD changer, sets it running, and then lets the system do its job. And if something *does* crash, they can call up the computer by its network ID, reinstall the entire system to a new hard drive, walk up and exchange hard drives. Job done. Or write a few CD-Rs that contain all of the relevant data, plus a small disk reformatting routine, and then go up and reinstall the system of a few days back. Then hit it with an antivirus check, if necessary. P.S. I've now stepped off the listserver for the time being, so any replies will have to be cc:d to me directly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
