Notes for December 30-January 5

After two weeks safely ensconced in books, terminal windows and holiday movies (yes, of course I watched Die Hard and Love Actually), I am really dreading returning to work tomorrow–every return to work for the past two years has been far too stressful for me to even joke about it, so this year I’m trying to find a way to ease in somehow.

So I started doing chores throughout the week: upgrading things, dusting, cleaning up old stuff, endlessly fiddling with vim configuration files, etc. – anything that reminds me I have things to look forward to regardless of work.

This site still has over 4000 wiki pages that are in Textile format (because when I started it 23 years ago it was nicer than Markdown), and I’ve tried to convert them across in various ways over time.

However, vanilla automated conversion doesn’t work that well for my content–in particular for pages with complex layouts and markup extensions. This year I’m trying out the LLM route with fabric, which I’ve looked at several times over the past year and that greatly appeals to me because it solved both CLI integration prompt management by dint of having a very tiny Go-based CLI and the notion of a library of “patterns” to apply.

So I wrote a pattern (i.e., a prompt) to do the conversion, and have a trivial workflow to handle things:

❯ cat ~/.../aliases.sh
# convert to a draft, get an overview of changes, get a QuickLook preview
alias conv="cat index.txt|fabric -p convert_post > draft.md \
         && diff --color index.txt draft.md; qlmanage -p draft.md"
# clean up older automated conversions
alias done="mv draft.md index.txt; git mv index.txt index.md; \
            git rm original_markup.txt; git add index.md"


# do conversion and wait for preview popup
❯ conv

# tweak if required
❯ nvim draft.md

# if happy, move the draft to the original file
❯ done

This has been working pretty well once I tweaked the prompt (it still consistently messes up some things, but they’re easy fixes), and gives me immediate feedback on what it did. If you want to replicate this for similar CLI-based document workflows on your Mac, you’ll want to have QLMarkdown installed for qlmanage to render a preview. There’s a minor niggle regarding disk access permissions, but it’s easy to sort out.

During my upgrade spree I found out that Fedora is now shipping the latest xrdp release, which does H.264 encoding of the RDP session, and had a play with it by installing it from the testing repository:

dnf --enablerepo=updates-testing upgrade xrdp xorgxrdp-glamor openh264 \
   --refresh \
   --setopt=updates-testing.baseurl=http://www.nic.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/testing/41/Everything/x86_64/ \
   --setopt=updates-testing.metalink=

Incidentally, if you’re having trouble upgrading a Fedora 40 LXC to 41, use dnf4. In my case using version 5 inside LXC completely broke the upgrade, and I had to restore the container from a backup.

Sadly I don’t think that the current build does GPU-accelerated hardware encoding of the RDP stream, but I got it to run beautifully by bumping up both the target bitrate and the maximum frame rate in /etc/rdp/gfx.toml:

[OpenH264.default]
# NOTE: OpenH264 specifies bitrate in unit of bps, not kbps.
EnableFrameSkip = true
TargetBitrate = 50_000_000
MaxBitrate =    0          # unspecified
MaxFrameRate = 120.0

There might be a little tearing depending on the apps you’re running, but if that annoys you you can revert EnableFrameSkip = false. I don’t particularly mind, these settings are so much better than what I could get a couple of years back…

I went down the Obsidian rabbit hole all over again. I still don’t like it, but since I was fiddling with it on the Supernote Nomad I’m testing I decided to see if I could sync notes to my iPad using SyncThing, and guess what, it worked fine with Möbius Sync’s “External Folder” feature, as long as you set up each vault with a different sync folder (picking the Obsidian base folder inside iOS doesn’t work due to the way entitlements are handled).

Then I discovered the Linter plugin, and… I ended up importing all the notes I was managing with Foam and got it to clean up all the metadata almost like I like it. The only thing it really should do as a Markdown linter is clean up links the way I prefer (as reference, not inline links), but the rest of it works well enough that I can at least give it another go as a cross-platform note-taking and drafting tool.

And, as a nice bonus… I got it to run on Armbian yesterday:

I’ve been using mkdocs-material for our home wiki since April. That serves as a knowledge base for setup documentation and a service dashboard that is set as my home page, so it’s something I use dozens of times a day, especially given that it’s much more immediately useful than the default home page on any browser.

The thing is, even though I find mkdocs-material excellent for finished documentation that you don’t edit that often, it’s somewhat slow and cumbersome to edit when you’re constantly adding small notes to it or editing the static parts of the homepage to add something I need to keep an eye on temporarily.

Although I’m fine with doing git push for most things and had zero issues getting it to run under Piku, the mkdocs layout and content management conventions are a bit overbearing for something that I typically want to use for less than a minute, and the JavaScript-based search is just abysmal.

I need this kind of thing to be light (and instantly find what I am looking for) so I’ve been exploring alternatives like Otterwiki (which, sadly, doesn’t do things quite the way I like it).

But, as it happens, I used to have a great, live updating WIki that supports full text indexing and ran off my Dropbox almost seven years ago, and the code is still around (you’re looking at the statically generated output from its cousin).

So I started hacking at it again to see if I could modernize the UI and editing experience to a degree I’m happy with. For now my priorities are a good search experience and quicker editing of the “dashboard” parts, so I can use SyncThing to get content across and get it indexed in real-time.

Next up, I might look at actually adding a web editing feature. That would definitely be a first for any of my Wiki engines, but hey, it’s 2025 and I’ve been doing those for a quarter of a century now… I guess it’s about time.

Of course, all of these nice things I’ve been doing are quite likely to hit a brick wall as soon as I log back in to work, so… let’s see.