Brain on Fire » Blog Tim McCormack, distilled

• It was probably a mistake to use a catchall account and make up addresses on the fly. Now I get spam on every address that is published! I may do something like the fellow at unstable.nl does and have a dedicated spam address that allows me to deduplicate those, but I haven't yet figured out how to do that in Claws Mail.
• I think spammers may be avoiding honeypots by preferring email addresses that are very likely to be real -- such as those on Bugzilla sites.
• I recently switched my hosting service for my brainonfire.net email address from Lavabit (horrible customer service) to Cotse (they seem like good folks), but I still receive spam at Lavabit! I think spammers are caching MX records. This could be used against them.

You can do everything "in the cloud" these days, from blogging to posting photos to running servers. Most impressively, you can now also lose control of your files and personal information with unprecedented ease, or simply lose it, period. This is exactly the worst possible feature for the personal publishing use-cases of cloud computing. Possibly the most distressing aspect of cloud-based publishing is that it firmly designates the intangible network as the primary resting place of one's data. (I will note here that this aspect is itself what I am using to define "cloud computing" for the purposes of this blog post.) If the first place you put your creations is some hosted service on the great wide interwebs, you're playing with fire.

One of the minor pain points (but a major surprise point) of using the Ubuntu Linux package management system occurs when upgrading an application that itself implements package management. A classic example of this is Firefox, which has an extension system with a central repository, version compatibility checking, and automatic updates.

On local installs of Firefox (or in Windows), Firefox handles its own upgrades, and has the ability to warn the user if any extensions will be disabled due to incompatibility with the new Firefox version. However, when Firefox is managed by an external agent such as APT, no such warning can take place. (There's another problem here—upgrading Firefox when it is running results in gradual bitrot of the running process as it loads mismatched bits of itself from disk.)

This is totally a solvable problem. Deb packages can contain pre-install scripts that check for bad install or upgrade conditions, and I would bet they can also prompt the user for input in questionable circumstances, such as forced disabling of extensions. There's the minor issue of how to handle multiple user accounts, networked /home, etc., but these all seem solvable with a reasonable amount of effort.

I suspect this post will be too late to influence the Firefox 4 release, but I'm filing an enhancement request anyway. Hopefully the developers of other apps with package managers will take this advice as well.

I recently got started using Emacs, and I was surprised to see just how bad most of the quick-start guides are. Most lacked the basic commands and definitions that beginners really need. This is my attempt to do better. I'm a n00b myself, so there won't be much explanation, just a basic overview, some useful starter commands, and links to proper tutorials.

Today I ran into a frustrating syntax pitfall in Clojure, which I am attempting to learn using a simple homework assignment as motivation. Below is a simplified testcase containing the same mistake I had in my actual code. The code compiles, but at runtime I receive "java.lang.IllegalStateException: Var selfr is unbound.".

(defn magic []
  (println "magic happens") ; one too few closing parens

(defn selfr [i]
  (if (< i 0)
    0
    [(selfr (dec i))
     (selfr (dec i))]))) ; one too many closing parens

(defn selfr-caller []
  (selfr 3))

(defn -main [& args]
;  (magic) ; uncomment to make everything work
  (println (selfr-caller)))

If you stare at the code for a bit, you'll see that selfr is defined inside the magic function. So why doesn't the compiler complain that selfr-caller can't see it? What I didn't realize until today (with the help of some wonderful people on IRC) was that defn hoists the declaration to the top-level, where everything can see it... but the assignment won't occur until the code block is actually run.

This kind of bug is extraordinarily tricky to find, since it is ultimately a syntax error but may not show symptoms depending on the execution order of the code. I suppose this could have been prevented by having a better editor, such as one with draconian indentation support (e.g. Emacs) or perhaps a matching-paren highlighting feature.