But my wife, she loves The Sims. She has sunk at least as many hours into The Sims 3 as I have in Starcraft 2 and Civ 5 combined. She owns every major expansion that’s been released, as well as The Sims Medieval and its expansion.

So when her Sims 3 update failed halfway through, leaving the game in an unlaunchable state, she was understandably distressed. The game plus all of its expansions requires a lot of effort to reinstall; we’d be looking at several hours of installing, with user prompts spaced just far enough apart to make doing anything else impractical.

So, we researched the issue and discovered that the EA Download Manager needed to be updated before The Sims 3 could be updated. Now, EA doesn’t make it terribly clear that the Download Manager is a separate application; it is usually launched from The Sims launcher, and is skinned to look like any other menu in The Sims when this is done. So, we found and updated the EA Download Manager.

And it turned into EA Origin.

Again, nothing told us this was going to happen, it just popped up an EA Origin installer, without telling us what Origin was, why we needed it, or why it started installing it when we were trying to update EA Download Manager.

Some further googling revealed that EA Origin is the new replacement for the Download Manager, and that it (gods help us) is “our new digital playground”. Apparently it is EA’s attempt at Yet Another Online Distribution System. With social features! Look, EA, I hate to break it to you, but Valve already one that battle conclusively. We need another Games For Windows Live about as much as we need arsenic.

The fact that nothing told us, at any point during this process, what EA Origin was or why it was being installed is a huge oversight. The user shouldn’t have to use Google to figure out what the product you’re giving them is. This is a terribly sloppy user experience.

But it’s still not insurmountable. So, rolling our eyes, we proceed to install it, and then we go back and launch The Sims 3.

It launches EA Origin instead.

Why has this happened? Perhaps Origin serves as the new launcher? Okay, that’s fine – another crappy application sitting in the system tray, but we can at least live with this. Let’s just launch The Sims 3 through Origin.

What’s worse, EA Origin wants us to create a profile before it will let us do anything. This is obnoxious – yesterday, The Sims 3 would just launch and let us be happy. Plus, we already have a login on The Sims website, which is where you go to purchase downloadable content for the game. So this is Yet Another Login to Remember, and that’s annoying. With absolutely no warning, EA has added a ton of requirements that prevent us from playing a game that has worked fine on its own. Still, whatever. Let’s make this profile, get this over with.

Now we can just launch The Sims 3 from here, right?

Click. Click. Nothing happens.

Did we do something wrong? Is our profile not acceptable? Is EA just not that into us any more? We close origin, launch it again, try The Sims again. Still nothing. After a few more minutes of troubleshooting, we give it the old Windows solution – we reboot the machine.

When we get back to Windows and launch The Sims again, it launches perfectly, without seeming to care about EA Origin. It’s like nothing ever happened, and everything works just fine. The old Download Manager interface is even still there, and allows us to update the system. Apparently it just wanted Origin for authentication, or something?

But even though this story has a happy ending, there are still troubling implications here. EA did a very poor job of informing the user about what was happening here, leaving us to guess and google and hope that things would end up working. This was a very stress-inducing experience, which is not what you want when you sit down to play a game.

Also, the fact that they retroactively tied a single-player game into an online distribution platform seems both unnecessary and potentially problematic. When we bought the game, we did not do so with the understanding that an Internet connection was necessary for authentication or activation, for instance. We didn’t agree to have the game tied in to an account that may prevent us from updating if it is ever suspended or deleted for some reason (and these things happen; no system is free of errors). While we don’t have any reason to suspect that the game would become *unplayable* in the absence of Origin, this is still troubling.

In a post like this, I would, at this point, customarily make a plea to the company in question to be better, to stop disappointing its users, to be more transparent and try to foster trust. But I’m not going to bother. Because EA has proven themselves time and again to be unwilling to hear those pleas. Instead, I’m going to close with a question.

EA, what happened to you?

Curious, my friend and I got a ride over to Media Play. There, I found a pretty large group of people playing Magic. I also saw an interesting sight: some people with books, funny shaped dice, and little painted figures arranged on a square grid. I watched for a few minutes, and quickly got the gist of what they were doing. I asked if I could join. The response? “Sure, we need a cleric.”

Thus began a hobby that has spanned half my life and cost a great deal of money. I have played a number of systems: World of Darkness, Cyberpunk 2020, Shadowrun, Rifts, Call of Cthulhu, Star Wars (the older edition that used d6s), homebrew systems created by various friends. But I always come back to D&D. It was my first system, and it remains my favorite through three editions of the game. In a lot of ways, it has grown with me.

In the last few years, though, I haven’t had many chances to play D&D. I was skeptical of 4e at first, and then spent a lot of money buying 4e books after Alexandra Erin convinced me of its merits in her repeated, impassioned blog posts about it (all of those links are excellent reading, even if you already know you like 4e). I sat on these purchases for months, planning games, even getting some people to make characters. But no game formed; the other players either didn’t have free time, or I didn’t have free time, or we were too far away.

The Search for a Gaming Table

Eventually I found a little free time to bring a game together, and since I couldn’t solve the problem of my friends’ lack of free time, I started looking to solve the problem of people who had free time, but were too far away. So I started looking for a solution to playing D&D over the Internet. Namely, what I needed was something known as a virtual tabletop. I started out with simple requirements: free is good, open source is even better. Since there was no good overview or comparison of the existing virtual tabletop options, I decided to make one. I’ll describe, briefly, why I didn’t pick each one (until I get to the one I *did* pick, of course).

OpenRPG – frustratingly deprecated

Years ago (about 10 of them), I tried using WebRPG as a virtual tabletop. I remember it having a somewhat cumbersome and over-engineered interface, and being frustrated with it on many levels. Still, it was the first thing in my memory, so it’s the first thing I looked up. Turns out it went open source a while back, and is now called OpenRPG.

Unfortunately, this was a non-starter. OpenRPG is written in Python (yay!), but doesn’t work with Python 2.7, which is the de facto standard in Fedora. I didn’t want to maintain a separate Python install for just one program (this is possible, but would be a pretty big hassle to set up), so OpenRPG was a bust.

Screen Monkey – expensive and cumbersome

The next program I discovered was Screen Monkey. Once again, Alexandra Erin was instrumental in this – she mentioned using it for her online games. Screen Monkey has one big advantage – for the players, it is browser based, so only the DM needs to install any client software. Unfortunately, that software only runs in Windows. So, I found an old install disk for Windows XP, and installed it as a virtual machine using KVM. Then I installed Screen Monkey Lite.

More bad news, though. Screen Monkey Lite turns out to be rather light on useful features. The biggest problem is that you can’t save your work – you have to buy the $35 version of the program to save and restore a session. The tools for hiding what the players can see was also fairly awkward. Awkward, in fact, is the word I would use to describe the program’s feeling as a whole. NBOS are terribly proud of their software ($35 proud) only to be outdone by multiple free and open source competitors. Sounds like some other software companies I know.

Gametable – RIP

Gametable looked promising, but doesn’t seem to be actively developed (there was a sourceforge project available a while back, and remnants of it are here, but it seems to be dead now), and it didn’t work very well for me.

Fantasy Grounds – pretty, but overpriced

Next up is Fantasy Grounds. I didn’t even try the demo once I saw the price tag – $40 for the DM-capable client, and $24 each for the players’ clients. One of my hard requirements is that my players not have to spend any money on the solution, so this one was right out. For a more affluent group, though, it might be a great solution. I will concede that it is gorgeous, and looks very well polished. Certainly a better contender for your money than Screen Monkey. And it has acknowledged, if unofficial, plugins for various game systems, including D&D 4e.

MapTool – the right balance

Eventually, I found MapTool, one of the applications created by the RPTools team. MapTool originally didn’t impress me – it seemed cumbersome and unwieldy. After working with it for a while, though, I found that most of its design decisions make sense, and that it is very powerful. Like most powerful toolkits, it is subsequently pretty complicated, and using it effectively took some practice. However, once I got the hang of it, it’s unbeatable. It’s more stable than any of the other open source offerings, and it runs well out of the box. It lets you use fog of war, individual player views (based on available light sources), and it lets you make maps in advance but have them hidden from the players until you are ready to show them.

Also invaluable was Dorpond’s 4e framework. This is a set of configuration settings and macros that work together to make MapTool work well with the D&D 4e rules. I have modified his macros a bit to fit my particular play style (notably, I prefer to let players roll their own initiatives), and am continuing to do so as I playtest them. You can find my latest version of the framework here.

Also, three caveat with maptool:
1. The network functionality doesn’t work with OpenJDK. Linux users will want to install the Java JRE instead. In Fedora, I just installed the jre RPM from Sun’s website, then edited MapTool’s startup script and added ‘export JAVA_HOME=/usr/java/default’ and ‘export PATH=\$JAVA_HOME/bin:\$PATH’ near the top of the file.
2. When starting a server, if you do not select ‘Use Individual Views’, the GM will not see an accurate version of the player’s view.
3. When you have tokens in the initiative list, players can only move their token on their own turn. Trying to move when they don’t have initiative will send them into an annoying endless loop of NullPointerExceptions. I’m hoping this gets fixed soon by the MapTools team, because it’s an obnoxious bug. Luckily, MapTools is Open Source – I may take a crack at finding that bug myself.

D&D Virtual Table – still cooking

Wizards of the Coast has recently announced a beta version of their own virtual tabletop – called, simply enough, D&D Virtual Table. It is only available to select D&D Insider subscribers. And, since D&D Insider is not worth the price for me personally (a topic worthy of an entire post unto itself), I have no idea whether it is any good. It would also certainly require every player to have their own D&D Insider subscription, so it breaks my stated rule. Still, it might be something to keep an eye on.

Adding Voice

So, now that we had a game table, we needed a way to talk to each other. Luckily, there is a readily available, cross-platform solution to this: TeamSpeak. Now, TeamSpeak isn’t open source, and it is not free if you want to host multiple teamspeak servers on one machine (or have more than 32 clients connected). But it’s great for a D&D game, which would never need those resources. It’s dead simple to set up the server in Linux, and the permissions management is very intelligent (and again, dead simple).

Let’s look at the options I didn’t choose for voice chat: Skype relies on a central server, and has a history of iffy privacy practices. Ventrilo offers a Linux server, but no Linux client. And the voice chat available in various Instant Messaging programs is either unreliable, or doesn’t work in Linux either. So, TeamSpeak it is, and it works great.

Passing Notes

The last thing I needed was a way to present textual information to the players. I do a lot of world-building and writing background material, and I want to make sure that is available to the players (at least, the publicly revealable parts). I also want to be able to give them things like notes that they might acquire, and possibly conduct some roleplaying between sessions if a session ends during downtime.

There are plenty of ways to simply share files, and these would be adequate. Dropbox could be used, especially for image files. Google Docs seemed like a pretty good way to share documents with players. After considering it for a while, I discovered a site called Epic Words. Epic Words gives you a journal system, so players can post in-character summaries of game sessions; this also works well as a means to deliver chunks of story-based text such as notes, riddles, etc. in a way that the players can easily access and remember.

Epic Words also has wiki-like functionality, and lets you define “references”, including NPCs and places, that will be linked automatically when mentioned in a blog post. This is an especially useful feature, because it lets me, as the DM, add content to the players’ writings without actually changing their creative work. It also gives you a private forum, which is perfect for the kind of between-session downtime roleplaying I have in mind.

Epic Words’ biggest problem is that it only allows you to run a single campaign without either upgrading, ‘retiring’ the existing campaign, or deleting it. And even with the upgrade, there doesn’t appear to be a way to share references / wiki content between campaigns (I don’t know this for sure, because I can’t really test that, but it appears to be the case). If I were running multiple campaigns, there is a slew of generic world history and other setting information I would like to share between campaigns. If you could make wiki pages independent of campaigns and then ‘link’ them in, that would be ideal. As it is, I happen to only be running one campaign at the moment, so I will have to cross that bridge if and when I come to it.

Final Thoughts

In the end, I ended up using three tools to interact with my players: MapTool, TeamSpeak, and Epic Words. I like this solution because it is very Unix-philosophy friendly – each tool serves one purpose. MapTool acts as our tabletop, TeamSpeak is how we communicate, and Epic Words gives us a handy place for wrap-up/reference/between-session play. The overall experience is pretty excellent; this is a good way to play D&D. It is better than I was hoping for, and even surpasses actual face-to-face play in some ways (I would love to find a way to use MapTool with a projector for face-to-face play).

wine is not an emulator

Let’s start with the basics (then probably skip the middle ground and jump straight to the advanced stuff). Programs written for Windows or Mac OS can’t be run natively in Linux. By ‘natively’, I mean you can’t just click on a Windows application, or type its name on your terminal, and expect it to work. You’ll get an error like this:

bash: ./windowsprogram.exe: cannot execute binary file

There are a number of reasons this doesn’t work. The first and most fundamental is that Windows and Linux use different binary file formats; that is, the actual program code is structured in an entirely different way.

So why not just create a tool that can take one binary format and convert it to another? Well, to begin with, that would be pretty complicated, and probably fraught with problems; these binary formats are actually pretty complex, and include things like how to dynamically access libraries. Libraries are big chunks of code that are written separately from the program, then used by the program so that software developers don’t have to repeatedly write the same code to accomplish common tasks.

And that leads us to the real problem – Linux and Windows have fundamentally different sets of libraries available. Each OS has a large collection of system libraries that developers can use to interact with the Operating System in different ways. And there is very, very little overlap between these libraries. A prominent example of a library that exists only in Windows is Direct3D, which is used by a lot of game developers; it contains code that makes it easier to do a lot of complicated things with the graphics card, thus making it easier to make pretty, visually involved games.

So, if you want to run a Windows program in Linux, you would have to create a tool that could take a Windows program, make it “think” it is running in a Windows environment, and then take its library calls and somehow convert them into a set of library calls that Linux can understand. Direct3D calls, for instance, might be converted into equivalent OpenGL calls in Linux. This is exactly what the wine project does.

Wine has been around for a long time, and it has aged well (these are the jokes, folks). The latest wine codebase does a great job handling a ton of Windows applications, including a great many games. This article is an overview of my experience using wine to play games on Fedora.

blizzards and steam valves

My journey begins with wine-1.3.18, the version packaged with fedora 13. Wanting to play Starcraft 2, I ran the installer, which executed without a problem. The game itself also ran great, without having to make any tweaks at all to wine’s configuration. So, Starcraft 2 was an easy win. Blizzard’s games, in general, work great under wine. I’m not sure if Blizzard just avoids strange API calls, or if wine has a lot of developers interested in making certain Blizzard’s games work. Either way, this one was phenomenally easy.

The next thing I tried was Valve’s Steam client. If you’re somehow reading this from the past, or Steam no longer exists in the future (or you have recently emerged from a coma), Steam is a game distribution platform. You can buy electronic copies of games, install them in steam, and play them. Many games also support achievements and server-side syncing of your game data. This makes gaming on multiple computers really nice (as long as you’re the only one using Steam, that is). It also has community features; you can see what your friends are playing, join them in multiplayer games, etc.

So, I have quite a few games on Steam, and before I can try to run the games under wine, I have to get Steam to run. This was a little bit trickier than running Starcraft 2. First, the Steam installer is a .msi file, which requires the msiexec tool to run. Luckily, recent versions of wine come equipped with an open-source clone of the msiexec tool. So, all I had to do was:

msiexec SteamInstall.msi

Once this was done, Steam launched, but I ran into a new problem: every time I move my mouse over the Steam windows, they would flicker, making it hard to see what I was doing. This was solved by using winecfg to set the ‘Windows Version’ to Windows 7. Problem solved.

The next problem I encountered with Steam was that, when I drag a Steam window, it continues to move around after I release the mouse button, as if I’m still holding it. I have to click on another Steam window to make it stop. This problem remains unsolved in the latest version of wine (1.3.21 as of this writing).

Having Steam running, though, I was able to try a few games. The first thing I discovered was that every game I tried had major problems until I unchecked ‘Enable Steam community in-game’. Once I had done this, Plants vs Zombies and Darkstar One both worked great ‘out of the box’, with no tweaking required.

Portal, on the other hand, was not as great. Every few seconds of game play (not exactly precise, and it happens more when portals are open) the game will stutter for a moment. I spent a lot of time tweaking wine to try to fix this, but the problem remains in the latest version of wine. In addition, in wine 1.3.20, an even worse problem appeared – instead of stuttering, the game would act as if the mouse had been moved a random distance in a random direction periodically.

The last game I tried out was Team Fortress 2. It refused to start until I added an override for hl2.exe (in winecfg) disabling gameoverlayrenderer.dll and changing the Windows version to NT 4.0 (who knew Windows NT was a good gaming platform?). After this, the game worked with a stuttering problem similar to Portal’s, but more dependent on how much action was happening on screen. This was probably my most disappointing experience with wine, and 1 problematic game out of 5 isn’t bad.

So far, I have a (let’s say) 80% success rate with running Windows games under Linux using wine, with comparatively little effort required on my part. This is a fantastic result compared to even 2 years ago, and I look forward to watching the wine project enable ever more games under Linux.

tips, tricks, caveats

If you’re using Fedora, you may run into problems with pulseaudio. I recommend disabling it completely, via the following:

yum remove alsa-plugins-pulseaudio
echo > ~/.pulse/client.conf << EOF
autospawn = no
daemon-binary = /bin/true
EOF

Then, reboot your machine (or make sure you kill all running pulseaudio processes). Wine works a lot better this way. You’ll probably also want to run:

setsebool wine_mmap_zero_ignore 1

To make SELinux play well with games in wine.

Something I wanted to do but was unable to achieve was run native Linux games directly from Steam, and have Steam keep track of them. After asking on the wine-users mailing list, I learned that the way wine emulates Windows process handling makes this impossible. So, instead, I created steamstub, a Windows program written specifically for Steam under wine. To use it, add it as a non-steam game to Steam, then edit the game’s properties and change the name to a native Linux game of your choice. Now, before you go play your Linux game, click ‘Play’ on this game in Steam. Steamstub will deliver a small popup, and to your Steam friends, it will look like you are playing a non-steam game until you click ‘OK’. This lets you advertise what game you are playing, even when Steam can’t launch it.

One more thing you may find interesting is a tool I developed called wino. It lets you keep track of multiple wine prefixes (virtual Windows environments), so you can keep your programs separated. This makes it easier to recover if something in your drive_c directory gets broken; you only have to worry about reinstalling at most one program. If you make heavy use of steam’s ‘non-Steam game’ functionality, like I do, then this is not as useful for you. However, wino also does a lot of other useful things, like allow you to have a default command assigned to a wineprefix (so you could just run ‘wino steam’ to launch Steam.exe). It can also run winecfg (and a lot of other tools) on a prefix via ‘wino prefixname –config’.

However, I have a problem with (most of) the available BitTorrent clients. Given what BitTorrent does, which is allow you to download and subsequently seed content, it should really run like a service – quietly running in the background handling your torrents. However, most of the clients for Linux work like Windows applications. They sit in your system tray, giving you “helpful” popup notifications. More importantly, they die if you logout. Luckily, I have found a solution.

Enter transmission-daemon

Transmission is one of the bittorrent clients for Linux that works like I described above – it’s a desktop application. However, it comes with a variant, transmisison-daemon, that can run in the background, as a dedicated ‘transmission’ user. This is much nicer.

Setting it up in fedora is pretty easy. Install the transmission-daemon package. Edit /etc/sysconfig/transmission-daemon to suit your needs. You can change TRANSMISSION_HOME to whatever directory you’d like your completed torrent files to live in (you do not need to modify the actual home directory of the transmission user, but do make sure TRANSMISSION_HOME is owned by that user).

Now, start transmission-daemon, then stop it again:

service transmission-daemon start
service transmission-daemon stop

That step created the transmission configuration files, which you can now find in $TRANSMISSION_HOME/.config/transmission-daemon/. The file you probably want to edit is settings.json. Edit this file to suit your needs, then start transmission again. To tell transmission to automatically start at boot, run:

chkconfig transmission-daemon on

transmission-remote – for all your transmission-related needs

So, now you have a daemonized BitTorrent client, running unobtrusively in the background. But how do you use it?

The answer is transmission-remote. This tool is an administrative front-end for transmission-daemon that lets you add, remove, start, stop, and view your torrents, and a lot more besides. To add a torrent, you can use ‘transmission-remote -a’ on either a local .torrent file or a URL, like so:

transmission-remote -a /path/to/file.torrent
transmission-remote -a http://example.com/file.torrent

Once the torrent is added, it will automatically start. You can get information on all your torrents with ‘transmission-remote -l’. Note that each torrent has a numeric ID assigned to it; you use that ID with the ‘-t’ option to tell transmission-remote to perform actions on the torrent. For example, to stop the torrent with ID 42, you could run:

transmission-remote -t 42 -S

transmission-remote can do a lot more; check its man page for details. In particular, the -s, -i, and –remove-and-delete are useful flags to know.

Making things easier – the watch directory

The problem with the approach I have described is that the command line, while great for interacting with your local torrents, is not the place most people go to look for torrents in the first place. More often, you find a .torrent file on the web, and having to open a terminal and run a command is an annoying extra step.

To make things easier, you can set up a watch directory; any .torrent files placed in that directory will automatically be added to transmission-daemon. To set up a watch directory, edit settings.json and add the following:

watch-dir-enabled: "true",
watch-dir: "/path/to/watch/dir",

(I have found it is best to always stop transmission-daemon before making changes to settings.json. It often overwrites settings at shutdown)

One caveat about the watch directory: when transmission-daemon is started, every .torrent file in there will be added. While this has no effect on torrents you are still downloading or seeding, torrents you have already removed will be re-added to transmission-daemon. For this reason, it is a good idea to routinely delete the files in your watch directory. You can use tmpwatch and/or cron to periodically delete the files.

Torrents from anywhere – using Dropbox with transmission-daemon

Dropbox is a fantastic tool for always having access to important files. Any files you put in your dropbox directory get automatically synced to every machine you use dropbox on. There are also Android, iOS, and web interfaces, so you can really get to your files from anywhere.

What does this have to do with transmission? Well, you can put your watch directory inside your dropbox directory. Any .torrent file you add to that directory – from any computer or phone – will automatically be started on the computer running transmission-daemons. This means you can start your torrents whenever you come across them, no matter where in the world you happen to be.

And if you have multiple people in your household who might all like to use one machine for BitTorrent, you can simply share your dropbox watch directory with all of them.

The way computers should behave – the world according to Anna

User interface design is a complicated thing, and a lot of research has gone into it. What a lot of UI discussions miss, though, is that everyone has different needs and preferences. The setup I have described here works the way I personally like best. It is transparent; that is, it gets out of your way and just does what it is supposed to do, with no fuss. It is powerful and flexible. For a Linux power user who prefers to use the command line where she can, it is hard to imagine a better BitTorrent solution.

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.

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.

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!

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.

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.

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.

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.