Brane Dump

Using Virgin Mobile Broadband with wvdial

File Under: Stuff I'm guaranteed to forget if I don't write it down

I just went a bit wild and decided to get myself some mobile broadband love -- I'm finding that I crave a bit of light 'net when I'm out and about, and an impending change in circumstances will mean that I'm out and about a lot more than I am currently.

I have:

Hardware: Huawei E160e USB dongle, USB ID 12d1:1003
Provider: Virgin Mobile Australia Prepaid
OS: Debian GNU/Linux 5.0 with an upgraded 2.6.32 kernel

My wvdial.conf stanza looks like:

[Dialer virgin]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP" "VirginBroadband"
Stupid Mode = 1
ISDN = 0
Phone = *99#
Modem = /dev/ttyUSB0
Modem Type = USB Modem
Username = irrelevant
Dial Command = ATDT
Password = irrelevant
Baud = 460800

I also had to disable CHAP (by putting -chap in /etc/ppp/options, although I suspect the same would have worked in /etc/ppp/peers/wvdial).

After that, a simple sudo wvdial virgin and I was away.

Scarily enough, there was actually some useful information on the Virgin support site regarding the settings, which helped me confirm that I was on the right track. I have no doubt that the universe will find some alternate means of punishing me down the line.

Making pbuilder just that little bit faster

Give yourself a small, slightly late christmas present, and put a tmpfs on /var/cache/pbuilder/build. It makes a noticable difference, especially if you're on a laptop system (like I am) with a disk that's not going to win any speed records.

When Scientists Get Into The Kitchen...

You get a rigorous analysis of the science behind boiling eggs. I want one of those thermal circulators for Christmas.

Cool Regex Win-of-the-week

I just had a need to match a regex where there were two occurances of the same string, and it would be really, really nice to make sure that both occurances were actually the same (rather than both being different strings that just happen to match the same regex). Just to be funny, I tried this:

  /([a-z0-9\.-]+).*\1/

And knock me down with a feather, it worked! This is using Ruby's regex handling, but I'd be stunned if Perl didn't also handle this case.

The world just got a little bit awesomer today.

Is There Something Wrong With Me...

When the first thing I thought of when I saw this baby outfit was "What sort of cretin wrote that code?", rather than anything more "paternal"?

I want those two day of my life back, Puppet

Pop Quiz time, everyone (well, the Puppet-using subset of "everyone", anyway). Where is the dependency loop in the following manifest:

class klass {
   file { ['/tmp/a']: ensure => present }
}

define def_file() {
   include klass

   file { $name:
      ensure => present,
      require => File['/tmp/a']
   }
}

def_file { '/tmp/b': }

def_file { '/tmp/c': require => File['/tmp/b'] }

This seems pretty straightforward: /tmp/c can't be created until /tmp/b (via the direct require) and /tmp/a (via the define) have been created, while /tmp/b can't be created until /tmp/a is created. You can draw some pretty graphs and see that everything looks fine.

However, if you run this manifest, you will find that roughly half the time, you will get a failure saying that there's a dependency loop (and the other half of the time it'll work fine), like this: "err: Could not apply complete catalog: Found dependency cycles in the following relationships".

So, where is the loop? It's because the require on the /tmp/c resource also applies to the /tmp/a resource -- iff the include klass directive is applied to the /tmp/c resource. So `/tmp/a` then requires `/tmp/b`, and `/tmp/b` requires `/tmp/a`, and it's LOOP TIME!

Whether or not this loop occurs on a particular Puppet run is controlled by fickle Lady Fate (because Ruby hashes, which are used at some point internally in this process, don't have a well-defined or stable order). As to why the include only applies to one of the defines rather than all of them, well, that's related to the fact that a class only gets evaluated once, and I think someone was having a lazy day when they wrote that part of the system (I can't imagine it would be the end of the world if each instance of the class was linked to the defined resource in the scope tree).

Now, when you've only got the above manifest, it's relatively straightforward to isolate the problem and fix it -- I had it sorted in about an hour. The two days prior to that were isolating the bug from the live manifest, because there are about 20 instances of def_file in our live manifest, and so I'd have to run Puppet (on average) 20 times to make the problem appear every time I had a new hypothesis (and since I didn't know whether the bug was client-side or server-side, I had to run it in the real, full-blown environment, which slows things down further). If the class-handling stuff had been written properly, then the error would have been constant, rather than intermittent, and I would have been asking for a couple of hours credit, not a couple of days.

The fix? Use virtual resources instead of the class, which does $DEITY-only-knows-what to the scope tree. These have their own giant buckets of ugliness, but our options, at this point, are unpleasantly limited.

I really do wonder why I'm not a raging alcoholic sometimes. The reasons not to are strangely hard to recall right at this moment...

Oh Firefox...

What are you doing in that the 1.1GB of resident memory (1357m of virtual memory) you have decided to consume in order to display three web pages? All fairly basic pages -- no flash, no excessive Javascript, and I haven't even done anything particularly exciting in the browser -- just loaded the pages up and let them sit for a few days.

Time to look at Conkeror on the Netbook, I suppose. I'm unlikely to be needing Firebug on there any time soon.

Vimoutliner... finally!

I am, at best, a vim dilettante, preferring joe for most of my day-to-day text-editing needs. However, I do like using vimoutliner for notes, plans, todo lists, and calendaring (more on that some other time).

However, the Debian vimoutliner package (in combination with the awesomely undocumented vim-addons mess) is an absolute pain to get going, requiring far more swearing and prodding than seems necessary. Since I don't do it often enough, too, I keep forgetting how, and today things came to an absolute head when I very nearly flung my netbook across the room as it singularly refused to do my outliner bidding.

Finally, however, after much swearing (and even installing vimoutliner's upstream package to see if it worked -- it did -- and what it was doing differently -- just a small, crucial addition to .vimrc), I got the magical recipe. No doubt someone with an acheing need to make sure that vim stays as user-hostile as possible will immediately spring into action to make sure this doesn't work for squeeze, but at least for the life of lenny, here's how to get vimoutliner working:

 # apt-get install vim-vimoutliner vim-addon-manager vim
 $ vim-addons install vimoutliner
 $ echo "filetype plugin indent on" >> ~/.vimrc

May it help someone avoid putting their laptop through a wall.

Backwards Compatibility FTW

Over the weekend I updated a small app I wrote for my local bushfire brigade from Rails 1.2 to Rails 2.3. Given it's small size, all-encompassing test suite, and general lack of mission criticality, I decided to bite the bullet and just kick up straight to Rails 2.3.2, and fix whatever broke. I was expecting quite a bit of fun and games.

Well, there was fun, and there were games, but it was all relatively painless. I had to run rake rails:unpdate, add a couple of session config lines to my environment.rb, and get rid of a bunch of testing plugins that had been superceded by functionality in core (which involved me rewriting an awful lot of XPath into CSS selectors -- a massive net win, I have to say), but the core code of the application was completely unchanged (not a single line changed in the app directory).

Given the number of major releases I leapt, and the fairly haphazard way in which I did it, I am quite pleasantly surprised at the outcome. Kudos to all the Rails hackers who made it possible.

The Rise and Fall of Wordperfect

It's been sitting in my browser for so long that I've forgotten where I got it from, but I've just finished reading The Rise and Fall of Wordperfect Corporation, written by W. E. "Pete" Peterson, one of the very early employees of the company, and one of the top people there for many years.

It's a really interesting book, giving some insights into what it was like in the early days of "the microcomputer revolution", and with some solid observations of how to (and how not to) run a software company, and manage a very rapidly growing organisation. I'd recommend it to computer historians, software development managers, and business owners.