You must log in or register to comment.
It’s a good philosophy, to be sure. It doesn’t take many migrations to realize that keeping your files in open, easy to read formats is preferable.
I also use obsidian, but I do sometimes worry that the linking and metadata will be difficult to work with in the future when the software goes away. It’s all there in the files, but my vault is slowly linking together in interesting ways that rely on obsidian functionality.
Try logseq, it’s a foss alternative to obsidian
I wonder this with obsidian also, it is one of the things that keeps me from diving in head first.
It seems a lot of its “powerful” functions are against it’s plain text advantage. However I don’t really see an easy way around it.
At least at the end of the day you or someone else could write a script to modify the plain text files for the next app.
Try logseq, it’s foss and solves some of these problems. Mostly compatible with files from obsidian
Does it have a plugin ecosystem like Obsidian?
That is the double edged sword though. Get cool features - lose true plain text
Who wouldn’t want a double edged sword? Twice as good for chopping!
It’s tricky for sure. The plain text is great, and all the functionality is built off of plain text (even the canvas!), but replicating the functionality isn’t trivial by any stretch of the imagination. Migration is easier because of the text files, but will it be as easy to see the links between notes? Or query all the notes I need more detail in? Or map it all out visually?
I think reimplementing the core obsidian functionality in a FOSS clone would be fun… except I already have a queue of projects and not a lot of time, so here I am complaining instead 🤷
Logseq is the obsidian foss clone , worth a try
And they must be local rather than remote (cloud).
Also, always prioritise a common format served through filters (for example having all your data in postgres and minio, and serve that on demand as ICS, XML, etc) so that you don’t need to duplicate or lose data due to formats.
Interesting, I must admit, I never thought of digital data like this. I suppose a lot of history from our current era is either online or in a digital format. That in turn makes data important to preserve, although that part was obvious.
Take it further. Convert all of your data into forward or simple formats. Don’t encode your images as gif, keep them raw. Store word docs as markdown. Don’t use proprietary formats (duh).
Linux will be around for a long time, which is convenient. Everything is a file, that counts, right?
Also be thankful for VMs and the push towards distroless containers.
Don’t encode your images as gif, keep them raw.
This is fucking insane. There are plenty of open standards for image files.
It was an example. Lossless formats exist.
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.
keep a copy of the software with the data files.
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.
