Starcraft on Wine is horribly slow due to the missing DIB engine.

Handling DIBs is a crucial component when it comes to fast 2D drawing. Other games like Age of Empires and even applications like Adobe Photoshop are affected by this weakness in Wine.

Work on this has started last year as a Summer of Code program, but progress has slowed down recently.

All in all I guess we won’t get a usable implementation within the next few years except if another dedicated effort is spent on it.

Enter VirtualBox

Luckily another solution has come up recently: Sun’s VirtualBox virtualization product is free (as in beer and freedom), easy to use and works well enough with Starcraft.

Here’s my basic setup: VirtualBox 3.0.0 (in beta state right now but so far it hasn’t crashed on me) with guest additions, Windows XP and Starcraft Brood War 1.16.1.

I have enabled DirectDraw acceleration and bridging as network mode in VirtualBox. Both are simple point-and-click settings; you need to make sure the vboxnetflt module is loaded, though.

All of Starcraft is usable and very importantly fast.

Resolution issues

Update: You can just use VBoxSDL to start your VM in proper fullscreen mode without jumping through the hoops below. Makes it much more convenient and reliable.

VirtualBox does not have a real full-screen mode. With the guest additions you’re able to get a Desktop that resizes automatically to fit, but fixed resolutions (Starcraft uses 640×480) will not be scaled up to fill the VirtualBox window or the whole screen.

I have tried XRandR but it just made the viewport smaller which is worse than useless.

The kludge here is to copy over your X config, remove all resolutions except for 640×480 and start a new X server. I cannot go into the full detail here but it boils down to this:

xinit /home/sky/scripts/xinitrc.2 -display :1 \
  -- :1 -ac -config xorg.conf.lowres

Put in some lightweight window manager or VirtualBox itself at the end of xinitrc.2.

After that just use VirtualBox as you have before and switch to full screen.

You should be ready to get the full experience of playing Starcraft now!

Bonus: Hamachi integration

Hamachi is a proprietary cross-platform VPN solution that is also beginner-friendly and gratis. It works well with my VirtualBox setup, too.

However the latest version (1.0.3.0) does seem to have some problems with UDP networking.

Downgrading to 1.0.1.4 helped, and I was even able to play Starcraft via a VPN. Don’t forget to turn off the helpful Windows firewall least it might interfere with your network.

Did this post help you?

If yes, then I’d like to know about it. Please also tell me about other games that work or don’t work with this setup.

If you’re really happy about it you may also send me a gift.

In the last few days I especially noticed that hg is faster for me than git (even after repack of the git repository).

That said, git has some very cool features that are missing in Mercurial.
Two of them are local branches (helpful for feature development or bug isolation) and the stash command that lets you stash away local changes for later (sort of a simplified patch queue).

Fortunately there are two extensions that provide both local branching and stash functionality.

Localbranches extension

Wiki page

http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches

Repository

http://hg.kublai.com/mercurial/extensions/localbranch

Shelve extension

Wiki page

http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension

Repository

http://freehg.org/u/tksoh/hgshelve/

Installation

To use an extension just clone the repository and put the following line into the [extensions] section of your hgrc (create file and section if necessary):

EXTNAME=/path/to/EXTNAME.py

Usage examples are on the wiki pages.

Happy hacking!

Very useful for testing local mail emitting routines.

Usage: download, extract, quickly edit the configuration files and execute bin/mail.sh.

Thanks, Eric!

It was recently uploaded to ArchLinux AUR and I gave it a whirl.

Its output for one of my disks claimed it to be close to failure:

HDD Device  2: /dev/sda
HDD Model ID : ST3160023A
HDD Serial No: 5JS2NX0R
HDD Revision : 3.06
HDD Size     : 152628 MB
Interface    : IDE/ATA
Temperature  : 42 °C
Health       : 13 %
Performance  : 100 %
Power on time: 658 days, 7 hours
Est. lifetime: 19 days

The theory behind HDSentinel seems sound, so I’m looking forward to see whether the prediction will hold.

urlcheck is lightweight, concurrent url checker. It uses minimal resources, and is multicore-capable.

In contrast to popular link checkers, it uses few resources, will readily take advantage of multiple cores, and is easily killable.

Works great and is fast as lightning. Plus, it’s written in Haskell.

Arch Linux users get it from AUR, all others from their distribution or directly from source.

You just have to enable it in your .zshrc (after installing ZSH, of course):

autoload -U url-quote-magic
zle -N self-insert url-quote-magic

Those speakers are built-in, too, so I can’t change them easily.
No problem, there’s ESD, right? Well. The Enlightened Sound Daemon might have deserved its name when it was released, but since then a bunch of years have passed and it didn’t show acceptable quality when I tried it here.

PulseAudio to the rescue! This modern solution runs even on Microsoft Windows (although not on the 9x series, it seems), has dead simple GUI tools and is the best thing since sliced bread. A real sports car.
Except, for some unknown reason, I couldn’t get it to work on one of the machines in question. No sliced bread for me, I guess.

But then I came across a real slick solution in the ALSA wiki: a sound server using Netcat and the out-of-the-box ALSA utilities aplay and arecord.

Setup is as simple as:

# on the server:
nc -u -l -p 9999 | aplay
 
# on the client
arecord -t wav -f cd | nc -u SERVER 9999

Now just set your recording source via alsamixer -Vc to “Mix” and adjust the output volume levels on client, server and speaker.

Made me slap my head ’cause I didn’t think of it myself.

Here’s a little recipe that shows how to get the load averages (the thing uptime shows) in Lisp, which will be useful later when we build a solid logging foundation with Gary’s log5 package.
In case you don’t know, the load average shows an approximation of the number of processes in the system’s task queue, thus serving as indication for machine load.

First, let’s do the initialization work for CFFI, as pointed out in its user guide:

(asdf:oos 'asdf:load-op 'cffi)
 
(defpackage :cffi-user
  (:use :common-lisp :cffi))
 
(in-package :cffi-user)
 
(define-foreign-library libc
  (:unix (:or "libc.so.6" "libc.so.5" "libc.so"))
  (t (:default "libc.so")))
 
(use-foreign-library libc)

Now we actually need to start thinking. How do we get at the numbers?
Let’s find the C function:

% apropos load | egrep -i "average|avg"
getloadavg           (3)  - get system load averages
[...]
% man 3 getloadavg

The man page gives us this prototype:

int getloadavg(double loadavg[], int nelem);

It also tells us that the first parameter will be filled with nelem samples and notes that (at least on my Linux system) the maximum number of samples is three, denoting the load averages of the last 1, 5 and 15 minutes. Let’s say that we want all three.

Now unfortunately the CFFI manual doesn’t say anything about arrays. But we can rewrite the prototype as

int getloadavg(double* loadavg, int nelem);

leading to the following CFFI function spec:

(defcfun "getloadavg" :int (loadavg :pointer) (nelem :int))

Now we are able to use foreign-alloc to allocate a pointer of the correct size (i.e. 3*sizeof(double)), and mem-aref to access the resulting array.

Combined with matching LOOP and FORMAT programs and the manual garbage collection we get:

(defun load-averages ()
  (let ((loadavg (foreign-alloc :double :count 3)))
    (getloadavg loadavg 3) ; note the imperative style we are forced to use
    (prog1 ; we need to clean up after producing the return value
      (format nil "~{~,2F~^ ~}" (loop for i from 0 to 2
                                    collect (mem-aref loadavg :double i)))
      (foreign-free loadavg))))

If you have questions regarding any part of that last snippet, feel free to ask.

Note that we don’t do any error checking here; getloadavg will return -1 on failure, although I can’t imagine why it would do so.

You can access the full code at http://paste.lisp.org/display/54746.

I hope this post wasn’t overly verbose (read: boring) to you.
It was my intention to make this understandable for beginners.

Today I decided to find out what was the culprit of this. I started Firebug and inspected the offending CSS. It turned out that they mention the font name clean in their font-family path, and that removing this from the valid families helped restore order among the glyphs. To make this permanent I had to find the offending font and delete it.

xlsfonts | grep -i clean

told me that the subject was “Schumacher Clean”, but not more. After messing around with Fontmatrix (which doesn’t attempt to find the fonts registered with the X server by itself) and GNOME Specimen (which didn’t knew about or refused to tell me the location of a font’s files), this helped:

fc-cat | grep -i clean
# showed something like clR6x12.pcf.gz
locate clR6x12.pcf.gz
# gave me the location
sudo rm /usr/share/fonts/misc/clR*
# removed all incarnations of the font
sudo fc-cache
# informed the X server

Once again command-line tools proved to be the solution. Great for me, but quite problematic in a world where more than 99% of users don’t use it (because they don’t know what it is or how to use it productively).

Why? Simplicity!

My personal highlights in the new version:

• Support for xdelta diffs: binary diffs so I can go back to previous package versions if the current one is borked. Previously one had to hope to have the old version in the cache or find some outdated mirror.
• --ignorearch option for makepkg

— no more hacking of PKGBUILD files that don’t have arch information.

• Topological sorting for dependencies: I suspect this is responsible for the speed-up I noticed.
• Massive optimization and speed-up for --owns: finding the package a certain file belongs to is a function I often need.
• single mirrorfile: finally a centralized place for the mirror list.