hpr-knowledge-base/hpr_transcripts/hpr0943.txt

Episode: 943
Title: HPR0943: Freedom is not Free 2 - Bugs
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0943/hpr0943.mp3
Transcribed: 2025-10-08 05:18:03

---

Hello, this is Ahuka, and welcome to the second in our series Freedom is not free.
In the last episode I introduced this idea that I think the software that we work with,
we sometimes call it free software, we sometimes call it open source software, but I find
that there are certain problems with both of those, and I suggested that really what
we ought to do is refer to this as community supported software.
And that raises then the question of, well, what are the various ways you can support?
And I mentioned four of them in the last podcast, and I said I wanted to come back and take
a look at them in somewhat more detail.
So what I want to do this time is I want to talk about the first of the four topics that
I had mentioned, ways that you can support free software, even if you are not a programmer.
All right?
I mean, if you're a developer, if you're helping to keep the kernel going, you are working
on some of the software that we all love to use, then God bless you.
You're already doing enough.
What I want to do is I want to address all of the people in the free software community
who use the software, who love the software, who want to support it, and say, hey, I'm
not a programmer.
How can I help?
And that's what this series is all about.
Now the first of the topics that I want to address is bugs.
Yeah.
Okay?
Well, every piece of software has bugs.
That's an unavoidable fact of life.
And Linux software, open source software, that has bugs too.
So I'm sorry, that's just the way it is.
But, you know, I happen to think that in many cases, the free and open software is as
good if not better than the commercial proprietary software, but that doesn't mean it's perfect.
That doesn't mean it is bug free.
These things have bugs.
And when software has bugs, one of the questions then is, well, how are we going to deal with
that?
If you take a look at most of the projects that you're interested in, and you go check out
their website, you're going to see that almost always there is some kind of mechanism that
is going to deal with bugs.
Now I'd like to start with the distribution, okay?
Generally speaking, when you install Linux on a system, you are installing a distribution
and the whole idea of a distribution is that it is a bundle of software that was put
together that is designed to work together.
So it makes sense to start there, all right?
Now in some cases, you may want to go past the distribution, and I want to talk about
that, but let's take that as a starting point.
There's a fellow named George Castro who is a canonical employee and has done a lot
of work with the various upstream projects.
That's a big part of his job at canonical, and he happens to have spent a lot of time
living in the same general area that I do.
So I've had a number of conversations with him about this.
When a software distribution puts all these things together, they make certain choices.
So for instance, Ubuntu might say, well, this is the software we're going to use for
playing your MP3 files.
This is the software we're going to use for video.
This is the software we're going to use for your mail client.
This is the web browser we're going to install, and so on and so forth.
Now when they do that, what they're doing is saying, we have tested this software in
our distribution.
We think it is the best choice for what we want to do, and they're making essentially
some kind of claim to providing at least some level of support here.
The opposite can also be the case.
Let's say you've got a distribution that says, we're going to use evolution for our
mail client, and you say, I don't like evolution, I'm going to install Thunderbird.
You're quite welcome to do it.
I'm sure all of the major distributions are going to have that in their repositories.
But if you were to file a bug and say, well, Thunderbird is not, you know, I've got a problem
with Thunderbird, they might look at it and say, it's not our problem, okay?
I had something like this happen to me recently.
I filed a bug with OpenSusa, and the bug had to do with a video editing program called
Kaden Live.
Now, I happen to love Kaden Live.
It was having this certain problem.
It kept crashing.
That's considered a serious problem, and I filed a bug with OpenSusa, because I thought
that was a good place to start, and then I got a response from the people at OpenSusa.
They closed the bug and said, you know, we don't support this particular software package.
This is not part of our distribution, therefore we're not taking responsibility.
That doesn't make the people of OpenSusa evil.
It's just, you know, you can't deal with everything.
So they've made a decision about what they will or will not deal with.
So in a case like that, the only thing you could do that is to file the bug with the Kaden
Live project, which I did.
So that's fine, but you might want to start with, generally speaking, the distribution.
Now every distribution is going to have their own little way of doing things I know with
Ubuntu.
They've got this thing called Launchpad, and you go in there, and you can file your bugs
and all of this, and OpenSusa had a particular forum that you would go in, and you'd file
bugs there.
And so, you know, there's different ways of doing it.
How are you going to find out about that?
Well as it happens for at least the major ones, there's already a very nice site.
And it's a place called Linux, called HowToAtLinuxCareer.com, guide to bug submitting and bugtracking
in Linux.
I've put the URL in the show notes, and they give you some general instructions for Ubuntu
for Mint, for Fedora, for Debian, and for OpenSusa.
So I'm thinking you're kind of hitting the biggies there.
That's going to work for a lot of people.
And if you go to this site, you take a look, you know, what's the first thing they say?
Linux distributions and open source software in general are before anything, community
efforts.
All right, that's exactly the theme of this series that I'm doing is to say this is
community-supported software, all right, then they go every distribution list somewhere
in its website, ways to contribute and help the effort, okay?
So submitting bugs is important, and if you go to this site, it's going to tell you.
So, you know, if you go there, you take a look at Ubuntu, they're going to give you
a link to LaunchPad and some general instructions about all of that.
If instead you went to Mint, they give you a slightly different.
And it's also in LaunchPad, but it is because Linux Mint is based on Ubuntu.
Then for Fedora, there is a site called bugzilla.redhat.com that you would go to there.
If it was Debian, it's a site called bugs.debian.org, all right?
And then, of course, OpenSusa, you've got a bugzilla.novel.com, and then they say for
non-technical users, you might want to try the forums.
So that's the starting point.
You take a look at all of these places and you find out, okay, how do I do this?
Now, the next thing I want to say is that you can submit a bug at any time, but it is
going to be most useful if you do a little bit of work first.
Now, when I talk about the work, you got kind of thinking about what's happening.
All right?
I had a problem recently that initially I thought it was a software problem.
I might have filed a bug.
I just started having crashes on one of my machines, and so I started to think, okay, what's
happening when it crashes?
And I started looking at that, I said, gee, every time it crashes, I'm doing something that
involves video, interesting idea.
And okay, what did anything change on the system?
Yes, I put in a video card a few weeks ago.
That was a new video card.
Come to think of it, I think all of those crashes happened after I put in the video card.
So first thing I did a little troubleshooting, I said, change drivers.
And I tried several different drivers.
I tried the default drivers from the distro.
I tried some proprietary drivers from the manufacturer.
No matter what driver I tried, I kept having the crashes.
Finally, I just pulled the video card out and ran off of the onboard video, no more crashes.
I kind of think I found my problem.
And that's an example of the kind of the troubleshooting that you want to do.
A good bug report is going to help.
If you can, identify these things.
So one of the first things, if you're having a bug, did anything just change?
Okay, in my case, I put in a new video card.
Is it, I've had bugs that happen because, for instance, I decided to upgrade the version
of my distribution.
I run kabuntu on a number of my boxes.
And so every six months there's a new version of kabuntu.
And okay, I upgrade to a new version.
Now I've got this problem.
All right, well, that's an indication right away.
It probably has something to do with that new version of the distro.
Did I just install some new software?
That new software might be conflicting with something.
So you kind of look at what changed as being a clue.
And then if you can, can you roll back the change?
All right, if you install the piece of software and it causes a problem, does removing the
software get rid of the problem?
You know, if you change the driver for your video card and the problem showed up, can
you change the driver back to what it was before and make the problem go away?
You know, information like that is really useful to the developers in trying to figure out
where the problem is.
The next thing that they're almost always going to ask you is, what were you doing when
the problem occurred?
So in the case of that video problem I had, you know, the machine crashed when I was,
for instance, encoding a video.
That's something I do a fair amount of.
So it was pretty easy for me to make that connection and say, hmm, that's, there is
the problem.
The next thing is it reproducible, which means if I always do action X does result Y always
occur.
It's really useful to know that, you know, the hardest ones are the intermittent bugs
where that's, well, I do action X and sometimes Y occurs and sometimes it doesn't.
That's always a little bit harder.
But the more you can trace that and say, yes, this is what happens.
Try and do the same action over and over again and see if you get the result.
That's a really good piece of information for the, because what you're trying to do is
give the information to the developer to say, this is the problem, would you fix it?
It's a wonderful feeling when the developers actually take your bug and fix it.
And I've had that happen.
But they can only do that if you give them the information.
Next thing, do you have any log data to add to the report?
Now in some distributions, they're trying to automate this.
I know the folks that Ubuntu have been trying to build an automated bug reporting system
that, when the bug, you know, if the system crashes, let us say, it's going to pop up a
little applet that is going to file the bug and they will frequently be able to automatically
access the right log files to get that information.
That's wonderful.
But it never hurts to get to know where your log data lives.
For instance, the Command DMESG, great source of information, okay?
And that's reading a file that you could include that, the output of that, include that
in your bug report.
And you might even be able to figure out how to read it and pull out some of the relevant
details first.
Finally, the one of the things you might want to do is you might want to check to see if
the bug has already been submitted, okay?
Now if that's the case, you may be able to add on to the report.
You might be able to improve someone else's bug report.
They might have just made some sort of vague thing of, yeah, you know, I installed this
piece of software and it crashed.
Well, you know, that's not really very helpful, but if you had the same problem and you
know how to do a proper bug report, you could commit and say, hey, same thing happened
to me.
I was running this particular version of this distribution.
I was running this particular version of this software and here's my hardware setup.
And here's the attached log file that is going to have all of this wonderful information.
And you know, you could really improve that.
And I know from talking to George that a lot of the work that he and some of the other
folks do with Ubuntu is finding these rather poorly written bug reports and improving them
so that there's actually information there that the developers can use to do this.
And I emphasize that because in most cases, developers want to fix the bugs.
They take pride in their work.
They want to do the right thing.
But if you don't give them the information, oh, it's just, it's so terribly hard.
Now, the other thing about checking to see if a bug has been submitted, think about it.
Someone may already have the answer.
Isn't that wonderful?
So gosh, I'm doing such and such and you know, I installed this software, but it won't
run.
It gives this error message and crashes and I really want to run this software.
And if you go looking what you might find is someone's going to say, oh, I know the
answer to that.
You need to change this one library and if you do that, everything will be wonderful.
That's great information, okay?
And the way you find that is by taking a look at the bugs, all right?
So you go to look to the bug report, you see what's in there and you discover there is
a solution, you apply it and all of a sudden you're happy because you get to do this.
Now, I had a complicated one with a piece of software called Miro.
Now, if you're not familiar with Miro, it is basically, it's for video podcasts and
online video content.
And I will just emphasize in this case that they're really focused on legal video content,
all right?
You know, if you're looking to download illegal bit torrent copies of the latest Hollywood
movies, this is not the place you would go and I don't, if you're into that, you'll
figure it out.
I don't need to tell you about it.
But I find Miro absolutely essential to me because there are a lot of video podcasts
that I like to listen to to watch.
And so what it does is it downloads all of them and then has a playback console that
I can watch all of these videos and it's very, very convenient.
So I had a problem.
First thing, I upgraded my distro to the newest version and suddenly Miro doesn't work.
Uh-huh.
Okay, that happens.
Then, okay, where's the problem?
Miro doesn't play any videos.
I started doing the troubleshooting.
Can I play videos with other software?
Could I use VLC?
Could I use drag and, you know, and the other software was, no, no problem.
They can play it just fine.
All right, so obviously there's something going on here with Miro.
In my case, I happen to have several computers with the same distro version, so I was able
to test it there.
Same problem on all of these different computers.
So I filed a bug in actually in this case in two places.
I filed it with the distro, which was Ubuntu in this case.
And I also filed the bug with Miro.
Now as it happens, I got to reply from the developer on the Miro project within a couple
of hours.
And he said, gee, I tried that exact distro version and I had no problems.
Interesting.
So how are we going to find out?
He said, there's this log file.
He told me where the log file is.
And I said, great, I grabbed that log file and I sent it to him.
And then he wrote back, again, within, you know, maybe an hour of me sending it to him,
he wrote back and said, well, you know, looking at the log file, I'm seeing, this looks
like your problem.
It looks like it's missing a package.
And I thought, OK, I checked, you know, using my package manager.
And it told me that the package was installed.
But as I say, this is a recently released upgrade to Ubuntu.
So you know, things can go wrong with that.
So what I did is I removed the package and reinstalled it.
And then suddenly Miro is working.
And I was able to go back and tell the developer exactly what had happened.
And you want to do that because what, you know, someone else might come along, OK?
And so I not only told the developer directly, but made sure that it was attached to the
bug report that I had filed.
So that if the next person comes along and takes a look at it and says, gee, I'm having
this problem.
They'll see that I had reported the bug.
And this is the steps that I took and this fixed it and now I'm happy.
And then if they follow that, they're going to be happy as well.
So you know, when you create good bug reports, you help yourself and you help others.
And I think that's such an important part of the community support.
It doesn't cost any money.
It does cost a little bit of your time.
But that's what it means to have community supported software.
So I encourage anyone listening to this.
You know, the next time you get some annoyance, you know, some program crashes on you, don't
just piss and moan and curse at people that the software isn't working the way you like.
File a bug.
And you know, you just might be responsible for making free software better for other
people.
Now, I want to mention something else because I am in addition to podcasting for hacker
public radio, something I started doing at the beginning of 2012, but hopefully I'm going
to be continuing.
I'm also involved with Ohio Linux Fest.
So I know that hacker public radio has a very international audience, but I'm sure that
there are a lot of people who are in the Midwest of the United States who may be familiar
with Ohio Linux Fest and perhaps even thinking about attending or what have you.
And I would like to tell you that we have just opened up our call for talks.
All right.
We'll be doing the 2012 event at the end of September, September 28 through 30th, but most
of the talks will be on the 29th, which is a Saturday.
And what we're really looking at right now is trying to get some people to submit proposals
to give a presentation.
We're looking for just about anything that is related to free and open source software,
free hardware, open hardware, with hardware when I say free, I mean, as in freedom, not
necessarily free of charge, because hardware is going to cost money.
But we're pretty broad about that.
So just a quick list of some of the things, Zen, Samba, WordPress, BSD for the home user
or in production, using Linux in a Windows world, open source in the view of a teenager,
video editing, GNOME 3, KDE, IPv6, that'd be a great one, because we know that a lot of
companies have said they're going to turn that on for good in June of this year, I'd like
to know more about that.
I'd love to have people talk about Android, so it's a pretty broad range of things.
And the other thing is we look for variety in the levels of these things, so that it's
not that everything is going to be aimed at CIS admins or that everything is going to
be aimed at the newbies.
We want to have a mix, we want to have all of those levels.
So when we get these talks, we usually sort them out as beginner, intermediate and advanced
and try and then select a good number from each of those three categories.
So we'd love to have that, and the other thing is that we put a lot of effort into trying
to be family friendly and trying to be as inclusive as possible.
So we would love to have more women or minorities or just as much of a mix of people as we
possibly can, and we really do, and I think if you talked to anyone who's been involved
with us, we don't just talk to talk, we do our best to walk the walk on this one.
So if you're interested, we have an announcement up on the web page, and I've put the URL
into the show notes, so that'll make it easy for you.
So I think that I'm going to sign off, this is a hookah, and it's been a pleasure talking
to you, and I'll talk to you again.
Bye.
You have been listening to HackerPublic Radio at HackerPublicRadio.org.
We are a community podcast network that releases shows every weekday and Monday through Friday.
Today's show, like all our shows, was contributed by a HPR listener by yourself.
If you ever consider recording a podcast, then visit our website to find out how easy
it really is.
HackerPublic Radio was founded by the Digital Dark Pound and the Infonomicom Computer
Club.
HPR is funded by the binary revolution at binref.com, or binref projects are crowd-sponsored
by linear pages.
From shared hosting to custom private clouds, go to lunarpages.com for all your hosting
needs.
Unless otherwise stasis, today's show is released under a creative commons, attribution,
share, and like Digital's own license.