Microbits

From what I’ve seen of Python, I relegated it to CUI and backend type tasks, since C# and .NET offer a powerful GUI platform out of the box, and Python seemingly didn’t have anything similar.

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.

After a few PHP access violations, I’m pretty sure EAccelerator does not work properly with multiple IIS worker processes.

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

This file will put a more standard Linux prompt on your Cygwin login shell (file should be ~/.bash_profile):

#!/bin/bash

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

Launching MC in rxvt showed all the box drawing characters replaced with strange looking accented characters… What?

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

UPDATE: For solutions to box drawing issues, see this post.

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

As an administrator of several Source based game servers, I’ve dealt with various known security vulnerabilities that Valve hasn’t bothered to fix. Some of the most common include client side console commands, that if run once, or spammed (which the server will allow), will cause a degradation (massive lag) or denial of service (you guessed it, the server will crash). These really aren’t all that bad, since they are well known, server plugins are available to block the commands.

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:
Read more…

I’m currently working on a TCP client/server system, and I wanted to prevent clients from DoSing the server.

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).

Most projects have multiple release packages whenever a new version comes out. Depending on the project, there are usually two, a binary (one for each platform) and a source distribution. Some projects don’t distribute binaries at all.

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:

Read more…

After needing a copy of MinGW to compile some C code, I was somewhat annoyed to find that their all in one installer is now considered “deprecated”. That meant I had to download and extract 15 packages manually (two of them were even compressed as .lzma).

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).

Now that I’m correctly loading the extension (zend_extension_ts), eAccelerator is running smoothly.

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.