Divester innocently points out Dive Google, a scuba diving search engine offering paid listings. But it's not Google suddenly getting into scuba diving, it's someone riffing badly on the trademark. Or as one of Divester's commenters puts it:

another downside [to Dive Google]? It's likely only hours away from being shut down by the Google team for trademark infringement.

The worst part is that they missed such an obvious name: Dive Goggle. D'uh. You could even work the paid listings thing into the metaphor by noting that goggles limit your field of vision.

I was a bit despondent at the time of the Edgy beta release because it looked like all of my bugs were going to lie untouched until the end of time. But things have picked up.

Bugs I originally complained about:

Inability to scale CPU frequency.

This wasn't bug 36014, bug 36014 was about the CPU being stuck at the lowest available speed, whereas mine was stuck at the highest available speed. It was actually not a bug at all: it was caused by my not having powernowd installed. (It's only a suggested package for gnome-applets, it isn't a proper dependency. Likewise, it's only recommended by ubuntu-desktop, and I stopped installing all recommended packages because the recommendations for some packages are... comprehensive.)

Aptitude being slow to resolve dependencies

This was bug 51893, which never had a problem getting anyone's attention. It's been fixed for a while.

As for the second lot of bugs:

Network Manager not being able to identify wireless cards

This is actually a problem with hal, bug 59981 (my originally filed 60162 was a duplicate, and it's attracting duplicates like nobody's business because everyone looks for it against NM, not against hal). It's not fixed, but there is a patch floating around and being tested.

X having dramatic glitches after suspend.

Evidently the neglected child of the family, bug 60882. Someone has confirmed it and moved it to a new package, but there's been no sign of anyone wanting to look into it.

One more major one for me springs to mind: bug 61423 against Nevow. If this one goes unfixed, as seems likely (essentially the fix is for someone to approve an exception to the upstream version freeze as per bug 57482), I won't be able to use Edgy on my servers unless I want to install my own Nevow versions. I've gone through this before with Nevow—for either the Hoary or the Breezy release there was some problem with Nevow not matching the packaged version of Twisted—because it's so little used, and I felt really bad hassling #ubuntu-motu daily about the UVF exception. I'll probably go with my instincts and just not use Edgy on my servers, or at least not on the puzzling.org host. Given that though, I'm less concerned about using Edgy on my desktops for the next six months than I was on the day of the beta release.

We had a programming committee meeting for linux.conf.au 2007 on Saturday. Decisions were made. They may be revised based on budget. But the general consensus was that it's the papers that linux.conf.au rejects that makes linux.conf.au the best. And here's the more cuddly than Rusty guide to being among the best.

First a note. We had in the order of 250 proposals for 60 talk slots. (The ratio is a bit better for tutorials, about 2 proposals for every slot available.) We reject most of what we get, and we reject a fair number of things we suspect or know would be perfectly fine talks. It's a competitive conference.

1. Software talked about or that is core to your talk must be available under an Open Source licence. This is not negotiable, with a tiny bit of wiggle room for people who are waiting for their employer to sign off on an Open Source release. Only a little wiggle room, mind you.
2. It is getting towards being a requirement that you are a core member of a project, or of the part of it you're talking about. You need to have written a fair chunk of the code, initiated the documentation project, done the benchmarks, whatever. Sweated the sweat. Tutorials are a little different: for a tutorial, evidence of ability to convey enough knowledge well is generally important, and depending on your intended audience might trump not being a major developer of the tool in question.
3. Project maturity is not essential, but is desirable. If it hasn't been merged yet, or you are the only user, it will have to be great to be accepted.
4. Enormous maturity can be a disadvantage, or at least it is if it leads to the the style of proposal that goes here's the update on my LCA 2005 talk about [some project]. It's easier to get accepted if you submit a talk focusing on a particular new feature or development.
5. Being known as a good enough speaker is a big advantage. Standards here are high, but I feel not crazy. You can be accepted without being an amazing speaker. It is, however, essential to convince the review committee somehow that you have had and can convey 45 minutes worth of thoughts about your subject and that people will want to hear it. Being known as a good speaker from other conferences or events is excellent, and a high quality abstract can be convincing in some cases too.
6. Insane coolness is another huge advantage. In particular, people who've built things they can hold in their hands, put their arms around or have a sword fight with, tend to get their papers accepted. Most proposals do not fall into this category, those that do have a high acceptance rate.
7. Not submitting a kernel talk helps your chances of acceptance. This one is interesting. The problem is that we get a huge number of very good kernel proposals. linux.conf.au accepts a fair number of kernel talks, but is not a kernel conference and doesn't intend to become one. So to get a proposal accepted into this stream, you must not only be good, but be very very good.
8. Not submitting a general commentary on your experiences in the Open Source world also helps your chances of acceptance. Again, we accept some of these, but almost everyone has opinions on how to run an Open Source project, and they submit a variety of them. We need some special reason to believe you have something to say that the audience can't easily think up for themselves or read about.
9. Having some relevance to a primarily Australian audience is useful. This is really only meaningful for the above mentioned commentaries, for things like kernels it doesn't matter, and if it's hella cool, it also doesn't matter.

For comprehensive information about submission statistics and a list of all the program committee's blog entries, see John Ferlito's entry.

This work is licensed under a Creative Commons Attribution-Share Alike 2.5 Australia License.

Val(erie) Henson is a man.

For posterity, yep, joke. Val had a temporary manly homepage.

After a wee bit of confusion Valerie Valiant Henson, kernel hacker, has inned herself and resumed her identity as a woman. Her male identity is still around for those who want to admire Dana Sibera's work with virtual beards.

Yes it was a joke. And this is tough to tell on blogs, but yes, I knew it was a joke. Pinkie swears!

A couple of years ago, I was sitting in a dingy but servicable apartment in Prague whinging about the Open Source Web Design site. Since I went back there the other day and used one of their designs to make a site I run look passable, I thought it was only fair to point out that the quality of designs there have improved a lot, and many seem to be quite good at being reasonable implementations of current standards-compliant lightweight web design in the blog mode. It's still a little sketchy on the idea of licences or conditions of re-use though.

This sounds like faint praise mostly because it is. I'm a little bit wary of the thin centre column, still life image at the top, smaller navigation bar at the side etc etc trend mostly because I feel like I've been slapped around with it a lot. I suppose there's a part of me that looks forward to the day that web design becomes more like typesetting in terms of its intrusiveness. However, that said, they really are quite reasonable designs, no longer in any way a shock to the system. I'll probably use a couple of them to re-style puzzling.org and andrew.puzzling.org.

Yesterday, after talking with Akkana Peck on IRC about quiet servers, I was all set to write a long request for recommendations for server recommendations that are small, cool and quiet. But the ends of the Internet have converged, it seems, so I'll probably just watch Jordi Mallach do the same thing.

Google is having a women in engineering event on Thursday October 26. It will feature Jen Fitzpatrick (Google's Engineering Director) and Rob Pike (famed hacker of general UNIX stuff and author of beloved C textbooks) as speakers plus a panel featuring local women software engineers, including a number of Sydney LinuxChix. And I will be there in my capacity as an Anita Borg scholarship finalist, practicing my best happy for the winner face!

Date

Thursday 26 October

Time

6:30pm–10:00pm

Location

Google Sydney, Sydney CBD (Level 18, Tower 1, Darling Park, 201 Sussex Street)

More details and RSVP

http://services.google.com/events/ohsydney_rsvp

Women only?

I'm assuming so (unless you're a man who actually works for Google), I'm waiting on someone at Google to say for sure.

At present there's places left but be sure to RSVP.

As part of linux.conf.au 2007, which is being held at the University of New South Wales, Sydney from 15–20 January 2007 I'm organising a LinuxChix miniconf ('miniconf' is lca jargon, for people who know their academic conferences it's essentially a workshop scheduled into the main conference and included with the main registration—not to imply, I hasten to add, that lca is an academic conference).

We've just put out our Call for Presentations (we aren't going to require written papers), feel free to pass it onto any interested women or groups.

Part seventeen million approximately of how not to bug Mary: understand how anaphora are used.

Anaphora are the shorthand words that you use in sentences rather than naming something in an identifiable way. The obvious examples are pronouns: “she” and “you” and whatnot. There are plenty of less obvious examples: “one” in “I hate the tall woman and like the short one” is an anaphor. (I wrote my undergraduate thesis on “one” in the anaphoric usage and it was exactly as weird a computing thesis as that might lead you to believe.) Respectable noun phrases, particularly definite ones like “the idea” in “I like the idea, don't you?” can also be anaphoric. An anaphor is, loosely, a reference to something that you need some fairly immediate context (not always verbal, you could, say, be pointing at something and calling it “that”) to be able to work out.

So far so good. Which is why I don't understand how people use them on the Internet. I've had people use “it” to refer to an idea they discussed with someone else several hours previously, and judging from their profuse apologies, have genuinely actually forgotten that it might no longer be foremost in anyone's mind.

More generally, text mediated communication seems to reduce everyone's capacity to actually model what other people might know. Mostly they assume too much of their audience. “Which idea? The idea I discussed with someone you've never heard of who lives on the other side of the world in a lead box, of course. That idea. Hello? Duh.” Some assume too little. “You want to change your tyre? OK, let's back off a step. A wheel is a round object that, together with an axle, allows low friction in motion by rolling... [thanks Wikipedia].”

In the ultimate failure to model one's audience, the other day I sent a mail about the Google thing. I got a reply from someone I don't know reading, in its entirety, “women engineers?????????????????????? And me?” It was tempting to reply “Lookit, cannibals!” or something. Instead I politely replied that I hadn't understood the question, and my correspondent has failed to enlighten me.

I just got a supposedly anonymous review of my OSDC paper with a very recognisable name stuck in the middle of the name of the file containing the review. So it's quite a good chance that I know my reviewer's surname and first initial. (There is of course, the small chance that a reviewer stuck someone else's first initial and surname in the filename...) Likewise, Andrew just got one entitled spiv.txt, meaning that it was written by someone who knows that Andrew's IRC nickname is ‘spiv’. The overlap between people he talks to on IRC and people who have had papers accepted (the speakers review) at OSDC is fairly small, so he can fairly easily pick the two or three people who that could have been.

Just goes to show how hard setting up an anonymous review process is. When the anonymity goes both ways—the reviewers don't know the authors' identities either—it creates some amusement for readers. Academic papers that were prepared for blind review read strangely because the authors refer to their own past work really distantly and non-judgementally in the third person because they couldn't tell the reviewers that they wrote the paper under consideration. I suspect that half the time it's obvious to the reviewer anyway, since, often, of all the techniques in the world that author S could have chosen, they've chosen to follow up on Smith et al (2005) and Smith et al (2002). I wonder who author S might be?

Back in 2004 I finally noticed a really common construction that so far seems confined to American English: it's not that big of a deal and similar (How big of a perv is Foley?, How big of a problem with security?, How large of a volcanic eruption would it take to cover the entire world with volcanic material?) In Commonwealth, or at least Australian, English this would be it's not that big a deal (likewise how big a perv is Foley?, How big a problem with security?, How large a volcanic eruption would it take to cover the entire world with volcanic material?, although I suspect the last one would often be rephrased).

I asked about it at the time (and of course one never blogs alone) and completely failed to notice that the answer came from on high, that is, that Mark Liberman from the Language Log bothered to answer. Wow.