[HN Gopher] Make It Ephemeral: Software Should Decay and Lose Data
___________________________________________________________________
Make It Ephemeral: Software Should Decay and Lose Data
Author : BerislavLopac
Score : 21 points
Date : 2024-10-31 09:53 UTC (2 days ago)
(HTM) web link (lucumr.pocoo.org)
(TXT) w3m dump (lucumr.pocoo.org)
| maxbond wrote:
| The physical world does impose itself on software in some ways.
| Software is prone to going out of fashion, becoming disused and
| unmaintained, and eventually forgotten. Peering at a long dead
| document format in a hex editor is the digital equivalent of
| wiping dust and grime from the wall of a forgotten tomb.
| Arainach wrote:
| This is a strange and awful take. Physical objects decay to the
| fundamental forces of nature, but that is a flaw, not something
| we should emulate.
|
| Software is a tool. Software is infrastructure. Degradation is
| desirable in neither.
|
| Data has metadata - creation time, access time, etc. - that can
| power workflows to identify and deal with old data if that is
| desirable, but in most cases they are not desirable. I haven't
| looked at the directory full of my wedding pictures in a decade,
| but I don't want my photo editing software to decide they're
| irrelevant and delete or hide them.
|
| Having access to old documents and data is often important and
| beneficial. It's why people look at inscriptions in old books,
| why they keep photo albums, why finding a forgotten item when
| moving furniture can be delightful. It's why we're able to
| identify trends.
|
| Most crucially, it is incredibly difficult to predict in advance
| which data will be useful in the future. Proactively discarding
| things when storage is incredibly cheap is a net negative.
| rpmisms wrote:
| You can view software as tools or art, it is arguably both.
| TZubiri wrote:
| Disagree, I'm with Kay on this one, life is much more powerful
| than current machines.
|
| When was the last time your mind ran into an out of storage
| issue and crashed?
|
| You talk about metadata being important, yet more than half of
| the storage used today isn't used to store books, or medical
| records or whatever business case, but traffic logs and
| virtualized package dependencies and shit like that.
| fragmede wrote:
| It's called a senior moment, and you'll have them too if
| you've never had one before. In a middle of a conversation,
| you'll just forget what you were saying because you got
| distracted.
| TZubiri wrote:
| First of all that's memory, not storage.
|
| And second, it's a graceful decay, you are not completely
| shut down from storing imporant information for later use.
| If in that moment something memorable happens, you will
| remember that.
| castwide wrote:
| The disagreement here seems to be about what kind of data
| should be considered ephemeral. Traffic logs from a decade
| ago? A ten-year-old package lock? I'm sure I don't care
| anymore. Documents I wrote in the 90s? Yeah, I might still
| want them. I might not need them everyday, but I can say from
| experience that I've needed to track down files that are more
| than a decade old, and I'm glad I was able to find them.
| TZubiri wrote:
| We strictly talking documents? It's very unlikely they will
| suffer from any decay since they are so lightweight. And to
| the extent that it's important you probably accessed it or
| shared it sometime in that period.
|
| A video from the 90s that you never read or accessed in
| that period? Yes, a candidate for deletion, or at least a
| decay. For example, if it was a video, the transcript might
| be saved, but the video might be lost. We may also get some
| written interpretation on the visual elements of the video.
| castwide wrote:
| I'm talking documents in a very general sense. It might
| be a text file, audio, video, a software installer,
| source code, or anything at all.
|
| > A video from the 90s that you never read or accessed in
| that period? Yes, a candidate for deletion, or at least a
| decay. For example, if it was a video, the transcript
| might be saved, but the video might be lost. We may also
| get some written interpretation on the visual elements of
| the video.
|
| My point is that the video shouldn't decay, either. It
| might not be playable in modern media software for a
| variety of reasons, but that doesn't automatically make
| it a candidate for deletion.
| erik_seaberg wrote:
| If you're trying to rebuild or upgrade ten year old
| software, it's very important to know exactly what its
| dependencies were, because there are too many other
| versions to choose from and most of them won't work. New
| software only needs a lockfile because it will eventually
| get old (if useful).
| the_mitsuhiko wrote:
| Author here.
|
| > Physical objects decay to the fundamental forces of nature,
| but that is a flaw, not something we should emulate.
|
| That is explicitly called out in the article and I do not agree
| with you. Useful information is replicated, less useful
| information tends to die out. That we threw away that concept
| entirely in the digital world without a good replacement has
| some pretty strong downsides from my experience.
|
| And if you read what I wrote in more detail you can see that
| I'm very open to the idea of soft deletes and intentional
| information hiding.
| CyberDildonics wrote:
| Please don't write inflammatory headlines then chastise
| people for not reading every word so they can find out you
| back peddled and walked back what made a crazy title
| outrageous in the first place.
| totallykvothe wrote:
| Methinks the mindfulness cult has gone too far
| TZubiri wrote:
| Thought about this. I agree 100%. The incumbent belief in
| software that machines should always remember (embedded in
| postgresql logo for example) has a dystopian sense of inmortality
| desires.
|
| I would like to play with the idea of a filesystem layer solution
| that tiers out information based on staleness. The closest I've
| seen to this is AWS S3 tiers, you've got standard S# at 2.2 cents
| per GB month, then infrequent, then glacier and some tiers in
| between.
| tracerbulletx wrote:
| I mean, retention policies exist.
| donpark wrote:
| Decay and losses are just two of the many constraints that could
| be mixed like paints to create new systems.
|
| Limitations, artificial or not, are not always bad. Walls, for
| example, can be seen as limitation or protection depending on how
| it's used.
| paulproteus wrote:
| For this reason, my browser's Downloads folder is /tmp.
| orbital-decay wrote:
| That's a very feel-good "why" that doesn't answer on "how", which
| is 99% of the work. How exactly do you select what to forget?
| batch12 wrote:
| The attempts I've seen at this are usually in support of a
| corporate data classification and retention policy and are
| pretty hard to pull off successfully. The attempts I've seen
| usually involve adding metadata or tagging the data either
| manually or using automated classifiers.
| crabmusket wrote:
| What are some concrete examples of this?
|
| - Linear automatically cancels tickets which haven't been touched
| in 6 months
|
| - Trello would visually "age" cards, making them increasingly
| yellow and tattered
|
| - Datadog dashboards have a "popularity" score based on usage
___________________________________________________________________
(page generated 2024-11-02 23:00 UTC)