I just love that I get paid to mess around with fun crap. I've had 'package navit for Fedora' on my todo list for a week or so now, so today I decided to get down to it. It was quite easy to convert my Mandriva package to a Fedora one, but then I had an itching to make sure it really worked for myself (before I just had someone else test it). But to really test it, I needed a GPS input.

Well, my phone has GPS. Surely it's possible to turn a Windows Mobile phone with GPS into an external GPS receiver for a Linux computer, I thought. (Why yes, I am a natural optimist). Proving that there really isn't anything you could try to do with a computer that no-one else has tried before, indeed it is, and someone has been there before - thanks a lot to the author of that blog. I threw the system he outlined there together, and with a bit of trial and error, confirmed it was working - xgps shows my location. So I downloaded the latest openstreetmap snapshot for Canada, added it to my navit configuration, fired up navit, and...here's the result!

There's Navit, showing you where I live. Excellent. I just love that I get paid to do this stuff. :)

Navit package for Fedora should go into review soon!

Ladies and gentlemen, I present for your delectation and delight Mr. Conrad Meyer's fine refutation of yet another overstretched car analogy:

"Did a bunch of hobbyists from around the world build your car by communicating over the internet? If so, I think it would be safer to stop driving immediately (EBADMETAPHOR)."

Well, a quick update on Fedora stuff. I've mostly been working on a few things: the Common bugs page for Fedora 11, the triage metric script being written by one of the Bugzappers which is now up and running and producing its first results, and the priority / severity proposal for Bugzappers which is now almost in place. Recently, though, I talked to jlaska about getting the Test Day cycle for Fedora 12 up and running. We'd like to start pencilling in events so we can organize a few things around the schedule. So, if you're a Fedora contributor and you'd like some testing done for something you're working on during the Fedora 12 cycle, please get in touch with me or James or anyone else from QA and we'll see what we can do about getting things in motion. Don't be shy!

In a move that would give the honourable Will Woods paroxysms, today I upgraded my HTPC from Mandriva 2009 to Mandriva 2009 Spring. Live, with urpmi. Over an ssh link. While the media center it runs (Freevo) was still running in the foreground.

...playing a video.

Well, the upgrade happened, the video kept playing, and Freevo continued to work happily after the upgrade was done and the video had finished. Try THAT with Windows. (I did lose the remote control until I rebooted...inexcusable! Who's the lirc maintainer again? Oh, er, right - me.)

On reboot, though, my RAID array had disappeared. With help from the awesome zcat in Fedora IRC, we determined that it was something to do with RAID-related changes in udev - it had somehow created one array device for each drive that was part of the real array, and these arrays were in some sense running (though obviously they didn't work for anything). mdadm -S /dev/md_d12[5-7] - to stop those odd arrays - then re-starting the real one turned out to be the trick. Never would have figured that one out myself in a month of Sundays. However, the real array came up degraded, with one disk being reconstructed from scratch. I'd already noticed some suspicious errors relating to that disk in the logs, so it got the old heave-ho, I ran down to Crystal Mall to pick up a new one (500GB for $65...sheesh, we're living in the future. Hell, I bought a 16GB micro SD card for $60 while I was there. 16GB. It's smaller than my frickin' thumbnail...), threw it in there, and now the array's building that drive into itself. That'll take all night. Ah, well - at least I didn't lose my data, and that was the point of the whole RAID-5 array exercise in the first place. So that's done its job.

(the failed drive was a Seagate 7200.11, for anyone keeping track. Yes, of the OEM variety. And yes, I bought it on May 3rd 2008, or just over one year ago, or just after the one year shop warranty on OEM drives expired. Sigh. Replaced it with a WD, since that's what the closest shop had on hand.)

Please take five minutes to learn the difference between:

LOSE and LOOSE REIN and REIGN

that is all. Thank you.

So, this week I've got to do something I'm pretty familiar with!

We've been working on the Fedora 11 Common Bugs page. In my Mandriva days, I worked a lot on the same page, which is known as Errata in the Mandriva universe. Here is my magnum opus - take that, Dan Brown. The Fedora 11 page hasn't hit such heroic lengths yet, and hopefully won't :)

So, we want everyone involved in Fedora to take the Common Bugs page to heart. Why should you do this? Here's Several Awesome Things about the common bugs page:

1. You - a Fedora user - can find out what all the known gotchas for Fedora 11 are in one place. No picking through mailing lists or forums - just take a quick peek at the page before you take the leap into Leonidas Land.
2. You - someone who helps other Fedora users - have a handy reference point for all the known gotchas in Fedora 11. No longer will you have to explain the same three issues five times a day! Each entry on the Common Bugs page has a handy anchor link titled "link to this item" which will never change. Just copy and paste that link, and move on with your life.
3. You - a user or a helper - can make life easier for other users and helpers. Just add any issue you come across more than one person getting hurt by onto that page, and it'll make it much easier for others to find out about the problem before it causes them a lot of pain.
4. You - a Fedora developer - can find out easily if there's any commonly-encountered bugs in a package you're involved with, and you can find all the information and a link back to the bug report right there.

Obviously, you now agree with me that the Common Bugs page is the best thing since sliced bread or the indoor toilet. So, how can you help?

It's really easy - everything you need to know to add an issue to the Common Bugs page is right there in the page source, as a comment. If you edit the page you'll see a few chunks of comments which explain how to add an issue (including a template entry), and what else to do when adding one (it's a good idea to make a few complementary changes to the bug report). And don't worry about getting it a bit wrong - several of us in QA and other groups have a watch on the page, and will check new entries and tidy them up if anything's out of place. The important thing is just to get the information down there, the formatting can always be tidied up later.

If you really don't want to edit the Wiki (or sign up for a FAS account so you can), you can just let anyone in the QA team know - via email, IRC, mailing list, blog comment, anything you like - and we'll get it done. You can also mark bug reports in Bugzilla with the CommonBugs keyword to indicate you think they should be mentioned on the Common Bugs page; I'll search through bugs with this keyword every so often and add any appropriate extra issues.

For triagers, when following up on reports, if you notice it has the CommonBugs keyword set, try and update the entry on the Common Bugs page with any significant changes to the bug (for instance, if a new workaround is discovered, or an update released). Or just notify someone in QA of the change and ask them to update the page.

And for everyone - try and refer to the Common Bugs page whenever you tell anyone about Fedora 11. I've found it really helps reduce frustration when you know about a resource where you can learn about common bugs that may affect you, and how to work around them. Without such a resource, people might hit a bug which has a simple explanation and workaround that they're just not aware of, and get really frustrated or wind up avoiding Fedora altogether. Common Bugs can help avoid this. Use the force!

I have mixed feelings about Wikipedia, but one thing that's wonderful about it is it feels exactly like Gopher, or the very early web, used to. It's just a big bunch of little essays on different topics, chained together with links. So I went on one of those little chain surfing excursions that Wikipedia encourages, and that I used to do all the time back in 1994 or so - from yet another highly charged debate on fedora-devel-list, to the Wikipedia entry for Wolfenstein 3-D, to the page on Doom, back to my old stomping grounds - Compet-N. Yeah, I guess the few people reading this now wouldn't know that, in a former life, I was one of the top five or so ranked Doom players in the world :). I was unreasonably happy to see that people were still sending in new demos. Compet-N is / was a site where people competed to record the fastest times for completing levels under various conditions, sending in recordings - 'demos' - of their efforts, known as 'speedruns'. It's probably the oldest still-vaguely-active speedrunning site in the world. There's a new guy I hadn't come across before called Guillaume Pierson, and at least one guy I remember, Chris Ratcliff, still sending in stuff. It's somehow reassuring to see people still sending in runs of the same set of 68 levels that have been competed over since 1993/1994.

So I couldn't resist - I installed prboom, grabbed my Doom Collector's Edition CD from the shelf (next to my still-intact original CD copy of Doom 2...), put the main data files back in the right places, and watched Guillaume's n4s4-050 (Doom 1, episode 4, level 4, nightmare skill with 100% secrets found, 0:50 - compet-n has a very neat compact naming scheme), and went back in time ten years to when I'd spend the wee hours of the morning blowing away the same enemies in the same order, over and over again, to try and get to the exit a second faster than the last guy. Good times :). Guillaume looks to have a nice smooth style, and I was both happy and faintly worried to realize that I still remembered exactly how to complete that run. Guillaume's demo, of October 2008, beats the previous record of Adam Hegyi (one of the best speedrunners ever), by one second. Adam's run was recorded in June 1999. And as far as I can tell, my oldest record - p2m1-039, also June 1999 - still stands...

Wow, this is big news. No drivers yet, but the Linux Drivers Project have their name on it, and I trust those guys.

A while back I wrote about adding extra displays via a USB video adapter, on my old laptop. Long story short - it's hard as nails, and the results were fairly crappy, and it's not possible any more anyway with most laptops since the move to RandR 1.2-based drivers for intel, radeon and nouveau.

If you need more monitors and your graphics cards are all maxed out, DisplayLink really is the best option these days. You can get a USB video adapter based on DisplayLink, or just monitors with DisplayLink baked in which plug straight into a USB port. DisplayLink does a lot of special-sauce compression to get pretty decent performance for most operations over the USB link. It's a good technology. But, for a long time, it's had no Linux drivers, so you just couldn't use DisplayLink hardware on Linux at all. Once this project bears some fruit, it'll be really nice for people who want a couple of external monitors connected to a laptop (or netbook!), or the other various use cases for this. Nice to see it at last.

This also came up as one of the more dubious bits (to my mind) of Bryan Lunduke's "Why Linux Sucks" talk I wrote about a few posts back.

I don't understand why this debate won't go away and die already, because it's fundamentally silly, as anyone who's actually bothered doing any packaging knows. Why don't we have a common packaging format? Because we don't have a common distribution.

Look, there's nothing particularly important about a packaging format per se. Fedora, Mandriva, OpenSUSE, Alt Linux, PCLOS...they all use RPM, but that doesn't mean you can somehow magically use any RPM package without any problems on any of those distributions. It's the same with DEB packages - you can't magically be sure that any given DEB will work on Debian, Ubuntu and any other DEB-based distribution out there. Anyone who's looked at the OpenSUSE packaging guidelines, for instance, and compared them to the Mandriva or Fedora ones, will know that there's a huge difference between a 'good OpenSUSE package' and a 'good Mandriva / Fedora package'. Even though they're both in the same format.

Packaging, essentially, is simply providing software in a form that complies with the policies for the distribution into which you're packaging it. The package format itself plays a pretty minor role in this. If you believe that you'd suddenly be able to install anything you like on any distro if only RPM distros would adopt DEB or vice versa, heads up: you're just wrong. This is not a point of view that's up for debate, it's a simple, objective fact, which is easily verifiable just by learning a little bit about what packaging actually is, and how it's done on all the different distributions. So the fundamental tenet at the base of the 'we need a common package format' argument is simply invalid, which is enough to make the argument just a giant waste of time.

Those who make the argument need to step back and look at what it is they actually want. Usually, what some want is a world in which there's only One True Linux Distribution that everyone uses (so they don't have to worry about learning about the repository system to get packages), in which case, you might want to fill in a "I want a pony" feature request. It's not happening, it's never going to happen, get used to it. If you either want One True Distribution or bust, then I advise you to go out and get a Mac already.

What others want is something that would actually be achievable, which is a unified system to make it easier for third parties to independently provide self-contained software packages for various distributions. This is a valid desire, and something that could be done. The error is just in imagining that the way to go about this is to force all distributions to adopt a common package format, as if that'd somehow magically solve the problem (here's a hint: it wouldn't).

The most appropriate way to address this problem is fairly simple. Just write a decent distribution-independent software delivery platform. There's absolutely no reason why third parties have to deliver software to Linux users in the native package format of their distribution, and many don't. Many just provide a tarball or a binary installer, and there's nothing wrong with that. If you want to do it really snazzily, though, what you want to do is design the App Store for Linux, or Steam for Linux, or something like that. It would be perfectly possible to implement such a thing in such a way that the client (or multiple client apps! why not?) could be made available on all distributions. It could install everything to /opt or /usr/local in the filesystem layout of your choosing (go to town, people who want OS X-style hierarchies or whatever). There's no reason at all for third party application delivery to be done in the same way as first party package delivery, it's perfectly sane to have two systems.

There have already been attempts to do this sort of thing, like Autopackage. Most of them have failed, probably because they weren't very well designed or maintained. But there's nothing intrinsically wrong with the concept. Fix up one of the existing implementations or write a new one, get some buy-in from major third-party application providers for Linux (how about Google?), and then get the users on board - shouldn't be too hard.

So I built the mesa GL libs from Ubuntu and tried 3D acceleration and it still doesn't work. Not really sure why. Might just be that I need to rebuild things in a different order, I'm thinking about it now. I'm hoping to get the 3D acceleration working as I suspect using Compiz might give better overall performance, letting the graphics chip handle the window management...moving windows around and stuff is pretty slow at present.

Still haven't tested the video playback stuff.