Adopting IkiWiki

I have many problems that I’m trying to solve. The top two at the moment are that my blog is in dire need of a facelift, and I need a wiki database to sort out my last project.

But what I want is a “web-enabled” lifestyle, not a “web-dependent” one.

Over the last three years, I tried multiple tools with wiki integration - trac and a few other project managers - and was largely dissatisfied.

Yesterday I setup wordpress on my openrd box to experiment. It took me about 20 minutes to get running… and I hated it. Principally - it was SLOW. Why do we have to generate all that content dynamically from a database?The vast majority of a website or blog SHOULD be static content - original content - content worth sharing and syndicating. All the dynamic stuff should take place on the client, if possible.

I’ll be damned if I’ll contribute to the icecaps melting from the residual heat of all the server farms running useless stuff.

In a day and age when you can get a website with a virtual machine for 10 bucks a month it may seem pointless to do any of the optimizations in the underlying web protocols - but when you are on the other end of a slow (think - 3G or satellite) link, you can spend a few seconds - on every page load - cursing those that didn’t bother to AT LEAST running Yslow on their site and fix the obvious stuff.

The latency problem made me crazy while I was in Nicaragua. So I decided to continue to be selfish and work on something that worked for me, best, and for others, well, hopefully nearly as good, and forgo things like php, etc, in the interest of a highly performant blog and wiki system. This cuts my choices down on blog and wiki software considerably. In fact, to one: [ikiwiki).

Things I like (so far) about ikiwiki:

  • Serving content is FAST.
  • Open source
  • Local publishing: I can write a draft, publish it on my laptop, look at it in various browsers, fix it, publish it again, link check it, THEN push it out to the main server(s).
  • Git: I love using git elsewhere in my daily workflow
  • Mirroring capable: Assuming everything can be statically generated, we can mirror large chunks of the systems and ONLY point back to the main system for editing
  • Source code formatting
  • Webserver and database independent: Wiki content can be served up by ANY webserver - even including a wimpy openwrt box. There is no database required. I’ve got both apache and lighthttpd working so far
  • openrd enabled: I would like to open my blog up to multiple editors and the wiki to all that have a real login.
  • link checking: After 8 years of blogging (936 articles on blogger at last count), many important links have moved. Finding a sane way to spend multiple days getting everything fixed would be nice. Then I could reduce it to a once a month process.

Notably I have some hope that I can roll a tool that will let me inspect the old links via, in the hope that I can find where they point to now.

Things I didn’t like:

  • default templates

The default templates are wiki oriented and although they can be made to work for blogging - don’t generate output in the generally flowing means that I prefer my blog to look like. I anticipate mucho hacking on the perl code.

  • default output The default output is blocky, and doesn’t take advantage of the increasingly sparse vertical resolution of most (landscape oriented) displays.

  • Commenting

There isn’t one commenting system out there that I like. The one that comes the closest is disquis.

What I wanted was something that worked a lot more like netnews. In fact, netnews would be perfect. Why on earth has everyone re-invented the wheel?

  • Publishing


I’d like to be able to easily refer to my own content inside of ikiwiki, so that the publishing step takes care of the changed links. So I’d like very much to make it be both a wiki and a blog, so I can talk about [IPv6).

Features I intend to add:

  • Gzipped output. Most browsers and many web servers support serving up gzipped files as a default over-the-net compression mechanism. ** Done - lighttpd does this for me
  • Expires headers for css, images, and javascript
  • Next and Prev buttons for the blogging interface

I want to preload certain web pages. This should make navigation EVEN faster.

<link rel=“prefetch” href=“" /&rt;

  • Better support for mobile devices

I have a long rant on this subject coming up.

Stuff that would be nice:

  • Dynamic content via javascript

  • Flat hierarchy

I’d like a directory structure organized by publication date, rather than depositing all the files in one directory.

Find me elsewhere.

Best of the blog Uncle Bill's Helicopter - A speech I gave to ITT Tech - Chicken soup for engineers
Beating the Brand - A pathological exploration of how branding makes it hard to think straight
Inside the Internet Mind - trying to map the weather within the global supercomputer that consists of humans and google
Sex In Politics - If politicians spent more time pounding the flesh rather than pressing it, it would be a better world
Getting resources from space - An alternative to blowing money on mars using NEAs.
On the Columbia - Why I care about space
Authors I like:
Doc Searls
Jerry Pournelle
The Cubic Dog
David Brin
Charlie Stross
Eric Raymond
The Intercept
Chunky Mark
Dan Luu's rants about hardware design
Selenian Boondocks
Transterrestial Musings

February 10, 2011
813 words

latency usability