Setting up Bridged Networks (in Linux) For Dummies

I set up VirtualBox to do virtualize some odds and ends testing I was doing (specifically, with the intent of freeing up a laptop to be reissued) and encountered the wonderful problem of trying to bridge the connections to the network at large. With VMWare Server, this is delightfully trivial. The bridged connections are already set up and all you have to do is pick it off the list when setting up the virtual adapter. VirtualBox works the same way, but you have to set up the adapters yourself. So, here are my notes on doing it.

At the system level, what you are doing is creating a bridge (which enslaves a hardware interface) and creating virtual adapters off of it. What you get is something like this:

On Debian (and, by extension, Ubuntu) you can create the devices by editing the /etc/network/interfaces file and adding the following sections:

  1. auto br0
  2. iface br0 inet dhcp
  3. bridge_ports all tap0 tap1
  5. auto tap0
  6. iface tap0 inet manual
  7. up ifconfig eth0 up
  8. down ifconfig eth0 down
  9. tunctl_user <user>

The first section creates the bridge and enslates eth0 to it. The second section creates a TAP interface that is assigned to that bridged device.

Alternatively, you can manually run commands like the following to accomplish this task. If you go this route, you will want to take your commands, put them in a shell script, and rerun them at boot time so that your interfaces are recreated after booting up. The utilities are brctl (for the bridge) and tunctl (for the TUN interface). Given the sections above, it is actually pretty easy to know what sequence of commands to run, so I’ll leave that as an excercise for the reader (with the help of the man pages/help section).

There you have it. All you need to know to go crazy and create seven million bridged network devices. While my reason and example here is setting up VirtualBox, it is not the only use for it. Other uses include operating system virtualization, running multiple services on different IPs (i.e. bridging Apache to another address than the main system one), and other general tomfoolery.

The Problem with Poker AI

My wife and I watched Roger Moore in The Saint last night. The episode in question opened with Simon Templar sitting at a table playing poker with some underworld characters. He cleans out the head of these by bluffing his three eights (I think?) over the other man’s three jacks. The opening camera work focused a great deal on the expressions of the players. Then it occurred to me: this is why, at the present level of technology, poker AI will never, really be feasible.

At the highest level, poker isn’t really about hands. There is fairly little one can do about that and, what can be done, is very strictly governed by the laws of probability. If it were, computers would whip the finest poker players right now. The game comes down to each player’s ability to read the person across from him. When they’re right they either win big or avoid losing. When they’re wrong, they lose big. Computer’s cannot read human expressions. They can have various heuristics built in and they can compute probabilities until it would make any of our (human) heads spin, but they cannot understand people beyond the most primitive tendency tracking. So they will fail, ultimately. Moreover, they cannot offer the player the fun that by and large comes with the game, of trying to see how well he does know the person across from him.

Computer poker is about hands. Human poker is about people.

Blogging Code

As you may have noticed, some of my snippets have not rendered too well on this website. I have tried a few things, including the fine highlight and pygmentize tools. However, the results have been…ugly. The WordPress layout seems to have been intefered with by the classes and CSS as posted. I just installed the excellent Highlight Source Pro plugin for WordPress and, after revising my recent PHP post, the results look quite promising. I will be doubling back and revising my past code snippets to make them much more readable.

Personal blog

To date, I’ve kept limited to professional and vocational elements. I figure that when I am on programming/computer science blogs, I want to read about programming/computer science. When I am looking at non-techie blogs, I am looking for non-technical information. With a few exceptions, the two worlds do not seem to mix all that readily. So, I have created a separate blog at dedicated to personal, political, theological, and literary musings. If you’re interested head on over and follow it for a bit. If you’re not…well, that’s why the blogs are separate.

Caveat to PHP array functions

I was doing some work in PHP that, at least as I was approaching it, made use of many arrays. Having spent too much time in Lisp and company, I used functions like array_map regularly as the more expressive, concise, and elegant way to do my crunching. Several of these functions had their home within a class and were private static functions.

My test box had the following version:
PHP 5.2.6-2ubuntu4 with Suhosin-Patch (cli) (built: Oct 14 2008 20:06:32)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

and the live server:
PHP 5.2.0-8+etch13 (cli) (built: Oct 2 2008 08:26:18)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies

True the test box was slightly newer, but not so much that it usually matters. In review, the test box allowed code like the following:

  1. class Foo
  2. {
  3.      private static function exampleUpper($a)
  4.      {
  5.          return strtoupper($a);
  6.      }
  8.       function something()
  9.       {
  10.           $a = array('a', 'b', 'c');
  11.           return array_map('Foo::exampleUpper', $a);
  12.       }
  14.  }

Naturally, the original code in question actually did stuff, but this should get the point across. The idea of using the :: operator (on a public or private static function) worked in the slightly later version of PHP, but not the earlier. The more’s the pity, too.