I just noticed the super-awesome PulseAudio guys (Lennart and Colin and others) guys have set up profile switching for PulseAudio. The credit for this one seems to go to Colin - that's his post on the topic. I ran pavucontrol just now and noticed the tab has showed up, for Fedora Rawhide users anyway. As a super extra added bonus, when you use it, nothing crashes, and it works! Finally, a vaguely sensible GUI for switching between the analog and digital output modes of my Chaintech AV-710. The previous method was, um, to create a custom ~/.asoundrc file, which you had to Google about for instructions on. Not optimal. So a big thanks to the PulseAudio guys for that.

I just saw the Dutch baseball team (yes, Dutch readers, you have one!) beat the Dominican Republic (stacked with MLB all-stars) for the second time in a week. That's so ridiculously improbable I don't know where to start. Good on 'em. Great team play, amazing pitching.

I'm currently doing less work than usual, as I'm on an experimental remote learning RHCE training course for four hours a day. It's quite interesting, actually.

We touched on kernel modules today, briefly, and I noticed that when looking through the output of 'modinfo', the instructor skipped straight over all those icky 'alias' lines. This reinforces my suspicion that I'm one of the few people who vaguely understand what the heck's going on there. It's actually a rather a) important and b) cool subsystem, so I think it's nice to know about it.

Most of the useful information about modaliases can be found in this excellent article in the Arch wiki. Basically, a modalias is a way of representing important information about hardware attached to the system.

What's not entirely obvious from that page is why this is important to you. It's important because this is how modules get automatically loaded to support your hardware, that's how! That's what those 'alias' lines in the output of modinfo do. Let's look at one:

[root@adam pci0000:00]# modinfo ssb filename: /lib/modules/2.6.29-0.203.rc7.fc11.x86_64/kernel/drivers/ssb/ssb.ko (...) alias: pci:v000014E4d00004329svsdbcsci* (...)

(There's lots, for most modules, there's just one). These are coded into the kernel modules, and updated by the authors each time they add support for another bit of hardware. They take the same format as the actual aliases for bits of hardware, except that * is a wildcard. So that alias means that the 'ssb' module supports any bit of hardware with the PCI ID 14E4:4329 (which is a Broadcom wireless adapter). All the other bits of the modalias are filled in with * to indicate that it doesn't matter what they are.

Let's look at another style. If you look at the output of 'modinfo usb-storage', you'll see quite a lot of lines like this at the top:

alias: usb:vpddcdscdpic08isc06ip50*

Here, we're not caring about the device ID (USB ID in this case) - all the ID fields are wild-carded out. Instead, what's specified are the ic, isc and ip fields, which together identify a class of devices. There's quite a lot of these lines, as I said, which together cover all the 'USB mass storage' class IDs. So, the usb_storage module supports any device which identifies itself as being in the USB mass storage class. (There's some device-specific IDs further down the modinfo output. These are corner cases for broken or quirky hardware, I think.) You'll see similar aliases in, for example, the snd-usb-audio and uvcvideo modules, thanks to USB having standard interfaces for handling audio and video devices, and classes for these devices.

Aliasing a module simply tell the module tools - like modprobe - to poke that module when they're called with the alias. You can just edit /etc/modprobe.conf, add a line:

alias usb_storage foobar

and run 'modprobe foobar', and the usb_storage module will be loaded. Modaliasing takes advantage of this. As we just saw, modules have aliases representing each bit of hardware they support. When udev comes across a hardware device, it simply runs modprobe on the device's modalias. Thanks to the aliases written into the modules (actually, these are dumped into /lib/modules/uname -r/modules.alias each time 'depmod' is run, they're not read directly from the module files themselves by modprobe), the correct module is automatically loaded.

Well, that's how that works, anyway. I think it's rather elegant.

So, we've got a bit of a hard sell: this week's test day is on the thrilling-sounding topic of...block devices. Please, try and stay awake! This is more important than it sounds :). Block devices are, to a basic approximation, what your Fedora install goes onto - your hard disk, or RAID array, or LVM volume, or whatever it is. The handling of block devices in Anaconda - the Fedora installer - has been rewritten for Fedora 11. So we really, really need to test it.

Here's the thing. If it works, nothing exciting happens, and you'll never really notice. All it means is that your install works, as you'd sort of really expect it to. However, if it breaks, we're totally stuffed, because your install isn't going to work. So even though this is not something super exciting and sexy, we really need people to come out and help test, because we need to test with a wide range of hardware and configurations to make sure we didn't break something really badly. It shouldn't be too hard to do testing, all you'll need is a spare system or partition to do a few Rawhide installs onto - we don't really care if the installed system works, we just need to make sure the stage where the Fedora partitions are created works properly and the install can succeed from there (or, at least, breaks for some reason entirely unrelated to the block device support rewrite). You can do useful testing with a small chunk of spare space on any machine, or even in a VM. So please, please, everyone - Red Hatters, l33t Fedora hackers, and people who are just reading this for the incisive Canucks analysis (go Alex!) and don't have a clue what Fedora is - come out on Thursday and help us get some testing done. There'll be developers and QA folks around to help you out with what exactly we need to test, so please just show up in #fedora-qa - see how to use IRC - and ask how you can help. Thanks a lot.

Harald Hoyer, the main developer working on improved boot speed for Fedora, posted a great follow-up explaining how the results received from the test day helped to identify areas for improvement - it's a great way to see how testing helps the developers. Thanks again to everyone who came out!

Had another of those "oh, dear, what WERE they thinking?" moments the other day. Walking back into my building I noticed a car parked up outside (probably a visitor as I'd never seen it before, I would've remembered...). Typical Vancouver ricer car - TRD (Toyota Racing Development) decals, bucket seats, custom muffler, all that stuff. Except the poor kid obviously hadn't really had enough money to go with the car of his (almost certainly his) dreams...seeing as how it was an Echo, the name under which the Yaris was sold in Canada for a couple of years. Forget a Celica or Supra or something, you couldn't even manage a frickin' Corolla? Come on, man.

Great game by the Canucks today, it's getting to the point where I can actually watch games without needing something to cringe and hide behind again. Well, hope that hasn't jinxed things.

This week's test day is on Crash Catcher, a new feature which will allow you to submit automatic bug reports when packaged applications crash in Fedora 11. If people could come along to help with the testing, that would be awesome. This is a new feature that will be showing up in Fedora 11 and will be very visible, so if you want to make sure it's not going to annoy the hell out of you, come to the test day and tell the developers how it should work! Test days take place in the #fedora-qa IRC channel on the Freenode network - see How to use IRC if you don't know how to use IRC yet. This one will run from 12:00 to 20:00 UTC (7am -> 3pm ET).

There's a Wiki page for the test day, which explains all this information, plus how to test that the system is working as expected. If you have any questions about anything, let me know.

Sorry I haven't posted about work much lately, haven't had time - had quite a lot of non-work stuff to do lately.

So, last Thursday we had the 20 Second Startup project Test Day. It went really well, which was great. We had a good turnout of people both from inside RH and from the Fedora community, and got a good set of test results. Harald was a superhero in sticking around for 18 straight hours, and he was able to make some useful changes based on the data we got, so it was definitely a productive day. Thanks to everyone who came along and contributed test results, and please continue to come to future test days, and consider helping out with other QA projects!

Have to mention Fred Crozat's Speedboot project back at Mandriva, in this context. It looks like the logical progression in boot time improvement and his preliminary results look impressive. I meant to try this out over the weekend but didn't get time in the end. I pointed it out to Harald, and he said he's been thinking along very similar lines, so something similar may come into Fedora in the future.

No, not software, the real kind.

There was a wonderful line in this week's Guardian Weekly, in a review by Stephen Bayley of the Royal Academy's show on the great classical architect Palladio. Bayley writes "I bumped into Robert Adam, Britain's leading 'traditional' architect, carefully taking notes. I asked him what Norman Foster could learn from all of this. Adam said: 'Fuck all!'"

Concise. :)

I read with interest that Google has come up with yet another incredibly clever invention.

It's an email client application. You're with me so far, right? Using this application you can access mail stored on a mail server, and send emails to other people. Now that's already pretty damn nifty in my book! Jeez, what will they come up with next, etc, etc. But that's not the best part. The incredible bit happens now. Oh yeah. This new email client application can actually store the contents of some of the emails in what's called a "memory chip" on your device - stop me if I'm going too fast - so you can read them even if you don't have an Internet connection! Now, how cool is that? But wait, there's even more. You can write an email and then click the Send button. If you don't have an internet connection, instead of showing you an error message, the application will store your email on the "memory chip", and then send it out when you get online.

Wow, those crazy cats. I never would have thought such insane black magic would be possible. I know! Let's call it the 'Local Cloud!'

Unsurprisingly, Engadget is really impressed.