Logbook

Obsidian as a daily note taker, a year out

I started using Obsidian about a year ago, and switched away from Github Issues about six months ago. So far so good. As is my habit, here's some notes on the process that will probably be more useful to me than they will be to you, but that's the nature of blogging these days to write notes to yourself mostly.

Obsidian has completely captured the "daily diary" part of my daily routine, as well as the "write down what you're going to do today before you do it", and the "take notes in wiki format". All of that is about 80% of what I need, and so it gets repeated daily use on my laptop.

Surprisingly, even though I can and do sync my laptop with my Android phone, I don't really use Obsidian much on my phone! To the extent that I do, it's for lookup rather than typing. I guess part of that is that the computer is so much faster as an input device that for any writing of any length I'd rather be at a full sized good keyboard.

When I gave up on Github Issues for daily tracking, there were 10000 issues that I had gone through, and I could tell you with some certainly how long various items had been on my todo list. And you know what, that's not a knowledge about myself that I miss having. I write things down and then I do them or don't do them. The process leaves enough of a trail that I can reconstruct my thoughts. I'm not really reporting out to anyone else the progress towards any one specific goal, so there's less unfinished business to worry about.

Is there unfinished business? Of course. It's just that's accepted as a normal course of events, and you get to things because you remember them and not because there's some Master List Of All Undone Tasks that you consult before taking on the next iteration of your day.

I love Obsidian as a daily note pad, and I really like it that I can bop around in about 1600 separate pages that are a fair capture of a year's worth of doing things and feel at least to a certain degree that it's a connected whole.

At 1600 pages a year, it's about six years when I hit the 10000 page mark. That would be a nice body of work, and by then some other system for writing will probably be available on some shiny new computer and I'll want to start over again from scratch. But until then - this is pretty nice, and I intend to keep at it. (Check back in 2027 and see if I still am thinking the same way.)

backup state - good, bad, ugly

Backups get worse over time, keep these in mind when designing your backup strategy.

Good backups cover your working set. If you accidentally clobber something you're currently working on, you can get it back with minimum fuss. A good backup also provides you with some protection against catastrophic drive loss or other wholesale catastrophe. Good backups generally have an ongoing monetary cost, so there's a risk that your backups will fail not because of hardware failure but because you missed a payment.

Bad backups can look like good backups until they fail to restore. Your bad backup would be a laptop backed up to a hard drive in the same house, both at risk of the same catastrophe like a fire. Bad backups are better than no backups if you're lucky, but you're not really doing this to be lucky.

Ugly backups are the worst. Imagine a decade old laptop which has had several attempts at file system organization. There are financial records mixed in with old photos mixed in with ancient versions of free software. You're not sure whether to throw the whole thing into the chipper, or to back it up very carefully. It will take too much time to sort through everything, much longer than it's worth. And yes while the drive is backed up carefully it's on old hardware that's expected to fail sooner rather than later.

Good backups consume time and money, but given enough money, there's not that much time needed to keep enough copies of your current working set of files active and alive. Once the working set grows - every photo you ever took, everything you ever downloaded, all those records of your existence - it gets harder. I don't have an easy answer for the "ugly" scenario except to do all you can to prevent it from happening, and a strong recommendation to sort through things up front rather than let random files clog up your drives.

For myself, the most important backup question: did I save enough pictures of my younger son as he was growing up? His older brother got all of the first photos on the first digital camera (backed up to floppy drives). Not so sure of the second child's digital record.

Also a sad reminder for those of us from the Napster era: we had very interesting digital music collections, and a lot of those digital files were "too big" at one point in the history of storage. Shiny new streaming services combined with ugly on-disk storage techniques means we just don't have that music as bits on disk anymore.

Learning complex systems, piecemeal - this time lima, limactl, Fedora and RISC-V

The pattern runs something like this.

1. Identify a shiny, new, and ferociously complex system that you'd like to know more about.

2. Bumble your way through the initial install, taking copious notes on things that will have changed by the next time you get around to look at them.

3. Declare victory after some trivial task beyond the initial install is complete.

This is an anti-pattern in a lot of ways. Perhaps the ferociously complex system can be safely ignored for a week or a year, rather than needing attention now. If it does merit attention, then give it a proper fully automated install rather than a haphazard try. Note that this might take a few uninstall cycles, that would be fine.

As an example, I have Rancher Desktop running on my MacBook Air M1. It seems to idle just fine, taking up a bunch of memory and a couple of cores but not getting in the way of actual use of the rest of the machine. I've installed exactly one application on it (my "sisyphus" function for OpenFaaS), and even that is less than ideal because the container it's running in isn't up to date. There's some complexity in there that I just barely remember about nerdctl.

And yet - and yet - here I go again with the same pattern. Gee, it would be interesting to have a Fedora version running Tailscale SSH on my M1 Mac. I'll bet I can run that under something - "lima" it is.

limactl start --name=fedora template://fedora

Try it out, run into something of course, a fresh issue at

https://github.com/tailscale/tailscale/issues/4908

in which Fedora Server at Fedora 36 doesn't want to run Tailscale SSH because of SELinux, but there's a workaround of sorts there. And with the workaround, I can ssh into an arm64 Fedora VM on my M1.

But wait, there's more. Armed with that knowledge, and looking at the limactl templates, I see there's a "riscv64" template that turns up a VM under emulation. A failed install later, notice that the Ubuntu distribution has moved a file, and we're up (and also have Tailscale SSH up again). Notes at

https://github.com/lima-vm/lima/issues/930

Now not just one but two different VMs running, plus a third in which to run Kubernetes. An embarrassment of riches (or perhaps just an embarrassment of idle cycles). Two more diverse systems for my tailnet, and two more chips away at a complex system to understand just a little bit better.