The following guide is to serve as a quick introduction to Git-SVN, hopefully making it easy for others (e.g. fellow Osmosoftonians) to get started.
Note that I’m an enthusiastic command-line user, which is why this guide does not cover any GUIs. Also, I’m far from being a Git expert at this point, so feel free to suggest improvements!

Initial Setup

• check out Subversion repository:^[2][3]

  git-svn clone -T[trunk_subdir] -t[tags_subdir] -b[branches_subdir] [URL]

  (e.g. git-svn clone -TTrunk -tTags -bBranches http://svn.tiddlywiki.org)

• create branch for work in progress (WIP):

  git checkout -b [branch]

Working with Git

• modify files on WIP branch, creating (and amending) local commits:^[4]

  git add [files]
  git commit -m "[message]"
  git commit --amend

• switch to master branch:

  git checkout master

• grab changes from WIP branch:^[5]

  git merge --squash [branch]

• commit changes and push to Subversion:^[6]

  git commit -a -m "[message]"
  git-svn dcommit

• switch back to WIP branch:^[7]

  git checkout [branch]
  git merge master

Useful Commands

• git branch (list, create or delete branches)
• git diff [-w] [–color-words] (display changes)
• git apply (patching)
• git status (working tree status)
• git log (commit history)
• git reflog (comprehensive history)
• git-svn rebase (update local repository)
• git checkout [files] (revert changes)
• git config (user preferences)^[8]
• git gui (graphical user interface)
• gitk (repository browser)

Thanks to Kerry for getting me started with Git in the first place!

1. The same is true for other DVCS, like Mercurial — though I have only worked with Git so far.
2. Cloning an entire Subversion repository can take a while (mostly due to protocol overhead) — an alternative is to grab only the latest revision: git-svn init [URL]; git-svn fetch -r HEAD.
3. Instead of manually specifying directory names for trunk, tags and branches, -s can be used for the standard naming convention “trunk”, “tags” and “branches”.
4. Use git commit -a -m "[message]" to automatically add all modified files.
5. Squashing means that several local commits can be merged into a single commit.
6. dcommit will automatically perform an update (rebase).
7. The merge operation is required due to the rewritten commit history on the master.
8. My current .gitconfig file:

   [user]
   	name = FND
   [alias]
   	ci = commit
   	cia = commit -a
   	cim = commit -m
   	ciam = commit -a -m
   	co = checkout
   	diffi = diff --color-words
   	diffw = diff -w
   	diffx = diff -w --color-words
   [color]
   	branch = auto
   	diff = auto
   	status = auto
   [color "branch"]
   	current = yellow reverse
   	local = yellow
   	remote = green
   [color "diff"]
   	plain = white
   	meta = yellow bold
   	frag = magenta bold
   	old = red bold
   	new = green bold
   [color "status"]
   	header = white
   	added = yellow
   	changed = green
   	untracked = cyan

Our first idea was to use TiddlyWiki to aggregate data from various social networks, turning into a sort of global dashboard for users. However, the OpenSocial API does not permit this (yet, according to Google).
So we went for the opposite approach, embedding TiddlyWiki as an OpenSocial gadget. This opens up quite a number of interesting possibilities — for example, users composing and sharing notes.

The first step was to simply take the entire TiddlyWiki source code and wrap it into the required XML framework. Apart from having to deal with nested CDATA sections, this actually worked without too many problems (also thanks to the gracious help from a Google expert). We used TinyTiddly’s externalized core to save us the headache of excessive scrolling through the source code. Since gadgets are limited to a certain display size, we decided to apply a theme designed for handheld devices^[1] (created by BT’s James Lelyveld).
The preliminary results can be seen here; the XML gadget file is located here.

The next steps, should we decide to follow up on this, are to integrate this with ccTiddly, as this prototype does not yet provide any way for saving the inputs. Also, there are some issues with running TiddlyWiki within a frame — for example, paramifiers and direct permalinks to specific tiddlers do not work properly.

While I’m not a huge fan of social networks (apart from Twitter, if that counts), this was a very interesting experience. Overall, the event was very enjoyable and well-organized, with quite a number of interesting attendees.

1. using Chef to build it from source

This bookmarklet works in two steps: On the first click, the TinyURL is created. The second click then extracts both URLs from the page and presents them in a newly-created input field, ready to copy and paste.
The original plan was to circumvent the first step by using a hidden IFRAME element. However, due to XSS restrictions, that seems not to be possible.

Limitations

TinyURL currently strips in-page anchors from the original URL (e.g. http://domain.tld/index.html#section becomes http://domain.tld/index.html).
I’m afraid there is nothing I can do about this.

Also, some error handling is currently missing, which might lead to JavaScript errors in case TinyURL change their HTML structure.

Source Code

function extractTinyURL() {
    var txt = document.body.innerHTML;
	var RE = /(http:\/\/tinyurl.com\/\w+)/;
	var original = document.getElementsByName("url")[0].value;
	var tiny = txt.match(RE)[1];
	return tiny + " (" + original + ")";
}

function displayTinyURL() {
	var txt = extractTinyURL();
	var c = document.createElement("div");
	c.style.position = "absolute";
	c.style.top = "25%";
	c.style.left = "25%";
	c.style.width = "50%";
	c.style.width = "border: 2px solid #AAA";
	c.style.padding = "50px";
	c.style.backgroundColor = "#EEE";
	var e = document.createElement("input");
	e.setAttribute("type", "text");
	e.setAttribute("value", txt);
	e.style.width = "100%";
	c.appendChild(e);
	document.body.appendChild(c);
	e.select();
}

if(document.location.toString().indexOf("tinyurl.com") == -1)
	document.location.href = "http://tinyurl.com/create.php?url=" + location.href;
else
	displayTinyURL();

Feel free to suggest improvements!

1. see here for my reasoning on this
2. created using Bookmarklet Builder

Some folks join the Peace Corps. Others join groups such as Habitat for Humanity. Still others choose to write open-source software.

Source: Josh at The Daily WTF (slightly modified)

Many people believe that the open-source principle equals grassroots democracy.
However, I don’t think that’s a fair assessment.

While community involvement is generally important and valuable, it is also a double-edged sword.
For certain issues, opening the debate to the community at large can prove an obstacle to making progress. That’s because discussions involving a large number of people can easily get out of hand — especially if there is no tangible concept yet to base the discussion on.
Also, many tasks require a certain expertise, and should thus be delegated to qualified contributors. The wisdom of crowds (as described by Surowiecki) is no panacea, but only applies to certain kinds of decisions.

That is not to say the community should be excluded though. The entire process needs to be transparent — not only to avoid alienating contributors and users, but also because diverse opinions and perspectives are essential to achieving optimal results (e.g. to avoid common traps like coders’ tunnel vision).
But this involvement should be timed carefully. Gathering feedback on a well-thought-out concept will often be more productive than starting a discussion without a solid foundation.

Bottom line: In my opinion, open-source projects are more about transparency and a diverse assortment of skills, rather than forcing everyone’s direct involvement on every single level.

Thanks to Saq and Phil for their insights on this topic.
I’d be happy to continue the discussion in the comments…

The first thing that needs clarification: In practical terms (I won’t go into the technical details), the screen does not actually offer a resolution of 1200×900, but only 800×600 — however, the picture is as sharp as if it was 1200×900.
That was a bit of a disappointment at first, as I had expected to browse the web with a “desktop resolution” (in my naïveté, I expected there to be a toggle switch between hires monochrome and lores color mode).

Much more of an annoyance was the Sugar interface though — it proved to be way too limiting for an experienced computer user like myself (e.g. documents can only be saved through the Journal activity).
I was delighted to learn that I could install a different window manager — so I opted for Xfce, giving the XO a much more familar interface.

That in turn enabled me to install pretty much any application that could also be found on a regular Linux PC — like Firefox for web browsing, as well as MPlayer and VLC for multimedia files.

Unfortunately, my XO is suffering from the sticky keys syndrome; the left ALT key is stuck, which makes the keyboard pretty much unusable. Nobody seems to be quite sure what the cause is — whether it’s a hard- or a software issue — so it remains to be seen whether there’s gonna be a fix for this.
In the meantime, I’ve figured out that there’s a workaround; remapping can be used to disable the ALT key.

All of this has taught me a lot about Linux (sort of… ) — knowledge that might come in handy, considering that I intend to become a full-time Linux user soon (more on that at a later time).

Beyond that, I’m not entirely sure what to use this machine for, as it’s not really suitable for day-to-day productive use. For example, I have yet to use my beloved TiddlyWiki on this machine.

Bottom line: The XO is not quite what I had expected, as it’s hardly a replacement for a “proper” UMPC. But it’s definitely a nice gadget — a geek toy!

PS: A few weeks ago at the airport, the security guard was quite enamored of the device — but she gave it back to me, eventually…

The problem: Finding accommodation in the London area is a major challenge.
So let’s tap into the wisdom of crowds here — help me get my bearings to find a nice, affordable flat to live in.

These are my main criteria:

General Area

• I wouldn’t mind - indeed, I would prefer - living a little outside the city, up to about one hours’ commute from Osmosoft Towers in central London.
• I have friends in Hatfield, so the Hertfordshire county might be a good place to start with. (This might have the added benefit of being reasonably close to Stansted Airport.)

Local Area

• The neighborhood should be reasonably clean and safe, of course, but I don’t need to live in an excessively posh or upscale area.
• Good public transport connection as well as close proximity to supermarkets and retail stores are essential (I won’t bring my car).
• Being near a sports club would be nice, as I intend to take up table tennis again (though this isn’t a major concern).

Housing

• I would prefer not to live in a house share (if I end up in a house share anyway, I would probably insist on ensuite facilities).
• I imagine a nice flat with one or possibly even two rooms (in addition to bathroom and kitchen).
• It should also be furnished to some extent, at least with regards to basic appliances like an oven/stove and a fridge.

Since I’m not entirely sure yet what to budget for these requirements, a few rough estimates might save me some trouble there.

I would immensely appreciate any help you might have to offer!

My first impression of the device was very good; it looks fun and sturdy. The display delivers a very crisp image, and the screen can also be rotated.
I haven’t done a lot of testing yet — let alone read the manual (which is only available online) — but it can safely be said that the Sugar interface takes quite some getting used to for regular PC users like myself.
The keyboard keys are small (of course) and feel a bit wonky, as there is no proper pressure point; the contact points have little more than a rubber coating, but I assume that’s intentional to make it more resistant. It might take some time, but I’m confident I’ll get used to typing with this.
Based on this very preliminary review, I think I’ll have a lot of fun with this device - despite some of those negative points.

I wanted the XO primarily as a fun gadget, but its small size will certainly prove useful in many ways — e.g. serving as an ultra-portable device used when carrying a regular laptop might be too cumbersome (e.g. in the car… ). Also, it has been suggested that the XO might “be a great ‘distraction free’ writing machine” — sounds plausible!
How I’m actually gonna end up using it, though, that is yet to be seen (I’ll report any findings here). Either way, I will almost certainly do a lot of TiddlyWiki stuff on it, using it both as a notebook and as testing platform.

From my perspective, the XO hardware has several advantages over its main “competitor”^[1], the Asus Eee. The main criterion here is the larger screen and higher resolution^[2] — not to mention the exclusiveness of this device (which, personally, I don’t much care for though)… A drawback is the lower processing power (e.g. 433 MHz vs. 900 MHz CPU) and smaller storage memory (1024 MB vs. 4/8 GB).
For more information, there’s an interesting in-depth dissection of the XO-1’s hardware on bunnie’s blog.
Ultra-portable laptops seem to have become a fad (again?), with a number of companies jumping on the bandwagon — so we will certainly see more developments in this field.

A few words on the OLPC project in general:
I’m not entirely convinced that a laptop is what children in poor countries (or regions/districts) need the most.
However, a laptop does allow for easier distribution of reading material — think downloading an e-book vs. ordering a truckload of paperbacks. So this might indeed provide a significant boost in spreading education.
However, I’m still skeptical as to whether the money that went into this project could not have been used in a better way. We might be wiser five or ten years from now. At the very least, the kid getting that second laptop funded by my order will have some fun with it, and that should be worth something…

1. Of course the OLPC project is non-profit, and the XO-1 not a regular retail product…
2. In monochrome mode — which should be sufficient for most tasks — the XO’s 7.5” screen has a resolution of 1200×900 (800×600 in “backlit” mode). The Eee’s 7” screen has a tiny resolution of 800×480 pixels (a larger version is in development though).

• After his initial probing draft, Phil has published the Ten Commandments of Twitter. Definitely a must-read for any Twitter user!
• In a similar vein, Paul has come up with the distinction of Twits and Twerps. (I’m definitely a Twit — I hope… )
• Finally, JP has a very thoughtful posting discussing the underlying issues of these recent developments.