012.txt (1823B) [raw]
1 Optimizing for Archival 2 ----------------------- 3 Sun Nov 21 13:56:35 EST 2021 4 5 --- 6 Written on my desktop while Jennie mod-podge's the puzzle 7 we put together last weekend for framing. 8 --- 9 10 If you've read any of my previous posts, it's no secret that 11 one of the reasons I'm really enjoying phlogging is the 12 plaintext content. I wanted to call out one of my favorite 13 side-effects of plaintext entries: ease of archiving. 14 15 Browsing gopherspace, it's clear that plaintext is among the 16 most suitable formats for long term storage. Look at quux.org's 17 treasure trove of historical documents. Or all of the IETF 18 RFC's. Plain ascii-encoded files seem to be a guaranteed way 19 to ensure your content is not only readable in the future, 20 but easy to archive for that future. 21 22 This is actually one of my biggest beefs with mdoc(7). It's 23 a great semantic language, but it's not really that legible 24 in its raw form. It's a safe bet for archival--given that so 25 much of our historical manuals are written in it, it seems 26 that interpreters like mandoc(1) will be around for a while; 27 however, it's still dependent on external tools for proper 28 viewing. 29 30 Same with HTML--you need a browser or interpreter to read it. 31 32 I think this is one of the strengths of markdown--even in a 33 post-HTML future, the markdown source will be archived and 34 readable. However, I kind-of like explicitly scoping the 35 content to _just_ ascii and not focusing on *any* other 36 presentation format other than the source. It's all too common 37 to get markdown files that are illegible because the author 38 cares more about the way GitHub renders it than the way 39 it looks in an editor (unwrapped lines, massive amounts of 40 image URLs, non-prettified tables, etc). 41 42 I take comfort knowing I'll be able to `cat` this file 43 two decades from now and still remember what I was thinking :)