It seemed strange that a character in the game sounded so much like my wife. Also, my character had just looked at her watch, and it was way after 1. And there wasn’t anyone else in the room.

“Did you hear me?”

The surround sound on this game is great, too. It sounds like that voice is coming from right behind me. I turn my character around, but don’t see anything. Kinda creepy.

Then it dawns on me, and I press Start, and turn around.

This is the effect Heavy Rain has on me. The story in this game is that gripping, compelling. It propels you forward naturally, the pacing keeping you engaged without overwhelming. This game has the highest production quality of any game I can recall playing. I’ve seen the phrase interactive movie thrown around here and there over the years, but Heavy Rain turns that on its head; it is not a movie; it is doing things with storytelling that a movie can’t do, for a number of reasons. It’s not a visual novel either, because it is far more than a series of cinematic sequences with decision points. Rather, we have something entirely new here, and it is an ambitious and compelling idea.

I have been known to opine that a great piece of art is one that plays to the strengths of its medium. A great novel uses the written word to convey something that can only be conveyed with writing. Certain combinations of words have great effect on the reader, in a way that the same scene in a movie might miss entirely. Literature has the advantage of narration; a voice that can drive the story in ways that are unique to the form, and great stories capitalize on this.

A great movie, on the other hand, uses the fact that it is a visual medium to convey powerful emotional content that would feel flat in writing. Lighting, facial expression, and tone of voice can be evocative in a movie like they never could in writing. Plays have their own framework, and they are at their best when they exploit this fact. Ditto music, painting, and other artistic forms.

Heavy Rain is the first game that I have encountered that takes this approach with a video game. It is treating the game as a work of art, and not simply an entertaining way to kill time. Sure, other games have stories and beautifully rendered scenery. They have characters that portray emotion, sometimes. But Heavy Rain uses the canvas of video games to tell a story in a unique way; you couldn’t copy this story to movie or novel form without losing, or at least changing, something important.

Traditional games, even ones with great stories, are hampered by a number of problems. One is the tendency for this pattern to emerge:

1. Plot (cutscene, dialogue tree, etc)
2. Gameplay (random battles, shooting bad guys)
3. Goto 1.

In Heavy Rain, the plot and gameplay are intertwined inextricably, and the gameplay doesn’t devolve into the usual video game tropes of, well, killing Bad Guys. It’s more nuanced than that, and you observe a story unfolding in which your actions have real consequences, both minor and major, and in both the short and long term.

It’s been obvious to me for a long time that video games could potentially be art, evoke a broad range of real human emotion in the player, and deal with deep themes without resorting to ham-fisted tropes or dulling the emotional experience with tons of unrelated gameplay between evocative scenes. Heavy Rain is the first time I’ve seen this potential realized.

Anyway, there are people in Second Life that I like being able to communicate with. However, when I’m at work, it’s a lot of trouble to create an SSH tunnel home, then forward a text-only client like ommviewer-light just so I can log in and see who is online.

So, as I always do, I went way overboard and created a system that can relay chat between an IRC channel (or channels) and any location (or locations) inside Second Life (or any other grid that supports LSL). It can also check the online status of users and send them one-way IMs. I call the entire system slrelay, and you can get it here.

It requires a few things to work: a running webserver is absolutely necessary. If you want the IRC features, then you also need an IRC network of your choice and a machine that can execute perl scripts. I have my IRC bot connected to irc.slashnet.org.

slrelay has a number of possible uses. You could use it to relay chat between key locations on a large landmass (say, an area that spans 3 or 4 sims). It could relay chat between Second Life and another metaverse grid like OSGrid. It can be used as a simple IRC tool to check who is online very quickly. Or it can do all of these things at once.

I played through the trial run of Eve Online. It worked without much complaint in wine. Let’s look at the things I think are cool about Eve Online, and the problems and realizations that came from the trial.

Okay, the star map. I could spend hours just playing with the gorram star map. Coloring systems by various data, playing with routes… the star map makes me feel like I’m in an Asimov novel. This hits my geek spot so very very hard.

The scale of the game is immense. 4500 star systems. Something to do in every one of them. It’s mind-boggling, and it’s easy to feel lost in the vast cloud of stars. Which is a good thing, for me.

The setting is really cool. The whole concept of capsuleers – transhumanist sociopaths, small gods reigning death on lesser humans – is really cool. The fact that you play as one is the surprising part. And NPCs even make reference to the fact that your ‘kind’ have a reputation for callousness. Very well executed.

In theory, I love the PvP/corporation/territorial battle aspects of Eve. Player-run corporations can control star systems. That’s amazing. In fact, it is the single coolest thing the game has to offer. If VO could find a way to implement sector/system sovereignty, it would be a better game (I believe this is being worked on).

Eve has a HUGE player base. There are human players in pretty much every system I pass through. However, while the player base is huge, I find myself rarely interacting with them. Which is fine, in that it is realistic enough; I have no real reason to talk to these pilots at this time. But it makes me realize that VO’s absence of a huge player base isn’t as much of a deal breaker as I thought.

I like that Eve’s economy is thoroughly player-driven. Vendetta feels contrived; sure, prices fluctuate as you move commodities from one port to another, but a station isn’t relying on players for a shipment of actual, usable goods, like weapons and ships. The economy in Eve is easily the most amazing thing I’ve ever seen in a video game. The fact that it works is almost unbelievable.

Eve has some graphical and performance issues, and it isn’t really any prettier than Vendetta Online on my hardware. This is annoying, because Eve looks and runs better in Windows. That’s a HUGE point in Vendetta’s favor; Linux compatibility is very important to me.

Combat in Eve can be boring at times. Theoretically it’s a more tactical approach, but PvE comes down to:

1. Click enemy.
2. Click “Lock”
3. Press F1
4. Wait until enemy is dead

You might need to toggle some shield hardeners or armor repair modules, or run away to repair/reload. But that’s about it for the entry-level PvE. Now, granted, PvP is another deal altogether, and I’m sure the combat in PvE gets more nuanced. The presence of tons of options (weapons, shields, add-ons, upgrades, ‘rigs’) is really cool, too, if a bit overwhelming.

In contrast, VO’s combat is immediate, twitch-based, and immensely rewarding. It is also a lot harder for me, but I relish the challenge. In my two-week trial of Eve, I didn’t lose a single ship. In Vendetta, blowing up happens every day. Of course, it isn’t as big a deal either.

Vendetta’s limited options with weapons and ships makes it easy to build a balanced, meaningful loadout. It also has a really good variety of different ship types (light/medium/heavy fighter, transport, bomber) without having an overwhelming number of options.

I think that, in the end, VO is more my style. It is better suited to casual play. It has a more open attitude (native Linux client, client plugins are encouraged, very open source-style release model). The public chat channel makes the game’s community very accessible; you can ask questions or just chat, and it makes the whole experience feel like hanging out on IRC (but with more explosions).

Eve Online has a lot of things that I want in a game, but it’s not quite casual-friendly enough for me. If Vendetta takes some cues from Eve in terms of the broader features, it will turn into a damned fine game. As it is, it’s enough fun to justify paying for it.

The biggest problem, by a long shot, is the player base. 60 players seems to be the absolute upper bound at any given time, at least while I’ve been playing. This is abysmal for an MMOG; there are FPS games that support larger numbers of players at a time. I might even be happy with this player base, if they did anything other than hang out in Sedina B8 PvPing. It doesn’t really feel like an MMO at this point, it has the feeling of a social dogfighting game.

A lot of noobs seem to appear, play for a few weeks, and vanish. I can see why. The player base seems a little cliquish, though not overly much. But you get the feeling that Veterans will always be Veterans, reminiscing about the glory days, and noobs will always be noobs, struggling to make a few credits in the face of vastly more experienced and skilled pirates. Of course, that’s when you find pirates at all. I’ve flown across have the game’s universe trading and never been pirated. Like I said in my previous post, it’s a ghost galaxy.

The numerous buggy things and realism-breakers are a turn-off, too. Capships in convoys don’t carry any cargo, so they’re worthless to both escorts (who get a “share of the profits” for their pay) and pirates. The cargo is simply an unlimited stream of widgets moving back and forth across the universe, with no great purpose in life. The convoy missions don’t always work, either; I’ve had several simply fail to end, giving me nothing and forcing me to abort the mission.

There is not a lot of variety in missions. After playing through the few available mission trees, the missions are all one of a few boilerplate missions. Fly out, kill some stuff, you’re done. Take this here, bring that back. Mine for lots of foo, get paid. Nothing more elaborate than that, which is disappointing.

I’m not cancelling my subscription yet. I’m giving the game a little more time to impress me. But at the same time, I’m going to try out Eve Online. You see, the MMO bug has hit me, and now I want a large, persistent universe full of people that I can fight with, trade with, and just generally game alongside. The space theme is more appealing to me than fantasy MMOs have ever been (fantasy has been done to death, is what it comes down to).

As far as roleplaying backstory goes, the science in Eve is surprisingly non-squishy, with a lot of modern scifi concepts making an appearance: quantum entaglement-based FTL communication, consciousness hot-backups, etc. Sure, the spectre of “jumpgates” (replace with “wormholes” at leisure) makes an appearance, but I can accept some foils for the sake of the story.

While I love twitch-based gameplay, I am a lot better at tactical/strategic combat. I think on my feet pretty well, but my reflexes suck pretty hard. I would probably find the combat in Eve more enjoyable, as a result.

If you ignore the combat layer, Eve has a lot of awesome features that would make VO great: player-owned systems, player-run economics (the materials you trade actually seem to come from a player at some point), and player-designed ships. All of these could have an analogue in VO, and if features like these were present, I would probably enjoy VO a lot more.

Of course, there’s also Jumpgate: Evolution. It’ll be interesting to check that out when it launches. We’ll see.

I love space shooters. Put me in a cockpit and give me 3 dimensions of unfettered movement, and I may as well be in Valhalla. Combat is secondary; fighting in space is fun, but just the feeling of (pretending to) pilot through the stars, skirting around asteroids, and maneuvering into docking bays is intoxicating to me. The chance to do so with other people in a persistent world is something I can’t pass up.

The space flight in VO is a very solid balance of realism vs playability. Contrast Vega Strike, which focuses on realism to a fault. In Vega Strike, it often takes upwards of 15 seconds to maneuver your craft into position for each attack run on an enemy. Also, to disengage your engines you have to throttle all the way down, and to turn without having your engines engaged you have to press a special key.

Vendetta Online, on the other hand, operates in a more enjoyable way; you only apply thrust for as long as you keep pressing one of your thrusters. When you stop thrusting, you maintain your current velocity until you thrust again. This lets you reorient your ship without changing your vector, which is very useful for targeting objects, getting a visual on enemy craft, etc. It also feels very intuitive and realistic (whether it really is realistic or not is irrelevant, see below). Moreover, you can apply thrust in 6 directions; forward or backward along the 3 primary axes (relative to your ship’s current orientation). The game controls refer to left (+y), right (-y), up (+z), and down (-z) as strafing, while forward (+x) is accelerate and backward (-x) is decelerate.

Having the ability to thrust in any direction is useful and fun, but it isn’t very realistic (well, not with the ships looking the way they do; a ship that could do that would need thrusters all over the place). This is where the fun > realism design mentality comes into play, and frankly it makes for a very fun game. Another unrealistic design decision is the existence of a maximum velocity. Sure, you could make some sci-fi sounding arguments for it, but honestly it’s a balancing mechanic, plain and simple. And in my opinion, there’s nothing wrong with that.

The game world is vast; 30 systems with 64 sectors in each system (a system is a 16×16 grid of sectors). Each sector is “theoretically infinite” in size, although all of the interesting stuff is centered about the sector’s origin; after a few kilometers you find a whole lot of nothing that goes on forever. To get between sectors you can set a destination and ‘jump’ there. Likewise, to get between systems you go to special sectors that have wormhole areas, and you ‘jump’ while in one of these.

The game’s main RPG element (and I mean RPG-esque mechanics, not actual roleplaying) comes in the form of licenses. These are like a combination of level and skills in most MMOs. There are 5 licenses: combat, light & heavy weapons, trading, and mining. As you perform the eponymous activities, the skills increase. When they level up, you gain access to new ships, weapons, and missions. But the game remains primarily skill-based; in the hands of an incompetent pilot, the better ships aren’t that much better. I am afraid that I’m a testament to this fact.

The game isn’t perfect, though, and as long as I’m writing something like a review I’ll have to point out a few flaws. I hate to have to do this to you, Vendetta, but it’s for your own good. This will hurt me more than it hurts you.

The game world is big, like I said before. However, the player base is small. VO runs entirely in one instance, and you could easily fly across the galaxy and not meet another player. There are, on average, only 30 – 40 players online. This is alleviated a little by the fact that there is a cohesive world-wide chat, so communicating with the other players is easy.

I don’t know if there are more people on at other times of the day (I tend to play any time between 22:00 and 06:00 UTC) or if this is a low point for the year (more players during the summer?). Maybe the game is just old, and has lost most of its player base to attrition. At any rate, it feels like a ghost galaxy sometimes. I want to populate this world, to convince everyone I know to play and invade the VO universe en masse.

The other flaws in the game are fairly minor. You can only take one mission at a time, and many missions are automatically aborted (and thus failed) if you log out mid-mission. A network hiccup can destroy an hour of work (or more for mission trees that require you to start all the way over if you fail any mission in them).

In-system jumps and wormholes look the same. A more spectacular graphic for wormholes would be really cool, but on the other hand, the in-universe explanation for wormholes makes the modest special effects make enough sense.

There is also a stat called “grid” that weapons have but don’t explain. It refers to the total amount of power connected devices on your ship can use (i.e. the “power grid”). It’s kind of like a maximum voltage, and you can only use 20 grid per ship, although this is not explained anywhere. It’s not important until you get access to some pretty hefty ships, but it would be good to know about it, at least.

Other than these and similar minor nitpicks, the game is tons of fun and I foresee myself playing it for a long time. There is a free 8-hours-of-play-time trial available. My character’s name is Gjalfr. See you there.

Before we begin

You will need the following software for this tutorial. All of this software is free and open source.

• Blender, a professional 3d modelling tool. Blender is powerful but complex, and basic blender knowledge is assumed for this tutorial. Blender will be used to actually create the heightmap.
• The Gimp, a powerful program for creating and editing raster (i.e. normal) image files. The Gimp will be used for splitting the heightmap into RAW terrain files that OpenSim can use.
• gimpterrain, a plug-in for The Gimp that allows it to open and save RAW terrain files.
• terrainerizer (optional), a bash script I created to automate splitting the heightmap into RAW files. Terrainerizer only works on Linux, and still requires The Gimp and gimpterrain to be installed. It also requires ImageMagick.

In addition to the above software, you will also need a blank RAW terrain file. You could download a terrain file from OpenSim and transform it into a blank one (replace the Height layer with #ffffff, replace the factor layer with #808080), or you could just download this one that I have created for you.

Create a heightmap

A good tutorial on creating a generic heightmap in Blender can be found here.

The tutorial above creates a heightmap that is 512×512 pixels. However, an OpenSim RAW terrain file is only 256×256 pixels. This means that the above tutorial will create terrain for 4 regions, arranged in a square. If you need terrain for a different number of regions, you can modify the above tutorial to create different sized heightmaps.

For example, suppose you want to create an oblong island that is 2 regions by 4 regions in size. To do that:

1. Create the plane, but instead of scaling it to 2×2 blender units, scale it to 2×4 blender units. To do this, you can use this command sequence in blender:

• Right-click on the object to select it.
• Change the mode to Edit mode.
• Press ’s’, ‘y’, ‘2′, ‘return’.
• Press ’s’, ‘x’, ‘4′, ‘return’.

Now you should have a plane that is oblong instead of perfectly square.

2. When you configure the render settings, you will need to use different values.

• In the Scene settings (F10), SizeX and SizeY should be set to 256 * (number of regions). In our case, we have 2 regions in the Y dimension, and 4 regions in the X dimension. So, SizeX should be set to 1024, and SizeY should be set to 512.
• In the camera settings, the scale needs to be adjusted to fit the plane precisely. In our example, the scale should be set to 8. To get it just right, select the camera, and press Numpad0 to switch to camera view. You should see two concentric rectangles composed of dashed lines. Now, press F9 to view the Editing options for the camera. Now, adjust the Scale value until the outer dashed rectangle encompasses your plane completely, without including anything outside the plane. If the dashed rectangle is not the same shape as your plane, then you still need to set SizeX and SizeY in the Render settings.

Creating RAW terrain files with the Gimp

Now that you have a heightmap file, you still need to turn it into terrain files that can be uploaded into OpenSim.

Enter Domino Marama, creator of gimpterrain, an import/export plug-in for the Gimp that can handle the OpenSim RAW terrain format. Download gimpterrain and install it into your gimp plug-ins directory.

Now, if you are running Linux, you can automate the rest of this section with my terrainerizer script. See below.

We also need the blank terrain file that I mentioned earlier.

Armed with these tools, we can open a terrain file in the gimp and combine it with a portion of our heightmap.

1. Open your blank terrain file (blank.raw) and the heightmap in the Gimp.
2. Using the Rectangle Select tool, select a 256×256 pixel section of the heightmap, starting in the upper-left corner.
3. Click Edit -> Copy
4. Select the terrain file and make sure the Height layer is selected.
5. Click Edit -> Paste. You should see the section of the heightmap you copied appear as a floating layer.
6. Click Layer -> Anchor Layer. The Height layer should now look like the copied portion of the heightmap.
7. Click File -> Save As and save this file as a new file with the .raw extension.

Now, repeat this process for every 256×256 pixel section in your original heightmap.

Making it easier

Performing the steps in the previous section is very tedious, especially given how long it takes to save the terrain files. To make this easier, I have automated the process with the terrainerizer script.

If you are running Linux, simply put the terrainerizer script somewhere in your path. Edit it and specify the path to your blank.raw file, then run:

terrainerizer heightmap.png

Replace ‘heightmap.png’ with your heightmap file. Now let terrainerizer work. It will handle everything we did in the previous section automatically. It may take a while, depending on how large your heightmap is.

When it is finished, terrainerizer will leave several files in your current directory, named with this scheme:

heightmap-nxm.raw

Where ‘n’ and ‘m’ are numbers starting at 0 that represent the column and row for that terrain file. So, 0x0 is the top left region of your terrain, 0x1 is the next region (moving from top to bottom), and so on. Just upload these terrain files and you’re done!

Uploading the terrain files

Now that you have the terrain files, you can upload these files into OpenSim. There are two ways to do this.

1. From the OpenSim server console, you can simply:

change region RegionName
terrain load /path/to/terrain.raw

Repeat this for each of your regions.

2. From a viewer connected to OpenSim (assuming you are using Hippo or a similar viewer):

• Move to the region you where you want to upload terrain.
• Navigate to World -> Region/Estate -> Terrain
• Click “Upload RAW Terrain…” and select the terrain file you created for this region.

The Upload Terrain menu in Hippo

Repeat these steps for each region where you want to upload terrain.

(require 'dbus)
(defun send-desktop-notification (summary body timeout)
  "call notification-daemon method METHOD with ARGS over dbus"
  (dbus-call-method
    :session                        ; use the session (not system) bus
    "org.freedesktop.Notifications" ; service name
    "/org/freedesktop/Notifications"   ; path name
    "org.freedesktop.Notifications" "Notify" ; Method
    "emacs"
    0
    ""
    summary
    body
    '(:array)
    '(:array :signature "{sv}")
    ':int32 timeout))

(defun pw/compile-notify (buffer message)
  (send-desktop-notification "emacs compile" message 0))

(setq compilation-finish-function 'pw/compile-notify)

Add this to your .emacs file and you will receive a libnotify popup when M-x compile completes. It will even give you the exit message, so you know whether the compile was successful.

So now you can let that long compile run, and work on something else. emacs will let you know when the compile finishes.

As written above, the notifications will stay on your screen until you dismiss them (by clicking on them). If you would like them to vanish after a preset time limit, change the 0 in the call to send-desktop-notification. Set it to the number of milliseconds the popup should remain on the screen.

Screenshot of libnotify popup showing a compiler error

This is just the tip of the iceberg, of course. Any application that presents a dbus interface can be interacted with from emacs, which means that emacs can also integrate itself with the Linux desktop in other interesting ways.

If you are renting a series or seasons, we will ship the DVDs in order. That means:
…
* If there is a wait for a particular DVD in a series, will we wait until we ship you that DVD until we ship the next DVD in that series.

Which is great. If I add, say, Excel Saga to my queue, I can be certain that I will get disc 1 first, followed by disc 2 and 3. Under no circumstances will I have to worry about getting, say, disc 4 before disc 2. Right?

Well, in theory. In practice, some TV series (notably, Excel Saga) have discs missing completely. These discs go into your “Saved DVDs” list instead of your queue, and they aren’t considered to be discs with a “wait”. As a result, they get skipped over completely, and you get the next disc in the series that isn’t missing.

Why am I complaining here instead of directly to Netflix? Because Netflix doesn’t have any reasonable way that I can find to open a bug report or provide feedback. And I wanted to vent a little.

While I was off not paying attention, it seems that almost all of my predictions have come true. An open-source server for running a simulator and/or grid, OpenSim, has been created. OpenSim appears to have solved many of the problems, and implemented many of the predictions, of my post from 2006.

One “problem” that remains, though, is economy.

The problem I outlined in my original post was that without a robust permissions scheme, economy would break down. Looking back, this seems terribly unlike me. Even in 2006, I had a strong dislike for anything that reeked of Digital Rights Management (DRM) even for the me that wrote that post. The permissions scheme employed by Second Life, after all, is just a DRM scheme. Like all DRM, it attempts to keep the user from using the things they purchase the way they would like, and like all DRM it is ultimately futile.

Economy on a Closed Grid

On the Second Life grid, you use real money to purchase virtual goods, which might have any of a number of permissions associated with them (modify, copy, and transfer). This permissions scheme is enforced by the fact that Second Life’s grid is a walled garden; Linden Labs controls the asset server, so your data all exists in their hands. They safeguard it, preventing nefarious users from copying your creations.

Except, not really.

Like all DRM, this scheme just plain can’t work. It can’t. It violates information theory. It is mathematically impossible to give something to someone and then keep them from having it. This is a corollary to the Law of Cake. I will elaborate.

For the Second Life viewer (aka client software) to render the object, it needs a copy of the object. This copy is necessarily sufficient to reproduce the object. Since any viewer that can speak the protocol can connect to Second Life, all you have to do is create a viewer that copies the object data being sent to it.

In fact, exactly such a viewer has been written. Linden Labs responded to this viewer’s existence by appealing to their Terms of Service. Whenever a user is caught using CopyBot, they are banned from Second Life.

In other words, there is no technical solution, only a social/legal one. This is because DRM is fundamentally flawed; it is trying to achieve the impossible.

Even without CopyBot, you could just decode cached objects from the official viewer’s data cache. Programs have also been created which do this as well, although they are harder to use than the infamous CopyBot.

The point of all this is that the assumption that the Walled Garden protects your Intellectual Property is simply false. As with the rest of the Internet, piracy is a given. Anyone creating and distributing content on the web must start with that assumption.

Economy on an Open Grid

I haven’t explored OpenSim enough to determine whether it supports any sort of monetary transaction, but let us assume that it does. In other words, assume that you can, via direct credit card payments or via a virtual currency, purchase virtual goods. Even if you can’t do this yet, I have little doubt that OpenSim will support it eventually.

Now, let us further assume that I connect to OSGrid via a region that I run myself. This means that I control my own asset server, where my inventory resides. If I purchase an object with restrictive permissions on another region, a copy of that object will be transferred to my asset server, where I can simply log in via mysql and change the permissions. Now, I can create multiple copies of this object, or give a copy to someone else.

What I have done here is to defeat DRM, just like CopyBot. It’s considerably easier, and much harder to detect. However, in practice this is no less secure to the Intellectual Property owner than Second Life’s walled garden. It still requires a reasonable level of competence (running your own grid/sim) to exploit, so piracy is likely to be similar in rate. Of course, the open metaverse has no Terms of Service (although individual grids/regions within the metaverse may). But the technical merits are the same; when looking at the threat of piracy, the open grid has the same basic properties as the closed grid.

Of course, even without our own asset server, we could still use the same techniques to copy data that I described for the closed grid. CopyBot and copying assets out of cache work identically on an OpenSim grid.

Not a problem

Okay, so the economy “problem” isn’t really a problem, just a fact of life. In the words of the OpenSim folks:

[The existence of piracy] is the kernel of the belief that open grids are hopeless for a virtual-goods economy. DRM discussion aside, maybe they are hopeless. But then, everyone thought the web was hopeless for selling music, and look at the success of iTunes in spite of all the piracy that still exists out there.

I am not proposing that piracy is good in any way, merely describing how it is inevitable. You simply cannot restrict how users will use the things you buy. You can’t keep someone from copying digital data, if they are determined enough to do it. You can use restrictive terms of service and try to sue or press charges, but there will never be a technological solution.

So, to current and potential content creators shying away from the open grids: piracy is an unfortunate fact of life. It will happen. Start with that assumption, and work from there. If this means you don’t want to create digital content, I’m sure the creative community will miss you. If, however, you realize that some people will appreciate your work enough to pay for it, without worrying about the details, then you are in the company of some fine artists.

Get it here.

I’m lifting my moratorium on D&D 4e, as well. This means that d20tools will eventually support 4e creatures. However, this is a huge undertaking, and I have to decide how best to handle it. I’m leaning towards a system that will allow anyone to write system templates; then, any gaming system could be plugged in, theoretically. In practice, this is a lot of work for a single developer, so I wouldn’t anticipate this happening any time soon.

Defining Transhumanism

For semantic clarity, I’m going to define what I mean by transhuman, because my definition and connotations may differ from yours.

A ‘transhuman’ is someone who augments reality with technology at a constant and unconscious on nearly unconscious level. The key concept here is that transhumans use technology to augment reality. This helps avoid the temptation to define any tool-user as a transhuman; a primitive man with a spear is more capable at hunting than a primitive man with his bare hands.  A person driving a car is more mobile than a person walking.  A person who watches a movie while browsing IMDB on their iPhone knows more about the movie than someone watching it passively (though the passive viewer may well be enjoying the movie more).  By our definition, the iPhone user comes close to transhumanism. We might call her a proto-transhuman. However, these is still significant effort involved; she must look away from the movie and focus on her iPhone to search IMDB.

So, where are we now?  Some people (early-adopting geeks, for example), already consider quick access to information to be something like an extra limb; as one of those affected with this feeling, I can vouch for it.  Are we transhuman or not? Again, we’re on the way there, but we haven’t yet achieved the fluidity of control and automation needed yet.

As for where we’re going next, let’s begin by discussing how we got where we are.

The Evolution of Information Access

For the majority of human history, access to information has been difficult.  Even after the invention of the printing press, one had to have either a personal library or access to a public library.  Information could be obtained, but not in a timely manner; poring over books was the purview of academia.  And even academics could only access this information when they were actually at their libraries.

As a result, the human brain has been the only way to store a significant amount of information for quick retrieval.  As a storage device, the brain is not that great; storing something permanently requires multiple writes (our recall of a fact is better the more times we have heard it).  It can be finicky at retrieving information; everyone who has ever had something ‘on the tip of their tongue’ can attest to that.

The next revolution in storage was electronic storage; in other words, computers.  Of course, early computers couldn’t hold a ton of information, but more importantly; that information was still stuck in one location.  To look up a fact on a computer, you had to physically travel to the computer with the information on it (or to a terminal connected to that computer; typically, these needed to be pretty close to the mainframe).

Enter the Internet

And here we come to the revolution; the Internet allows us to access virtually any piece of information from any computer in the world.  And with the information searching miracle we call Google, we can usually find that information very quickly.  Of course, the original problem with the Internet was that you still had to get to a computer to use it.  The solution?

Smaller computers.

Laptops, to be precise.  Laptop computers allowed us to connect to the Internet, and its massive store of information, anywhere we could find a phone line.  With the emergence of wireless networking, all we need is a wireless signal.  However, laptops are big, and cumbersome to use in a hurry; if I’m in the midst of a conversation and need to recall a fact, it takes several minutes to get my laptop powered on and connected to the Internet.  The solution?

Smaller computers.

Cellular telephones have evolved from foot-long bricks that required external power to pocket-sized devices with capacitive touchscreen interfaces.  These phones can also connect to the Internet, play music and games, function as e-book readers, scan bar-codes and do real-time price comparison, and perform myriad other tasks.  They can access any information from any location that has cellular service.  This is the first real step toward ubiquitous information access.  However, these devices can still be somewhat cumbersome to use.  The device must be fetched from a user’s pocket, then interacted with for quite some time to get the information you want.  If you want this information in the middle of a conversation, it can be fairly cumbersome.  The solution?

Smarter computers.

The current state of the art

Immediate mastery of a wide array of information was once a symbol of the elite.  Now, anyone who can type reasonably quickly can have an online, text-based conversation and match the knowledge of anyone else on many topics (this can be tough for very advanced or specialized topics, obviously). I suspect that this trend will continue until anyone can retrieve any fact instantaneously.

The implications this has for culture are immense. Once memorization of fact is no longer a measure of the intellectual elite, intelligence will be judged along other axes; the ability to synthesize existing content (analysis) and the ability to create new content (art). The stigma that exists against artists will disappear, and we will be left with a culture in which artists are not only lauded as worthwhile members of society, but financially supported by society.

Portrait of a Transhuman

Let’s look at what transhumans might look like at a point in the near future.

He wears sunglasses with transparent OLED overlays and a bluetooth radio that communicates with his personal Mobile Device (the successor to the smart phone). The overlay provides a Heads-Up Display; in it, he sees that he has 3 unread emails, 4 new RSS items, and an instant message from his wife. A pinhole camera in the glasses tracks his eye movements and responds to them; he keeps his gaze on the IM for a moment and it expands. His wife is asking him to pick a restaurant for dinner. A second pinhole camera looks outward from the glasses, feeding data about his surroundings to the Mobile Device. He looks at a restaurant down the block, and a moment later his HUD provides a menu, operating hours, and reviews. He pulls out his Mobile Device and types a quick reply to his wife.

All of the technology I just described already exists; it just needs to be made small enough, responsive enough, and accurate enough. Protocols and standards need to be developed, and our access to information needs to be made a public commodity. Once this is achieved, we will have the future. What we’ll do with it, I have no idea.

Here is the result:

#!/bin/sh
echo -n "twitter> "
read text

while [ ${#text} -gt 140 ]; do

echo
echo "Message too long; used ${#text}/140 characters."
echo
echo -n "twitter> "
read text

done

echo
echo "Message is ${#text}/140 characters.  Press enter to post, or Ctrl+C to cancel."
read

curl --basic --user "username:password" --data-ascii "status=`echo $text|tr ' ' '+'`" "http://twitter.com/statuses/update.json" &> /dev/null


To use the script, copy all of that into a file somewhere in your path, then make the file executable (e.g., chmod 755 /usr/local/bin/twitter).  Now you can type ‘twitter’, type in your tweet, and you’re done!

I even set up fluxbox so that mod4+t launches a terminal with the script running.  To do that, I added this to ~/.fluxbox/keys:


Mod4 t :Exec xterm -e "twitter"


If you’re not familiar with ‘mod4′, it is the Windows key on most PC keyboards.

I’ll eventually get around to writing a slightly more full-featured twitter updater in c or c++.  Until then, enjoy this script!

The netjatafl server (taflserv) operates on a simple, completely open protocol; it will eventually support authenticated logins and statistics tracking. Anyone could write a netjatafl client for any platform, if they wished. My clients will all be in C++, because this let’s me reuse the ‘libboardgame’ library, which contains the game logic used by the server. I will also build in a “capabilities” system at some point, so the client and server can both advertise which games they support.

The whole thing is theoretically usable in its current state; the client is an ncurses-based text UI that is pretty cumbersome, but can be used. As far as I know, it only works in Linux. Anyone who wants to cross-compile it for Windows and send me a patch with everything you had to add, feel free! I will eventually add a proper GUI, probably gtk+-based.

Like the sound of this project? Feel free to check out the code, compile it, and let me know what you think!

Etymology notes: netjatafl is Old Norse for “net-table”; i.e. a networked table you can gather around to play games. ‘taflbordh’ is ON for ‘tafl board’ (tafl can also refer to tafl games in general), which sounds a little redundant, but it made a nice name for a client. And ‘taflserv’ is just ‘tafl server’… ’serv’ was meant to be short for ’server’, but I later noticed that it’s also a French word meaning ‘it serves”. I find this somewhat appropriate.

2. su -c “reboot”

Misconfiguration Most Foul

We begin our tale with NetworkManager.  Since I connect to several wireless networks and a VPN, NetworkManager is a very useful thing to have working.  Its initial setup was great; I loaded nm-applet in my fluxbox startup, it prompted me for a default keyring password, and we were off.

However, on my next boot I was not prompted for my keyring password; I had to enter my WEP key manually.  After some exploration, I learned that gnome-keyring-daemon needs to be running.  The paradox is that it WAS running.

A Red Herring

I found some rather old advice thas suggested I run gnome-keyring-daemon manually from ~/.fluxbox/startup, but this didn’t work; gnome-keyring-daemon starts automatically in Fedora 10, thanks to pam_gnome_keyring.so.  I now had two copies of the daemon now running, neither of which worked.

What I eventually discovered was this: if I kill the automatically-started gnome-keyring-daemon (or remove auto_start from the pam_gnome_keyring options in /etc/pam.d/kdm), then start it manually with different options, it works every time.  So, instead of:

gnome-keyring-daemon -d --login

which is the automatically provided command, I ran:

gnome-keyring-daemon -f -c keyring

from my fluxbox startup file.  This worked, but turned out to be unnecessary.

An Anwser

My next discovery:  If I disable the daemon’s automatic starting (once again by taking the auto_start option out of /etc/pam.d/kdm) and remove my custom invocation from the startup file, it still starts automatically, but with different options than the auto_start version!  In fact, it starts with the options work.

It turns out that nm-applet and gnome-screensaver both automatically start gnome-keyring-daemon if it isn’t running.  Since nm-applet runs first, it starts up the daemon, and passes it a completely different set of options than the pam-invoked version.  Thanks for the consistency, gnome!

A Problem

Starting gnome-keyring-daemon manually or allowing nm-applet to start it still poses a problem: the daemon doesn’t die when I log out!  This means that, as I log in and out several times, useless instances of the daemon end up sitting around doing nothing.  Since the apps that talk to the daemon use $GNOME_KEYRING_SOCKET to do so, everything keeps working; but it’s cruft I’d rather not have.

Elementary

After following this circuitous path, I finally stumbled into the answer: it’s a known bug.  It is actually related to the lack of a proper $DISPLAY getting set for gnome-keyring-daemon; it isn’t related to the passed in options at all.

At this point, I’m forced to fall back on a hack.  I’ve added the following to my ~/.fluxbox/startup, above the gnome-related apps:

killall gnome-keyring-daemon

I’ve also removed the auto_start option from /etc/pam.d/kdm.  Unfortunately, not launching the daemon with pam means that I can’t take advantage of the single sign-on feature provided by pam_gnome_keyring.  But until the bug is fixed, I guess this will have to be good enough.

(As for why I don’t use gdm, see this post)

Update: a command explained

If you look at the –help output for gnome-keyring-daemon (or, if you’ve applied my hack below, gnome-keyring-daemon-bin), you’ll see this output:

Usage:
gnome-keyring-daemon [OPTION...] - The Gnome Keyring Daemon

Application Options:
-f, --foreground Run in the foreground
-d, --daemonize Run as a daemon
-l, --login Use login password from stdin
-c, --components=ssh,keyring,pkcs11 The components to run

Anyone acquainted with Linux will understand the first two options, -f and -d, pretty intuitively. You’ll note in my post above that my ‘working’ option set included -f; this is because -f prints to standard out, allowing us to capture the GNOME_KEYRING_SOCKET and GNOME_KEYRING_PID variables that the daemon spits out. However, when run in -d, these variable seem to get set correctly anyway. Further, the -c option I used in my quest seems superfluous; the daemon defaults to using the keyring component. I wanted to explain this since it wasn’t clear in the original post exactly why I bounced between options. At the time, I was grasping at straws, and assigned a simple correlation (the different command-line options in use) to a causation (the daemon that started automatically, with the different options, failed to work correctly).

The option that had me baffled, though, was –login. The information in the help output is cryptic, but I finally worked out its purpose; it allows single sign-on. pam_gnome_keyring passes your login password to gnome-keyring-daemon, which uses it to unlock a special keyring called the login keyring. This keyring can then be used to store the passwords to your other keyrings, so that when you log in, everything unlocks automatically. Your system login doubles as your keyring authentication.

Further Update: Eureka! (or: building a better hack)

Based on a comment in the bugzilla entry for this problem, I have crafted a better (if more system-intrusive) hack. I simply perform the following:

mv /usr/bin/gnome-keyring-daemon /usr/bin/gnome-keyring-daemon-bin
touch /usr/bin/gnome-keyring-daemon
chmod 755 /usr/bin/gnome-keyring-daemon
cat > /usr/bin/gnome-keyring-daemon << EOF
#!/bin/sh
DISPLAY=":0.0" /usr/bin/gnome-keyring-daemon-bin "\$@"
EOF

This hack creates a wrapper script that sets the $DISPLAY variable before running the keyring daemon. Until this kdm bug is worked out, this hack performs beautifully.

First, a summary, for those who get a case of the tl;dr’s.  A woman bought a laptop to use for her coursework at a local college.  She accidentally bought a Dell laptop with Ubuntu on it.  When she realized her ISP’s setup disk wouldn’t work, she tried to get Dell to swap the laptop for one with Windows.  The Dell representative apparently convinced her to keep the one she had.

She claims that this problem, combined with a lack of Microsoft Office, forced her to withdraw from classes.  The local news ran the linked article; it is worth noting that the bottom portion (the part where the news agency contacted the college and Verizon, and everything got cleaned up) did not appear in the initial article.

Needless to say, the Linux community (and the Ubuntu community in particular) exploded.  The article hit digg, slashdot, and reddit.  The angry letters and phone calls started pouring in to the news station (though they got tons of traffic, naturally).  More significantly, the woman in question was harassed on facebook.

This story shows mistakes from every party involved.  The Dell representative should have helped her switch to a machine she was more comfortable with.  The woman herself should have taken initiative, called Verizon and asked what she could do to get her connection working.  Alternately, what’s wrong with using another computer (say, at a local library) until you can get the laptop issue sorted out?  Dropping all your classes for the semester is overly drastic and melodramatic.

The worst perpetrators of stupidity here, though, are the Linux community members who not only lambasted and ridiculed this woman publicly on forums and blogs, but also attacked her personally on her Facebook account.  This is childish, pointless, and it paints the entire Linux community as anti-social assholes.

Unlike most groups, the Linux community IS Linux.  If a Star Wars fan blogs about how everyone who doesn’t know the difference between a Sith and a Dark Jedi is an idiot, the Star Wars franchise is not going to be damaged; there is a clear disparity between the creators (Lucasfilm et al) and the consumers (fans).  On the other hand, if a Linux fanboy blogs that everyone should know the intricacies of iptables configuration before being allowed on the Internet, this will color peoples’ perception of Linux.

Why does this happen?  Because Linux is Free, open to the world.  Anyone can add to it.  The community and the product are intricately intertwined.

This is a false perception, though; in reality, the rabid fanboys who would harass a woman on Facebook are a completely different set of people than the assholes that argue fine technical points on LKML. (I’m using asshole here in its rare application as a compliment)  However, the impression that an outsider has looking in is that Linux is some wild, anarchistic (or maybe communist) creation.  This stems from the growing cultural knowledge that Linux was created by and for the people that use it.  This is not quite true.  Linux was created by and for developers and technology enthusiasts, true.  However, not every vocal member of the community actually contributes to Linux itself; only a fairly small subset of users are actively involved in improving the software.

I don’t mean to devalue the role of the community in development.  Community contributors are important, welcome, and numerous.  Bug submitters and other “active users” are vital to the strength of the open development model.  However, the active users aren’t even the people that we see evident in this article.  What we see here are fanboys:

fanboy (n): Someone who is so obsessed with some subject or thing that they are blind to its faults and harass and deride anyone whose opinion differs.

These are precisely the people that Linux does not need.  The community would be doing itself a favor by creating public distance from this subset of itself.  We need more rational, clear-headed people speaking out about the benefits of Linux.  Fanboys ranting and harassing people will get us nowhere.

First, a little background.  I switched to Fedora from a mixture of gentoo and slackware around the time I started my current job, since it was far easier to keep track of one package management toolset, and several things about gentoo’s packaging system had started to irk me.  The current release of Fedora at the time was 7.  I have been using it since, usually upgrading to new releases (via a clean install) about a month after they release.

My needs are simple, but apparently elusive to Fedora.  I use fluxbox as my window manager.  I prefer to perform all of my system configuration from the command line.  My graphical application use is minimal (firefox, games, pidgin).

Let’s explore the problems I’ve noticed have started creeping in, starting with the release of fedora 8.  My solution/workaround for each problem is included, if I have one.  For what it is worth, I realize that some of these could be the result of 3rd-party packages (such as Nvidia’s proprietary drivers).  However, if any of these are the result of user error, then the solution should rightly be easy to find by searching documentation, which I have done extensively in every case.

1. Pulseaudio

Pulseaudio… I hate the word

This one heads the list because it’s the problem I’ve had to deal with most recently.  I have been lucky in that pulseaudio plays nicely with the sound cards on all 3 of my Fedora machines (others have been less fortunate).  However, I was stuck with audio far quieter than what I had grown used to in gentoo.

Solution: I finally discovered that pulseaudio has its own volume settings, independent of the ALSA-level audio device.  You can adjust the hardware volume levels with either of these commands:

alsamixer -Dhw:0
alsamixer -c 0

It would be nice if this were clearly documented somewhere.  There are some vague hints on this page, which is what pointed me in the right direction.

Thankfully, pulseaudio is no longer quite so painful when dealing with apps that only talk to ALSA.  I noticed some popping in certain applications, though (Neverwinter Nights, for one).  pasuspender seems to work around this, but the fact that this is necessary is kludgy.

2. GDM

The thousand injuries of GDM I had borne as best I could; but when he ventured upon insult, I vowed revenge…

GDM in Fedora has been upgraded to the latest upstream from the gnome team.  The problem with this version of GDM is that it removes almost all of its configuration options.  They have crippled it thus intentionally, and while they claim the removed options were “obsoleted due to redesign”, it seems that some of the options were dropped to prevent users from doing stupid things.

This Lowest Common Denominator approach is fine for a default configuration, but it should always be possible to change the default behavior.  Removing the ability to customize it entirely is not only against the spirit of open source software and Linux, it is insulting to the users.  It feels as if the team responsible for GDM thinks they know better than I do when it comes to configuring my machine.

In my case, the default behavior that troubles me is the fact that GDM passes the +accessx option to X.  Gnome includes a daemon that can override the accessx behavior (namely, enabling sticky keys if you hold shift down too long).  KDE includes a similar tool.  Fluxbox, however, has none – it assumes (justly) that you can turn off the accessx option at the X11 level if you don’t want it.  The new GDM denies you this ability, however.

Solution: Switched to KDM, which doesn’t seem to enable +accessx by default.  I tried XDM first, but it has SELinux errors and fails to launch fluxbox.  Also, KDM looks much nicer.  Alternately, I could have booted into runlevel 3 and then used startx, but I’ve become a fan of the graphical login prompt.

3. Upstart

The name says it all

upstart is the new init system in fedora; a replacement for the aging sysVinit.  In theory, upstart is great – gives you much more granular control over what processes should happen at each runlevel, and may eventually replace /etc/init.d entirely.  In practice, however, it has a rather annoying problem: sometimes it fails to respawn the ttys when in runlevel 5.  This problem doesn’t seem to be present in runlevel 3, for whatever reason.

Solution: no real solution at present, but you can work around it with initctl start ttyX

4. rsyslog

Hey… Listen!

The traditional syslogd has been replaced with rsyslog, a much more powerful/configurable syslog daemon.  However, it seems to dump all kernel output to the console.  The default configuration doesn’t include any statements that should be logging to the console, so it could be caused by something else.  Either way, the problem is present.

You can test this from any fedora machine: it seems to happen on every F10 box I can find.  Just press Ctrl+Alt+F2, then plug in a USB flash drive.  This is annoying on its own, but is especially frustrating when combined with #5, below.

Solution: none

5. PCI-Express device errors

Or How I Learned to Stop Worrying and Love X.org

On my PCI-Express video card, I receive constant error messages, both in messages and on the console (see #4, above).  These happen whenever the screen is cleared or switched to.  In other words, Ctrl+Alt+FX will generate one of these, sometimes two.  Running ‘less’ generates the errors.  So does the ‘clear’ command.  emacs and vi both trigger the error.  Each instance of the error takes up about 25% of the screen’s real estate.  This makes operating on the command line extremely difficult.

Solution: None yet.  I suspect this may be related to the Nvidia drivers; in that case, a future update may fix these errors.  I’ll give Fedora the benefit of the doubt where I can.

At any rate, Mr. Burell now has a new blog at education.change.org.  In particular, one recent post impressed me, and I wanted to increase its distribution, at least by the tiny amount that people actually view this blog :P

Why Schoolwork Doesn’t Have to Suck

There’s some important ideas here.  The concept that our technology could (should, must) become the medium through which we engage in learning is as groundbreaking as it is obvious.  Enjoy.

http://silenceisdefeat.com

I have updated my previous link to their site (in this article) to reflect the change as well.

Recently, I pondered a fairly simple question: which of these games is the most complex?  All of them are complex enough that new players have room to become stronger over time.  Skill in these games has been traditionally praised as a virtue by each game’s culture of origin.  So, which game provides the greatest depth as a topic of study?

Before I consider the differences in the level of complexity of these games, let’s look at how a few basic elements of the games compare.  This will give us a fuller understanding of the factors that contribute to the games’ complexity.

Symmetry

Chess and Go have in common that they are symmetric games – both players have the same resources at their disposal, and seek the same goal.  In chess, the pieces for each player are arranged similarly at the start of the board, and each player tries to capture the other player’s king.  In Go, the board begins empty of pieces, and capturing territory is the goal for both players.  In both of these games, neither player has a handicap evenly matched opponents will have an equal chance of winning.

Tafl, on the other hand, is asymmetric.  One player, the defender, controls a king and his bodyguards, and tries to flee to one of the corners of the board.  His pieces begin the game arranged in the board’s center.  The attacker, on the other hand, has his pieces along the four sides of the board.  He also outnumbers the defender 2-1.  Tafl also favors the defender; if two equally skilled players play each other, the defender is nearly guaranteed victory.

Board Size

Tafl and chess are played on fairly small boards – 8×8 for chess, and anywhere from 7×7 to 13×13 for tafl.  The most common tafl board sizes appear to be 9×9 (Tablut) and 11×11 (Hnefatafl).  I will be contemplating a hnefatafl board here, because that is the size on which I most commonly play.

Go, on the other hand, is played on a 19×19 board. This means that, in general, far more moves are possible at any given time in Go.

Spaces vs Intersections

While we’re talking about boards, I will pause briefly to discuss spaces and intersections.  In Go, your pieces are played on the intersections of the lines.  In tafl and chess, your pieces reside in the spaces, or squares, between the lines.  This fundamentally makes no difference at all.  You could make a grid of 8×8 intersections instead of 8×8 spaces, and play chess on it.  It would feel unnatural, perhaps, but only because you would be accustomed to the other convention.  Likewise, you could play Go on a board of 19×19 spaces.  In fact, some variants of tafl were played on a grid of intersections, such as Alea Evangelii, a tafl game played on a 19×19 board (you could, in other words, use a modern Go board to play Alea Evangelii).

Capturing

Go requires a player to surround an opponent’s stones and ‘cut him off’ from all open spaces.  Capturing, however, is not the point of the game, only a strategic element.  This is also fundamentally true of tafl and chess; the ultimate goal is to surround the king; the capturing move is not strictly necessary.  Tafl’s capture rules are less straightforward than chess; you must ‘flank’ an opponent’s piece (place your pieces on opposite, orthogonal sides of the opposing piece) to capture it.  The king must be surrounded on all four sides (in most variants).

Construction vs Destruction

In chess and tafl, players begin the game with all of their pieces in place; pieces can be captured, but new pieces will never be added to the board.  In a sense, they are destructive games; the forms which are in play at the beginning can change and be eliminated, but nothing new ever appears in play.

By contrast, Go is a constructive game.  The board begins completely barren; players add pieces until the board is full of pieces surrounding empty territories.  Pieces can be captured, but the overall trend during play is toward a fuller board.

Complexity

So, how do these games compare to each other in terms of strategic complexity?  Go has a lot going for it in terms of complexity.  First, it is played on a large board, meaning there will always be more moves to consider.  In addition, the constructive nature of the game means it is legal to play in nearly any open space at any time.  This means that the number of possible moves in Go will always be much greater than the other two games.

Additionally, the strategic elements within Go are extremely intricate.  Opening moves can impact the later game dramatically, and individual ‘battles’ (sequences of moves on a small section of the board) have countless patterns and scenarios that players must be comfortable with.  Capturing an opponent’s stones isn’t always a good idea; often, nothing prevents your opponent from immediately capturing even more of your stones (and thus gaining territory) in return.

By stark contrast, chess and tafl have a fairly small number of legal moves.  For example, in chess, there are only 20 possible moves on the first play.  The average number of possible moves for a given chess game is something in the range of 32.  Tafl provides more possibilities than chess, even with fewer pieces; since all tafl pieces can move any number of spaces orthogonally, the attacker (who plays first) has 116 possible opening moves.  The defender’s first move has 120 possibilities.  Go, by comparison, has 361 possible opening moves.

In terms of capture rules, it is not clear to me whether tafl’s capture mechanics, which are more involved than those of chess, make the game simpler or more complex than chess’ straightforward captures.  In chess, the capture rules require you to keep track of more information, since each piece has a more complex influence on holding territory.  Go, however, is the clear winner here as well, as capturing can be extremely intricate – often when trying to capture a group, you may limit your own liberties and end up being captured yourself.  A significant portion of the game’s strategy involves creating arrangements of stones that cannot be captured.

Ultimately, my observations and subjective experience suggest that Go is the most complex of these games.  It has an amazing number of possible permutations, and a very simple ruleset that nevertheless lends itself to an immense number of factors that must be considered.

Between chess and tafl, the numbers seem to favor tafl.  The asymmetry,  larger board, and larger number of possible moves seem to make it more sophisticated.  However, as long as the game is skewed in favor of the defender, the complexity may mean very little in the end.  Mostly from subjective experience, I would estimate that tafl is the more numerically complex game, but this experience may be skewed by the fact that so many of the possible moves in chess have been so well mapped. The complexity of tafl also depends heavily on the specific tafl game and board size. Even subjectively, I can’t come to any real conclusion here.

First, the user (me) inserts a USB flash drive with an encrypted partition.  He mounts up the encrypted disk on a local machine (I’ll call this machine the ‘client’ throughout this article), providing the necessary password, and runs a script called ‘callhome’.  He is prompted for his passphrase, and then gets a terminal session on his home machine (we’ll call this one the ’server’).

Read on for details about this setup, and how to do it.

Warning: what follows is madness. It is overkill taken to an extreme.  I am describing a way you can take a very, very simple procedure (connecting remotely to a system), and make it exceedingly complicated, all for the benefit of a little added security.  Whether or not this security is worthwhile to you is, of course, your business.  In an age where our governments and fellow citizens are increasingly keen on everything from our shopping and reading habits to our credit card numbers, I personally feel that cautiousness is worth the effort.

It is madness.  I’m not convinced it isn’t justified madness.

This tutorial assumes you are running Linux, and that you are comfortable with the command-line interface and with networked computing in general (of course, you’re reading this on the Internet, so that’s a good start).  All of my examples will be Fedora-centric.  If you don’t use Fedora, you’ll need to figure out what the commands are for your distro.

So, how is this complex setup I describe different from just typing “ssh user@server”?  Well, first, the callhome script executes a portknocking sequence.  Until this sequence is done, ssh is closed on the server.  After the sequence, ssh is opened only for the IP address of the client, and only for a small time window.  The ssh connection must happen during this window.  The script initiates the ssh connection, which helps keep this secure.  In addition, each portknocking sequence is valid only once – the USB drive contains a list of all valid sequences, and the script is set up to only use each one once.

Next, ssh on our server is set up to only allow connections with public keys.  This means that even if an attacker knew the correct portknocking sequence, he would not be able to login with a password – he must have the private RSA key.  The private key is on our USB flash drive, which is encrypted.  The key itself is further encrypted with its own passphrase, so you still enter a password to connect home, the work to verify it is simply done on the local machine.  The passphrase is never sent across the Internet, even in an encrypted/hashed form.

There are some other nice features, including a ‘panic’ portknocking sequence that will shut down the portknocking server itself, locking down the remote server completely.  This panic script is stored on a machine to which I have a shell account.  If the USB flash drive is ever lost/stolen, I can get to any machine with an ssh client, log in to the shell account, and kill the knock server.  New connections to the server then become impossible.

This setup is useful for more than just a terminal connection home.  You can forward X through it and run graphical apps from home (this is typically going to be very slow, however).  You can forward any ports you like, so that you can route web traffic through this ssh tunnel and prevent people on your network from watching where you go on the web.  Anything you can do with a normal ssh connection can be done here.  Later I’ll demonstrate some examples that I use. So, that’s the setup.

Now I will outline exactly how to do it, one step at a time.  You might want to grab a snack and use the bathroom – this is going to be a long trip.

Part 1: Dynamic DNS

Before you can call home to your server, it helps to have a name to call it by.  However, you can’t use a traditional hostname if your machine is on a broadband network because your IP address may periodically change.  Dynamic DNS (or DynDNS) was created to solve this problem.  A daemon runs on your server that periodically checks the IP address of the server and sends it to a DynDNS server.  This DynDNS server then updates a DNS record whenever your IP address changes. I use DynDNS.com.  It’s free and easy.  Just choose a hostname for your machine, then install and configure the ddclient software.  You can get instructions on configuring ddclient for DynDNS.com here.

Part 2: Configuring SSH

On the server, find your sshd configuration file (on Fedora, this is at /etc/ssh/sshd_config) and ensure the following options are set to these values:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no

Now, restart your ssh daemon:

service sshd restart

Now, try to ssh into your machine (you can just do ’ssh user@localhost’).  You’ll get denied immediately, without even seeing a password prompt.  This is what we want. Next, we create the ssh key that we will use.  Run:

ssh-keygen -t rsa -b 4096

When prompted, specify a path other than the default.  Your home directory is a good choice – we will be moving id_rsa to the USB flash drive later.  Also, make sure you specify a good passphrase – if the USB flash drive is compromised, the strength of this passphrase will buy you time to lock down the server. Now you have 2 files in your home directory, id_rsa and id_rsa.pub.  id_rsa is your encrypted, private RSA key.  id_rsa.pub is the public key that matches this private key.  Copy the contents of id_rsa.pub into ~/.ssh/authorized_keys.  This step will allow the private key to connect to the server as this user.

Part 3: portknocking

There’s still one significant security concern: unknown vulnerabilities.  OpenSSH is a complex program, and almost certainly still contains a vulnerability or two that haven’t been discovered.  To combat getting hit with that latest exploit, we can hide the presence of ssh from the outside world completely.  This is the beauty of portknocking. The premise of portknocking is that the ssh port is firewalled off unless a specific sequence of ports are first pinged, in order.  This doesn’t add a lot of security by itself; an attacker can simply sniff the portknock sequence, then repeat it to open the same port.  Normally, portknocking will only deter attackers who don’t know you have ssh open.

However, the portknocking server we are going to use supports one-time sequences.  With this configuration, the correct knock sequence changes after each knock.  The server has a list of sequences to use, and we will also keep this list with us on the USB flash drive. Before we begin configuring portknocking, make sure you have firewalled off port 22.  There are two possible network setups we will consider:

• You have a router between the server and the Internet.  This router passes ssh traffic to your server, and the router acts as the firewall that blocks ssh access.
• The server is connected directly to the Internet.  Local firewall rules on the machine are blocking ssh access.

In the first instance, you need to be able to install a portknocking server on the router; additionally, the firewall rules needed will be more complicated, and will vary based on how your router is configured.  My example here assumes the second case: that the server itself is listening to the knocks (i.e. it is directly connected to the Internet).  The first case is discussed in Appendix C.  Install knockd.  Once installed, you’ll need to configure /etc/knockd.conf.  For now, I’ll present a basic configuration (we’ll add some more stuff to this later):

[options]
logfile = /var/log/knockd.log

[ssh]
one_time_sequences = /etc/knockd/ssh
seq_timeout = 10
tcpflags = syn
start_command = /usr/sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
cmd_timeout = 5
stop_command = /usr/sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

In /etc/knockd/ssh, you need to have sequences of numbers to use as one-time sequences.  Each entry in the list should be formatted like this:

1,2,3,4,5

There is a space at the beginning of the line; this is helpful because knockd will comment out each line as it uses it by placing a ‘#’ at the beginning of the line.  The numbers you generate should ideally be between 1024 and 65535; I generate my numbers with a script similar to the following:

#!/usr/bin/perl
$num_keys = 50;
@data = `d20diceroller --nototals "5d65535[reroll< 1024][repeat $num_keys]"`;

foreach (@data)
{
next if (/:/);

s/ $//;
s/ /,/g;
s/^/ /;

print;
}

This script uses a program I created, d20diceroller, to generate its random numbers.  That tool is part of the d20tools package, and can be found at its sourceforge page.  The subversion repository is currently recommended. Now that you have the one-time sequences, you must start the knock daemon.  You’ll most likely want to add this to an init script (such as /etc/rc.local):

knockd -i eth0 &

‘eth0′ here should be replaced with whatever the name of your Internet-facing network interface is. Now, portknocking is configured and running.  We only need to configure the USB flash drive, and we’re done with the basics.

Part 4: USB Flash drive setup

First, you need a partition on the flash drive that will be dedicated as the encrypted partition.  This can be one small partition, or it can be the entire disk.  I set aside the last 10 MB of the disk, myself.  Use fdisk, parted, or another partitioning tool to get the disk to your liking (remember, re-partitioning can erase everything you have on the drive.  Be careful). Once the disk is partitioned, you must create a secure volume, then create a filesystem on that volume.  As root, run the command:

cryptsetup create secure /dev/sda1

Where ‘/dev/sda1′ is the device name of the partition that should be the encrypted partition.  Enter your desired passphrase when prompted.  This should be a different passphrase than you used with the ssh key, ideally.  Now, you should have a device file named /dev/mapper/secure.  This is the encrypted pseudo-device Linux has created to represent your partition.  Create a filesystem on it.  I recommend a DOS filesystem because of its portability (an ext3 filesystem will retain the UID/GID and permissions for each file, which can get really confusing when moving from system to system and using users with different UIDs):

mkdosfs -F 16 /dev/mapper/secure

Now mount /dev/mapper/secure.  On it, create a directory called .ssh.  Copy the id_rsa file you created earlier into this directory, and create a file called ‘config’ that looks like this:

Host your.server.address home
User your_user_name
UserKnownHostsFile .ssh/known_hosts
HostName your.server.address
Port 22
IdentityFile .ssh/id_rsa
Compression yes

Also, take a copy of the sequences you created earlier (in /etc/knockd/ssh) and copy them to a file called ’sequences’ in this .ssh directory.  You need to modify this sequences file so that the commas are converted to spaces.  You can do that with this command:

perl -p -i -e 's/,/ /' sequences

Now, create a script in the root of the encrypted partition with these contents:

#!/bin/sh
SERVER_NAME=your.server.name
WD=$(echo $0 | perl -pe 's/^(.*)\/.*?$/\1/')
cd $WD
chmod 600 $WD/.ssh/id_rsa &> /dev/null
sequence=`head -n 1 $WD/.ssh/sequences`
[ -z "$sequence" ] && echo "Error: No more knock sequences" && exit 1
for i in $sequence;
do nc -z $SERVER_NAME $i; done
sleep 1
ssh -F $WD/.ssh/config home && sed -i '1d' $WD/.ssh/sequences

This script will execute the next portknocking sequence in the list, then automatically ssh into the server.  It uses the config file in our local .ssh directory, so the username and key file are already specified. Now, to unmount the USB flash drive’s encrypted partition, you can execute these commands:

umount /dev/mapper/secure
cryptsetup remove secure

That’s it!  Now, all you need to do use the system is set up the partition as an encrypted volume, mount the encrypted filesystem, run the ‘callhome’ script, and enter your ssh passphrase.  Extra-secure connection home, for the truly paranoid.  The only upkeep required is to periodically generate a new list of sequences when you run low.  This system is a bit more complicated than just using an ssh command, but I discuss how to automate the connection procedure on systems you use a lot in Appendix B.

But wait, there’s more!  What happens when The Bad Guys steal our USB flash drive and start frantically trying to decrypt it?  Enter the panic knock.

Part 5: Disaster recovery

A scenario, if you will.  You’re sitting at your desk, your uber-secure connection home humming along, letting you chat on IRC without your boss being any wiser.  You lock your X session and get up to grab some coffee.  You get back to your desk, and glance over at your workstation, expecting to see protruding from the front your faithful USB flash drive, fast friend these many years, steadfast companion against the dangers of revealing your personal life’s details to those who would kill for it.  But it’s gone.  Someone has taken it. A quick survey of your fellow workers (and by “survey” we mean “threaten them with violence so they know you’re serious”) reveals that they don’t have it.  No one saw anyone come near your desk.

There is only one explanation: Identity Theft Ninja.  Trained in the secluded mountains of Japan from birth, these versatile agents of stealth can smell a USB flash drive that allows a connection to someone’s home server from a league distant.  You never had a chance. Hope is not lost, however!  Because the drive is encrypted, and the ssh key is further encrypted, you have an advantage.  The Identity Theft Ninja have powerful computers for cracking encryption schemes, but it will still take time.

Basically, when you notice your USB drive is missing, you can execute your panic script. The panic script should live on a shell server; something you can get to from any machine.  I recommend silenceisdefeat.  On the shell server, you simply have a script called ‘panic’.  It can look like the following:

#!/bin/sh
SERVER_NAME=your.server.name
sequence=("1" "2" "3" "4" "5")

for i in ${sequence[@]};
do nc -z $SERVER_NAME $i;
done

Most shell servers will not give you execute privileges, but because this is a script, you can simply type ’sh panic’ to execute it. On the knock server, we have a special action to perform when someone executes that particular sequence.  Add this to /etc/knockd.conf:

[shutdown]
sequence = 1,2,3,4,5
seq_timeout = 10
tcpflags = syn
command = killall knockd

By the way, do not actually use the sequence 1 2 3 4 5.  Use a random sequence, but include a number that will never appear in your normal portknocking sequences.  The ‘out of phase’ number guarantees you never accidentally shut down the server, and keeping the sequence random guarantees that a portscan or other malicious attack won’t lock you out down your server.  It would be a good idea to change this sequence every time you use it, as well, to prevent an attacker from repeating the sequence to frustrate you.

Appendix A: Beyond SSH – forwarding other traffic

You can take advantage of the power of SSH to create an extremely secure tunnel for almost any data; you aren’t limited to running commands on your remote machine. Perhaps you want to browse the web through the encrypted tunnel, so other users on the network can’t see that you’re really shopping on newegg instead of getting work done.  In that case, you could add this to your .ssh/config file:

DynamicForward 8137

This creates a SOCKS proxy that you can route traffic through.  Simply configure your web browser to use a proxy at localhost, port 8137.  If you want to tunnel certain sites through the proxy but not others (and you use Firefox), check out FoxyProxy. Check the command ‘man ssh_config’ for more options you can put in the .ssh/config file.

Appendix B: Mounting your encrypted volume made easy

You need root access to create and mount an encrypted volume.  If you use the same few computers all the time (and you have root access on them), you can simplify your life.  First, use the ‘visudo’ command and add a line to the end of the sudoers file like this:

your_user ALL=(root) NOPASSWD: /sbin/cryptsetup

This will allow you, as a normal user, to execute ‘cryptsetup’, which lets you create and remove encrypted volumes.  Next, add a line like this to /etc/fstab:

/dev/mapper/secure /mnt/secure auto noauto,user,umask=077 0 0

This will allow users to mount /dev/mapper/secure once it is created.  The umask guarantees other users on the system can’t see our files, which would compromise the ssh key.  Don’t worry, we can still prevent another user on the system from hijacking our mount; that comes next. Now, create two files in /usr/local/bin, called ’secureon’ and ’secureoff’.  In secureon, put:

#!/bin/sh
sudo cryptsetup create secure /dev/sda1 && \
mount /mnt/secure

sda1, of course, is whatever the device name of the encrypted partition is.  You can use udev or hal to ensure this is always a consistent name.  secureoff looks like this:

#!/bin/sh
umount /mnt/secure && \
sudo cryptsetup remove secure

Make both of these scripts executable (‘chmod 755 /usr/local/bin/secureo*’).  Now you can simply run ’secureon to create and mount the secure volume (you’ll be prompted for the encryption passphrase), and ’secureoff’ when you’re finished.

Appendix C: Behind a router

The last case we will consider is the complex but extremely common situation where you have one device acting as a router.  This changes the iptables rules we need to use with the knockd server.

First, you need to have a router that  you can install Linux software on.  In other words, your router must be running Linux.  If you have a computer acting as your router, this is probably no problem for you.  If you have a consumer broadband router, this may be more difficult.  You can get Linux firmware for certain models of broadband router, however.  Several broadband router distributions exist; I use OpenWRT; it is easy to install new software with OpenWRT, and knockd is available for it.

The exact rules you will need are going to depend on your particular iptables setup, but to forward a port you will need two rules:  one in the filter table’s FORWARD chain and one in the nat table’s PREROUTING chain.  The approach that I recommend is to add the rule in the FORWARD chain permanently, and use knockd to add and remove the PREROUTING rule.  This simplifies the knockd configuration, and allows you to use the FORWARD chain as a handy reference for what forwards are possible.

For example, let’s say you have a machine at 10.10.9.18, and the knock daemon will open SSH to this machine.  First, you want to add this firewall rule permanently:

iptables -A FORWARD -p tcp --dport 22 -d 10.10.9.18 -j ACCEPT

Put that in your router’s iptables configuration.  If your router is running Fedora, put this line (minus ‘iptables’) in /etc/sysconfig/iptables.

If you’re using OpenWRT, I would suggest using the forwarding_wan chain instead of the FORWARD chain.  Also, on OpenWRT you can put this line in /etc/firewall.user.

The start_command and stop_command lines in /etc/knockd.conf will add and remove the PREROUTING rule, like so:

start_command = /usr/sbin/iptables -t nat -A PREROUTING -s %IP% -p tcp --dport 22 -j DNAT --to 10.10.9.18:22
stop_command = /usr/sbin/iptables -t nat -D PREROUTING -s %IP% -p tcp --dport 22 -j DNAT --to 10.10.9.18:22

For OpenWRT, use the prerouting_wan chain instead of the  PREROUTING chain.

One great thing you can do with a router is use different knock sequences to forward SSH to different servers.  If you have several machines on your network, you can simply add additional sections to knockd.conf (and additional rules in the FORWARD chain).  As long as they use different knock sequences, you can overload port 22 to forward to whichever machine you need.

That’s the purpose of this site.  It will be somewhat more general; the goal of this blog is to discuss geek culture and everything that may mean to me:  programming, technology, gaming (video and table-top), and whatever else springs to mind.  However, each post will try to be an entity separate from myself; personal matters that I feel like ranting about will not appear here.  I have a personal journal for that, after all.

Anyone who feels like reading this little piece of the Internet is welcome to come along for the ride.  If it’s just an exercise in self-indulgence, then so be it.

(Below this post, you may notice I’ve included all of the posts from slashsplat as well.  Those few posts span a lot of changes in my life, so the tone will vary as you venture farther back.)

It might void the warranty, it might put my life at risk or potentially damage the thing I’ve purchased, but it is my right as a consumer.

Nintendo takes a different view on the issue.  Owners of the Wii have long been able to employ a simple buffer overflow exploit in Twilight Princess to run custom code.  This exploit, called the Twilight Hack, allows a user to install, among other things, an application called the Homebrew Channel, which looks like any other Wii channel and lets you run other custom code without using the Twilight Hack again.  It’s the gaming console equivalent of installing a new stereo in your car.

Since the hack was made public, Nintendo has been trying to thwart it.  They have, to date, released three firmware updates that included code targeted to stop the Twilight Hack.  The most recent update succeeded at stopping it completely – it appears to detect the hacked save files and delete them, both on boot and whenever you insert an SD card.

So, all of this is standard fare.  Whenever a console launches, homebrewers will make it run custom code.  The console manufacturer will release an update to prevent this.  The homebrewers will work around it.  This process will continue in an escalating cycle.

However, Nintendo has delivered a low blow here.  Along with the System Menu 3.4 update, they changed their terms of service.

Now, that’s pretty cold – deleting our custom software?  Come on Nintendo, all I want to do is play videos on my Wii!  Also, the first time a fully automated background firmware update breaks something, the angry calls are going to pour like rain.  Power outage in the middle of a night-time firmware update?  Too bad!  But it gets worse…

Okay, at this point I feel it is crucial to point out a couple of things.  First, these quotes come from two documents, the Wii Network Service Privacy Policy and the Wii Network Service EULA.  Both of these documents are required, not to use the Wii in general, but to use the Wiiconnect24 services (the Shop channel, Nintendo channel, and Nintendo’s other online content channels).  So, to use their network, you agree that they may disable your system completely.  This means two things:

1. You can perfectly legally run hacked code on a Wii that does not use Wiiconnect24.

2. You grant Nintendo the right to break the law (destruction of private property) if you choose to use the Wiiconnect24 service.

Now, according to a lawyer I know, a contract cannot override criminal law, even if signed in full knowledge as opposed to clicked-through (the enforceability of click-through EULAs is still up for debate in the US).  So this clause is, by necessity, unenforceable.

So why is it there?  Nintendo has a juggernaut legal team, famed for its ruthlessness.  They can bankrupt any individual consumer with the legal proceedings necessary to challenge them, and it is unlikely that this will raise enough stink to get a class-action suit started.

I used to have some respect for Nintendo.

In the last year, whenever someone talks about “whether Linux is ready for the desktop”, the complaints that always crop up revolve around the fact that a user can’t throw in a Linux install CD, click next a few times, and have a fully functional desktop environment in half an hour. Several things plague these proverbial users: the lack of mp3 support is probably the most problematic now, as is the lack of 3d graphics support. The complaints further, er… complain, that the user has to know what she is doing to enable/install all of these components.

What most people overlook, though, is that installing Windows is no cakewalk, either. Windows ships with almost no real video or audio hardware support – everything must be downloaded from 3rd party websites, and more importantly, the user has to *know* what vendor website to go to, and how to navigate the vendor’s site (with some vendors, that can be a real pain!).

So now, let’s be fair. I’m taking a Windows XP install, out of the box, and comparing it side-by-side with an Ubuntu Linux install. Okay, here goes.

As a user, I have to install several non-free packages, which means changing my available repositories and running a few commands (or using the graphical tool). If I prefer the less-questionably-legal route, I would purchase Fluendo (28E for their entire set of plugins, with perputual updates, as of this writing. Still about 1/4 the price of Windows’ most basic version), and follow their instructions to install it.

Of course, I also have to *know* about these options. A quick google search (“MP3s in Ubuntu”) and a forum gives me the answer, in step-by-step format.

This is even easier. All we need is to install the nvidia-glx or xorg-driver-fglrx packages, depending on the card. They’re also in the restricted repository, but we’ve already enabled it previously. If we hadn’t, the google search “3d graphics in Ubuntu” gives us the correct answer immediately.

Another quick google search turns up the answer, as always with step-by-step instructions.

And, that’s it. Everything else I need to do to be productive is already provided by Ubuntu: web browser, office suite, multimedia software. Note: I never had to restart Ubuntu during this whole process.

First, I have to figure out the name of my audio chip, which Windows doesn’t tell me. All Windows will say is “Unknown Multimedia device”. By booting Linux and running lspci, I discover it’s a C-Media chip, and go to their website. I have to give them the exact chip model number, and they give me a driver to download. I have to restart Windows.

Again, the video controller is just called an “Unknown display adapter”. Foreknowledge tells me I have an Nvidia Geforce 6600 GT. I go to Nvidia’s website (much easier to use than C-Media was), and get the driver. I have to restart Windows.

Well, this one installs automatically. Doesn’t even need a restart! 1/3 isn’t bad, I suppose.

What’s the point of this exercise? Am I trying to say Windows is teh sux0r? No, that’s not my message today. I could extoll the myriad problems with Windows that make Linux a better option (spyware, viruses, openness and all the benefits thereof, etc), but that’s not the point.

The point is this: when it comes to installation, Linux and Windows are roughly equivalent in complexity. Linux has its installation issues; so does Windows. They tend to break roughly even, in my experience, although Linux has a much more readily available support structure in the form of community forums. But both OSes require a lot of user knowledge in order to get up and running. They assume you already know how to do things. What they really assume, underneath, is that

Most Windows users never install their OS; some technician installs it, either OEM at a factory, or at the local computer shop, or the in-law programmer who gets drafted for technical work (ahem…). Linux users have seldom known this luxury; instead, whenever someone talks about Linux, they assume that the end user is doing the install.

The solution is to treat Linux installation the way we treat Windows installation. Someone who Knows What They Are Doing ™ sets up the OS and delivers it to the end user. One practical advantage for the Linux community is that all the time spent on fancy installers could be channeled elsewhere (not to say we don’t like our hardware auto-detection, et al. But a curses-based menu is just fine, thanks). Make Linux installation work like OS installation always has before: technical users install their own OS, everyone else leaves it to the techs.

At least don’t hold us to a double standard.

Where have I seen this kind of threat before? Hmm… SCO, anyone? Is MS really desperate enough for that? SCO only sued IBM because they were losing money in copious amounts, flirting with bankruptcy. Vista seems to be the straw that’s breaking Microsoft’s back.

That is all.

To that end, I’ve been thinking about how Second Life could be successfully decentralized, without adversely affecting the experience that everyone has come to know and love. I’ve identified key elements of the user experience that would be difficult to decentralize, and possible ways to handle them. First, though, we’ll talk about the basics; how could decentralization even work.

First, LL releases the code for the Second Life server. Now, anyone who wants to can host a Second Life sim/sims of their own on a server. A central repository would keep track of the existing sims, in a vaguely similar fashion to DNS (see The Grid, below). This would allow Second Life to grow without bound, with sims run by a multitude of companies and even home users.

So, how do we keep that Second Life experience without the centralized monolith of Linden Labs?

Economy
First and most importantly, the Second Life economy must be preserved. The economy has become the most crucial element to the experience; the ability to use real money, diluted down to a virtual quantum, to purchase other users’ custom created content. This breaks down into two sub-problems:

a) Managing the money. The most likely way to do this would be to set up a “bank”, wherein a single host (or several different hosts) manages all of the banking transactions. I’m thinking basically a system like paypal, where you buy L$ (“Linden Dollars”, Second Life’s currency) from the bank, or sell $L back to the bank for real currency. Each SL server would use this central bank system to check a user’s account balance, and make withdrawals/deposits, with proper confirmation on the part of the user, naturally. A public/private key system to ensure the user actually sent the confirmation could prevent abuse here, so no worries on that score. The SL bank could even be controlled by Linden Labs, as this would be a lot easier to handle than the entire grid, and still give them opportunity to have a strong stake in their creation.

b) Protecting Intellectual Property. This is a tricky problem, and the single hardest element to decentralizing SL. Since a huge portion of the money in SL is traded for users’ creations, there must be a way to prevent them from being stolen. Under a decentralized scheme, when a user rezzes an object on a sim, all the data for that object (textures, sounds, scripts) would necessarily be available to the owner of that sim. The most obvious solution I can find for this is to keep the object data elsewhere, and have a rezzed object be a pointer to that data. The advantage is that compiled scripts, raw texture data, and sound files stay on a secure server independent of their rezzed location. But where is this mystical server? I see two options here: either the data is on another sim, perhaps the user’s “home sim” (see User Accounts, below), or the data is in a central “asset server” (essentially the way SL works right now). Using the former approach, the client would have to make tons of connections to different servers to get all the data. Under the latter, the asset server would have to be extremely load-tolerant and robust, and all the data is stored by the same group of people, whose ethical integrity the SL user base would have to trust implicitly. Since both of these are flaws in the *existing* Second Life system, however, it is acceptable for the hypothetical exercise we’re attempting here. Also, under either system the sim owner’s creations could be stored on-sim for lower lag.

One other solution would be to create some DRM scheme that encrypts this data until it reaches the client. Of course, in all of these cases the client could be modified to steal the data. However, here we again reach the fact that these flaws are already inherent in SL, and there’s no easy way around them.

The Grid
The ability to bring up a map and scroll around, or teleport instantly to another part of the world, is an exciting part of SL, and another crucial part of the SL experience. Fortunately, the Internet already has a great system that we can build on – DNS and hyperlinking. We simply define 2 kinds of link: “landmarks” and “neighbors”. Each sim can have 4 neighbors, and neighbors must mutually agree to be neighbors (for a neighboring to work between sim A and B, A would have to set B as a neighbor and vice versa). The neighboring agreements would be stored in a central server system, modelled on DNS. A few recursive calls to this system and each sim can cache a portion of the overall grid map. Want a private island? Simply don’t neighbor your sim with any others. This creates user-level “peering agreements” that could create a more logical terrain (snowy areas linked together, etc) even if the landscape does shift from time to time.

The other kind of link would work just like landmarks in the current SL system. Pretty self-explanatory, except this system would make “click to teleport” objects a necessity, finally.

If a user searches for a sim on the map, the client can grab that sim’s cache of neighbors, and display more of the grid. The client could be configured to keep any amount of that information cached locally, for a more immersive experience.

User Accounts
There are two ways to handle user accounts: a centralized account server, or a sim-based account system. Under a centralized server, all accounts would be handled by, say, LL. This simplifies the system greatly, and aids in managing the asset server. With “home sims”, you’d have a system similar to Jabber, where user accounts are essentially user@home_sim. I believe the centralized system will work best, given that the asset server system seems to be the most logical way to do things.

Instant Messages
Well, LL is currently planning to re-implement the IM system in Jabber, so we’re pretty much covered there :P

So, in summary, we have a system that uses a centralized server for accounts and user-created assets, as well as a DNS-like neighboring system to create the world map, but grids are controlled by individuals, and hosted by companies just like web servers are now.

So, what causes this, if not simply “they’re dumb”? Fear. Technology is mysterious; most people, when confronted with something unfamiliar, are uncomfortable. It feels like some delicate piece of magic; if they touch it too hard, it might shatter.

The consequence of this fear is that, once gripped by it, people start assuming they *can’t* learn anything about computers; it’s too arcane. So, when presented with technical terms or ideas, they stumble over them. If the technophobe stopped to think about the idea they are grappling with, they’d probably figure it out pretty quickly. But their mind won’t do that, computers are “too complicated” for anyone like them to figure out.

An example: USB flash drives. Even most technophobes know what floppy disks are, but when you tell them this is similar, except it connects to that rectangular plug on the side of their computer, they give a blank stare. They can’t comprehend it because it’s new.

A better example: If presented with two products that very clearly do the same thing, but are made by different companies, the technophobe will invariably ask “what’s the difference between these two?” If you showed them a Dirt Devil and a Hoover, they would have no such problem, but computers are *mysterious*, afforded a special class of untouchability.

So, to all you technophobes out there: Stop being afraid of the computer. I promise it won’t bite. Engage your mind and really *listen* when computer jargon floats by. Make intuitive leaps; even if they’re wrong, they’ll eventually point you in the right direction.

A programming language is a tool. A skilled craftsman isn’t good at her trade because she knows how to use a given set of tools; anyone can learn that. Rather, true skill comes from knowing how to *apply* the tools. The fundamental concepts behind programming are the skills on which we should be focusing.

This applies to academia as well. The language you use to teach students, especially the first language they encounter, *is* important. I’m not about to advocate “teaching languages” like Pascal, though. I think it’s important to choose a real-world language, with all the pitfalls and caveats of a real-world language, as a student’s first language. At the same time, it should be a language with the features available to demonstrate all the fundamental concepts in programming. A language that doesn’t support recursion would be a Bad Choice, for example.

So, when someone (a peer or a hopeful programmer-to-be) asks me “what languages do you know?”, I won’t respond “Well, I know C, C++, Java, perl, php, xhtml/xml/css (if you count those), lisp, prolog, LotusScript, Javascript, LSL…” etc. Instead, I’ll say “I’ve used a number of languages, but the key thing is that I know how to learn any language.” When an employer asks, I suppose I’ll have to say “Well, I know @languages…”. Then, though, I might add “…but I consider the fundamental concepts behind programming languages to be more important, because mastering those means I can learn to get around in any language given a week or two of study.”

In summary: Learning a programming language is trivial, once you know the fundamental concepts of programming.