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. ¯\_(ツ)_/¯

Yeah, the title originally said “6.8 is Very Close!”, which confused me quite a bit.

Hab so ein Spotify für Arme darauf laufen, damit ich meine Musikdateien vom Arbeitsrechner aus streamen kann (und damit Meeting+Musik auf den selben Kopfhörer bekomme).

Ist in meinem Fall was Eigengeschriebenes, aber kann man auch mit Ampache, Navidrome, Jellyfin oder Funkwhale machen.
Mir waren die anderen zu komplex zu betreiben, aber mein eigenes ist auch echt nicht besonders ausgereift in der Hinsicht. Funktioniert halt für mich so ganz gut. 😅

RIP

“I rewrote Kafka in COBOL”

Oh man, it’s late here and I thought to myself “How would you rewrite a Kafka novel in COBOL?”… 🥴

(In case, anyone actually isn’t aware, they’re talking of Apache Kafka.)

In general, though, yeah, I also find it cumbersome how much noise these toy projects add. Actually usable software involves so much more than just dumping some code into a repo.

Nevermind that even just useful software requires you to not rewrite existing software in a worse way. You need to actually come up with something novel, which requires tons of design decisions.

Letting the LLM auto-complete those is a lot harder, because 1) you need to actually describe design goals rather than just telling it “do it like Kafka”.
And 2) because those design goals will be wrong every so often, and/or the detail decisions that you outsourced to the LLM. And then you still need to painstakingly find out what those detail decisions were, so that you can correct the decision.

Das Krebsrisiko, was von HPV ausgeht, wird um so viel gesenkt. Nicht das allgemeine Krebsrisiko.

Falls jemand bisher nur den Titel gelesen hat…

Personally, I found it worth playing around with. I cared less than I thought where I had to move my eyeballs to, once I didn’t have to make the decision anymore.

And automatic tiling can also enable workflows that just don’t make sense with manual tiling, for example master-stack-layout where basically one window takes up half the screen and the other windows share the other half, and then you swap out which one’s the big window as you see fit.

But I also wouldn’t have written all that, if I didn’t have a way that you can easily try it out: You can add automatic tiling into KDE Plasma via Kwinscripts. Personally, I’m using Krohnkite: https://store.kde.org/p/2144146
(Easiest to install by going through the System Settings…)