Logbook

moving from Github Issues to Obsidian for daily issue tracking

I started using Github Issues as a personal issue tracker in 2012. The first issue was "Replace mobile phone with new device - iPhone, Android, or burner". It took me months to decide what to do. Since then, I've opened over 10,000 other issues with small or large details of things I'd like to do.

I've decided to give up on Github Issues as a personal info tracker, and replace it with Obsidian. While the thought is fresh in mind, here's a few reasons why.

Speed. Github Issues is available only through a web browser, while Obsidian is an app that stores the entire database in memory. As a consequence there are round-trips to the net for every transaction and every browsing effort on Issues, while Obsidian lets me bop around from node to node with no visible lag.

Portability. Github Issues isn't easy to download as a database. The whole thing can be pulled down to Markdown by a third-party tool (I'll want to do that). Obsidian is easy to sync to Git with a plugin, so I have the whole thing locally backed up, and I can browse and edit when I'm offline.

Native apps. The several third-party native apps I've tried for Issues have been really nice and have had a too-short shelf life. Bee.app was discontinued by its maker, and Gitscout seems to have died before a proper 1.0 release. Having to do everything through a browser feels clunky and slow and distant.

Community. Github Issues is designed for teams working on software. Obsidian is full of individuals with quirky knowledge management habits. I'm much more likely to run into someone with a cool idea about how to traverse their state of consciousness in Obsidian-land, and much more likely to find a product manager burning down a backlog in Issues-land.

Fresh start. Like I said, I had over 10,000 issues completed, which is my signal that I've learned enough about the environment to make some decisions about how well it works for me and whether the limits of it are ever going to change. My Obsidian page-count is nearly 600 right now, which means it has plenty of room to grow and morph as needed.

Wiki nature. I fell hard for Wiki ideals and wiki naming a couple of times (Socialtext, Arborwiki, Localwiki). I like typing a word in double brackets and having it make a hyperlink ready to click on. With Github Issues it is possible to cross-link issues by referring to items by number, but then you have to remember a lot of numbers, and who can do that?

The "law of two feet" from Open Space says that if you're not happy where you are, it's your responsibility to remove yourself from that location and put yourself somewhere that you are happy. I'm ready to explore a new challenge, cross everything off my todo list all at once, and recreate it as needed in a new place. We'll see how long this enthusiasm lasts.

on log4j and dependencies on other people's complex systems

The issue of the {day, week, month, year} is log4j, a logging library for Java that turned out (unbeknownst to the world) to have a lot more subtle power than was obvious on the surface. When looked at closely, this subtle power turned into a vector for remote code execution (through the Java JNDI interface) and exfiltration of secrets (through variable expansion). The world is scrambling to figure out what their exposure is to this newly found threat, and in many cases also trying to figure out how they can safely update deeply embedded buggy dependencies.

If log4j were the product of a well-funded, scrappy, pre-unicorn startup, the question of what to do would be different. As is, the committer base for the product is very small, it's old in Internet terms, and the original feature that triggered this issue was added years ago.

The pernicious thing about this particular exploit is that to be sure you're not vulnerable you have to audit not only all your own code but also all the code of all the systems you interact with. This includes embedded systems, control planes for routers and switches, software that you consume as a service rather than running on-premises, even device firmware. Java is everywhere, and log4j is very popular, so the attack surface is huge.

I am not sure what we as an industry can do about this kind of issue. Software lifecycles are very tricky to manage. If code is feature complete and not being actively added onto, people walk away from it to do more interesting things, and you get the risk of abandonware. If on the other hand the code tries to keep up with the pace of change of the modern Internet, it can very easily accumulate a lot of cruft and complexity. Scrapping a fully working system to replace it with something brand new is very risky.

The question of funding comes up time after time. The very small team that continues to work away at log4j after lo these many years is not paid directly by the foundation (Apache) that hosts their effort. For most big corporations, it's very hard to spend small amounts of money. Larger amounts of corporate money might be available for feature development (and added complexity), but see above re cruft.

I have seen foundations try to tackle this conundrum, e.g by paying outside parties to do a security audit of code that's under their umbrella. This is an expensive but controlled way of finding bugs and design flaws in a system, and if it's done right it can contribute to a sense of confidence about one specific component. But no one is talking now about auditing "all code in Maven" or "all code in npm", that's near enough to an infinite task to be considered impossible. Even automated audits and fuzz testing only go so far to find known classes of bugs.

I leave this without any simple solutions. The "software bill of materials" (SBOM) approaches being actively promoted right now will help to a certain extent, but even if they can accurately enumerate your dependencies they won't necessarily tell you how to fix them if something goes haywire. GitOps and other automated deployment tools will assist you in recreating your infrastructure if need be, but won't always have a simple answer about how to safely shift a single embedded component.

No one really understands their full stack (from pretty UI all the way down to BMC firmware). Complex systems are in a state of perpetual partial failure. It might have been a mistake to teach sand how to think.