If you follow my blog you may have detected I'm not a big fan of Google in some ways, but they do get some things incredibly, awesomely correct. (Like, of course, basic search, which is the big thing they got incredibly awesomely correct, and the main reason they're now very rich). One of these things is Google Maps for mobile. Having a nicely designed Google maps app for your phone is neat enough, but it has for me one absolutely killer feature - walking and transit directions. I don't drive, never have, probably never will. Luckily I live in Vancouver, where the transit is really good (people in Vancouver who've never left don't believe this; I tell them to go to any mid-sized American city and try getting *anywhere* on the bus). Google's quite recently started integrating transit information in many cities, including Vancouver; Google maps has basically the schedules for the entire Greater Vancouver transit system programmed into it. So, this morning I woke up at a friend's house in Burnaby, with only a vague notion of where the hell it was (someone drove me there, I don't ask questions). A year ago I'd have had to find out the address then fight with Translink's hideous trip planning site to find out how to get home. It's got a crappy interface, it's horribly slow, and it gives you your final directions as a text list with a tiny, ugly, static map attached. Woo frickin' hoo. I hated that thing. Ten years ago I'd have...well, I'd have had to ask someone. Who probably wouldn't have known either. Then I could have either called up the transit company's information line (at 6 a.m....heh) and waited for hours, or found out it was closed, before trying to understand and write down the information. Then I'd probably have got lost and taken random buses until I found one that I actually knew. (I've done this in the past.) Instead, I ran Google maps on my phone, hit menu / get directions, told it to start from wherever the hell I was (GPS integration makes this whole thing ten times more awesome), and wind up at the Skytrain station by my house. It promptly spat back the next three possible journeys, complete with walking instructions to the bus stop. It shows the route as a blue line on the map. I followed the instructions then just sat back and watched the two buses that took me home go whizzing along the little blue line. It even makes it easy to know where to get off a bus you've never taken before. If you look at this technologically speaking it's easy to lose the awesome. I mean, it's just a simple combination of a few bits: GPS, 3G data, and Google's map and transit information. But the use of it is just so freaking awesome. I've only been using this setup for a couple of weeks and I'd already hate to live without it. I mean, I've got a little box in my pocket that can tell me how to get to anywhere in the metropolitan area, from wherever the crap I am, and plot it out on a really nice map, then show me moving along that map as I go. That's the future happening. Tell people twenty years ago you'd be able to do that in the future and it'd be the best thing ever. Now it's just a little niche use case for technologies everyone's kind of used to already, but that doesn't mean it's not really amazing, if you keep a sense of perspective about it. So, thank you, Google. And GPS. And transit authorities of the world.

Slashdot does give you a good laugh sometimes. There's an interesting story there about music copyright infringement back at the turn of the 19th/20th centuries. The story mentions that the publishers fought the infringement - which was basically unauthorized copies of sheet music being sent by mail - by asking the Post Office not to send the unauthorized copies. Some wag gave the story the 'deeppacketinspection' tag. I like that :)

This Thursday, April 30th, will be a Test Day for SSSD, the System Security Services Daemon. SSSD provides several key enhancements to Fedora 11, including: * Offline caching for network credentials * LDAP connection pooling * D-Bus InfoPipe service for extending user information (e.g. face browser images, preferred language, etc..) A lot of prep work has going into making this test day a reality. Test cases have been defined, a fedora-infrastructure hosted LDAP server will be available for testing, detailed setup instructions defined and all of it pulled together in a pre-configured live image to make testing easier. So please make all our effort (well, not mine, I was busy fighting with mixers) worthwhile, and come out to #fedora-qa to help with testing! If you're not sure how to use IRC, see these instructions.

somewhere in Carolina, Greg DeKoenigsberg just bounced off the ceiling.

I'm mostly a very lightweight geek, but I do one thing that's quite hard core, these days: I run my own mailserver, rather than letting Google do it for me. (I know they just want to love me. I know, I know.) This includes outgoing mail. I send all my mail through my own postfix server, which - until today - relayed it all through my ISP's SMTP server. Geeks have been doing this sort of thing for years. Lately I've had a bit of a problem: more and more of my mails are getting rejected by SPF. Especially ones from my redhat.com address, because redhat.com implements SPF, and so any server which also implements it will flag or refuse mail that claims to be from a redhat.com email address but which didn't arrive from Red Hat's outgoing mail server. This is a bit of a pain. If you're in the same situation but you *don't* run your own mail server, all you need to do is make sure each of your accounts is set to send outgoing mail through the correct server, don't just send them all through your ISP server. If you run your own mail server which then relays the mail, though, it's a bit trickier. I started on a whiny post about how SPF was evil, then decided I'd better just try and fix it instead. So with a few minutes of Googling, here's how you do it, with Postfix at least. Postfix has a feature which lets you override the relayhost parameter conditionally, depending on the address the email claims to be from. So, I added a line like this in my /etc/postfix/main.cf: sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay and I created the file /etc/postfix/sender_relay , which contains this single line: @redhat.com [foobaroutgoingserver.redhat.com] et voila. Any mail sent through my server which claims to be from [email protected] gets relayed via Red Hat's SMTP server (no, that's not its real address), not via my ISP's server (which all my other mail gets relayed through). That was simple.

In non-Fedora news - my old home will be releasing Mandriva Linux 2009 Spring very shortly. I haven't been able to stay as involved with Mandriva as I would have liked to, but I did at least manage to contribute a few bits, and keep Elisa pretty much up to date for the release. I hope mobile synchronization should be solid too, but I haven't had a chance to test that on a Mandriva system lately. From what I've seen dipping into the mailing lists it looks like it'll be another excellent release, so congratulations to everyone at Mandriva.

Those of you - you poor, poor people - who read the Fedora development mailing list - were treated this week to a flamefest (or, as it is classically referred to in the British press, 'full and frank exchange of views') regarding the change to the official GNOME audio volume control applications which will appear in Fedora 11. The debate was expertly summarized in the latest Fedora Weekly News by Oisin Feeley. However, I'm going to take advantage of my little soapbox to go over it again, myself, in what will obviously be a way more biased towards the truth (otherwise known as 'my point of view'). Here's the central point of contention. In GNOME 2.26, the two programs which deal with setting the audio volume - gnome-volume-control and gnome-volume-control-applet - have been more or less rewritten. The old gnome-volume-control looked like this: (screenshot stolen, with apologies, from Piraja in this thread, since I don't have a copy of the old app to hand). The new gnome-volume-control looks like this: As you can see, they're really rather different. The old one was more or less a classic 'big list o' sliders' mixer, which exposed the raw mixer elements as provided by ALSA, and let you tweak them all directly. The new application is nothing like this at all. It's really an interface to PulseAudio's volume control system, which does not expose the raw ALSA mixer elements to you at all. What you get is a single volume slider. Slide it up, things get louder. Slide it down, things get quieter. You don't have to look at twenty different sliders and wonder what the hell they all do any more. In many cases, this is great. The basic idea - that the default volume control application should not expose every little element of control available on your sound card, but make it easy to turn the sound up and down - is a good one. The Pulse-based system also enables some other neat stuff, like letting you pick which sound 'card' (including things like USB headsets and webcams) you want to use to play which sounds, like pavucontrol has let you do for a few releases now. However, this extremely simplified system comes with a couple of drawbacks. The biggest one - and it's something of a whopper - is this: you can't pick an input channel. If you've got multiple sound devices in your system - say, an onboard sound card, an expansion card, a webcam, and a USB headset - you can pick which device you want input to come from. Which is nice. But you can't pick which channel on that device you want the input to come from. In practical terms - if you want to record (or monitor) from line-in, but the default is mic-in, you're in trouble. Ditto if you want to record or monitor from the front mic, but the default's the rear mic. Or vice versa. If the ALSA default input channel isn't the one you actually use, gnome-volume-control no longer provides any way for you to switch. This isn't some kind of braindead interface design or excessive simplification on the part of the designers. It's just a feature that didn't get implemented yet. Lennart wants to do it in a reasonably smart way - only expose elements which are really 'genuine' input channels you might actually want to select - and that's somewhat tricky. He'd also like to implement jack sensing, for compatible hardware, so that when you plugged in a mic it'd automatically get activated. So, in future - we're expecting around the Fedora 12 timeframe - this will get fixed. For now, though, it isn't, and that's a rather giant hole in the new system. The second drawback is that Pulse's abstraction of volume control is not yet perfect. At present, it more or less just turns the primary mixer element - the one that shows up further to the left in a traditional mixer application - up and down. On most cards, this is enough to give you a proper range of volume control without any other elements getting twiddled. If you turn it up to 100%, everything gets nice and loud; turn it down to 0%, and everything goes quiet. Great. So for most cards, the Pulse system works fine already. However, on some cards it doesn't. On some cards, even if the 'primary' element is at 100%, if another element isn't raised, everything's still really quiet. Or even totally inaudible. In the past, most people would notice this, fairly quickly discover that moving one of the other mixer elements sorted the problem out, and then probably forget about it. With the new design, you can't do this. You turn it up to 100%, everything's still really quiet, and you're pooped. The counterpart to this case exists, too - cards where, even if you set the 'primary' element to 0%, you can still hear sound unless another element's turned down to 0. There's even more advanced cases, like a card that has a separate channel for the rear speakers and another for the subwoofer - if you turn down the 'primary' element, the front speakers go silent, but you still get sound coming out of the rear speakers and the subwoofer. Which is a bit disconcerting. This kind of bug can be fixed. In some cases we just have to add an entry to the ALSA database of default mixer settings, so the secondary element that messes things up is set to a level so that adjusting the primary element does what we want. In others, Pulse can be tweaked to actually control multiple ALSA elements when you drag the single Pulse slider - so, on the card with separate elements for the surround speakers and the subwoofer, moving the new "Volume" slider adjusts all three ALSA elements, and everything just gets quieter or louder as you'd expect. However, we haven't yet fixed all the cases we know about, and the fact that several have come to light already through Fedora 11 pre-release testing is a pretty strong indicator that there'll be more bugs of this kind that only show up once Fedora 11 is released. The final drawback to the new system is it simply doesn't cover some less common use cases. Some people want to play back music from a line-in or aux-in, for instance. Aside from the input switching problem, the new gnome-volume-control also doesn't let you set the monitor volume for input channels. So, we have a radical new design which is genuinely simpler and more user-friendly than the old one, but causes some regressions due to features not yet being implemented, and bugs that have always existed becoming more important due to the simplification removing the ability to easily tweak the settings. Sound familiar? Yep, it's a situation that happens often enough in software development. What I pushed for is, simply, a fallback mixer for Fedora 11. The new mixer is great, it'll do the job for most users in Fedora 11, and they'll appreciate the simplicity. However, there are going to be a significant number of users who fall foul of either the input switching problem or one of the manifestations of the 'slider doesn't control the volume properly' bug. Until the input switching feature is implemented in Pulse and g-v-c, and most of the volume control bugs are fixed, we really need to keep providing a graphical mixer in all default Fedora 11 installations, so those who are stuck with one of these problems can fix it without recourse to the console. This is what the flamefest was about, and - I'm happy to say - that position pretty much carried the day. Fedora 11 should ship with either gnome-alsamixer, or the old gnome-volume-control (under a different name), installed by default alongside the new gnome-volume-control. If the new mixer doesn't do the job for you, you'll still have a traditional graphical mixer with full access to all the ALSA elements available so you can get what you need. If you find yourself in the position where the shiny new gnome-volume-control doesn't give you a decent range of adjustment of your output volume - it's too quiet at maximum, too loud at minimum, doesn't have a wide enough range, or your card has separate mixer controls for separate speakers - please file a bug in Red Hat Bugzilla (component 'pulseaudio'), and mark it as blocking the bug 'AlsaVolume'. This bug has a procedure to follow to provide the information necessary for the bug to be fixed. What does this mean for users of other distributions? Well, I looked at Ubuntu. I didn't actually check a Jaunty (9.04) install, but according to this bug report, it shipped with the old gnome-volume-control installed by default. Apparently they don't consider the new one ready for prime time yet. The new one is available, but not installed by default, in the package gnome-volume-control-pulse. Mandriva 2009 Spring, as far as I can tell, is shipping with the new mixer, and no fallback installed by default. Of course, Mandriva defaults to KDE in the DVD edition and the KDE Live CD is above the GNOME Live CD in the download list, and most Mandriva users use KDE, so most MDV users won't notice this issue (it really only affects GNOME, as KDE's kmix has not been changed at all to the new simplifed Pulse interface). But if you're using GNOME on Mandriva, you might want to be aware of this issue, and be ready to install gnome-alsamixer if you need it. For any other distribution - if your distro ships GNOME 2.26 from upstream, you'll likely get the new mixer. So be aware of the changes and the background, as discussed above. If you need access to the raw ALSA mixer elements, use gnome-alsamixer or alsamixer from the command line (you may need to use the -c and -V parameters to specify the card number you want to work on, and the 'capture' instead of the 'playback' view if you want to switch inputs: e.g. 'alsamixer -c0 -Vcapture').

I had a great weekend at LinuxFest Northwest, which my employer (Red Hat) was good enough to send me to. This was only my second conference and my first user/developer-focused one (Mandriva has a rather restricted event budget), so I didn't go too far in terms of organizing events or giving a talk - I wanted to get my feet wet first. But I felt like it was productive nonetheless. I spent Saturday mostly in the 'Fedora room' - one event room hosted just about every Fedora event, and nothing *but* Fedora events - helping a few people test Fedora 11, and chatting with Brennan Ashton, who's working on a Bugzilla metric system (which can be found in the Bugzappers group's git repository) to be used by the BugZappers group. Sunday I spent some time at the Fedora booth and also chatted with a few people from other projects, including Joe 'Zonker' Brockmeier of Novell / OpenSUSE. I've now met the community managers of Ubuntu (that would be the incomparable Jono Bacon, of course) and OpenSUSE (and of course I was the community manager of Mandriva, and I've met Anne Nicolas, who now more or less holds that title, along with all her others). That means, a bit ironically, that I'm left with just the sort-of community manager of Fedora - Max Spevack - to meet to complete the full set of major commercial (or commercially-backed) distributions. It's very interesting to see how differently the role is conceived; I was sort of a user community mouthpiece at Mandriva, Jono considers 'community' to mean mostly the developer/contributor community, and Zonker says his role works out to be mostly evangelism (he prefers the title community manager because it avoids the rather off-putting overtones of the 'evangelist' concept). We had several of the OLPC project laptops - the XOs - on the Fedora booth (which, no doubt through the labyrinthine machinations of Larry Cafiero, was the very first booth you saw as you came in to the event). It was great to see just about every kid who walked past - along with most of the adults - being magnetically drawn to them. No matter whether you think the project has had shortcomings in implementation, or what you think about the OLPC project's own change of direction regarding software, the devices themselves and the original, Fedora-based and Sugar-topped software have always seemed to be a great success wherever I've seen them. In the midmorning session I saw an excellent talk by the Linux Action Show's Bryan Lunduke, entitled - somewhat provocatively - "Why Desktop Linux sucks and what can be done to fix it". All the other developers / distribution employees I spoke to, Fedora and non-Fedora alike, were avoiding it like the plague, but I'm always interested in hearing people's opinions on this topic. So it turned out to be sixty disgruntled users and me, a situation I am not unfamiliar with :). Bryan's analysis was spot-on on a wide range of topics, particularly on identifying the areas where the current model - where much of the serious F/OSS development work is funded by companies whose principal goals lie in the enterprise world (Red Hat and Novell), and most of the rest is done by the 'bedroom hacker geeks' of urban myth - is failing. He cited audio and video editing particularly, and he's dead right about that. I thought his take on software provisioning - which boiled down to the old saw, "all distributions should agree on a common packaging format and set of conventions so third parties can build a single package that works on any distribution" - was somewhat misguided, and there was an interesting group discussion on that at the end, but aside from that it was a really valuable event. So if you're going to another convention where he's giving it, show up. Yes, even if you're a developer. After that presentation I got talking to Bryan and his colleagues from the show (and a couple of other people), so we wound up all going out for lunch together, which was a lot of fun. There's a picture somewhere, at this very point probably being used to substantiate someone's expenses claim... It was great also to meet the Red Hat / Fedora folks who were at the show: Jesse Keating, Karsten Wade, Larry, Jeff Sandys and Clint Savage (if Clint hasn't already won the Greatest Name Of All Time prize, it's surely some sort of cosmic oversight). I'm hoping to go back next year, and hopefully be more active in terms of giving a talk or two and helping organize some Fedora-related activities. (Oh, and schwag? Got the usual assortment of pens and paper, plus a Fedora t-shirt, but easily the coolest thing was the Zenoss zebra. I am including the link directly to Zenoss' page there in the hopes that it helps whoever runs the Zenoss zebra program to justify its continuation to their bean counter department. Because everyone deserves a squishy zebra on their desk.)

I am here at LinuxFest Northwest - right now I'm sitting in Larry's 'Introduction to Fedora' talk (in the back row of course). If anyone else is here and didn't say hi yet, please do. I look mostly like this: only I'm wearing glasses, and a black button shirt with white pinstripes. Tomorrow I'm thinking of wearing my Mandriva t-shirt, just for the heck of it :)

From this story: "Police saw the girl smashing a computer monitor with a keyboard and flinging the keyboard against a window, breaking it." Now I'm willing to bet money that was a fine IBM Model M keyboard, just like mine. Weighs a good four pounds with its solid metal backing plate. Useful for both typing and home defence. If you went out for a good day's civil disobedience and trying smashing in the window of a capitalist overlord with one of today's crappy plastic keyboards you'd just look laughable... :)