4 ms·

I share you opinion. I'm a little bit horrified by anybody who is alright with digitally-represented information somehow "decaying". Why is that an acceptable t

I share you opinion. I'm a little bit horrified by anybody who is alright with digitally-represented information somehow "decaying". Why is that an acceptable thing? We should be working to create new less-volatile and longer-lived storage media, and to be documenting the specifications for the machines that process our data so that gate-level simulations can be made in the future. Nothing we store digitally need ever be lost so long as some basic stewardship is performed. For now that means moving data to newer storage formats, making redundant copies, using error-correcting codes, etc. Maybe eventually we'll get the mythical "store all your data in a diamond" 3D / 5D holographic storage that always seems to be a few years off.

TeMPOraL 5y ago
Exactly. And this is, in fact, the very reason digital won over analog: digital data does not decay. The medium carrying it does, but data itself can be perfectly read and copied ad infinitum. Somehow, we've managed to take that natural feature away.
- strgcmc 5y ago
  Because humans are the constraint, not the bits. Humans (in a group, societal sense) need to context switch over time, and cannot perfectly retain equal, active understanding of how to use all systems or frameworks ever invented, no matter how perfectly the bits are preserved. That being said, in an archival sense, it would be a shame and seems unnecessary to lose anything, since perfect preservation is achievable. But archival preservation, is different from staying in active use with a healthy community of practitioners perpetually ad infinitum.
  - dmix 5y ago
    That’s a really good point, there can exist a distinction where the goal should be to make it always accessible (archives, emulation, documentation, etc) but not necessarily always accessible in widely deployed web browsers. So even if you have good reasons to remove an API or feature, you should also provide means or resources to those who wish to preserve and archive the data. And this is something that could be factored into the original design without committing the project to the technical overhead of supporting it forever. Additionally reducing the problem to humans just chasing shiny new things is simply not true. There’s no denying that some implementations are just bad or dangerous security wise or the world has completely changed in some way. Not letting things decay could risk the whole platform dying as a result, not just the feature. It could even get to the point where adding anything new is way too risky because of long term support obligations, so decay could be made worse because of efforts to prevent decay! Obviously we can still make sure great consideration is made both before adding something new and before removing it. There’s no getting away from the balancing act between change and conservation.
- dredmorbius 5y ago
  Digital decays different. There's the physical degradation of mechanisms and data storage substrates themselves. That's ... not insignificant, but a minor part of the whole situation. The short-term strength and long-term technical debt of digital is dependencies. Sure, you can spin up some bare-metal or virtualised instance of a system from last month, or five years ago, or twenty years, ago, or fifty. Odds are that the emulation will run faster than the original.[1] But with time and complexity, dependencies started to expand. One of the underheralded changes of the 1990s wasn't so much Free Software as what it wrought: an ever expanding and accelerating increase in the number and specificity of dependencies. Tarball distribution gave way to packages, with dependency-resolution, some better (APT), some worse (RPM). Crucially, dependencies didn't simply have to be resolved at build time, once in the lifecycle of an executable, but at install time, once per installation. The explosion of Web apps and frameworks triggered another violent expansion of the situation with both even more dependencies, more deeply nested ones, but runtime dependencies where prerequisites are identified and fetched from remote hosts. At runtime. Which makes the current appified-web immensely flexible and convenient, but also fantastically brittle. (Of course, the old-school type scan extend this story back to interpreted vs. compiled languages, JIT, hardware-specific variations, high-level vs. machine langauge, binary, and toggling in programmes. It's been a long process.) But as bits of that infrastructure fall apart, you'll find that digital does in fact decay. ________________________________ Notes: 1. At a gig some years back, a cow-orker told of a uni prof they'd studied under, who did work on the the B and BCPL programming languages. Those are precursors to C. Back in the day when auto manufacturers were looking at automated systems controls, he convinced them that C was far too complex and high-level, and that they should use the more performant BCPL. Which they did. And still do (or did as of a decade or two back), running under several generations of emulation. Faster than the initial hardware implementation. Mind I'm taking them at their word....
  - dredmorbius 5y ago
    Obxkcd: https://i.redd.it/z8xovfqjwqj71.png https://i.redd.it/z8xovfqjwqj71.png (Via: https://teddit.net/r/xkcd/comments/pc5gl9/ive_checked_out_an_xkcd_link_while_exploring_on/ https://teddit.net/r/xkcd/comments/pc5gl9/ive_checked_out_an...)

TeMPOraL 5y ago

Exactly. And this is, in fact, the very reason digital won over analog: digital data does not decay. The medium carrying it does, but data itself can be perfectly read and copied ad infinitum. Somehow, we've managed to take that natural feature away.

strgcmc 5y ago
Because humans are the constraint, not the bits. Humans (in a group, societal sense) need to context switch over time, and cannot perfectly retain equal, active understanding of how to use all systems or frameworks ever invented, no matter how perfectly the bits are preserved. That being said, in an archival sense, it would be a shame and seems unnecessary to lose anything, since perfect preservation is achievable. But archival preservation, is different from staying in active use with a healthy community of practitioners perpetually ad infinitum.
- dmix 5y ago
  That’s a really good point, there can exist a distinction where the goal should be to make it always accessible (archives, emulation, documentation, etc) but not necessarily always accessible in widely deployed web browsers. So even if you have good reasons to remove an API or feature, you should also provide means or resources to those who wish to preserve and archive the data. And this is something that could be factored into the original design without committing the project to the technical overhead of supporting it forever. Additionally reducing the problem to humans just chasing shiny new things is simply not true. There’s no denying that some implementations are just bad or dangerous security wise or the world has completely changed in some way. Not letting things decay could risk the whole platform dying as a result, not just the feature. It could even get to the point where adding anything new is way too risky because of long term support obligations, so decay could be made worse because of efforts to prevent decay! Obviously we can still make sure great consideration is made both before adding something new and before removing it. There’s no getting away from the balancing act between change and conservation.
dredmorbius 5y ago
Digital decays different. There's the physical degradation of mechanisms and data storage substrates themselves. That's ... not insignificant, but a minor part of the whole situation. The short-term strength and long-term technical debt of digital is dependencies. Sure, you can spin up some bare-metal or virtualised instance of a system from last month, or five years ago, or twenty years, ago, or fifty. Odds are that the emulation will run faster than the original.[1] But with time and complexity, dependencies started to expand. One of the underheralded changes of the 1990s wasn't so much Free Software as what it wrought: an ever expanding and accelerating increase in the number and specificity of dependencies. Tarball distribution gave way to packages, with dependency-resolution, some better (APT), some worse (RPM). Crucially, dependencies didn't simply have to be resolved at build time, once in the lifecycle of an executable, but at install time, once per installation. The explosion of Web apps and frameworks triggered another violent expansion of the situation with both even more dependencies, more deeply nested ones, but runtime dependencies where prerequisites are identified and fetched from remote hosts. At runtime. Which makes the current appified-web immensely flexible and convenient, but also fantastically brittle. (Of course, the old-school type scan extend this story back to interpreted vs. compiled languages, JIT, hardware-specific variations, high-level vs. machine langauge, binary, and toggling in programmes. It's been a long process.) But as bits of that infrastructure fall apart, you'll find that digital does in fact decay. ________________________________ Notes: 1. At a gig some years back, a cow-orker told of a uni prof they'd studied under, who did work on the the B and BCPL programming languages. Those are precursors to C. Back in the day when auto manufacturers were looking at automated systems controls, he convinced them that C was far too complex and high-level, and that they should use the more performant BCPL. Which they did. And still do (or did as of a decade or two back), running under several generations of emulation. Faster than the initial hardware implementation. Mind I'm taking them at their word....
- dredmorbius 5y ago
  Obxkcd: https://i.redd.it/z8xovfqjwqj71.png https://i.redd.it/z8xovfqjwqj71.png (Via: https://teddit.net/r/xkcd/comments/pc5gl9/ive_checked_out_an_xkcd_link_while_exploring_on/ https://teddit.net/r/xkcd/comments/pc5gl9/ive_checked_out_an...)