So, I’ve decided to take the plunge as well. I haven’t yet decided to move my blog to github pages, but I have done some work to get octopress working on my existing host. This is the default octopress theme. I’m going to leave it like that for a while, because a) it works and looks fine, and b) I’m not entirely sure how to change it. As part of the migration, all of my posts were transcoded into Markdown (in some cases, back into Markdown, but the majority were straight html.) As such, some of the formatting is broken. I plan to fix them as time goes on.

Octopress has the advantage of just generating static HTML sites (which you then move to the host via rsync or git.) This makes me much happier from a security standpoint. On the other hand, I now have to have Octopress installed on any machine that I want to be able to post from.

Since comments were actually useful on my site (although I was very remiss in moderating them), I’ve moved them to disqus, as octopress can’t handle them in line.

So. What are your options?

Let’s back up a little. Why do you need to host git repositories at all? What sorts of things should a hosting solution give you? First of all, if you want to actually work with other people, and those other people use, um, different computers, it is quite convenient to have a central repository around to use as a conduit. Also, if you want to be able to push changes anywhere, a central hosted git repository is a not-very-confusing place to do so.

Generally hosting solutions range from just providing push and clone access to a bare git repository somewhere, to bundling repository browsers, bug trackers, wikis, graphs, ugh. The top end of the hosting solutions integrates everything you need to run a successful software project, the bottom end solutions do the bare minimum, letting other apps handle the metaphorical heavy lifting. Unless you are the only one going to use the hosted repositories, your hosting solution likely has to deal with account management (i.e., letting other folks get accounts, upload keys, etc.), and likely it will have to make trivial the task of adding new repositories to the service. Some other things that it is useful to know:

• ssh is the gold standard for pushing changes. It can be done other ways, but why waste your time with anything else?
• The git protocol and http (or https) are pretty common for pull protocols, although, you can use ssh too, of course. The nice thing about using http is that is almost always works (unless you don’t add the right post-commit hook). The git protocol is nice when it isn’t blocked by an annoying firewall.

And back to the main business at hand: your hosting options. This list is non-exhaustive, but it should get you headed in the right direction.

The high end:

• github:fi. This is the commercially available version of github that you can install yourself. It costs money, so it makes it hard to install as part of a stealth project. Count on paying at least $8k-ish. However, it does everything that github.com does, and looks to be quite easy to install.

• gitorious. (This project always makes me think of Duran Duran.) As an open source project, gitorious can be downloaded and installed on your own system. I haven’t tried this yet, but it looks like it has a fair number of dependencies, and no one has wrapped this thing up in a nice bow for you, so installation may be non-trivial.

• girocco. This is basically gitweb on steroids. That is, it looks mostly like gitweb, but also provides mechanisms to allow users to set up repositories, handles “forks” of projects, and can “mirror” an external git repository (that is, use a pull model rather than a push model). It is a bit non-trivial to set up, but has fewer dependcies than gitorious. You will likely have the easiest time of it if you are installing onto Debian “Lenny” (so I gather from the documentation). If you aren’t prepare to edit some of the scripts.

The low end:

• gitolite/gitosis. Both of these packages do roughly the same thing: manage user access. Project browsing, repository creation, etc. are not included. The basic technique with either tool is to create a single account (probably called ‘git’) on your host, then uses the package to add other user’s ssh keys to that account while still maintaining the idea that different users are committing to the repositories. Of the two packages, gitolite is still active and has more features, while gitosis hasn’t been updated in 3 years. gitolite is implemented in Perl, gitosis in Python.

Or, just give everyone an account on a machine and tell them the path to the bare git repositories. Or you could use a combination of straight ssh and gitosis/gitolite. With the “low end” solutions, you’d typically want to set up repository browsing (at least). Fortunately, git comes with a reasonable one, gitweb. However, there are others: cgit, Trac, and FishEye, to name a few.

Anyway, did you even know that Cocoa Emacs existed? You may have heard Of Carbon Emacs or Aquamacs, but WTH is Cocoa Emacs? It turns out that with the final stable release of Emacs 23.1, it came with a Cocoa native build option. Thus, Cocoa Emacs is Now the standard, no-nonsense build of Emacs for OS X. So, how does Cocoa Emacs compare to Carbon Emacs? It acts and feels mostly the Same, although I think it looks a bit crisper and feels a bit faster (which is probably an illusion). It is smaller on disk (95 MB vs 157 MB), and, of course, it is based on a newer version of Emacs Itself. It is The Future!

There are two things that irritated me with Cocoa Emacs when I Switched:

1. Meta is, by default, mapped to the option key. However, this is easily fixed.
2. Carbon Emacs came with a built-in version of aspell. With Cocoa Emacs you need to get aspell separately. This is less easily fixed, but it isn’t too bad.

You can get a pre-built stable version of Cocoa Emacs from Here, or nightly builds from here.

Step 1: Switch the meta key back to the command key, where it is meant to be. This can either be done via Customize, or you can do it manually with elisp. Manually, add: (setq ns-command-modifier 'meta) to .Emacs. This same thing can be done simply via Customize:

1. M-x customize,
2. go to Environment->NS,
3. and change the “Ns Command Modifier” option to “meta”.

You can map option to something else, keep it is “meta”, or unset it altogether (which is how it behaves in Carbon Emacs, and probably what You want).

Step 2: Getting aspell. If you never ask Emacs to spell check anything, you can ignore this. There are three Ways that I’ve thought of to get aspell:

1. Copy it from Carbon Emacs. I haven’t actually tried this, but it should be possible to copy it from the Carbon Emacs bundle into the Cocoa Emacs bundle. You will probably need Contents/Mac OS/bin/aspell and aspell-import, and Contents/Resources/lib, and Contents/Resources/site-lisp/site-start.d/builtin-aspell.el. Good Luck.
2. Install aspell via macports. If you already have macports, this is probably the way to go. To do it this way:
   • % sudo port install aspell
   • % sudo port install apsell-dict-en (or some other language dictionaries)
   • In Emacs: M-x customize-option, ispell-program-name, and set the value to /opt/local/bin/aspell.
3. Get it by installing cocoaAspell. This is what I’ve done currently.

CocoaAspell both delivers a version of aspell (to /usr/local/bin) and also delivers a preference pane for getting it configured. Nifty, but I had to manually fix the aspell configuration to point it to the dictionaries, and you also need to modify the ispell-program-name variable (which can be done via Configure, as well). To fix the aspell configuration, I edited /usr/local/etc/aspell.conf, changing: dict-dir /usr/local/lib/aspell-0.60 to dict-dir /Library/Application\ Support/cocoAspell/aspell6-en-6.0-0 Or, I suppose, you could copy the dictionaries back to /usr/local/lib/aspell-0.6.0.

However, I did discover that if you are running a 64-bit perl, which you probably are, you need to get the 64-bit Oracle instantclient release. If you build DBD::Oracle and then cannot load the module because of missing symbols (e.g., _OCIAttrGet), then what is happening is that you linked against 32-bit libraries which cannot load from the 64-bit perl instance.

Update: Sadly, since I have been such a blog slacker, I was able to upgrade to wordpress 2.7.1 while this post was still the top post. Using svn did, in fact, make this the easiest wordpress upgrade I’ve done.

Update 2: Even more sadly, I just upgraded to 2.8.1.

1. Install instantclient. You will need the basic and sdk modules. I suggest also getting the sqlplus module while you are at it. I put this in /usr/local/instantclient_10_2.
2. Modify your .bashrc (or whatever) to set ORACLE_HOME and DYLIB_LIBRARY_PATH to /usr/local/instanclient_10_2.

3. Get DBD::Oracle from CPAN. (I got 1.22). Here is where it gets tricky: In Terminal:

   % perl Makefile.PL

   This generates Makefile.

4. Edit Makefile, changing: NMEDIT=nmedit to NMEDIT=echo
5. Edit dbimp.c, removing all code that references dump_env_to_trace(). I found a patch at macosxhints.com, but this is tied to a particular release of DBD::Oracle. I decided to use my mad programming skillz to logically do what was needed. Hopefully this will be fixed in some future version of DBD::Oracle.

6. Again, in Terminal:

   % make && sudo make install

And that should do it.

Back then, I wanted this project to be unquestionably mine. I was paranoid enough to believe that if I used any of my employer’s equipment, network access, or time that my employer might claim ownership. Why they would want to is anyone’s guess.

So I was very careful to only work on python-rwhoisd at home, on my own time, on my own equipment. The initial version took me two weeks of nights and weekends. Hm. That makes it sound like I was furiously coding into the wee hours. I was actually only spending a few hours each day on it.

Python was a joy to use. My day job was in Java (and Perl) and it felt extremely liberating to be able to write so much code with so little typing. My favorite part was discovering that as I learned more about Python, my code kept getting smaller without getting less readable. Amazing!

Even though I had basically just written python-rwhoisd to learn a new programming language, I was planning on releasing it. I didn’t think that many folks would want it. RWhois wasn’t (and still isn’t) a popular protocol. But some of my colleagues were evangelizing IRIS at the time, and urged me to not release. They thought that it would muddy the waters, so to speak. So I didn’t release it, and then I basically forgot about it.

Fast forward five years. Just two weeks ago I suddenly wanted to learn how to use Git. I played around with tutorial-like git repositories, but it wasn’t enough. I needed something real to work on. I was casting about for a project that I could use, and I ran across python-rwhoisd, mouldering in a local CVS repository.

I had things that I thought should be improved about python-rwhoisd before attempting to release it again. The main thing was to add IPv6 indexing support, which I had done for the C version several years before. While this wasn’t a perfect project for learning Git in all of its glory (for that, I would need collaborators to merge with), it was good enough. Several days later, I’d added the IPv6 indexing and search support, and it was time to release it.

While I don’t expect there to be any major outpouring of interest over python-rwhoisd, it still should be easier to run than the C version (at least, for small datasets), and it should be possible to get it working on Windows without too much effort.

Get it here.

1. It will be nice once there are distribution packages for unbound. I spent more time that I would like (which is zero) figuring out where to put the log file, pid file, etc. Of course, I was installing it on a machine running Fedora Core 5…
2. I was forwarding a zone to a nameserver running on localhost:20053. There is a gotcha to doing this, as, by default unbound won’t send any queries to localhost. You have to add a ‘do-not-query-localhost: no’ config line to fix it. Maybe this is something unbound-checkconf could detect?
3. unbound’s configuration defaults leave it locked down fairly tightly. I had it running, but on my other machines, it seemed so slow – turns out, my queries were timing out and I was hitting my ISP nameserver. Make sure you add your networks to the ‘access-control:’ config parameters.
4. I turned up the logging to debug some of my issues. Looking at the log was uncanny.

Anyway, it didn’t take all that long to set up. Hopefully relatively soon I (or someone else) will write up how to configure unbound to run in a few different scenarios.

It turns out that in general, to prove the nonexistence of a name using NSEC you have to show at most two records, one to prove the name itself doesn’t exist, and the other to show that you didn’t delegate some parent of it. Often the same record can do both. In NSEC3, it turns out, you have to show at most three records. And if you can understand why, then you understand DNS better than almost anyone else on the planet.

One of the fascinating things about working on NSEC3 was that it forced us to really understand how existence in DNS works. Basically, we had to develop the general form of the theory when we already had a special case (in NSEC). So, after we figured out how NSEC3 had to work, we actually knew more about how NSEC worked. For me and our co-editor Roy, this RFC culminates the 2nd round of working on the some of the problems that NSEC3 solves. The first effort was “DNSSEC Opt-In”, now published as an experimental RFC, RFC 4956. (That effort was also tied up in DNS minutiae and political wrangling and ultimately failed to make the IETF standards track). For us, it feels more like the culmination of 7 years of work.

Idea #1: Cache Poisoning Resilience

This would be a draft that describes steps beyond RFC 2181 that a resolver must do to protect itself from cache poisoning. (RFC 2181 addresses this problem by introducing credibility rules in section 5.4.1.) Modern caching resolvers need to do more to protect themselves from name poisoning attacks like malicious CNAME chains. I would expect this draft to be able to lay out a few simple rules like:

• Discard any RRs in a response that are “irrelevant” (i.e., answer RRs that do not match qname/sname, addtional RRs that don’t match names in the RDATA of answer and authority RRs, etc.)
• Discard any RRs in a response that are not at or below the queried zone.

Update: A draft similar to this was written in 2009 by my friend Wouter: draft-wijngaards-dnsext-resolver-side-mitigation-01. However, it doesn’t appear to address my suggested rules.

Idea #2: Authoritative Servers Should Not Chase CNAMEs

This is a draft discouraging authoritative servers from chasing CNAMEs out-of-zone (or, optionally, at all), based on conclusions presented in draft idea #1. This draft could either side-step or confront other possibly controversial things about CNAME processing, like whether or not the authority section should apply the head or the tail of a CNAME chain.

Idea #3: DNS Name Compression Standards

A draft mandating the DNS name compression only be done in one direction. Virtually all (or perhaps even actually all) implementations have DNS compression pointers only pointing to earlier in the message. This draft would propose that forward-pointing compression pointers should be treated as format errors. This would accomplish two things:

1. Simplify what implementers need to support when parsing messages, and
2. Outlaw any possibility of having to deal with a compression pointer loop.

And, in the process, effectively codify standard practice.

Now, I have no idea what is in the original bachelor chow (nor do I want to know), but my bachelor chow is just the name I’ve given to the worst thing that I cook for myself on purpose. So, here is the basic recipe:

Makes one serving:

3-4 oz. pasta, preferably penne, but anything will suffice.
1/4 jar pasta sauce, any tomato-based variety.
Shredded cheese. I use Sargento’s 4-cheese mexican.

1. Cook the pasta. You can salt the water, but I’ve been running periodic experiments with not salting the water, and so far, I can’t really tell the difference. It is even less important with this recipe, since taste is clearly not high on the agenda.
2. Prior to completely cooking the pasta through, drain the pasta. Overcooking it is OK, undercooking it sucks, though, so err to the side of too long. Deposit the pasta into a microwave-safe plate or bowl. You know, the dish you are going to serve this on.
3. Optionally stir in a little bit of olive oil and salt (preferably kosher or sea salt). You can stop right here and have a pretty good dish, even if it is nutritionally unbalanced. It is only going to get worse from here.
4. Pour the (cold) pasta sauce over the pasta. Do not stir it in, just let it sit on top.
5. Sprinkle the shredded cheese on top. Again, no stirring.
6. Microwave on high for 2-3 minutes, until the cheese has melted.
7. Enjoy. Or, at least, Tolerate.

This recipe violates almost every thing I’ve learned about cooking, but it takes me back to my just-out-of-college days when I was equally as lazy and less polluted by cookbooks, Cooks Illustrated, and Food Network.

Update: I’ve managed to work through the major issues, so here is the source RPM for Fedora 7. I’ve put some actual binaries here. This version doesn’t replace the stock Emacs-22.1. Instead it installs into /usr/local, but can easily be made the default version via the alternatives command:

alternatives --set emacs /usr/local/bin/emacs-23.0.0

Now that I have a working version of Emacs with anti-aliased font support, I’ve been hunting down what font to actually use. Bitstream Vera Sans Mono is a good default, but at the moment I’m trying out Anonymous. For the curious, the bit of elisp that I’m using to set the fonts is this:

(if (eq window-system 'x)
    ;; if we have the Xft-enabled version of emacs...
    (if (>= emacs-major-version 23)
    (progn
      ;; note: Anonymous doesn't come with Fedora.  You can get it here:
      ;; http://www.ms-studio.com/FontSales/anonymous.html
      (set-default-font "Anonymous-10")
      (setq bvsm10 "Bitstream Vera Sans Mono-10")
      ;; unfortunately, anonymous doesn't have bold or italic
      ;; so, use bitstream vera sans mono for that
      (set-face-font 'bold (concat bvsm10 ":weight=bold"))
      (set-face-font 'italic (concat bvsm10 ":slant=oblique"))
      (set-face-font 'bold-italic
             (concat bvsm10 ":weight=bold:slant=oblique"))
      ;; ...and no proportional font, for that matter
      (set-face-font 'variable-pitch "Bitstream Vera Sans-10")
      (add-to-list 'default-frame-alist '(font . "Anonymous-10")))
      ;; otherwise...
      (progn
    (set-default-font
     "-*-lucidatypewriter-medium-r-*-*-14-140-*-*-*-*-*-*"))
      )
  )

I’m doing it this way (instead of in X resources) so that launching Emacs-22.1 will still work. If you stick with Bitstream Vera Sans Mono (or DejaVu LGC Sans Mono which is very similar), then you won’t have to bother with overriding the bold, italic, and bold-italic font settings as those will basically just work once you set the default font. You would still have to deal with overriding the proportional font, however.

Update: instead of getting an iPhone, I’ve gotten a Nokia 6102i with no contract. Nothing at all like an iPhone, but it is a credible phone. I may change my mind if I’ve got to take it overseas, though. By paying for the phone and not getting a new contract, I do still reserve the right to get an iPhone in the not-too-distant future.

1. Discover Black Ink. It has a 30-day trial period
2. Try for 30 days. Like in the beginning, like at the end.
3. Buy it. I go the the online store and pay via paypal.
4. Wait for 3 days. See credit card charge go through.
5. During this time, fail to check the spam traps.
6. Wait for 4 more days. Nothing from Red Sweater Software.
7. Send email to support@red-sweater.com asking for actual registration code.
8. Wait 3 more days. Silence.
9. Discover that somehow, searching for “red-sweater” in Mail.app doesn’t find mail in the spam folders.
10. Eventually find 3 emails from Daniel Jalkut with your registration code.

Hmm.. The online store page says “…usually within a few minutes”. Is two weeks to wait long enough? I guess after that I’ll be reversing the charges. Or something.

Update: All fixed now. I am somewhat amazed that posting to my blog was an effective means of communication. I’m guessing this reflects more on Red Sweater Software’s customer service diligence than anything else.

Update[2]: So my friend Sean summed this whole event up as: “You posted to your blog, Daniel Jalkut read it, said ‘check your spam box, dumbass’, and now you look like an idiot.” Yep.