For the same reason, I print all important photos for posterity. Who knows if apple / google cloud photo library will be around in 50 years when I grow old? I can make sure my printed material remains much more easily.
You can be sure the JPEG and BMP and PNG format will be, and plain text and basic html as well.
So you don't need to print anything, just to have plenty of backup and repeat the backup process every few years (which takes all of 2-3 minutes even for 1000s of images).
There is something to be said for tangible, archival-paper printed photographs.
Maybe printing the top 100 photos each year is a good middle ground, but to each their own :)
That's why I advocated for multiple copies -- and in a redundant format with corrections codes even better.
It's not like printed photos can't be burned, scratched, lost, discolor, soak, stained and many other things besides...
Not that I disagree with you, but this is an interesting point. I've heard archivists argue that with simpler analog storage, the curve for corrupt bits vs interpretability is smoothish, but with digital storage it's often a step function where it's like "whoops, a few bits flipped, can't read at all anymore"
Digital anything, really. Analog signals degrade somewhat gracefully—you have to explicitly build error correction into a digital signal.
A relatively recent example of a bungled transition from analog to digital: when the US switched to digital television in 2009, my family suddenly and completely lost many local/lower-powered/more distant stations that we used to be able to get with just a little static or distortion. And the channels we continued to get wou— —ut out occasio— —in a really a—oying wa— and became unwatchable (well, unlistenable).
That's not inherent in digital copies though. It depends on how much redundancy one adds. We've had self-correction codes that sacrifice size for redundancy and reliability since forever, even in simple formats like ZIP and RAR archives.
And with digital one can always make like 10 copies in the same disk too. If one is unreadable due to single bit flipped or a whole sector, some of the others will still be fine.
The problem I have had is that when one is trying to duplicate/copy > 1 Tb of data across tens, if not thousands of files, that the bitrot is not always easy to find. Windows and OS X / MacOS treat bitrot differently and, it seems, across different file types.
And yeah, lots of issues with scratching, discolouration, lost, etc., of any printed or optical media. That's why a hybrid physical-digital solution is a good half-way house. Same goes for encryption keys or one's crypto wallets, best to hedge one's bets over physical and digital media.
Yeah, plenty of backup copies. One can always die on you, and even just 2 is stretching it. And the working ones should be verified and copied to new copies every 3-4 years (but in overall, it's not a big deal).
>The problem I have had is that when one is trying to duplicate/copy > 1 Tb of data across tens, if not thousands of files, that the bitrot is not always easy to find
Yes, but for the order of 100s or 1000s of images (equivalent to those one would be able to print) this shouldn't be a problem though. Tiny HDs, SSDs, and USB drives + MD5 (or better) hashes/CRC codes should do.
> something on a flash drive the requires millions of lines of code to read data of
Does it really require millions of lines? Even if you’re just targeting that one model of drive, rather than writing a general purpose SATA/USB kernel stack? If what’s on there is, say, JPEG images, libjpeg (plus its dependencies in glibc, I guess) isn’t “millions of lines” either. Where are these millions of lines?
(I’m speaking as someone who has written a unikernel with disk IO and graphics support. It was far less than a million lines!)
It was a puny bit of data for todays standards (about 500M in total), but of the day it was incredible. Back then a mainframe winchester pack with the same capacity would be roughly the size of a washer-dryer combination.
The data not being publicly accessible at the moment is more of a copyright rather than a technical issue.