Wandering Thoughts archives

A cynical view on needing SSDs in all your machines in the future

Let's start with my tweets:

@thatcks: Dear Firefox Nightly: doing ten+ minutes of high disk IO on startup before you even start showing me my restored session is absurd.
@thatcks: Clearly the day is coming when using a SSD is going be not merely useful but essential to get modern programs to perform decently.

I didn't say this just because programs are going to want to do more and more disk IO over time. Instead, I said it because of a traditional developer behavior, namely that developers mostly assess how fast their work is based on how it runs on their machines and developer machines are generally very beefy ones. At this point it's extremely likely that most developer machines have decently fast SSDs (and for good reason), which means that it's actually going to be hard for developers to notice they've written code that basically assumes a SSD and only runs acceptably on it (either in general or when some moderate corner case triggers).

SSDs exacerbate this problem by being not just fast in general but especially hugely faster at random IO than traditional hard drives. If you accidentally write something that is random IO heavy (or becomes so under some circumstances, perhaps as you scale the size of the database up) but only run it on a SSD based system, you might not really notice. Run that same thing on a HD based one (with a large database) and it will grind to a halt for ten minutes.

(Today I don't think we have profiling tools for disk IO the way we do for CPU usage by code, so even if a developer wanted to check for this their only option is to find a machine with a HD and try things out. Perhaps part of the solution will be an 'act like a HD' emulation layer for software testing that does things like slowing down random IO. Of course it's much more likely that people will just say 'buy SSDs and stop bugging us', especially in a few years.)

Why I still report bugs

I've written plenty of entries here over the years about why people don't report bugs (myself included). Yet I still report bugs against some projects.

The quiet reality of bug reports that I haven't mentioned so far is that when one of my bug report goes well, it's an amazingly good feeling. When I find a bug, isolate it, maybe peer into the code to identify the cause, file a report, and have the project authors say 'that's a nice find and a good analysis', that's a real rush. It's not even so much that I may get a fix for my issue; it's very much also that I have reached into the depths of a mystery and come out with the right answer. It's even better when it helps other people (both in the future and sometimes right away). This is bug reports as the culmination of debugging, and successful debugging itself is a rush of puzzle solving and a victory over a hard problem.

(It's equally a good feeling, although a somewhat different one, when I file a carefully reasoned bug report in favour of something that the software doesn't currently do and I wind up bringing the project people around to my views.)

More than anything else, this is the feeling that keeps me filing bug reports with hospitable projects. It is the feeling that makes bug reports into something other than grinding work and that makes me proud to have written a good report.

I'm often down on bug reporting because I don't have this experience with bug reporting very often. But neither I nor anyone else should forget that bug reporting can feel good too. It's probably not a small part of why we're all willing to keep making those reports, and I don't want to lose sight of it.

(It's easier to remember the negative bug reporting experiences than the powerfully positive ones, partly because humans have very good memories for the negative.)

(As you might guess, this entry was sparked by the experience of recently filing a couple of good bug reports.)

A modest little change I'd like to see in bug reporting systems

It is my opinion that sometimes little elements of wording and culture matter. One of those little elements of culture that has been nagging at me lately is the specifics of how Bugzilla and probably other bug reporting systems deal with duplicate bug reports; they are set to 'closed as a duplicate of <other bug>'.

On the one hand, this is perfectly accurate. On the other hand, almost all of the time one of my bug reports is closed out this way I wind up feeling like I shouldn't have filed it at all, because I should have been sufficiently industrious to find the original bug report. I suspect that I am not alone in feeling this way in this situation. I further suspect that feeling this way serves as a quiet little disincentive to file bug reports; after all, it might be yet another duplicate.

Now, some projects certainly seem to not want bug reports in the first place. And probably some projects get enough duplicate bug reports that they want to apply pressure against them, especially against people who do it frequently (although I suspect that this isn't entirely going to work). But I suspect that this is not a globally desirable thing.

As a result, what I'd like to see bug reporting systems try out is simply renaming this status to the more neutral 'merged with <other bug>'.

Would it make any real difference? I honestly don't know; little cultural hacks are hard to predict. But I don't think it would hurt and who knows, something interesting could happen.

(In my view, 'closed as duplicate' is the kind of thing that makes perfect sense when your bug reporting system is an internal one fed by QA people who are paid to do this sort of stuff efficiently and accurately. In that situation, duplicate bugs often are someone kind of falling down on the job. But this is not the state of affairs with public bug reporting systems, where you are lucky if people even bother to jump through your hoops to file at all.)

My brush with the increasing pervasiveness of smartphone GPS mapping

One of the things I do with my time is go bicycling with a local bike club. When you go on group bike rides, one of the things you generally want to have is directions for where the ride is going (if only to reassure yourself if you get separated from the group). When I started with the club back in 2006, these 'cue sheets' for rides were entirely a paper thing and entirely offline; you turned up at the start of the ride and the ride leader handed out a bunch of copies to anyone who wanted or needed one.

(By 2006 I believe that people were mostly creating new cue sheets in word processors and other tools, but some old ones existed only in scanned form that had been passed down through the years.)

Time rolled on and smartphones with GPS appeared. Various early adapters around the club started using smartphone apps to record their rides. People put these ride recordings online and other people started learning from them, spotting interesting new ways to get places and so on. Other people started taking these GPS traces and loading them on their own smartphones (and sometimes GPS devices) as informal guides to the route to supplement the official cue sheets. As time went on, some people started augmenting the normal online ride descriptions for upcoming rides with somewhat informal links to online GPS-based maps of the ride route.

Last year the club started a big push to put copies of the cue sheets online, and alongside the cue sheets it started digitizing many of the routes into GPS route files. For some of the rides, the GPS route files started being the primary authority for the ride's route; the printed cue sheet that the ride leader handed out at the start was generated from them. Finally, this year the club is really pushing people to print their own cue sheets instead of having the ride leader give them out at the start. It's not really hard to see why; even last year fewer and fewer people were asking for copies of the cue sheet at the start of rides and more and more people were saying 'I'm good, I've got the GPS information loaded into my smartphone'.

(This year, on the group rides I've lead I could hardly give out more than a handful of cue sheets. And usually not because people had already printed their own.)

It doesn't take much extrapolation to see where this is going. The club is still officially using cue sheets for now, but it's definitely alongside the GPS route files and more and more cue sheets are automatically generated from the GPS route files. It wouldn't surprise me if by five years from now, having a smartphone with good GPS and a route following app was basically necessary to go on our rides. There's various advantages to going to only GPS route files, and smartphones are clearly becoming increasingly pervasive. Just like the club assumes that you have a bike and a helmet and a few other things, we'll assume you have a reasonably capable smartphone too.

(By then it's unlikely to cost more than, say, your helmet.)

In one way there's nothing particularly surprising about this shift; smartphones with GPS have been taking over from manual maps in many areas. But this is a shift that I've seen happen in front of me and that makes it personally novel. Future shock is made real by being a personal experience.

(It also affects me in that I don't currently have a smartphone, so I'm looking at a future where I probably need to get one in order to really keep up with the club.)

OpenBSD and the impact of culture

We use OpenBSD here for firewalls and a few other things, and over the course of doing so we've found a number of bugs and issues. Have we ever reported these to the OpenBSD people?

Ha ha. Of course not. We'd have to be crazy to do that.

The OpenBSD culture has acquired a reputation for being what we could politely call 'abrasive'. But let's call a spade a spade and say 'abusive' instead. As the folklore has it, if you show up with a question or an issue or a bug report that the OpenBSD people feel is stupid or ignorant or wrong, you can expect them to call you an idiot and a waste of their time. Innocently say something that they don't like? You can look forwarded to being upbraided, perhaps by the infamous Theo himself. Maybe you'll even get an explosion of invective.

(When I wrote about how a social obligation to report bugs implies that projects have a social obligation to make reporting bugs not unpleasant, OpenBSD was the big example I had in mind.)

If we cared a lot, if we desperately needed OpenBSD to work right in some case where it doesn't, maybe interacting with this would be worth it. But we don't, it isn't, and so we don't. We'll almost certainly never submit an OpenBSD bug report no matter what issues we run into. I suspect we're not alone in this.

(Certainly in the one case we ran into where we couldn't get OpenBSD to work at all for us, we just abandoned it rather than particularly file bug reports or interact with the OpenBSD community. This wasn't even a decision I was involved in, as it was a project my co-workers were doing.)

If OpenBSD doesn't want to get bug reports except from people who are really dedicated, the folklore about their culture is working really great for them. If they would maybe like some more bug reports, assistance, and so on, it is not being so helpful.

I also rather think that this culture affects how interested people are in using OpenBSD. Especially with free software, the community around the software can really change how usable it is because the community is where you go for information, help, advice, bugfixes, and so on. If there is effectively no community for you, the software becomes an unsupported black box, and those are much less useful and attractive.

Culture matters. Culture has an impact, one that goes far beyond the obvious. And contrary to what people sometimes say, you cannot divorce culture from technical issues or consider code and personalities separately, because how you talk about technical issues influences whether people are willing to talk to you about them at all. Some people will care enough to persist anyways; other people won't.

(And OpenBSD is not particularly an exception here, although it does make a great example that I have personal experience with. Any number of projects have their own cultural issues; I'm sure you can name your own favorite cases.)