Markdown with dated filenames in a Dir in git. I've been using this for decades. Logseq is a nice GUI for it and has great search, but you can always use grep and any text editor.
this post was submitted on 11 Jul 2026
63 points (98.5% liked)
Linux
14269 readers
469 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 3 years ago
MODERATORS
Personally, I've kind of given up all structure.
I have a script that creates a Markdown file with basically just the date in the file name and then it opens it in my text editor. All Markdown files are in one big folder. Notes, todos etc. all go into the there.
So long as a file is open in my text editor, it's actively relevant. Afterwards I'll use full-text search (like grep -iR), if I need something again.
I will often specify a title in the Markdown, but mainly because it's a great place for keywords to make the file easier to find again. It's also my way of tagging the files.
I mainly like this way of working, because I spend very little time on inputting information, which I do way more often than retrieving information (at least for the files which aren't actively open in my text editor).
But I've also never used a structured approach for more than a few months without it turning into chaos, where full-text search is the only option anyways.
Maybe this would be different, if my tasks were more structured. Your mileage may vary. ¯\_(ツ)_/¯
This is the way.
Avoid spaces in file names. Spaces in files names can be a pain in Linux, speically when dealing with scripts in the command line.
Or learn to quote
Even tab completion will either quote the thing for you or put in the excape characters. Why would one type anything? 😛
... Just make a git repo.
Then you can sync, too.
This workflow is tied to KDE Plasma's tagging feature. Moving away from KDE Plasma would likely mean abandoning parts of this workflow altogether.
~~It looks like these tags are stored in filesystem xattrs themself, not in dolphin or kde metadata. That is, even if you load up gnome's file browser, or another file browser, it should still be able to read them.~~
Nope, it looks like the tags used are KDE specific, even though any software could theoretically implement support for reading and writing them.
Agree. I think I'm going to add googles open knowledge format frontmatter to my templates. Not a lot of tools for it exist yet, but they're coming, and it's literally just a standard header for your markdowns including optional tags
Ironic. They call it "avoiding vendor lock-in", yet you end up getting locked into KDE.
Extended attributes are not KDE specific. KDE just utilize that feature while others just don't
Yes, but it looks like the xdg.user.tags and xdg.user.comments are KDE software specific, and not part of the official spec. Meaning other softwarw probably can't read and interact with those attributss in the same way.
Avoiding Vendor Lock-in By Using KDE Plasma As Personal Knowledge Base
More like:
How I vendor locked myself in KDE Plasma as PKB
/s
To be honest, I'd rather lock myself in KDE than ... Idk, windows or something
This does not seem convenient at all, from the bash script to get relative links, to the file tags which are not synced across devices by standard git or file sync.
Sounds convenient enough to me. I used to keep notes on Evernote, then my own media wiki instance on a VPS, tried Google docs. Lost most of those due to changing jobs, forgetting to renew subscriptions and getting locked out of my yahoo email. Google docs is surprisingly annoying to search for me
Obsidian looks nice, but this seems even simpler to me, who is comfortable with scripting