- cross-posted to:
- programming@programming.dev
- cross-posted to:
- programming@programming.dev
I personally wouldn’t recommend obsidian (mentioned at the end of the article), but still, I think the article is worth reading.
I personally wouldn’t recommend obsidian (mentioned at the end of the article), but still, I think the article is worth reading.
It’s a great point to be making, though it seems to me part of the answer is to keep a copy of the software with the data files.
I keep a repository of software, relying on my brain to know which apps go with what archived data.
Think I need to revisit how I track things.
That only works to a certain extent. Sooner or later you’ll need to run a vm to run that software, so then you’ll also need to keep isos for that operating system. The stack required to open that document will only keep growing.
Meanwhile, I’ll guarantee you that you’ll be able to open that markdown file that Obsidian generates with any text editor from 2124.
I kind of assumed all that with “keep the software”, but you make excellent points.
Guess I need to re-re-think my setup. Like keep some VM’s or containers already configured with the app, and an annual maintenance cycle (minimum) to verify it all works as expected.
Seems like this is really about backup or failover/DR management.
Sigh, yay, another thing to add to the list, haha.
Software isn’t reliable because older software typically doesn’t run on newer machines. This is mostly due to changes in libraries that software relies on, but sometimes can also be do changes in the actual architecture of the CPU.
The philosophy of “you need to own your files” is great.
The extension to “you should be able to open it with a computer from the 60s” is insane. You don’t need to give up efficiency and make everything plaintext. Just document shit.