I've been using Dave's publishing tools since 1998.

Blogging in an outline feels so natural. In fact, it feels so natural that I'm experimenting with putting my daily notes there instead of using TiddlyWiki at rudimentarylathe.wiki.

My Drummer blog is at oldschool.scripting.com/jackbaty/

I'm trying to phase out my use of Cloudron. It's a great service, but it lends itself to tinkering and an ever-increasing list of services I need to deal with. For blog hosting, it's one more layer of abstraction I don't need. Also, Cloudron costs $15/month on top of the 4GB Digital Ocean droplet. With the move of Baty.blog, I've got nothing remaining on the Cloudron instance and will go from $30/month to $12/month and with less complexity.

As much as I love TiddlyWiki, I've never enjoyed managing images with it. Embedded images are easiest but can quickly bulk up the wiki's HTML file size, so I reference them instead. I've done this a couple ways.

The cheat version is to just use the embed code of an image I've previously uploaded to Flickr. The second best option is to put the images in a /files directory within the same directory as the wiki itself and reference it using something like [img[files/my-image-file.png]].

It's not hard to do, but having to move each image to my wiki/files directory, then hand-write the path/filename to create a link adds just enough friction to prevent me from using images as freely as I might otherwise.

TiddlyWiki 5.2.0 was released recently, and it includes a great new feature that lets me drag and drop an image into an open "tiddler" which is then embedded and linked automatically. This is a terrific improvement, but it still embeds the image within the wiki file, which I was hoping to avoid.

Enter the File Uploads plugin from Saq Imtiaz and with it a brand-new PUT option for WebDAV.

This is all pretty new to me, so I'm probably not qualified to write a full-on tutorial, but here's what I did...

Upgraded my wiki to 5.2.0. (https://tiddlywiki.com/upgrade.html)

Installed the File Uploads plugin and the accompanying PUT plugin via simple drag and drop into my wiki file (TiddlyWiki is cool that way).

Configured the plugin by telling it to use the "PUT" uploader and where I'd like uploads to go (relative to the wiki file itself). I chose "files/2021".

I run my wiki via WebDAV using the WebDAVNav Server app for macOS. There are other options for other OSes, but I'm not familiar with those. The benefit for me is that I can open and save my wiki with any browser, no other extensions are required. I run the WebDAV server on my Mac Mini and visit it there via https://localhost:8080/index.html.

This is where the magic happens. I open a tiddler, drag an image into it, and boom! the file is uploaded to the files/2021 folder and a wikitext link is inserted automatically. So cool.

This is all dandy when editing the wiki on my Mac Mini with the WebDAV server running, but what about from my MacBook Air? I could probably figure out the IP used by the Mini on the LAN and access it that way, but that only works in my house if I want to get into dynamic DNS and port forwarding. (I don't).

Enter Tailscale, "Zero config VPN. Installs on any device in minutes, manages firewall rules for you, and works from anywhere."

I was up and running with Tailscale on all my Macs, my iPhone, and my iPad in less than an hour. Tailscale provides a private network I can access from all my devices. This means that I can reach and edit my wiki via https://100.74.14.72:8080/index.html from everywhere. (That IP is not publicly routable so it's safe to share it.)

It works with the WebDAV PUT uploads, too. I can drag an image from the Photos app on my iPad into Safari and the file ends up where it belongs on my Mac Mini. Magic!

I don't know yet what the gotchas of this approach might be, but so far it has solved all of my issues with managing a single-file wiki with images from all my devices.

My wiki is published via Github Pages, so in order to push updates, I do need to commit and push the repo. I have the repo directory synced using SyncThing so the changes are always available on both my Macs. While I can edit my local version of the wiki from iOS, I'm not yet able to publish it from there.

It may look like a lot of fuss and moving parts, but so far I haven't felt any pain from it. All of the individual parts (TiddlyWiki, WebDAV server, Tailscale, SyncThing...)  run without issues and there aren't too many dependencies between them.

I hope this has made enough sense to get you started. Feel free to ask me to clarify anything you find confusing or missing.

I'll always have at least one "static" webserver running Caddy, for tossing a bunch of small static sites onto. And I'll probably always host my own blogs. Other than that, let someone else deal with it, I say.

So today I've migrated my site analytics back to Plausible from self-hosted Ackee. Plausible is inexpensive, looks better, has more features, offers good support, and is always improving. I put up with the bare-bones-ness of Ackee because it was easy to add to my server via Cloudron.

I've also migrated my private Git repos back to Github from self-hosted Gitea.

I've shut down my Monica CRM instance. I don't need a dedicated app for tracking things about people.

I've shut down my Commento instance. I've caved for now and added Disqus to my sites. I know, I know, but even with all its jankiness it's an OK experience for visitors. At least that's how I feel when I'm using it on other sites. I'm already logged in and can just comment. Commento's moderation tools are essentially non-existent. We'll need to address privacy concerns later. I don't get enough comments to justify paying for anything. I'm also a little miffed because my old Commento (paid) annual subscription renewed automatically without warning and I've not heard back in a week from support about a refund. So that's $99 wasted. And I'm not going to use it just because I (unwittingly) paid for it.

I shut down my Lychee photo gallery instance. This one hurts a little, but I'm already paying for SmugMug and Flickr so c'mon. Still, I'm interested in a lightweight, personal photo gallery so this could come back.

This leaves me with my Cloudron instance running three instances of Ghost. I may even kill rudimentarylathe.org (the newsletter site) because I haven't felt like writing a newsletter and there's no sign of that changing. I recently paid for a year of Cloudron (which reduces the price to $15/month) but when that ends I'll find a new home for the blogs and that'll be that.

I like having a bigger phone because it is one of the devices, I use the most. I communicate on it for my job, my personal life and I write much of my blog on it. Couple this with the fact my eyesight isn’t what it was, and a bigger phone just gives me more value and I am sure it would do for others too.

I think Greg can take this off his list of things to feel angsty about in his attempts at minimalism. The size of one's smartphone doesn't play at all into how "minimalist" one is.

I use an iPhone 12 Mini because I prefer how it handles and it's not so cumbersome to carry about. My fingers have a better chance of reaching things. If I wanted to up my minimalist cred, I'd use a dumb feature phone or carry none at all. Go big, I say!

Now, though, I can easily type away here in Ulysses, publish, and fix edit things to my heart's content.

Thanks to Gabz for reminding me about using Ulysses for blogging. I launched it and was greeted with release notes telling me about the new publishing features. Neat.

I still don't love how Ulysses mangles Markdown, but it's close enough. I'll try it.

Update, 2 hours later: Nah. The first thing I did was include some strikethrough-formatted text using Ulysses' goofy pipe syntax, which then vanished from my post. I'm not interested in fighting that kind of battle. Besides, Ghost's editor is pretty nice already, so the advantage of using Ulysses is diminished.

GitHub - skeeto/elfeed: An Emacs web feeds client

An Emacs web feeds client. Contribute to skeeto/elfeed development by creating an account on GitHub.

GitHubskeeto

Since I use Doom Emacs, configuring Elfeed is easy.

Uncomment (rss +org) in init.el and create a new file at ~/org/elfeed.org and start adding feeds. The +org adds support for using Org mode to define the feed list . Something like...

* root :elfeed:
** Photography :photography:
*** [[https://6x6portraits.wordpress.com/][6×6 Portraits | Kenneth Wajda]]
*** [[http://www.alexluyckx.com/blog/][Alex Luyckx | Blog – Photographer, Explorer, Wanderer]]
*** [[http://www.fogdog-photography.com/][Fogdog]]
*** [[http://leicaphilia.com/][Leicaphilia]]
*** [[https://www.macfilos.com/][Macfilos | Leica Camera News, Reviews & Photography Blog]]
** General Nerdery
*** https://controlaltbackspace.org/feed.xml
** Programming :programming:
** News :news:
*** Top news :tops:
**** http://feeds.bbci.co.uk/news/rss.xml
...

I use Org links so that they're easy to read but one can just as easily use only the feed URL for each entry.

Now I'm always just an M-x elfeed away from catching up on my RSS feeds. I have an Emacs bookmark pointing to an Elfeed query showing just recent unread entries, like so

Elfeed unread                 @2-week-ago +unread

While it's nice having my feeds in the same environment as nearly everything else I'm doing, using Emacs for this ain't pretty, so I eventually tire of seeing everything in all text all the time and will happily retreat back to NetNewsWire. But for now Elfeed is fast and fun.

Dev builds perfect note-taking system which only stores info about building note-taking systems

the dream became reality when she finally completed her perfect note-taking system comprised of Zettelkasten-styled interlinked markdown files stored in Org-mode format with two-way conversion on the fly with syncronization across devices through a p2p network with E2E-encryption and backups stored in IPFS, with both native and PWA apps for all major platforms as well as command-line interface with a rich set of zsh autocompletions and keyboard shortcuts.

Things that matter to me in a password manager, in order of importance:

• Reliability and security
• Functionality
• Reputation
• Ease of use
• Multi-platform/portability
• …
• 100% native app with perfect macOS integration

My family and I will be sticking with the 1Password plan, even though it’s now a subscription-only Electron app.

There are valid reasons to dislike Electron apps, but most of them aren’t meaningful to me in day-to-day use.

I’m convinced that many people hate Electron simply because The Internet told them “It’s bad!"¹. Reminds me of people who claim to hate Nickelback but couldn’t name a Nickelback song or those who make fun of Comic Sans but couldn’t pick it out of a lineup.

All things being equal, I’ll always choose a native macOS app, but all things are almost never equal.

So, this week, I’m seeing how much I can manage using Emacs (with Org mode), the filesystem, a terminal, and a web browser. As you can imagine, it’s impossible. I’m sure I’ve written about this before, but it’s on my mind again so I’m updating the list while I’m here.

Below is a quick list of software (on my Macs) that I always have available and for which no reasonable substitutes exists (that aren’t just more software).

• Emacs
• Vivaldi
• Finder
• iTerm

There, that should be it, right? Uh, nope…

• Roon
• 1Password
• Preview
• Messages
• Lightroom Classic
• Capture One Pro
• SilverFast
• Silver Efex Pro
• Day One
• Deliveries
• Discord
• NetNewsWire
• Numbers
• DaVinci Resolve
• Photo Mechanic
• ScanSnap Home
• Signal
• Zotero

And then there are the utilities and background apps…

• Keyboard Maestro
• Alfred
• Carbon Copy Cloner
• Moom
• Minus
• SmugMug uploader
• Loom
• Dropbox
• Camo Studio
• CleanShot X

Some of these could be replaced with browser, Emacs, or command-line versions, but at a significant loss of utility. That list also only includes the must-have-and-can’t-find-replacement apps. I have dozens more installed that I use occasionally but don’t technically need. The current exercise of using just a few is mostly a reminder to stop installing and configuring every app I see and maybe just get some stuff done instead.

1. You could argue about “objectively” but I’m sticking with it.

But, weighing all these considerations, if it’s possible for you, as a newsletter-er, to rescue the meat of your dispatches from the inbox: I recommend it!

That’s not an email newsletter, that’s spam. What you’re doing is blogging and emailing me a link to new posts. If all I wanted was to be notified that you posted something on your blog, there’s RSS.

Unsubscribed^[1]

1. Ok, not really, but still.

I recently made yet another attempt at living on the iPad as my main device. It lasted less than a week. Going all-in on the iPad feels so nice and simple and liberating…for a day or two. After that, the constant reminders of its limitations quickly go from minor nuisance to deal-breaking irritation.

I’ve tucked my tail between my legs and scurried back into the arms of my Mac.

For my purposes, a computer needs fast, deep access to clipboard history, universal complex text expansion, reasonable window management, and a much larger screen. iOS can be coerced to do some of these, but doesn’t do any of them as well.

And the elephant in the room? Emacs and Org mode. I cannot seem to detach myself from Org mode. I’ve tried. In fact this latest move to using an iPad was really just another thinly-veiled attempt to leave Org mode behind. And once again the effort failed because Org mode is just too good at too many things.

So the iPad is once again relegated to it’s rightful place as a peripheral device. I love using it for browsing, watching stuff, writing journal entries in Day One, minor photo editing, and drawing. For everything else, I prefer the Mac.