What do you do with bugs?

Software bugs are an everyday fact of life, and the sad truth is we’re never going to be free of them. What causes them, and what we can do when we encounter them is what we’ll explore here.

Anyone who develops software starts on their own computer. They have a specific make and model of machine, with all the hardware that manufacturer decided to incorporate in building it. The programmer is using whatever disto they prefer, with that distro’s choices of lower level software (kernel, modules, libraries), and that distro’s spin on their desktop environment of choice. The programmer is also using the support libraries for whatever environment they’re programming for (GTK+, KDE, etc.). When they’re at a certain point where everything they’re trying to accomplish with their application works, it’s usually pushed out for some process of review, where they hope to catch any glaring bugs and fix them before release.

Think about all the variables involved in that process. Start with the programmer’s computer. How many different makes and models of computers are there? All computer manufacturers have one thing in common, they’re trying to make money while at the same time keeping costs low. They mix and match pieces, change hardware configurations, use differing makes and models of peripherals, not to mention core components like the motherboard, chips, bus types, etc. The sheer number of possible hardware variations is staggering.

Next think about the programmer’s distro of choice to work in. Every distro does something different with their core components to try and stand out, be what they feel is better than the others. They can and do change how they compile their kernels, modules, libraries, as well as how they interact with each other. Source code versions can be different, compile time flags are changed, init systems, what’s started, how and when, can all be modified. Another mind-numbing amount of variations is possible.

Then there’s the toolkit the programmer is using. Most will work with whatever is current and supported by the environment they’re targeting, and make any support libraries their application needs “requirements” for packaging. Unfortunately, it’s the distro we choose to use that has to compile and package those requirements, and they might do something different from what the programmer desired or used themselves.

The plain fact is, there are so many variables involved in computers and computer software, a programmer or team of developers can’t possibly foresee or account for them all. The very best developers can’t program for, nor anticipate, all the possible environmental and hardware variations their software is going to encounter in the wild. Many larger projects have Q&A teams or similar, where they try to “torture test” software to find and fix bugs before it’s released. While it certainly helps a lot – much is caught and fixed in the testing – it’s still impossible to account for every variation. We as users are going to find bugs sooner or later.

So before you go on a tirade in social media or other public venue about “buggy crap” software (you can insert your own vile and demeaning adjectives here), think about what the developers are up against. Think about what you are doing. In the FOSS ecosystem you’re railing against people who gave their time to create something good and useful, then gave it freely to the world. Often at some personal and/or economic costs to themselves. In essence, you’re dragging over the coals someone who is trying to help you!

Consider this: Apple controls both hardware and software creation on their platform. They build the hardware, so they know exactly what is in it. They create the software to work with that hardware. They control the toolkits, libraries, kernel, modules, init, everything. They have an extensive and thorough Q&A that all software has to pass. And they STILL have bugs!

As I said when I started, bugs are a computing fact of life. There will always be bugs, the sheer number of variables in modern computing makes that inevitable. However, we in the FOSS world have an advantage. We can do something about the bugs we encounter. We can be proactive, and we don’t need to be a programmer to do it. Almost all software projects have bug trackers, systems where users can report bugs and help find a solution for them. Those that don’t will at least have an email address or IRC channel, some form of contacting the developers. All that’s required is a little patience and a willingness to spend some time helping find a solution. Time and patience, these two things are vital to squashing bugs. If we take a few minutes to just browse through a bug tracking system, we’d see hundreds (if not more) cases of someone reporting a bug with little to no information useful to the developers, and never following up. Or worse, ranting about a bug without even trying to be helpful in squashing it.

The only way a developer can kill a bug is if they understand exactly what’s causing it. The only route to understanding is if the user supplies all the information necessary, and follows up with whatever further tests or information the developer needs. It requires time and patience. It also helps to have a positive attitude and be polite. In the course of trying to kill the bug, the developer may ask you to do or try something you don’t understand. If and when that happens, tell them you don’t understand and ask for guidance. Remember, you’re both asking for help with a problem. They need your help to fix the problem, so don’t be shy in asking for their help in return. Most importantly, stick with it. There IS a solution, it just might take some time to find it. Chances are it’s working properly on their system, so they need to diagnose what is different between your system and theirs, and then figure out what to do about it.

Not all users can be bug chasers. Many of us just don’t have the time or patience for it. That’s okay, because we can still be helpful. How? By NOT trashing the software or developers because we have a bug. Put yourself in the developer’s shoes. You’re trying to create something useful and giving it freely to the world, and someone is publicly flaying you for it? How would you feel? Don’t be a troll. If you don’t have the time or patience to help with a bug, that’s fine. But don’t be a troll instead.

For those of us who do have the time and patience, chip in! It’s the beauty of FOSS, even those of us who aren’t programmers can still be actively involved in software development. Report the bug. If it’s already been reported, add your information. Most bug trackers have a guide for how to submit information, follow it and include yours, don’t just add a “Yeah, I have that bug too.” The more information the developers have on how a bug is affecting users, the more likely they are to find a solution. Then take the time to follow up on it to its resolution. By staying actively involved until it’s fixed, you’ll be able to honestly say “Yep, I helped in the development of that.” You’ll have changed from a being a “user” to being a “contributor”. Then the real reward happens, you get to soak up the feel-good that comes along with the knowledge you’ve helped on something the whole world can use.


Transcribe Speech To Text With Linux And Google

Sometimes in life, you run into situations where turning a voice recording into a text document is necessary. Perhaps this is from an interview for a news publication or perhaps you need to transcribe a verbal lecture from school. On Windows and OS X, there are a number of software programs that can help with this. Yet for Linux users, the options feel a bit sparse by comparison.

Today’s tip will address this issue. In this tip, I’ll show you how to combine Google’s Web Speech API with the Linux sound management server, PulseAudio.

Ready to get started? Great, here’s what you’re going to do:

1) Install pavucontrol (PulseAudio Control). It’s available from most software repositories.

2) Open pavucontrol (PulseAudio Control), click into the Input Devices tab. At the bottom, set Show to Monitors. Select the monitor that reflects the audio device you’ll be listening from by clicking the box next to the padlock on the right side. In my case, this was the USB speakers.

3) Now goto the Output Devices tab, make sure the matching output device is selected by clicking the box next to the padlock on the right side. Leave this app open, for troubleshooting.

PulseAudio Volume
PulseAudio Volume

4) Install/Open Chrome, browse to Google’s Web Speech API Demonstration page.

5) Now open up your audio player that will play the audio file. Get ready to play the audio file, but don’t hit play just yet.

6) Back on the API Demonstration page in Chrome, click on the microphone icon in the right center of the page.

7) Now in the audio player, hit play.

If everything went well, you should start seeing text appear on the Chrome page. If it isn’t working, re-check your settings. Another reason why it might not work is because of music or other noises in the background making voice audio difficult to detect.

Bonus fun: This also makes for a fun game of Mad Libs, by using a separate tab for YouTube podcasts. Some of the results are quite funny!

Introducing Jed Reynolds

I’m honored that Matt Hartley asked me to contribute to Freedom Penguin. In upcoming articles, I’ll be sharing some stories about things I’ve learned during my journey as a professional programmer analyst. I program in multiple languages like Java, Perl, bash, and also write end user documentation in PHP and do my own CSS.

I fix my own computers, and pride myself in being mechanically competent. I also fix my own bikes. (But don’t fix people.) For example, back in college around 1994, one of my friends who was getting a job asked me advice about getting a car. She probably asked the wrong person: I said  that all the cars I’ve owned, or been around, all needed work. Water pumps, starter motors, plug  changes and so forth. She was quite anxious after I went quiet on the topic. She asked, “I can’t  spend all my time fixing cars, I need to get to work. Will anything just get me to work?” I then told her, “Well, a Toyota will. They won’t break a lot.”

(Surprisingly, the Toyota’s I have owned have done pretty well by me. I own a 2000 Sienna that keeps on ticking. Real guzzler by modern van standards, however the thing could tow a boat.)

And that’s (almost) how I think of Linux. It’s pretty dependable, but you’ve gotta roll up your sleeves once in a while. My family all have Ubuntu laptops. And as a result, I don’t have to worry about adware. Also stuff is easy to back up. The kids can game on these PCs, and only game just enough that they’re not bugging me for those fancy water cooled rigs. Luckily for me, I can keep the family running happily on used or refurbished hardware for the indefinite future. Similar to how I would view buying a used Toyota. I tend to think of myself as the family Linux mechanic.