Ada Lovelace Day Addition

So on actual Ada Lovelace Day, I was a little :( at being the only person on Planet Ubuntu that blogged for it. Plenty on Planet Ubuntu Women, but Planet Ubuntu was empty. And none of the guys involved posted anything.

But yay! They were just a little late. James Westby and Matt Zimmerman both joined in. Matt wrote about his mom, which I thought was pretty cool. And Miia Ranta joined in as well.

I did just realize that there are two women I should have given a little shout-out.

One is Cathy Malmrose, the CEO of ZaReason, the company that made my computer. She's a hardware geek, so it's only natural, right? She said they're considering expanding into the "make their own components" direction so they won't be constrained by what barebones brands offer. Neat! They sell t-shirts too. There used to be Little LinuxChick shirts, but now there's this cute one that says "friends help friends use Linux" with a silhouette of two teenage girls on laptops. Also, she's raising a few FOSS munchkins. Her 5 year old installed Ubuntu (the 7 year old helped by reading the words for her) to prove the neighbor wrong about Linux being hard to install. And the 7 year old is already programming. I think the fact that there's a photo of him on Flickr using 3 laptops titled "Mom, what's the kernel? Where is it? Can I mess with it? Why not? Just tell me where it is so I can play?" is hilarious and wonderful. She's obviously a great influence on her kids.

The other is Amber Graner, the "average user mom" who's been blogging her adventures learning to use Ubuntu (and trying Fedora and OpenSUSE), and making everyone go "oh…oh yeah…I guess we could make that easier…that's a good point…." She's providing great constructive feedback, and she's just so excited to learn. I ♥ people that love to learn. I hope her love of learning is something her kids pick up. In my mind, she's the perfect person to have promoting Ubuntu (which she does!) because she proves that anyone that's willing to give learning an honest try can use it—it's not a geek OS.

Ada Lovelace Day heroine: Valerie Aurora

Today is Ada Lovelace Day, named for the world's first computer programmer, Ada Lovelace. It's interesting to me that while the first programmer was a woman, and all of the ENIAC programmers were women, there are so many more men than women in technology fields nowadays. Ada Lovelace Day is a day to highlight women who rock in the tech world. Since here in FOSS-land, the FLOSSPOLS survey reports that only 2% of developers are women, compared to 28% in the commercial sector, I decided to write about a Linux kernel hacker: Valerie Aurora.

By default, Ubuntu uses the "relatime" mount option. It decreases the number of metadata writes on ext3. It turns out, Valerie created relatime because one of our friends discovered that Mutt couldn't tell which mailboxes had new mail when using noatime.

I think she really loves (or hates?) fsck. I can't tell which. She's responsible for some patches that shorten the amount of time needed to fsck an ext2 partition, along one that gets a 50% improvement on RAID 5 systems with ext3 and ext4. She also worked on a new filesystem architecture called ChunkFS. The goal of ChunkFS is to deal with the fact that as hard drives get bigger, fsck times get longer. She wants to be able to fsck smaller parts of the filesystem at different times, to avoid day-long fscks in the future. The white paper is interesting. And yes, she wrote a working prototype. Oh, and you know ZFS? The filesystem from Sun? She worked on that too, back during the architecture phase.

It's not all filesystems though. She's got patches in libc to make malloc() more efficient. She worked on the TCP/IP stack. She was the maintainer for SMP PowerPC support in Linux. Device drivers? Done that too. She's done it all.

She's not keeping that knowledge locked up though. Not by a long stretch. She's spent countless hours mentoring. She taught Linux kernel development classes at IBM, and she was even kind enough to teach kernel hacking classes for LinuxChix (on the old site). One time, she held a real-time kernel development Q&A session on the LinuxChix IRC server. She also used to writes "Kernel Hackers' Bookshelf" for Linux Weekly News

Valerie was one of the first people I met in LinuxChix. Immediate first impression? Wow, she's smart. Second impression? Don't mess with her. She's tough. You may have seen her HowTo Encourage Women in Linux write-up. If not, check it out. Possibly, you said something that offended someone and were directed to it. If that did happen, I hope you read it. It's the link everyone uses for those situations.

Valerie Anita Aurora was once known as Val Henson, but she recently changed her name. She chose the middle name "Anita" after Anita Borg, a computer scientist that strove to encourage women in technology fields. Pretty cool name change, eh? Just bringing this up in case "wait, that sounds like Val Henson..." was on your mind.

Ubuntu Developers Aren't Scary

Seriously, they're not. At least, I don't think they are anymore. They used to scare the crap out of me.

The first time I joined the #ubuntu-devel channel (slightly under a year ago) and said "hi, um, I have a patch. What do I do?" I was all scared. Jordan Mantha (LaserJock) popped up and offered to make it into a debdiff since I said I didn't know anything about packaging. The patch ended up not being usable because um, oops, memory leak. Wait, what? No teasing about making a newbie mistake like that? And I actually got credit in the changelog for figuring out what's wrong and how to fix it? Wow. Hmm, helpful people, not arrogant about what they know that I don't? Maybe being developers doesn't have to automatically make them scary. Maybe.

Soon after that I became friends with Jordan and with Daniel Chen, who lives nearby. Daniel showed up to our LoCo's Gutsy and Hardy installfests, and at the Hardy one I convinced him to start mentoring me on how audio works. They're both nice guys, just know that mentioning brokenness in QA to Jordan or in audio to Daniel will very likely result in a long, drawn-out analysis of the situation. You've been warned.

OK so at that point, those two stopped being scary, and the rest stayed frightening. Skip to last October, when I went to the Ohio Linux Fest (be there! we're having a Women in Open Source event on Sunday, so let's get that female:male ratio up, alright?). Wow, a whole bunch of Ubuntu and Kubuntu folks showed up. Rich Johnson, Jorge Castro, Jono Bacon, Greg Grossmeier, Steve Stalcup, Jacob Peddicord, and more that I forget. Guess what? It turns out they're all really nice people too! Well, Rich has his moments. Better without the beer...or tequila. Oh, and don't drunkenly moon Jono unless you want to relive the experience, sober, in front of 1200 people. Moving on…

So I think by that point I was probably subscribed to ubuntu-devel-discuss. That's a mailing list I recommend you join if you want to contribute. That's where discussion between users and developers happens. If you've got an idea and want to flesh it out enough to put up on Brainstorm, or are taking a Brainstorm idea and trying to figure out the technical details to write a specification, get opinions on how possible it sounds, etc. go there. It's a more relaxed atmosphere than either the ubuntu-devel mailing list or #ubuntu-devel. It tries to bridge the gap Amber noted in her 'Community v. "Community"' post.

About a month ago, I started setting my IRC client to join #ubuntu-devel by default, and I subscribed to the ubuntu-devel mailing list. On the mailing list, I'm much more talkative than on the IRC channel. It's more discussion-oriented than the channel, it seems. The channel seems to be more full of terse "<Y>X: did you upload $package? <X>Y: no, not yet, writing changelog now" sort of stuff. At that point, I still felt like ducking behind a couch every time I spoke in there, in case anyone cyber-threw something at my head. I don't feel like that anymore. Just lurking and seeing how interaction works there has made it less scary. It's not that they're trying to be scary. They're just trying to be somewhat professional. Sometimes I'll look into the channel and see someone make a joke. And every morning, without fail, Daniel Holbach says "good morning" to the channel when he wakes up. And then it's a reminder that "oh yeah, they're normal people too."

Oh, I also started joining #ubuntu-women and #kubuntu-devel around that time. Lydia is a KDE developer that's almost always in #u-w. She's really nice and helpful. And of course, everybody (except IRC spammers) loves Sarah Hobbs, AKA Hobbsee. I know, it's sad that I can't think of other women developers. Where are you, ladies? Why aren't you in #ubuntu-women? Women who aren't involved: why not? We in #ubuntu-women will show you how. Why do you think that channel exists?

Why am I writing this? Well, the point is: the Ubuntu Developers aren't scary people. They're actually really nice people. So if you're intimidated by the prospect of speaking up in development related areas when you've just started out and can't point to a list of things you've done, remember: they're not scary, they're unfamiliar. There's a difference. The image of developers being way up high, far from users, knowing how everything works, and not making mistakes? All in your head. Why do you think there are so many bugs? ;) Please don't be afraid to help out because you think you're not good enough. You'll learn. Everybody involved totally sucked at this stuff at one point.

Oh, and Daniel Holbach and Scott Kitterman both agreed that when they started out, they also found the whole thing intimidating. To lower the intimidation level, read on: Scott doesn't know C. Neither does Jordan. Daniel says pointers are his weakness. Mine too—especially when passing them into functions. I put in one & and get a *? Or do I put in a ** and get a *? What if the function declaration wants a **? And like I said, my first patch attempt in Ubuntu had a memory leak (Steve Langasek caught it, it didn't get to the archive, don't worry). And that doesn't make everybody go "you can't code, go away" when I try now.

Pidgin in Jaunty

This is just a quick update about how Pidgin interacts with the rest of the Jaunty desktop. Before we had the following problems:

1. Pidgin icon sits in notification area when not notifying
2. Pidgin status can be changed in both the FUSA and in the Pidgin icon
3. Removing icon gets rid of buddy list's hide-ability

The first point extends into "if Pidgin and Evolution and Empathy and Xchat and ... are all trying to show that you have new messages, that's a lot of icons." The solution that's implemented in Jaunty includes the addition of the messaging Indicator Applet. So far it only works for Pidgin and Evolution (first priority as default apps, I'm guessing), but eventually the others should be added. Ryan's working hard on making sure it works for @-replies in Gwibber as well. Then you can have just this one applet, and eventually, all your messaging stuff will go there. The Indicator Applet is not on the panel by default. You can right-click the panel and hit "Add to Panel" to get it.

On new users, the icon defaults to not showing in the notification area.

When I proposed removing the icon by default, there was an uproar of "but we want to hide the buddy list instead of minimizing it!" A few people I talked to on the bug report, blog comments, and elsewhere online agreed that if there was one applet that could work for all the IM clients to show and hide, that might be pretty nice. Someone noticed. The Indicator Applet does this too. Thanks to whomever made that work.

One note: this is like with Rhythmbox. If you click the X, that's still "close," and for a very good reason. If the X doesn't mean close, it is possible for the buddy list to be hidden in KDE (or in a GNOME session where the user hasn't added the Indicator Applet) with no way to bring it back! I don't use the notification area icon, so when Pidgin started being able to hide when it's not there (so the Indicator Applet could control it), I could see "X is now online" notifications and receive IMs but not get my buddy list to stop being invisible. Thank you very much to Ted Gould for fixing it so that the buddy list only hides from either the icon or the Indicator Applet, and not constantly.

Please test Jaunty...soon

Jaunty's release is less than two months away. Please grab a Jaunty alpha 5 or daily live cd and test! Go through the bugs you've filed and see if they still exist on the live cd. See if any new ones pop up. And do it ASAP.

In every development cycle there's a huge influx of bugs in the last two weeks because a lot of people jump from stable to beta or RC, skipping alpha completely. Great, we've got more testers, but…how many bugs can be fixed in two weeks without risking breaking anything else? Not nearly as many as are filed. That is why we need more people testing early on.

I'm not saying everybody should install the development release on their only computer or the one they use all the time, directly on the hardware. While I've been doing that for the last two years, that's generally not recommended. If you cannot function pretty much entirely from the command line, don't put it on your hardware. Put it in a VM.

VMs aren't terribly useful for testing hardware, but there are plenty of GNOME and KDE bugs you can find using a VM. Try it! Check out Virtualbox. Put Jaunty in there and play with it. Try doing anything that doesn't involve important persistent data in the VM. By that I mean: don't write your thesis in the VM without having it backed up elsewhere. Web browsing? Getting your email over IMAP? Chatting? Why not?

But for hardware, use a live cd. Very often a triager asked "is this still a problem in the current development version?" The end of that sentence is "or would it be a waste of time for us to try to hunt it down when it's already fixed?" though it's not said. Also very often, the bug reporter will reply "I don't know. I'll test it when it releases." Insert whatever development cycle you want in there. It happens in all of them. Guess what happens when the reporter says they'll test after release?

• 10 The bug gets ignored as "potentially fixed; waiting on feedback" because as I said, trying to fix what's already fixed is a waste of time.
• 20 The development release becomes a stable release.
• 30 The reporter complains that it's still not fixed.
• 40 Work starts on the next development release.
• 50 The reporter is asked "is it fixed in this one?"
• 60 The reporter doesn't answer or says again that they'll test after that release.
• GOTO 10

Bugs can't be fixed without information. Thus, bugs that have a lot of information are more likely to be fixed. If you're not giving us any information, what do you expect?