Lmao. No, I don’t agree that file format is the most critical choice
Local vs web-hosted, or open formats vs closed formats are part of the exact same choice. So I think you probably do agree that it’s a critical, basic component of your software decision. 😉
Yes obsidian supports various linking formats, but mainly uses its own.
But it doesn’t. The only two options are Wikilinks or original Markdown.
The only software that I’m aware of that is in the same camp as Obsidian - plaintext Markdown files and non-outliner - is Zettlr.
K. Md files using wikilinks, which don’t actually work in mediawiki. Not a great argument for compatibility off the shelf as some universal thing.
You’re describing now a larger scope of requirement than whether a file is .md, and which is met in various ways not solely relevant to whether a file is md.
Feel free to check out zettlr if your strictest requirement is that you use plaintext markdown files the entire time you’re writing and simply cannot accept exporting or interacting with a database. Or you just prefer it. Do what you like.
You’re describing now a larger scope of requirement
I am not. I am saying data storage format is a basic, critical factor. And it is. And I already know you agree on this, which is why you choose FOSS options with known, open formats.
Obsidian, Zettlr, and Logseq live in the category of local plain-text file-based PKMs.
Trilium lives in the category of local database-based PKMs.
The reason the first category exists is that people wanted to get out of vendor and file lock-in.
Apples and oranges.
Having been through the enshitification of Obsidian, it was important to me and many others to be not beholden to any vendor’s file system. Your database requires Trilium to be instantly usable. My notes are useful and usable (and frequently accessed) from Logseq and VSCode.
The two options are simply not comparable, hence apples and oranges.
Local vs web-hosted, or open formats vs closed formats are part of the exact same choice. So I think you probably do agree that it’s a critical, basic component of your software decision. 😉
But it doesn’t. The only two options are Wikilinks or original Markdown.
The only software that I’m aware of that is in the same camp as Obsidian - plaintext Markdown files and non-outliner - is Zettlr.
K. Md files using wikilinks, which don’t actually work in mediawiki. Not a great argument for compatibility off the shelf as some universal thing.
You’re describing now a larger scope of requirement than whether a file is .md, and which is met in various ways not solely relevant to whether a file is md.
Feel free to check out zettlr if your strictest requirement is that you use plaintext markdown files the entire time you’re writing and simply cannot accept exporting or interacting with a database. Or you just prefer it. Do what you like.
I am not. I am saying data storage format is a basic, critical factor. And it is. And I already know you agree on this, which is why you choose FOSS options with known, open formats.
And both the trilium db and markdown files validate that requirement. So it’s not really relevant.
Not relevant to you, but relevant to others who might require local plaintext files, rather than a database.
Which brings us right back to apples and oranges 😘
I don’t think you know what apples and oranges means, but if it means you’re satisfied with the conversation then happy day.
Use the software that works best for you. If dealing with a database is too much for whatever else you’re doing, feel free to use something else.
Obsidian, Zettlr, and Logseq live in the category of local plain-text file-based PKMs.
Trilium lives in the category of local database-based PKMs.
The reason the first category exists is that people wanted to get out of vendor and file lock-in.
Apples and oranges.
Having been through the enshitification of Obsidian, it was important to me and many others to be not beholden to any vendor’s file system. Your database requires Trilium to be instantly usable. My notes are useful and usable (and frequently accessed) from Logseq and VSCode.
The two options are simply not comparable, hence apples and oranges.