Optimizing for Archival
-----------------------
Sun Nov 21 13:56:35 EST 2021

---
Written on my desktop while Jennie mod-podge's the puzzle
we put together last weekend for framing.
---

If you've read any of my previous posts, it's no secret that
one of the reasons I'm really enjoying phlogging is the
plaintext content. I wanted to call out one of my favorite
side-effects of plaintext entries: ease of archiving.

Browsing gopherspace, it's clear that plaintext is among the
most suitable formats for long term storage. Look at quux.org's
treasure trove of historical documents. Or all of the IETF
RFC's. Plain ascii-encoded files seem to be a guaranteed way
to ensure your content is not only readable in the future,
but easy to archive for that future.

This is actually one of my biggest beefs with mdoc(7). It's
a great semantic language, but it's not really that legible
in its raw form. It's a safe bet for archival--given that so
much of our historical manuals are written in it, it seems
that interpreters like mandoc(1) will be around for a while;
however, it's still dependent on external tools for proper
viewing.

Same with HTML--you need a browser or interpreter to read it.

I think this is one of the strengths of markdown--even in a
post-HTML future, the markdown source will be archived and
readable. However, I kind-of like explicitly scoping the
content to _just_ ascii and not focusing on *any* other
presentation format other than the source. It's all too common
to get markdown files that are illegible because the author
cares more about the way GitHub renders it than the way
it looks in an editor (unwrapped lines, massive amounts of
image URLs, non-prettified tables, etc).

I take comfort knowing I'll be able to `cat` this file
two decades from now and still remember what I was thinking :)