GoKawiilIf you use software regularly, and have your wits about you, you will often realise that you’ve encountered a bug — in other words, that the software has done (or not) something that it shouldn’t (or should have). When this happens, the vast majority of people moan to the nearest bystander about how incompetent the people behind the software are and then carry on with whatever they were doing — often stumbling into the same bug repeatedly. Only a minority of people think of reporting bugs and, if they do think of it, they often fail to do so either because they think it’s too time-consuming or that they might end up looking silly.
It’s unfortunate that so few people report bugs. First, surprisingly few bugs affect a single person: by the time someone does report a bug, it can have affected hundreds or thousands of other people. We can’t all be freeloaders — someone has to take the plunge and report the bug. Second, bugs frequently appear in contexts unfamiliar to the software’s developers . Most obviously, we all have slightly different software installations, and those variations can cause odd effects. Less obviously, users often use software in ways unimagined by its creators, such that some previously untested combinations of operations work incorrectly . Either way, we cannot assume that the software’s developers will encounter the same bugs that we do: in many cases, if we don’t report bugs, the developers simply won’t know they exist.
Reporting bugs in someone else’s software is different from finding and fixing bugs in one’s own code, because we understand those other systems much less well. The sense of confusion I have with bugs in my own code is magnified when using other systems. I’m less confident that I’m actually seeing unexpected behaviour; less sure what the cause might be; and have lower trust than normal in any fix I propose. That means that we must acknowledge an important trade-off: a full understanding of the cause of a bug in an unfamiliar system is often beyond any reasonable investment of time; but if we just say “it doesn’t work”, no-one can be expected to replicate, let alone fix, the bug. Somewhere in the middle is a sweet-spot where the bug reporter invests the minimum amount of time to generate a good enough bug report that a developer can use to fix the bug.
While I wouldn’t exactly say that reporting bugs gets me out of bed each morning, I do feel something of a duty to do so. I have benefited hugely from the existence of open-source software, and reporting bugs is one of my ways of contributing a little back. Now that I’ve been doing so for years, reporting bugs holds many fewer fears, in terms of time or reputation, than it once did.
In this post I’m going to look at the bugs I reported in the first week of August on various pieces of open-source software. This is hardly a normal week, because I started it with a new laptop, which pretty much guaranteed that I’d hit more bugs than normal — but, as you’ll soon see, that was not the only source of bugs I encountered. Some of my reports have led to bugs being fixed, some haven’t. While I obviously hope for the former outcome, open-source developers aren’t under any obligation to investigate, let alone fix, my bug reports.
I hope it’s useful to see what happens when someone like me, who sometimes, but definitely not always, knows some details about the software I’m using, runs into what I believe are bugs. I’ve tried to record as much of the confusion that I went through as I can remember, because that seems an inevitable part of the process. Unsurprisingly, a lot of what I’ve written relates to my attempts to understand the effects of a bug and investigate their cause. I hope you also get a sense of how much my interactions with developers played a role in my and their understanding of a bug. Not only did my bug reports vary substantially in quality, but I was quite often wrong in my initial guess of the cause of a bug or what a good fix might be.
I’m going to present these bugs in roughly the order that I encountered them, because as you’ll see, there are more overlaps than might otherwise be apparent.
A new laptop
After 5 years of use, my old Thinkpad had reached the end of its useful life. The battery life had declined by around half, and more than once I ran out of power at an inconvenient time, damaging the battery further. Furthermore, its 2 physical cores were no longer up to the demands modern software places on them, causing me to twiddle my thumbs increasingly often. I’d been using Thinkpads for 19 years and until recently assumed I would continue doing so. However, Framework’s modular approach to laptops, which seems to me a more environmentally sustainable approach to hardware, appeared to be both equivalently good, and more worthy of my support, so I ordered one with my hard-earned cash.
I knew that the first generation Framework was supported under OpenBSD (my operating system of choice) and crossed my fingers that the newly released second generation (which I’d bought) would work too. However, I was aware from experience that newly released hardware tends not to fully work on OpenBSD for a little while.
... continue reading