After looking into the OpenERP/OpenObject project (which looks pretty neat), I realized their complex GUI was written in Python. After a little investigation, I figured out they were using PyGTK (Python bindings for the GTK widget toolkit) and Glade (a GUI builder).

Combining Python, PyGTK and Glade seems to lead to a workable solution for creating GUIs for Python applications. There’s a nice tutorial on how all these pieces fit together here.

I should really move to lighttpd or nginx one of these days…

#!/bin/bash

# Custom prompt
PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h:\[\e[33m\]\w\[\e[0m\]$ '

Turns out none of the Windows fonts support box drawing characters (from what I’ve read, it seems that they don’t have the characters in the expected positions in the character table)…

The easiest solution is to tell MC to use non box drawing characters to draw boxes with the -a switch. The other solution is to get the Lucida ConsoleP Font. (254), and set rxvt to use it (as suggested by this guide).

How do you set the fonts? You could set them with command line switches, or use a .XResources file in your Cygwin home directory (base file from here)):

rxvt.font:             Lucida Console-14
rxvt.boldFont:         Lucida Console-14
rxvt.scrollBar:        True
rxvt.visualBell:       True
rxvt.loginShell:       True
rxvt.background:       Black
rxvt.foreground:       White
rxvt.saveLines:        3000
rxvt.cursorColor:      Green
rxvt.scrollBar_right:  True

If you want to use the box drawing font (you have to install it on the system first):

rxvt.font:             Lucida ConsoleP-14
rxvt.boldFont:         Lucida ConsoleP-14
rxvt.scrollBar:        True
rxvt.visualBell:       True
rxvt.loginShell:       True
rxvt.background:       Black
rxvt.foreground:       White
rxvt.saveLines:        3000
rxvt.cursorColor:      Green
rxvt.scrollBar_right:  True

If you use the standard DOS terminal for Cygwin, you may want to change the code page setting in the batch file (original file is in this post) to:

set CYGWIN=codepage:oem

I just spent a good 30 minutes trying to figure out why the portable Cygwin installation (I haven’t really tested the portable part yet) I was working on refused to set my custom prompt automatically.

Turns out that bash doesn’t look for .bashrc for login shells, but instead looks for .bash_profile, which is what I’m used to using. For more info, see this nice page.

As far as making Cygwin itself portable, it seems to be as simple as this article suggests, however, there are some invalid and possibly unneeded (still worked when I removed them) commands in the batch files.

Here’s the batch file I use to start rxvt (I fixed some invalid options and removed some stuff):

@echo off

for /F %%A in ('cd') do set WD=%%A
set path=%WD%bin;%WD%usr\X11R6\bin;%path%
set SHELL=/bin/bash
set CYGWIN=codepage:437
set HOME=/home/user

:: Custom font for box drawing issues (not used atm)
:: bin\run rxvt -sl 1500 -bg black -fg gray -sr -fn 'Lucida ConsoleP-13' -tn rxvt-cygwin-native -e /bin/bash --login -i

:: Normal font
bin\run rxvt -sl 1500 -bg black -fg gray -sr -tn rxvt-cygwin-native -e /bin/bash --login -i

The most troubling incident I’ve dealt with involved an attacker who exploited a security vulnerability in Valve’s server query protocol, which caused a serious degradation of service condition. I couldn’t simply block all the query packets, since legitimate clients needed to be able to query servers. To further complicate matters, the attacker was also spoofing IP headers, which ruled out the possibility of a simple firewall rule.

This particular vulnerability was not really bad design per say (although it was poorly designed), but more a really poor implementation. Here are the details:

When a client wishes to find out basic information about a server (player counts, game type, game version, etc), they send a packet to the server requesting the information. The server then locates all this information, creates a packet and replies.

Normally, the query protocol works perfectly, without any performance issues. However, the code that generates the replies is so poorly written, that a large number of query packets will generate lag spikes on the server, thus making the server unplayable (degradation of service). Did Valve require a handshake / challenge before replying with this expensive to generate packet? Nope.

To resolve the attack, I wrote a server plugin that hooks the Winsock recvfrom call, and replies to query packets (it generates the replies itself) from a high performance cache (it returns SOCKET_ERROR to the server so it doesn’t try to reply).

With this cache installed, the server works flawlessly. This makes me wonder, how could Valve have written such inefficient code, and having written it, consider it ready for production.

I’d like to take a minute here and remind everyone this is just one of many known (and inexplicably, not yet patched) vulnerabilities (in game and network based) in the Source engine.

One way to do that is by restricting clients to a certain number of connections in a given time period. Since the code is designed to prevent a DoS condition, it must be extremely fast and efficient because it may be run thousands of times per minute (during a DoS attack for example).

I designed the connection limit system around a collection of connection records, a prune timer, and a test when the server accepts a client connection.

Since I needed to check two variables (timestamp and ip) in each connection record to determine the connection count for a given IP address in a given time period, I decided to use LINQ, which worked nicely:

// Get this client's connection count
int connCount = (from conn in _connectionList
                 where conn.Ip == clientIp &&
                 conn.Timestamp >
                   DateTime.Now.AddMinutes(-howFarBackInMinutesToCheck)
                 select conn.Ip).Count();

The other query I needed was for pruning the connection list:

 // Get the connections to prune
var connQuery = from conn in _connections
                where conn.Timestamp <
                  DateTime.Now.AddMinutes(-howFarBackInMinutesToCheck)
                select conn;

After checking the number of records to prune was greater than zero (connQuery.Count()), I pruned them by iterating through the query (LINQ queries implement IEnumerable).

What really got to me a few days ago was the MinGW project. This is a project that is intended to be used exclusively on Windows. Yet, the developers deprecated the installer (these are standard for most Windows applications), and instead asked users to download 17 packages by hand (something that is a little much even on Linux).

Even worse, some of the packages were compressed not with zip, gzip, or bz2. They chose to use lzma, one of the least common and supported compression formats on Windows. Why would a developer pick the hardest format for a given operating system when packaging specifically for that system?

I try to avoid exotic archive formats like 7z (ironically, these use LZMA compression), but the compression offered by them is so incredible that I decided to post one publicly for the first time. Why? It reduced my 119 MB MinGW distribution to 14.5 MB, and MinGW is intended for use on Windows, so most people will be able to easily read the package with 7-Zip.

If I was packaging source code that could be used on Linux, I wouldn’t use 7z, since it’s harder to deal with on Linux. In my opinion, a zip file or tarball would be the most appropriate means of packaging.

Here’s my personal table for package format selection:

Why anyone would compress a package designed for Windows in .lzma format? The only way to extract it is with a command line sdk tool. Even on Linux, distributing archives in .lzma format is a little strange.

Anyhow, to save everyone the trouble, here’s a package (includes C, C++ and all necessary tools) in .7z format (which can be extracted by 7-Zip, the best file archiver for Windows) -> MinGW Compiler Package (202).

I found something interesting in the event log yesterday:

PHP Warning:  [eAccelerator] This build of "eAccelerator" was compiled for PHP version 5.2.9. Rebuild it for your PHP version (5.2.9-2) or download precompiled binaries.

Now that error message makes perfect sense. The reason I didn’t see it the first time around is that PHP logged two messages separately at the same time. If I was reading a flat file log, I would’ve noticed it immediately.