Will Woods, Fedora Testing Guy

There's something stuck in my brain.

Tue, 12 May 2009 22:33:55 GMT

Saw this on boingboing earlier and I can't stop thinking about it:

1. No one cares about what you think, unless you do what you think.
2. No one cares what you do, unless you think about what you do.
3. No one ever really cares what you say.

Spending less time on talk - and more effort on thinking things through and getting them done - seems like some good advice for me right now.

Why glxgears is slower with Kernel Modesetting (and why it doesn't matter)

Fri, 13 Mar 2009 20:44:15 GMT

or: "glxgears is not a 3d benchmark"

One interesting fact came out of yesterday's Intel KMS Test Day. Everyone noticed that glxgears is much slower under KMS/DRI2 than it was before (e.g. in Fedora 9 or 10). A typical result was ~1000FPS in F10, but only ~440FPS in Rawhide. So what's changed?

Here's the deal, as best as I understand it (thanks to krh/halfline/ajax for trying to explain it to me): glxgears is rendering an insanely simple scene - so simple that the actual 3D rendering time is basically zero. So the only thing glxgears really tests is the performance of glXSwapBuffers() - basically, how fast we can push render buffers into the card. This operation is slower with DRI2, but - roughly speaking - unless it was an order of magnitude slower (e.g. glxgears drops from 1000FPS to under 100FPS) it wouldn't make any real difference.

So if you're going to be comparing "3D performance" - please, don't bother with glxgears. ajax has suggested a couple of things that might make better benchmarks:

The mesa-demos package has a few useful things - teapot in particular is nicely simple.
sierpinski3d and glblur from xscreensaver-gl-extras also work well.
extremetuxracer is, in my opinion, the most fun way to benchmark 3D.

If you see major (100% or more) performance differences between KMS and non-KMS in those apps, it's probably worth investigating further.

.i586 packages: not a big deal

Mon, 09 Mar 2009 17:58:49 GMT

A note about .i586 packages in Fedora 11, and why you shouldn't worry about them:

Since we have a new compiler, some RPM checksum improvements, and - for x86 users - changes to the default architecture support, we've done a mass rebuild of every package in Fedora. x86 users will likely notice the following changes:

All .i386 packages have been rebuilt for i586.

Instead of building four kernel packages (i386, i586, i686, and i686-PAE) we're now building just two kernels: i586 and i686-PAE.

Newly-installed x86 systems that have 'pae' and 'nx' in /proc/cpuinfo will get i686-PAE.

Everything else will use kernel.i586.

Here's the thing: moving to i586 isn't a big deal because we're already optimizing for modern (i.e. Pentium 4 or later) processors. For the past couple years we've been using gcc's -mtune=generic flag, which optimizes for "the processors that were most common when that version of GCC was released" (according to the gcc info page). The only thing that moving to i586 really changes is the instruction set that's used. i586 adds a handful of new instructions over i386 - notably CMPXCHG8B, which is useful for efficient atomic operations - but nothing world-changing. This probably isn't going to give you more FPS in glxgears.

As for the kernel, the only difference between i586 and i686 is the CMOV instruction family, which - as Linus explains here - generally performs worse than the equivalent i586 instructions on modern CPUs. So moving the kernel from i686 to i586 should have no real effect on performance.

I'm sure there will be much discussion on the subject, but I'd like to see some good benchmarks - real data, rather than people reporting that Fedora 11 is "snappier" because it's "Pentium optimized", or "slower" because "the kernel is only i586 now".

PING WITH DATA

Tue, 10 Feb 2009 16:18:15 GMT

If you want to ask a question on IRC, NEVER DO THIS:

<someguy> wwoods: ping

What's gonna happen if I'm not there? An hour later when I get back to IRC, all I know is - you wanted something. I have no idea what. So then all I can do is ping you back, and if you're not around, then we have to keep sending pings back and forth until we're both online at the same time.

An empty "ping" is the same as saying "Can I ask a question?" You just did. Just ask the question.

<someguy> wwoods: ping - what's that blue thing doing there?

Now when I get back to IRC, I can actually answer your question immediately. And if I'm online you'll get your answer right then - no need to spend the extra network roundtrip on a useless ping/pong.

Ping with data - ask the question, mention what you wanted to talk about, whatever. Just don't send empty pings. It's a waste of time.

This has been an Unwelcome IRC Etiquette™ lesson
© 2009 Surly Fedora QA Guy Enterprises, Inc. All wrongs reversed.

python-bugzilla - give me your queries!

Tue, 19 Aug 2008 21:12:57 GMT

I've been working on a branch of python-bugzilla that supports multiple different Bugzilla variants. The current version (0.3) only supports the functions provided by Red Hat's Bugzilla 2.18.x. This branch (which will become python-bugzilla 0.4) adds support for the upstream 3.0 and 3.2 WebServices and Red Hat's shiny new 3.2 instance. (Hooray!)

Yes, I'm sure you've noticed that we've updated to Bugzilla 3.2. Besides the shiny new web frontend there's also new and shiny XMLRPC code for python-bugzilla to use. It still supports the old RHBugzilla stuff, and it now supports all the upstream Bugzilla 3.2 services, but there are some additional new-style methods that will someday make their way to upstream Bugzilla - although probably not until 4.0.

The point is this - I'm trying to get python-bugzilla using the new methods wherever possible. This includes a new and slightly different Bug.search() call, and I want to make sure I can make the switch without breaking everyone's existing code.

So here's my request. If you use python-bugzilla, send me your queries - or just a link to the code, if that's too much to ask - and I will do my best to make sure that your code will work, unchanged, with the new upstream(ish) Bugzilla methods.

I'll update soon to talk about what else is new in python-bugzilla 0.4, but having some real-world test code to work with would be a great boon. Thanks!

Writing Test Plans

Tue, 22 Jul 2008 17:35:36 GMT

Everyone knows what Fedora QA does. "They're the testers. They test stuff." Sure, that's true. But.. what, exactly, do we test? And how?

That's where Test Plans come in. A Test Plan is a document that tells the testers how to test something.

A good software Test Plan should at least answer these four questions:

What special hardware / data / etc. is needed to test this (if any)?
How do you prepare your system to test this? What packages need to be installed, config files edited, etc.?
What specific actions do you perform to check that the software is working like it's supposed to?
What are the expected results of those actions?

Your answers can be short: "get a bluetooth keyboard and yum install bluez-gnome newer than 0.25" answers question 1 and 2 just fine. But they need to be complete and explicit: "Get an appropriate keyboard and install the new packages" is not helpful.

Questions 3 and 4 are answered by Test Cases. A Test Case is a single, specific thing to test - a list of actions to perform, and the expected results of those actions. Depending on how complicated a package or feature is, you could have one Test Case or a whole bunch of them.

While writing a Test Plan, pretend that you have an intern whose job it is to test Fedora releases. This brave, brave soul has a few years' experience as a Fedora user and basic familiarity with using the commandline to configure stuff, install packages, and so on.

Your job is to tell this person how they can test your favorite package or your cool new feature, so they can either a) tell their friends about how great it is, or b) tell you (via bugzilla) if it breaks.

Here's an example Test Case for Banshee, originally written by our own Balaji Gurudass:

Description:
Test loading a Local File in Banshee.
Actions:

Start Banshee

Choose "Import Media" from the "Media" menu

Select "Local Files" from the import source dropdown and click the "Import Media Source" button

Select the music file and click Open

Find the song in the music library and play it.

Expected Results:

Banshee starts successfully

The "Import Media" menu item brings up the "Import Media to Library" dialog

The chosen music file is imported into the Banshee library

The music file can be played and the tracker moves along and shows time elapsed.

This gives us a clear, easy-to-follow way for anyone to prove that a new banshee package does (or doesn't) work like it's supposed to. Or, at least, one small part of it.

So there's an overview of how to write test plans. Currently we're keeping Test Plans in the wiki. There's a section in each Feature Page for a Test Plan, and if you wanted to write a Test Plan for a specific package (or set of packages), you could add a wiki page named "QA/[package] Test Plan". For example, here's QA/Banshee Test Plan.

Next time, I'll talk about why I think this stuff is so important.

preupgrade is not 1.0

Mon, 19 May 2008 21:23:28 GMT

So, yes, preupgrade is in the F8 repos now, and that's nice. But it's not 100% complete and that's why it's not in the menus or anything yet.

The current version - 0.9.3-3 - will fail to boot the installer if your /boot directory is a) on RAID1 (#444497), or b) on your root partition (#446826). These should both be fixed in the next preupgrade release.

At the moment, though, there's a bug that prevents preupgrade from being able to finish any upgrades without a network connection. This is the bug that Greg hit during his preupgrade. Luckily, as he noticed, you can bring up the network in the installer, but you can't use anything fancy - no wireless, no VPN, etc.

This may not be fixable without a respin of Fedora 9 (or, at least, a custom stage2.img specifically for preupgrade). I'm not really happy about it.

Hopefully we can do this right for F10. Sigh.

Translation Halp!

Tue, 01 Apr 2008 22:20:14 GMT

So if you've used GNOME in Rawhide lately you probably noticed this new "About this Computer" thing in your System menu:

That was me! I did that!

The problem is.. those strings need to be translated into all the various languages I don't speak.

Eventually the patches involved will be in upstream GNOME or some Fedora-specific package. And then we can use the magic of Transifex to do the translation properly. But while that's being sorted out, I still need to get those strings translated for F9.

If you can help, please check out this wiki page and add translations for your language.

Thanks a million!

We're intercontinental when we eat french toast.

Sun, 25 Nov 2007 17:29:07 GMT

So today (as with most days) I hit http://planet.fedoraproject.org/ to see what's been going on in the Fedora Community.

The first six posts, in order, were in Spanish, Kashmiri (well, ok, English, but talking about Kashmiri), Chinese, Indonesian (I think?), French, and English.

Fedora might technically be US-based but it's pretty obvious that we are a worldwide community. And that's really cool. It makes us monolingual* Americans feel kind of silly, though.

* Well, OK, I took 6 years of French in high school and 2 years of Japanese in college, but I haven't spoken either language in years.

Fedora 8 - RC3 vs. Final bits

Sun, 04 Nov 2007 15:25:12 GMT

Someone asked in my last post if RC3 was the final version.

The answer is: Nope - we had to do two respins after RC3.

Thursday night we found, filed, debugged, and fixed the fsck-at-boot / rhgb hang at first boot problems (see bugs #357401 and #362721 respectively), completed the fix for #357401 (dmraid+livecd) and then rebuilt all the install and Live images to create RC4 for Friday morning. Friday's rawhide report notes these changes.

During Friday we found and fixed a bug in selinux-policy-targeted where restorecon etc. would screw up at install time and leave you with SELinux non-functional. Once again Jesse rebuilt all install/Live images - creating RC5 - with this change included. This change is listed in Saturday's Rawhide Report.

Once the RC5 bits were built (mid-afternoon Friday) we desperately tried to smoketest them and get them rsync'd to the Raleigh office before 9pm so that we could hand them off to the internal IT guys. (After 9, it would be too late to get it done for Monday, and we'd have to delay the release.)

The bits landed at 8:45pm. All our testing showed that the bugs above were, indeed, fixed. Jesse made the call, got a response, and that was that.

There were heroic efforts from a lot of people in those last two days, and I raise my glass to one and all.

F8 is done!

Sat, 03 Nov 2007 18:57:54 GMT

We got the final Fedora 8 bits handed off for mirroring at 9pm last night. Hooray! When I got home afterward the house was still empty - my wife was out to dinner with some friends - but I poured a celebratory glass of bourbon¹ anyway.

Then the three of them appeared at the door, bearing this balloon:

and sang me a song they made up which I don't fully remember, except that it rhymed "fleece" and "Fedora release".

I have some pretty awesome friends. And a totally sweet wife.

1. Blanton's bourbon is pretty much the best ever. Just look at the bottle! It's like the Holy Hand-Grenade of Bourbons.

Werewolf Calls

Mon, 22 Oct 2007 22:06:47 GMT

Just created the installer test matrix wiki page for Fedora 8 (Werewolf).

Today's rawhide wasn't installable without this updates.img (see here for instructions on using updates.img files with anaconda). Boo. But that bug is fixed, so tomorrow's rawhide should be very close to a first release candidate for Fedora 8.

Spent last week poking bugs on the blocker list - we started the week with, if memory serves, 54 blocker bugs. After a week's worth of tracking down bugs and testing fixes and pinging maintainers and reporters and such, we ended the week with.. 54 blocker bugs. Sigh.

But - good news, dear readers! Today (with help from jkeating, warren, jeremy, notting, and dozens more) we are down to 43 blocker bugs.

Some things were just dropped from the list - as much as I want the fingerprint reader on my thinkpad to work, we're not going to slip the release for bug #311361.

Quite a few things have been fixed - for instance, this bug where pirut and pup would demand the DVD before letting you update your system. Now, when pirut or pup fail to contact one of your configured repos, there's a nice "Edit Repositories" button that lets you enable and disable repositories.

Tomorrow should also bring a new NetworkManager build that restores the ability to connect to hidden wireless networks, adds dynamic WEP support, and other goodies.

Things seem to be going nicely. Hopefully we can clean it all up and hit the November 8 release date. It'd be nice to have a release go out on time for once!

Frozen for Fedora 8. Brace for impact!

Fri, 19 Oct 2007 17:53:08 GMT

Hoorj. So, yeah, we are definitely frozen for F8. Now comes the time when I spend every day staring at the blocker list and poking the bugs there (and the people responsible for them) and trying to make them die. The bugs, not the people.

All in all - and I realize that I'm jinxing it by saying this - the Fedora 8 release process has been much easier than F7, and I think F8 will be a good bit more stable out of the gate than its predecessor.

There's a bunch of lingering problems around the switchover to NM 0.7, but Dan Williams assures us that everything will be awesome by release time. Hopefully this will mean we can start work for making NetworkManager the default for F9.

PulseAudio is still cool, and the KDE guys have quickly whipped up a method for using PulseAudio as the backend for artsd. Things will be saner when KDE4 rolls around - it separates the sound server (like esound, pulseaudio, etc) from the file decoders (like gstreamer). For now, this should work. KDE users, please please please test that out and test it well.

I've got some things to say about Live Upgrades and Automated Testing and other stuff that's kicking around the back of my head, but.. right now I need to poke more bugs.

Rawhide Report

Wed, 19 Sep 2007 14:44:15 GMT

Rawhide's a bit wonky today. XULRunner has finally landed - hooray! - but unfortunately it wants to obsolete firefox < 2.1 and replace gecko-libs. This causes trouble with stuff that uses gecko-libs (like yelp and liferea), and - of course - firefox, since we're only at 2.0 in the repos.

So, skip the 'xulrunner' update until we get this worked out.

Possible rpm badness upgrading from F8Test2

Mon, 10 Sep 2007 19:53:50 GMT

Edit: take this post with a grain of salt - we're currently unable to reproduce the problem, and we've done multiple tests on i386 and x86_64 machines. It may have already been fixed. Still, it's a weird and interesting problem so I'm leaving this here for future reference.

We're tracking down a problem where a fresh F8Test2 install can, after upgrading to current rawhide, end up with no rpm-libs - and thus no way to install packages. Yikes. Luckily it's fairly tricky to hit this bug - we haven't been able to reproduce it on i386, for instance.

As far as we can tell the required sequence of events is as follows:

Install F8Test2 - on a 64-bit machine - with a custom package selection that includes the Development group

This will install rpm-devel-4.4.2.2-0.1.rc1, which (accidentally) includes all the libs that rpm-libs normally provides. The installer will not install rpm-libs, since all the files in that package are already provided by rpm-devel.

Boot your fresh new F8T2 system and notice ~150 new updates.

Install the new updates.

During this upgrade, yum will upgrade rpm (and friends) to 4.4.2.2-0.4.rc1. This new rpm-devel package does not include the rpm libraries anymore, so yum should notice this and pull in the rpm-libs package, to keep rpm working. For some reason, on multilib (i.e. 64-bit) machines, it does not.

After this update, your system would be missing rpm-libs and thus unable to install any packages. So you can't install the rpm-libs package to fix the problem.

Hopefully we'll have this isolated and fixed before F8Test2 goes live. It's pretty easy to work around, if you know about it - just install rpm-libs as soon as you boot your F8Test2 system for the first time - but if your system gets messed up it's tricky to recover.

Rawhide Report

Sun, 09 Sep 2007 15:00:25 GMT

Well, F8Test2 is complete, and the rawhide floodgates are open again. There's plenty of fun and excitement to be had in those new hundred-and-something updates.

The most obvious one is that kernel .169 reboots on startup on some machines- see Bug #283631. I've only tried one machine, but it failed there. Falling back to .164 is easy enough, so it's not that big a deal.

I've actually not seen any success reports with this kernel. If you're doing a rawhide update, you might save some time and skip that package.

Once you get the system booted, you may encounter some flakiness with dbus not starting up, and all dbus-related services thus also failing to start. I haven't tracked this one down enough yet to file a bug, but restarting messagebus seems to let ConsoleKit, NetworkManager, hal and friends work OK.

I'm not sure if this is related or not, but pulseaudio also seems to have trouble finding the ALSA devices now. Again, haven't tracked it enough to file a bug, but be on the lookout (and file a bug if you find a lead on the cause..)

I kinda hate these post-freeze updates. There's so many changes all at once and I'm never exactly sure where to start looking when something breaks. And something always breaks.

Rawhide Report and python-bugzilla

Wed, 05 Sep 2007 23:18:44 GMT

Today's rawhide seems to install just fine, at least if done without a kickstart on x86_64. That's good. I didn't get around to testing ppc, and my kickstart-based install broke somewhere.

I've still got a cold so I'm sorry if I'm a bit vague on details here. I'll be sharper soon.

I've been working on a python module to talk to Red Hat's bugzilla instance - you can get a copy of my git repo like so:

git clone http://wwoods.fedorapeople.org/python-bugzilla.git

The Red Hat XMLRPC stuff is a lot more featureful than the upstream bugzilla 3.0 web services. On the other hand, the upstream stuff is much cleaner. I'd really love to get some work done to get the RH stuff cleaned up and moved upstream so everyone could benefit. I think the RH bugzilla team is planning on doing this "soon" - but that's "soon" in RHEL terms, which means, like, early next year maybe. Sigh.

Anyway. If you've got patches or suggestions for my bugzilla module (I'm sure it's not the best code ever - I'm still getting to know python) I'd love to hear 'em.

Rawhide Report

Tue, 04 Sep 2007 22:15:46 GMT

Well, rawhide has installer images again today. Hooray for that. Unfortunately something about current rawhide keeps it from working right in KATE, our venerable installation test system. I'm told that manual installs work properly though.

I haven't done any manual installs myself because I'm out of the office with a nasty head cold. I can work for about two hours before I get all fuzzy and unfocused and I have to go nap for a while.

It appears that dbus has grown a dbus-libs package, and that's why upgrading to dbus-1.1.2-3 made my systems freak out - it didn't require its own libs! dbus-1.1.2-4 fixes this.

fonts-japanese-0.20061016-{8,10}.fc8 have broken %postun scripts, which prevent them from being installed. This would be merely cosmetic, except fonts-japanese...-11 requires the new sazanami-fonts packages, which conflict with fonts-japanese older than -9. So if you want to upgrade your japanese fonts, you'll need to do something like:

# force-remove the old fonts
rpm -e --noscripts $(rpm -q fonts-japanese)
# manually install new ones
yum install fonts-japanese

Rawhide Report

Thu, 30 Aug 2007 16:23:19 GMT

Today's rawhide: not installable. stage2.img is missing a whole bunch of stuff, so anaconda won't start. Still, at least we got updated packages pushed.

As far as I can tell mkinitrd still doesn't work right. Avoid updating to 6.0.12-1 or 6.0.12-3. Don't know of a bug number offhand; I should file one and attach it to the F8Test2 tracker. At least bugzilla's a lot happier today.

Depchecking for updates

Wed, 20 Jun 2007 23:26:32 GMT

I had a quick conversation with skvidal and notting earlier about how we should be handling dependency checking on new updates. Right now, I'm supposed to be packing - I'm going to visit my wife's family in Panama City, Florida. Ah, a weekend at the beach. Except I can't concentrate now. Can't.. stop.. thinking.. about.. depchecking! Argh! Must braindump!

# 'provides' = literal provides, filelist, name/ver
#

# get a list of oldpackage's provides & requires
oldprov = get_provides(oldpkg)
oldreq  = get_requires(oldpkg)
# get a list of newpackage's provides & requires
newprov = get_provides(newpkg)
newreq  = get_requires(newpkg)

# also check obsoletes! quoth skvidal:
# if NewA obsoletes pkgB 
#     then make sure nothing Requires pkgB but not provided by NewA

for obspkg in newpkg.obsoletes:
    oldreq.append(get_requires(obspkg))
    oldprov.append(get_provides(obspkg))

# Now that we've got the old and new lists, find the diffs
dropped_provides = [p for p in oldprov if p not in newprov]
new_requires = [r for r in newreq if r not in oldreq]

# And find the affected packages
willbreak = []
for dropped_prov in dropped_provides:
    for pkg in whatrequires(dropped_prov):
        willbreak.append(pkg)

missingdep = []
for new_req in new_requires:
    if not whatprovides(new_req):
        missingdep.append(new_req)

Yeah, something like that. Okay, now I can go to the beach. Yay!

Blarg!

Tue, 19 Jun 2007 21:39:27 GMT

Yeah, I'm bad at updating my interblag. Sorry about that.

So I've been trying to put together a small tool that does depchecking (so we can stop having updates go out with missing deps, like the recent F7 kernel update) and finding a clever way to integrate this with bodhi.

Ideally we'll choose a well-defined test reporting data format (there's a bunch out there) and write a test result aggregator thingy for Beaker. Then we'll give bodhi a little widget that shows per-package results from Beaker.

Unfortunately I got distracted for most of the day chasing down a problem with crond and selinux-policy-targeted-2.6.4-17.fc7. I think I got all the right info to the right people, so that should get worked out before we release new selinux-policy packages.

Anyway, for the depchecker I need to figure out how to properly enumerate a package's Provides: entries. A package can have explicit Provides, but it also provides each file in its file lists, and its package name, and its package NVR.. and maybe there's other stuff too?

I've gotta go read some more yum code and figure this out.

bug herding

Tue, 22 May 2007 03:58:27 GMT

So here we are, 10 days from the release of F7. Things are looking a lot better now than they were a week ago - the blocker list is down to a mere 27 bugs. A bunch of those have fixes that will be appearing in rawhide tomorrow. We might actually get this thing done in time.

Jeremy whipped up a fix for system-config-soundcard so that it wouldn't crash firstboot on my 12" PowerBook (or any other machine using snd_powermac.. like most PPC Macs, I think). The weird bug where the screensaver unlock dialog didn't appear (so it looked like your system had crashed) is fixed. There's a fix for the glibc bug that makes emacs crash that seems to work nicely, although I'm not sure it'll make tomorrow's push.

As of the next rawhide push, both mkinitrd and anaconda should be using mdadm to assemble arrays by UUID now, instead of by device name. That's good, since the F7 kernel changes everyone's IDE device names. This'll close a whole bunch of blocker bugs, and let people using RAID on IDE upgrade from FC6. Yay! I'm not real happy with only getting 10 days to test such a change, though. If you can help test this at all, I'd be in your debt.

iwlwifi still isn't as solid as we'd like, but as far as I can tell it's not crashing people's systems anymore. As much. Maybe.

So yeah, that's about where we're at. 10 more days. Let the fun begin!

An argument for Free Software

Wed, 14 Mar 2007 21:58:04 GMT

A friend of mine asked me this question:

Do you believe that open-source software (and operating systems) will be adopted on a large scale by the mass of average computer users, and if so how long do you think it might take?

My response is below. I know I'm preaching to the converted here, but I'd still like to know what you think. And maybe it will be useful to some of you when you end up having similar conversations with your friends and family.

In a nutshell - I think that Free Software is the only reasonable choice anyone could make, and that Linux (or something like it) would already have taken over if we were actually given a choice. But despite Microsoft's evil, anticompetitive business practices, I believe Linux (or Free Software in some form) will replace Windows on the average person's computer within ten years. There's three big reasons that I believe this is inevitable: the technology is better, it's the socially responsible thing to do, and - come on. It's free.

I won't sugarcoat it: if you've tried to use Linux in the past, you might question whether the technology is actually any better. I'd say the current state of the Linux desktop is something like Windows 2000, which is to say: fine for 90% of the world. But here's the thing: it's evolving much, much faster than Windows did, or ever could, because the Free Software development model is just plain better. It's so obvious! If anyone can read the source, bugs can be traced and fixed by anyone with the appropriate skills. Since all the documentation and tools are also Free, the appropriate skills can be learned by almost anyone with some time and effort. Software developed this way will inevitably be more reliable and improve much faster than stuff developed by small, closed groups working in secret.

This isn't just theory - the concept has been proven time and time again. In fact it's the foundation of the dang Internet. The only reason the Internet exists is that everyone is using the same freely available, agreed-upon standards. Want to know how a web server works? Here is the reference for HTTP. And so on. The Internet is already run almost entirely on Free Software.

The desktop, on the other hand, is being held hostage by a vastly rich global corporation with an illegal monopoly on the market. Apple has proven that a home user can be not only satisfied, but delighted by a computer based on an Open Source, Unix-like OS - if you have the cash for their hardware. The rest of the world is stuck with whatever comes on their computer, which is nearly always Windows.

So why do computer makers sell Windows? Simple economics would seem to point to an inevitable triumph by Free Software: 'free' is always cheaper than whatever Microsoft charges for Windows. Interestingly a couple of Harvard Business School researchers did some formal modeling of the situation, and their model predicts that, because of Microsoft's "first mover" advantage (i.e. illegal monopoly control of the market), simply having better software at a cost of $0.00 is not enough for Linux to completely replace Windows. You'd also need to have another factor, such as strategic buyers (e.g. entire corporate or government entities) switching to Linux.

This has already started happening, all over the world.

So yes, for those two reasons, I believe the triumph of Free Software is inevitable. But the most compelling thing to me - the reason I work for Red Hat - is the social and political implications. Nobody prefers closed-source software, in the same way nobody wants DRM. Would you buy a car that had the hood welded shut? That would only drive on Ford-approved roads? That could only be serviced at official Ford dealerships? Would you allow those dealerships to charge $40,000 for (or flat-out refuse) an oil change if your car was older than 2002, demanding that you buy a new car instead? Oh, and the new car comes with a special Ford stereo, which will only play special RIAA-approved CDs. Dear God no. Nobody wants this.

In sharp contrast, everyone in the world who's got a copy of Fedora can do whatever they want with it, without restrictions, forever. Make and distribute music, write stories, do business, whatever. If something's broken, you can fix it, or find someone who is sufficiently capable and have them do it. Even better, every improvement is shared with every other user in the rest of the world, for free, forever. Nothing is patented, there are no hidden traps - no company can ever start demanding money for any part of it. Places like the FAA and Orbitz pay Red Hat to make Linux stable for them. Red Hat pays people like me to work on making Linux better, and anyone with a computer, anywhere in the world, can benefit from my work, for free. Millions of kids worldwide will soon be doing just that.

Free Software grows without bounds and without restrictions and can never be shut down or go out of business. It's just so obviously and powerfully the Right Thing to do for the benefit of whole damn world.

And did I mention it's free?

Bugzilla and you

Fri, 26 Jan 2007 18:22:51 GMT

You may have noticed a bug involving Comps in FC6 yesterday. Basically, a typo in the comps.xml file on the mirrors confused yum, and caused it to crash. Whoops!

So someone fixed the typo and katzj fixed yum so it would fail a little more gracefully. Hooray! Problem solved!

Well, no. The bad file was still on the mirrors (they get resynched once per day), and the new yum code is just in CVS. So all day yesterday, anyone who tried to run pup, pirut, or yumex would get a traceback and a message asking them to report this on bugzilla.redhat.com.

Which they did. In droves. At last check, we had closed 75 different reports of the bug as duplicates of the one above, and we're still finding more now. And while it's kind of a pain to close all those duplicates, it's amazing that so many people - probably hundreds, all told - were willing to take the time to actually fill out a bug report.

So - a big "thank you!" to everyone who took the time to report the bug, even though we already knew about it.

Anyway, this entire thing brings me back to the idea we keep kicking around for a fedora-bug-buddy - basically something that would help people file bug reports. This is a tool that would help people answer questions like:

What product and version should I file this under?
This bug got filed against Fedora Core, Fedora Extras, and a couple of them were filed as Extras Review Requests. Sometimes it was filed against FC6, a few were FC6Test3, and some were devel. This is something that would be really easy for fedora-bug-buddy to figure out - all you need to do is check out /etc/fedora-release and it will tell you what version you are running.
What component (i.e. package) should I file this under?
We saw this comps bug filed against packages like oprofile, star, 915resolution, yum, yumex, and pirut. (For the record - it was a yum bug.)
Hooking into GNOME's bug-buddy would help a lot here, but it would also help if we had some explanations of where some trickier bugs should go (e.g.: bugs with suspend/resume should be filed against pm-utils.)
How do you know if someone has already filed this?
Face it - bugzilla searching is not all that easy, and it's especially hard if the bug is misfiled. But if fedora-bug-buddy presented you with a list of common bugs - either hand-picked by us QA types (like this list) or automatically generated (like this) - it would go a long way towards reducing duplicate reports.

So, yeah, that's something that would be awesome for Fedora, and probably any other distribution that uses Bugzilla.

But for now, it's back to testing F7Test1. It's going to be released Tuesday! Yow!

Wiimote fun!

Tue, 12 Dec 2006 17:00:29 GMT

So, in addition to various QA-style things, I've been messing with the remote from my shiny new Nintendo Wii¹. Apparently, the Wiimote communicates with the Wii over a plain, unencrypted Bluetooth connection, which means you can pretty easily talk to it using the Linux bluetooth stack. Pressing 1+2 on the remote causes it to become discoverable - you can then do:

[wwoods@metroid wii]$ hcitool scan --flush
Scanning ...
        00:17:AB:29:7B:2A       Nintendo RVL-CNT-01

And there it is - my Wiimote!
The enterprising hackers at wiili.org are putting together a fairly comprehensive guide to communicating with the Wiimote. They've even got a working mouse driver for it! Unfortunately, that driver requires pybluez, which is not yet part of Fedora. So I've submitted it for review for Extras.

I also started writing my own python wiimote monitor, which is a bit cleaner than the wiili.org one (1/5 the size, actually). To work with the pointing functionality (which uses the IR camera at the front of the wiimote), I built a substitute sensor bar with $5 worth of parts from Radio Shack:

Amazingly, it actually works. Next we'll see if I can learn enough pygtk to show the button status/accelerometer force/pointer position in a graphical format, rather than:
........... force=( -2, 0, 0) dots=(( 278, 515),( 699, 482))

¹After weeks of trying to get a Wii, someone at my wife's office mentioned they had an extra on the company email list. She ran out of a meeting to get it.
I knew there was a reason I married that girl.