Network Problems Fixed?

As far as I can tell, FreeBSD 8 tickled something in the driver for my ethernet card, and caused it to behave unreliably. Rather than muck around with half-tested kernel patches or ifconfig settings, I slapped a $30 Whatevertheyhadontheshelf-3000 (read: common chipset that’s been debugged by a lot of people), and as far as I can tell, things are now working as they should. If the site stays up for a year, I guess we’ll know.

I also took the opportunity to add some memory. So whoo-hoo all around.

And while I’m at it, I should point out that FreeBSD is like a VW Bug: not the prettiest thing to look at, especially compared to various Apple or Linux offerings, but in a crunch it’s nigh-indestructible. Wanna run with a root partition that’s over 100% full? Sure thing. Boot a 7.2 kernel with a 8.0 /usr? No problem.

Geek T-Shirt

I just had an idea for a geeky T-shirt:

In just seven days…

TTTCGCATTCTGGGATTCTCTAGAGCCATCTTGCGCCTCTGATCGCGAGACCACACGATGAATGCGTTCA
TGGGTCGCTTCACTCTATCCTGGACGTTGCCTTTACTGTTTTCTCCCGTTTCACACTGATACTTAGAGTT
ACAGCTTTCAGTGCAAAGGAAGGAAGAGCTTCTCCGGAG

SRY protein

… I can make you a man!

(For those who haven’t memorized the human genome, that’s the SRY gene, which is found on the Y chromosome and makes embryos develop as males.)

(Well, mostly.)

Google Criticized Over Name of Its New Language

Slashdot has a story entitled Google Under Fire For Calling Their Language “Go”.

I can certainly understand that: Go has got to be the least-googlable language name since C.

Happy Mole Day

As the Tree Lobsters remind us, today is Mole Day (the official site seems to be overloaded, but tehPedia isn’t). Yay!

For those who have forgotten High School chemistry, “mole” a word like “pair” or “dozen” or “score”, in that it refers to a certain number of things. But while “a dozen doughnuts” means twelve doughnuts, “a mole of doughnuts” refers to 6.02×1023 doughnuts (and, of course, a baker’s mole means 602,000,000,000,000,000,000,001 doughnuts).

6.02×1023 is known as Avogadro’s number (which is why you should celebrate Mole Day by having guacamole at lunch), which has the interesting property that that many hydrogen atoms weigh one gram. Oxygen, with 8 protons and 8 neutrons, has an atomic mass of 16 (minus some change), so a mole of oxygen weighs 16 grams.

This makes life easier for chemists. We all know that two hydrogen atoms and one oxygen atom combine to make one water molecule. And likewise, two dozen hydrogens and one dozen oxygens make a dozen water molecules. So two moles of hydrogen and a mole of oxygen make a mole of water.

So naturally, Mole Day is celebrated starting at 6:02 on 10/23 (US notation. Check with your local chemist and setting of $LC_TIME to find out when it’s celebrated in your area.

Update, Oct. 25: Alert reader Anne Wright pointed out a mistake. Fixed.

Quick and Dirty Perl Hack: Is Foo::Bar Installed?

Every so often, I need to find out whether I have a certain Perl module installed. Usually it’s either because of a security alert, or because I’m wondering how much of a pain it would be to install some package that has Some::Obscure::Module as a prerequisite.

I don’t know how y’all do it, what with the plethora of package-management utilities out there, but one way that works for sure is simply:

perl -MSome::Module -e ''

If this command succeeds, that means Perl successfully loaded Some::Module, then executed the (empty) script, printing nothing. If Some::Module is missing, it’ll print an error message and fail.

This is short enough that it should be aliased, but I haven’t gotten around to that yet.

It’s A Visual Pune, or Play on Dots

(Whipped up in 10 minutes with the Gimp, so don’t complain about the quality.)

Taxon Bingo

Okay, so I’m a geek. When I saw a story in the
Washington Post Maryland
RSS feed with the headline
“Chesapeake Beach Can’t Raise Taxon Bingo Machines”

RSS Headline

I wondered what
Taxon
Bingo would look like, and had to whip this up:

Taxon bingo card

(The headline has been fixed in
the full article,
but remains in the RSS feed.

Original image from
Wikimedia Commons.)

iReligion 2.0

The Telegraph
reports that

Cardinal Sean Brady, the leader of Ireland’s Roman Catholics, has urged social network users to start sending daily prayers by text, Twitter or e-mail.

This, of course, could be the start of something huge: if tweeted
prayers are as good as spoken ones (contest for the comments section:
condense the Lord’s Prayer into 140 characters), then the sky’s the
limit.

Imagine: you add a dinner date on your PDA. When it gets added to your
calendar server, it sends a request to the Catholic church’s server,
with the XML equivalent of “forgive me, father, for I have committed
gluttony”. The church’s expert system analyzes this request behind the
scenes, and responds with something like “say five Hail Marys”
(properly encapsulated in XML, of course). Your home computer then
schedules a time to tweet five Hail Marys while you sleep.

At MyVatican, you can view your history confession, schedule
preemptive penance, friend saints and other intercessors, buy relics
at the online shop, and follow your favorite priests as they get
shuffled from one parish to the next.

What would be really cool would be if they wikified the
Catholic Encyclopedia.
Though I assume that [citation needed] would be
replaced by [must be taken on faith].

Just A Little Bit of Planning

One thing I’ve noticed about my code is that an awful lot of the
comments are of the form

call_some_function();
	// XXX - Error-checking

(where
XXX
is an easily-grepped
marker for something that needs to be fixed.)

The proximate reason for this accumulation of “do something smart if
something goes wrong to-do items is that a lot of the time, the
function in which this appears doesn’t have a mechanism for reporting
errors, so I don’t know what to do if I detected a run-time error.

This leads to the other big problem, the one where I’m calling another
function of mine, which doesn’t report errors, so I can’t even tell if
something went wrong.

So if a() calls b() which calls
c(), all three are likely to have
XXX - Error-checking
comments; but c() doesn’t know what to do in case of en
error, and b() and a() don’t even know how
to detect errors. And so the XXX comments accumulate.

For me, this is often caused by the fact that experimental programming
and production programming are quite different: when I’m learning a
new system, such as a new graphics or math library, I want to figure
out which functions I’m supposed to call to get the results I want,
what the various data structures do, which one of multiple approaches
to the problem works best, and so forth.

If I set up a test environment (e.g., a database server so I can play
around with database-manipulation code), I’ll be keeping an eye on it
to make sure that everything is sane, so my experimental code needn’t
worry about checking whether the server is up. And if it can’t make a
connection, it’ll likely dump core; but since I don’t have any
precious data or users who’ll yell at me if things go wrong, it
doesn’t matter. It’s best to just set up a working environment and
hammer at the code until it works. I tend to accumulate a large number
of ad hoc modules, functions, data files with names like
foo, bar, foo2, and so forth.

In production, of course, this isn’t good enough: all sorts of things
can go wrong: servers go down, network connections get broken, runaway
processes suck up all available memory, users try to open nonexistent
files, viruses try to overflow buffers, and so forth. Code needs not
only to detect errors, but deal with them as gracefully as possible.

But if I’m working on a larger project, and working on adding new
functionality that I’m not familar with, the temptation is strong to
take the “learning” code that’s been hammered into some kind of shape,
and plop it in the middle of existing production code.

Neither approach is inherently wrong. Each is appropriate in certain
contexts. You want to keep things loose and fluid and unstructured
while learning, because by definition you don’t know what’s going and
what’s best. And you want to have things organized, structured, and
regimented in production, to make it easier to avoid and find bugs, to
ensure code quality and stability.

But this difference does mean that it can be hard to integrate new
code into production code.

Often, test code is so messy that there’s really no choice but to do a
complete rewrite. Neater test code is worse in this regard, since it
may trick you into thinking that with just a little bit of cleaning
up, you can use it in production.

So it’s important, when moving from test to production code, to ask
oneself how errors should be reported. This takes a bit more planning
ahead of time, but like security, it’s easier to build it in from the
start than to retrofit it onto existing code.

The thing that works for me is:

  1. Think of a function to add.
  2. Write a comment describing the function: what it does, which
    arguments it takes, what value(s) it returns, and what it does in case
    of error.
  3. Write the function.

In that order.

This may be more structured than you want in the playing-around phase,
in which case you should definitely consider using it during the
hammering-into-shape phase, after you have the basic functionality
working, and before you’ve started moving test code into production.
Over time, though, this kind of forethought may become automatic
enough that it doesn’t get much in the way of experimentation.

Legal Markup Language

Today at work, I had to sign some legal papers. They were pretty standard “I have read the attached policy and agree to be bound by it” stuff that all of us Full-Time Employment Units have to sign once a year.

But I’m the sort of person who believes that if I sign an agreement, I ought to at least know what it says. But I have better things to do than to read legalese all day.

The same problem applies to a lot of commercial applications: every time you upgrade, you have to agree to a EULA for the new version. For a variety of reasons, most people just click through and get on with their lives. But it would be nice to be able to know that the vendor hasn’t just asked you to sign over your firstborn.

One possible solution would be a markup and revision system for legal documents. For starters, if your job requires you to sign an Acceptable Behavior Policy once a year, you could read it carefully once when you sign on, and save a copy. Then, the next year, you can compare the version you’re given with the one you signed a year ago. If there are no changes, you can just sign it without reading, on the grounds that if you didn’t have a problem with it last year, you don’t have a problem with it now.

Of course, a lot of documents include other documents by reference. These need to be archived as well.

It would also be nice to add comments: for instance, if the policy requires you to keep your cell phone number on file with your manager so that you can be contacted outsiide of business hours, you could add “Has my cell phone changed since last year?” in the comment area.

Since big chunks of legal documents are just boilerplate text, and since many legal documents (such as software EULAs, credit card applications, car rental agreements, etc.) apply to many people, it would be nice to look them up on the net. That is, the tool on your desktop could take the MD5 hash of a clause, send that off to the legal opinion servers of your choice, and see what they have to say. For instance, the EFF could have a repository that says that certain clauses aren’t as scary as they sound; the FSF could point out which clauses will forfeit your Free Software-loving soul.

This could be a commercial service: you could pay a legal firm for online legal advice. Yes, a lawyer would have to read and research the various documents, and that’s expensive; but if they can spread the cost around several hundred or thousand clients, it could become affordable.

You should be able to specify certain details about your situation. For example, a clause that affects US Government employees might be either important or irrelevant, depending on whether you’re a fed or not. You should be able to check or uncheck “I work for the US government” in the preferences menu, so that the software will look up the appropriate response. Ditto if you don’t work at a nuclear reactor, don’t deal in foreign trade, and so forth.

One interesting aspect of this is the coding theory aspect of it: there’s a level of distrust that has to be dealt with. If you sign the yearly policy without reading it because it hasn’t changed since last year, then you probably don’t want to leave your copy of last year’s document with your employer, in case they try to change it. And if you leave a copy on your employer’s computer, they might not be above rooting around in your files to change your backup to make it match this year’s version. So you’ll want to be able to cryptographically sign each document. And of course any sensitive information that goes out on the net needs to be encrypted.

Then there’s the question of giving away information by the sorts of questions you ask. For instance, you may not want the people running Joe Random Legal Server to know that you work for the military or at a nuclear power plant, but there are common clauses that affect people who do. So while the program on your desktop needs to know this in order to give you good advice, that’s not necessarily something you need to send out on the net. So when it sends out a query about a particular clause, the protocol should allow to specify as much or as little detail as you want: if you say that you don’t deal in trade with foreign nationals, the remote server can save itself the trouble of looking up what a given clause means for those who do; but if you don’t say whether you’re in the military, it’ll send both responses back and let your desktop software decide which version to show you.

Of course, you probably don’t mind letting your attorneys know whether you’re in the military, so the software should be smart enough to send this information only to some servers and not others.

I imagine that some of this already exists: contracts are already negotiated between parties that don’t trust each other. Presumably the law firms on each side already have software that’ll tell them that section 3, paragraph 10 hasn’t changed since the last round of negotiations, so they don’t need to check it again.

And of course laws go through many iterations from original inception to bill to committee to floor vote, and are often amended by people of other parties, who’d love to make life miserable for you. The staffs of legislators must have some system for keeping track of it all. Hopefully some of it is automated.

For software, there are already software-installation tools that include presenting a EULA to the user as a standard step. It shouldn’t be too hard to put in a hook that calls the user’s preferred legal document management system.

The
Subversion version control system has a “blame” subcommand that shows you when certain lines in a file were last changed, and by whom. Legalese is so structured and formal that it seems that a similar approach should be able to help there as well.