As these sort of things go, this is only relevant for today (May 5, 2009) and will rapidly become out of date as versions are upgraded, betas are finished, and URLs change. YMMV.

This order works the best, on Mac OSX:

• Download the Adobe Flash Uninstaller: here
• Upgrade to Firefox 3.5 beta, whatever is latest: http://www.mozilla.com/en-US/firefox/all-beta.html
• Download Flash 9: here
  • If you’re on PowerPC (which my Powerbook is), you’ll have to open the .dmg and copy the two files to /Library/Internet Plug-Ins/
  • If you’re on Intel, run the installer app.
• It probably doesn’t hurt to run Disk Utility – Repair Permissions, as other guides for this suggested, but this is just Mac voodoo or snake oil. Can’t hurt, though.

Your Firefox should now be shiny and new, and your Flash videos, especially on Vimeo in HD, will hopefully be less stuttery.

Enjoy!

Instead I’ll say that it was a great weekend, I really enjoyed it, and the folks who did the planning really pulled it off! Excellent location, excellent food, excellent people!

My photos from the event are on my flickr

• Brooks Andrus –
  
• Gustavo Duartes: Software, computers, and business – particularly Lucky to be a Programmer
  
• Giles Bowkett
• Code Climber blog by Ethan Vizitei

And if you haven’t read it already, you should go back through Steve Yegge’s blog posts. He’s written some really good stuff.

I agree with this guy, though.

The Pirate Bay launched their free WordPress.com-clone service a few months back, with the added promise that they would not censor content as long as it did not violate Swedish law. I set up a blog, at mathiasx.baywords.com and briefly posted there as an experiment, without advertising it much via the usual means. The service leaves a lot to be desired (there’s no file/image upload and there’s a limited set of themes to choose from, with no way to customize the CSS), but then again, for a WordPress.com clone, it does reasonably well.

The main issue seems to be that only people with Baywords accounts can comment, and I’d rather have a way to comment without forcing the user to sign up for any service, perhaps using OpenID to validate identity but not leaving commenting wide open for spam.

My posts at that blog were quite literally inspired by the main character in Cory Doctorow’s latest novel, Little Brother. To that end I was going to write a few posts about some topics one might run into at DefCon, and I made a video of myself nuking an RFID tag in a microwave.

But, due to the problems with the Baywords service, I’ve now abandoned it and left my little experiment there. At some point I’d like to pull all the posts I’ve ever written from all the blogging engines I’ve used (including my own blogging system that I wrote all in one big perl file, circa 2001-2004, with an RDF feed that predated RSS 1.0 spec) into a sort of meta-blog with a huge timeline. Until then, I’ll just link things together with RSS glue and pull them into my soup.io tumblog.

This blog has not been particularly focused enough on code and technical ideas as much as I’d hoped, or at least I haven’t updated it enough to justify writing much more here, either. So this, too, will get pulled into my soup, and I may post here occasionally, but right now, I’m looking to abandon the sort of long-form blog posts in favor of short posts on my soup tumblog and twitter messages.

Thanks for stopping by.

When I finally did get a connection on my laptop and sat down to work on git-wiki, which I’ve been hacking on, I saw that a new version of Rubygems had been released (My laptop is frequently behind on software versions, as I only use it consistently while traveling.) I thought it’d be prudent to do a gem update --system while checking the changes other people have been making to git-wiki on GitHub. Unfortunately, gem has a major flaw right now, or rake’s creation of Makefiles does, or some combination of the above are responsible. I haven’t yet figured out the responsible party. As far as I can tell, both tools were never meant to care about code that is to be compiled, and therein lies a flaw.

It seems that whenever Ruby extensions written in C are compiled (in this case the http11.bundle compiled for Mongrel), the compiler is forced to assume the architecture is i386 (PC), despite the fact that it was building on my old PowerPC-based Powerbook. gcc tends to fail at this step, and even after the Makefile is corrected there are errors on the Mac with Ruby redefining GNU C library functions for itself (instead of coming up with new functions to call that are ruby-specific). Further, the error in compiling isn’t handled by either rake or gem and the installation continues. This means the user tends to get a confusing error message sent out by Mongrel or whatever framework they’re using that uses a Mongrel:

In retrospect, this failure to compile C extensions is also the reason I was unable compile Ruby on my Sun Cobalt Qube 3 (an x86 based microserver, but lacking a modern OS with a packaging system). The Ruby compile tended to die at the stage that it was creating the socket extension to Ruby.

Back home now, I’ve cloned my laptop’s git-wiki /wiki repo back onto my desktop and thought about how best to track down the source of the compile issues, or who even to take the errors up with. There are any number of mailing lists and places I could complain about this problem. I thought instead that a blog post, even on a lowly blog such as mine, is probably the best course of action. And viola! This post was formed. Now, does anyone know what’s going on, and more importantly, how to fix this?

Update: So, this issue seems to stem mostly from having XCode 2.4 or older. I upgrade to 2.5 and noticed that I no longer had issues in the linking stage (the tool is ld, and it has to do with processor architectures and finding libraries, both of which changed between XCode versions). So now it works, unless I want to build universal binaries. (when I build stuff for myself, that’s not really a priority)

So if you get this issue and want to fix it, either upgrade to XCode 2.5 or upgrade to Leopard, which comes with XCode 3.0. This also means that Leopard users probably never had this particular error.

I remember reading back in the early days of blogging a list of do’s and don’ts for bloggers, and the author listed apologizing was one of the things you should never do on your blog. I wish I could remember where I read that. I also caught on to the whole completely-transparent business ideas from the past few years. Add those two concepts together and I was confused about whether to apologize or explain things, so I thought I’d just throw out a simple update post.

Since last Thursday I’ve been visiting my parents in the rural portion of Michigan. What I didn’t count on was that I wouldn’t have much time to write more blog posts, but also the fact that I wouldn’t be able to find a reliable broadband connection, much less a coffee shop or rest station with wifi. So the posts about GitHub and git-wiki never got published.

Perhaps my own new maxim should be:

Don’t promise your readers any posts until you’ve written them.

git is an open source project started by Linus Torvalds and currently maintained by Junio Hamano, intended to replace the proprietary BitKeeper system that the Linux kernel project used. Like Monotone and Mercurial, git is a modern decentralized revision control system that makes use of cryptography. The ‘repo’ doesn’t live on one server, instead every local copy on a developer’s machine is a full repo, with full version history. Developers initially copy the repo from somewhere (also known as branching or creating a clone) and make changes locally, commiting changes to their local repo as they code.

The process of combining two branched repos in SCM is known as merging. When developers are ready to share their changes, they can ‘merge’ their work back into other developers’ trees, or others could pull down changes from the developer’s local repo and work from there. Merging was previously a time-consuming and frustrating task with other SCM tools, but git needed to be able to merge the repos of the Linux kernel developers fast. In fact, git makes it so much easier than previous SCM tools to branch and merge both local and remote repos that developers can keep several branches around locally for various changes to live in.

The best image I found to represent this style of passing around changes has nothing to do with version control, but gives a good idea if you think of ‘messages’ as the changes:

Because all the cool developers hack on laptops now.

Subversion & CVS, on the other hand, use a centralized server that all changes must be downloaded from and uploaded to; making concurrent work possible. But a centralized server may be restrictive if a development team is scattered across the globe (as in the Linux kernel team & most open source projects) rather than scattered across the cube farm. (As a side note: git does allow for public repo servers, but that is a whole ‘nother topic.)

Best of all, git is fast. Faster than your filesystem, in some cases. You can throw data in its repo & 10 years later it ensures you get the exact same file out, due to cryptographic hash checking. SCM tools of years past couldn’t vouch for the integrity of your files, in fact checking in files was more likely to corrupt files at some future point, rather than protect them.

I’m not going to go into all the features of git or why it’s faster, there’s plenty of resources already. If you’ve used Subversion (svn) in the past, then this tutorial is probably your best bet.

Since this turned into more of an overview of git rather than covering the two topics I had in mind when I started, look forward to two more posts this week: one on GitHub, a git repository hosting service, and git-wiki, a wiki intended for personal use that checks its changes into a local git repo.