|

Here’s Knuth in an interview:

As to your real ques­tion, the idea of imme­di­ate com­pi­la­tion and “unit tests” appeals to me only rarely, when I’m feel­ing my way in a totally unknown envi­ron­ment and need feed­back about what works and what doesn’t…

Hmm, peo­ple who are “feel­ing their way in a totally unknown envi­ron­ment”… Like new con­trib­u­tors to an open-source project or a new employee doing main­te­nance work on a project after the orig­i­nal team has gone on to other companies.

…oth­er­wise, lots of time is wasted on activ­i­ties that I sim­ply never need to per­form or even think about. Nothing needs to be “mocked up.”

Good for him. Here on Planet Earth, devel­op­ers are often asked to work on projects they didn’t design and imple­ment them­selves, and do so in a way that doesn’t hor­ri­bly break some­thing that already exists. Or work with oth­ers because your desired end­state and time­line are not such that you can do it your­self or work things piece­meal and take it back for a redesign. </snark>

For any­one who wants to han­dle dynamic DNS (either in con­junc­tion with DHCPd or not) with Bind and absolutely hates the ver­bosity of nsup­date, here’s a shell script which han­dles the common-cases of adding and removing:

• Forward/reverse entries
• CNAMEs

The com­mand line argu­ments are –k (privkey) –a (action) –h (host­name) –i (ipaddr) –c (cname) –d (debu­glevel) (-t ttl)

Usage:
    setns -k privkey -a set -h hostname (-i ipaddr|-c cname) [-d #] [-t ttl]
    setns -k privkey -a unset -h hostname (-i ipaddr|-c cname) [-d #]

You need to be famil­iar enough with Bind9/DNS to have cre­ated a key­pair with dnssec-keygen and added it to your named.conf.

Other ways of sim­pli­fy­ing this are a Tcl/Tk GUI tool and a python script. Neither of which have the dis­tinct advan­tage of my tool: giv­ing me an excuse to do useful/interesting things with bash. Downsides are peren­nial script­ing prob­lems with insuf­fi­cient input val­i­da­tion, it’s not trans­ac­tional (i.e. if the sec­ond half fails it won’t back out the first half), and it requires FQDNs rather than using your search domain.

The script, avail­able under the GPL.

Also, good to see all the progress we’re mak­ing in the ille­gal, immoral, unjust, but mag­i­cally winnable war to let Exxon take upwards of 75% prof­its on all the unex­ploited oil reserves in the Baghdad in the Midwest Cornfields.

So, I use Firestarter to man­age the fire­wall at home. It has it’s issues, of course (not all events show up in the lit­tle event viewer, for exam­ple), and I’m a lit­tle wary of using a graph­i­cal tool to man­age ipt­a­bles. That said, I’ve so lit­tle time at home, I don’t really care to spend it wrestling with the fire­wall on my Linux box.

This is also why peo­ple buy those toys from Linksys, they require lit­tle to no effort to use. Of course, their wire­less offer­ings should ship secure by default, with a lit­tle plas­tic win­dow on the bot­tom of the thing con­tain­ing a card with the SSID and WEP keys on it — and a stack of pre-labeled cards to write future SSID and WEP keys on.

Aaaaanyways, hav­ing setup OpenVPN at work (eth­er­net bridge over TCP) I needed to punch through the fire­wall on my box so it was worth a damn. Unfortunately adding the VPN net­work to the “Hosts allows to con­nect” list doesn’t work, since it still blocks the out­put. To fix this, you need to dis­able the fire­wall on your tap (or tun, if you’re using OpenVPN in a routed con­fig­u­ra­tion) inter­face by adding the VPN net­work to your “allowed hosts” bit, and then adding the fol­low­ing lines to /etc/firestarter/user-pre:

$IPT -A INPUT -i tap+ -j ACCEPT
$IPT -A OUTPUT -o tap+ -j ACCEPT

What that means is: “let any­thing com­ing in (INPUT/-i) or going out (OUTPUT/-o) on any tap inter­face through.” Getting the con­nec­tion to use the incoming/outgoing poli­cies is the ideal case, but I didn’t really research into how to make it work beyond a lit­tle experimentation.

Ok, so I decided to quite lit­er­ally worry myself sick this weekend.

Obviously in poor form.

Mmm, indeed, indeed.

At any rate, I’m going to ride the “fever train” for as long as I can.

For exam­ple, I can blame the fever for mak­ing me for­get that today was tarball-day after work, caus­ing the tar­balls for FUSA 2.13.91 to be pre­cisely 82 sec­onds late. Fortunately, Davyd uploaded the tar­balls any­ways, so you have some­thing to test.

I can also say that there is only one RC release left before 2.14, and the lack of bugs filed against FUSA is trou­bling. I know for a fact I’m a mediocre pro­gram­mer, which means that peo­ple sim­ply aren’t test­ing this crap, which is totally unac­cept­able. I want to hear about all three crash­ers that I’ve secretly sneaked into FUSA in the last few months. Of course, such crashes don’t exist… or do they?

Ummmmm, ok. Forget the stream-o-consciousness bizarreness and just test the freakin release, purty please, with sugar and such on top?