Here’s how I do it under Debian (and the script I’m using):

Requirements

This guide is for Debian  testing as of 25 March 2012. However it should work for other cases as well.

The procedure creates a minimal installation which can then be fully customized by hand or with puppet. The procedure installs Debian under Debian but should be easy to change for other distributions as well (especially Ubuntu).

Packages

You will need to install:

• lxc – The linux containers package
• bridge-utils – For bridging network interfaces
• uml-utilities – For tun/tap interfaces
• cdebootstrap – For the bootstrapping of the virtual machines
• puppet (optional) – for managing multiple machines

Networking

I prefer networking between lxc installations to be separate from my normal network. It is trivial however to bridge with the outside network as well.

Add the following to /etc/network/interfaces:

auto virtlxc
iface virtlxc inet manual
 tunctl_user     root
 up              ip link set virtlxc up
 down            ip link set virtlxc down

auto brvirt
iface brvirt inet static
 bridge_ports            virtlxc
 bridge_maxwait          0
 bridge_stp              off
 address                 10.3.1.1
 netmask                 255.255.255.0
 dns-search              virt.local

Then add the following to /etc/hosts:

10.3.1.1    deb0 deb0.virt deb0.virt.local
10.3.1.11    deb1 deb1.virt deb1.virt.local
10.3.1.12    deb2 deb2.virt deb2.virt.local
10.3.1.13    deb3 deb3.virt deb3.virt.local
10.3.1.14    deb4 deb4.virt deb4.virt.local

Add as many entries as you like. There should be one entry per virtual machine. It doesn’t matter if you have more entries than virtual machines since you may use them in the future. The first (deb) entry is for the local machine.

Bring up the brvirt and virtlxc interfaces and keep reading (ifup virtlxc; ifup brvirt).

You may also want to run something like this to provide network access to the virtual machines (assuming that eth0 is the interface the connects you to the rest of the world):

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -I POSTROUTING -o eth0 -s 10.3.1.0/24 -j MASQUERADE

Create the virtual machine

Get the following script and change the desired variables at the beginning as follows (assuming that you followed the network configuration):

• SUITE: The Debian suite to use (e.g. squeeze)
• MIRROR: A mirror to download debian from. If you use approx like me then you want to use the local machine (i.e. 10.3.1.1)
• VIRTUSER: A username you want to have created in the virtual machine. After that you may ssh as that user.
• LOCALUSERS: A space separated list of local users to get ssh public keys from and put then in VIRTUSER’s authorized_keys file to allow ssh.
• PUPPETMASTER: Leave it empty if you don’t have a puppet master.
• DNSSERVER: The DNS server to use. By default it is the local machine.

Each virtual machine should get a unique MAC address. The MAC addresses are auto-generated from the current y/m/d/H/M, so you should not create more than one virtual machines every minute. You’re free to change this of course.

Now run the script at the end of the page and let it create a virtual machine:

./easylxc deb1

The installation will happen under /var/lib/lxc (the default for lxc). You may visit that and fix things by hand if you (i.e.) manage to lock yourself out.

The virtual machine can be started with:

lxc-start -n deb4
- or -
lxc-start -n deb4 -d

However, a bug/feature of rxvt will prevent that for succeeding. In that case you can run:

sudo lxc-start -n deb4
- or -
sudo lxc-start -n deb4 -d

Inside the virtual machine you will be able to su to root by using “su” without password. You will be also able to ssh as root (using the same ssh keys).

Hints’n'tips

I strongly suggest using approx and changing the MIRROR variable as needed. It will speed the creation of many machines by orders of magnitude since there will be no network delays.

The script

#!/bin/bash

if [ -z "$1" ] ; then
	echo "Pass the name of the machine as the first parameter"
	exit 1
fi

# The name of the container to create. Also used as the hostname
NAME="$1"

# The name of the parent (local) machine without the domain
PARENTNAME="deb0"

# Distribution
SUITE="squeeze"

# The domain to be used by the virtual machines.
DOMAIN="virt.hell.gr"

# The network prefix (first 3 octets - it is assumed to be a /24 network)
NETPREFIX="10.3.1"

# Since we use approx, this is the approx server. If not, add a mirror.
MIRROR="http://ftp.debian.org/debian/"

# The gateway address for the virtual machine. This is most probably the
# address of the bridge interface.
GW="$NETPREFIX.1"

# The bridge interface to use for networking
BRIDGEIF="brvirt"

# The username of the user to create inside the container
VIRTUSER="v13"

# A list of local users that will have ssh access to the container
# They need to have a public key in the local machine
LOCALUSERS="v13 root"

# The puppet master. This must be the hostname of the master (not an IP addr).
# No puppet if this is empty.
PUPPETMASTER=""

# The DNS server to use.
DNSSERVER="$GW"

IPADDR2=$(getent hosts $NAME.$DOMAIN | awk '{print $1}')

if [ "x$IPADDR2" = "x169.254.1.1" ] ; then
	IPADDR2=""
fi

if [ -z "$IPADDR2" ] ; then
	echo "Could not resolve $NAME.$DOMAIN"
	exit 1
fi

IPADDR="$IPADDR2/24"

MAC=$(date "+4a:%y:%m:%d:%H:%M")

lxc-stop -n $NAME
lxc-destroy -n $NAME

export SUITE
export MIRROR

R0=/var/lib/lxc/$NAME
R=$R0/rootfs

mkdir $R0 $R

# Install base system
echo cdebootstrap -f standard $SUITE $R $MIRROR
cdebootstrap -f standard $SUITE $R $MIRROR

CFG=$R0/config

# Create config file
cat << _KOKO > $CFG
# Auto-generated by: $*
# at $(date)

## Container
lxc.utsname		= $NAME
lxc.rootfs		= $R
lxc.tty			= 6
lxc.pts			= 1024

## Network
lxc.network.type	= veth
lxc.network.hwaddr	= $MAC
lxc.network.link	= $BRIDGEIF
lxc.network.veth.pair	= veth-$NAME

## Capabilities
lxc.cap.drop		= mac_admin
lxc.cap.drop		= mac_override
lxc.cap.drop		= sys_admin
lxc.cap.drop		= sys_module

## Devices
# Allow all device
lxc.cgroup.devices.allow	= a
# Deny all device
lxc.cgroup.devices.deny		= a
# Allow to mknod all devices (but not using them)
lxc.cgroup.devices.allow	= c *:* m
lxc.cgroup.devices.allow	= b *:* m

# /dev/console
lxc.cgroup.devices.allow	= c 5:1 rwm
# /dev/fuse
lxc.cgroup.devices.allow	= c 10:229 rwm
# /dev/null
lxc.cgroup.devices.allow	= c 1:3 rwm
# /dev/ptmx
lxc.cgroup.devices.allow	= c 5:2 rwm
# /dev/pts/*
lxc.cgroup.devices.allow	= c 136:* rwm
# /dev/random
lxc.cgroup.devices.allow	= c 1:8 rwm
# /dev/rtc
lxc.cgroup.devices.allow	= c 254:0 rwm
# /dev/tty
lxc.cgroup.devices.allow	= c 5:0 rwm
# /dev/urandom
lxc.cgroup.devices.allow	= c 1:9 rwm
# /dev/zero
lxc.cgroup.devices.allow	= c 1:5 rwm
# /dev/net/tun
lxc.cgroup.devices.allow        = c 10:200 rwm

## Limits
#lxc.cgroup.cpu.shares                  = 1024
#lxc.cgroup.cpuset.cpus                 = 0
#lxc.cgroup.memory.limit_in_bytes       = 256M
#lxc.cgroup.memory.memsw.limit_in_bytes = 1G

## Filesystem
lxc.mount.entry		= proc $R/proc proc nodev,noexec,nosuid 0 0
lxc.mount.entry		= sysfs $R/sys sysfs defaults,ro 0 0

_KOKO

# fix interfaces
T=$R/etc/network/interfaces
mv $T $T.orig
(
	cat $T.orig \
		| sed "s/^iface eth0.*$//"
	echo "
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
	address			$IPADDR2
	netmask			255.255.255.0
	gateway			$GW
	dns-nameservers		$DNSSERVER
	"
) > $T
rm $T.orig

# fix resolv.conf
T=$R/etc/resolv.conf
cat << _KOKO > $T
domain $DOMAIN
search $DOMAIN
nameserver $GW
_KOKO

# add info to hosts
T=$R/etc/hosts
echo "$IPADDR2 $NAME $NAME.$DOMAIN" >> $T
echo "$GW gw gw.$DOMAIN $PARENTNAME.$DOMAIN $PARENTNAME" >> $T

# set debian_chroot (for help)
echo "lxc-$NAME" >> $R/etc/debian_chroot

# create ttys
for i in $(seq 0 6) ; do
	mknod $R/dev/tty$i c 4 $i
done

run()
{
	echo chroot $R "$@"
	LC_ALL=C chroot $R "$@"
}

run2()
{
	ssh -o StrictHostKeyChecking=no $IPADDR2 "$@"
}

runmaster()
{
	ssh -o StrictHostKeyChecking=no $PUPPETMASTER "$@"
}

# Install locales
run apt-get -y install locales

# disable init scripts
DISABLED="bootlogd bootlogs checkfs.sh checkroot.sh halt hostname.sh \
	hwclockfirst.sh hwclock.sh module-init-tools mountall.sh \
	mountdevsubfs.sh mountkernfs.sh mountnfs.sh mountoverflowtmp procps \
	reboot stop-bootlogd stop-bootlogd-single udev umountfs umountnfs.sh \
	umountroot"
for dis in $DISABLED ; do
	run update-rc.d $dis disable
done

# disable rsyslog's kernel logging
run sed -i 's/^\(.*imklog.*\)$/#\1/' /etc/rsyslog.conf

# add user
run adduser --gecos $VIRTUSER --disabled-password $VIRTUSER
run adduser $VIRTUSER root

# fix sources.list
T=$R/etc/apt/sources.list
cat << _KOKO > $T
deb $MIRROR $SUITE main
_KOKO

# Install ssh
run apt-get update
run apt-get -y install openssh-server
run /etc/init.d/ssh stop

# Fix root and su
run passwd -l root
T=$R/etc/pam.d/su
mv $T $T.old
cat $T.old \
	| sed 's/^# \(.*pam_wheel.so trust\)/\1/' \
	> $T
rm $T.old

# Add ssh keys
T=$R/home/$VIRTUSER/.ssh/authorized_keys
T2=$R/root/.ssh/authorized_keys
mkdir $R/home/$VIRTUSER/.ssh $R/root/.ssh
for u in $LOCALUSERS ; do
	H=$(getent passwd $u | cut -f 6 -d : )
	cat $H/.ssh/id_rsa.pub >> $T
	cat $H/.ssh/id_rsa.pub >> $T2
done
chown $VIRTUSER.$VIRTUSER $R/home/$VIRTUSER/.ssh $T
chown root.root $R/home/$VIRTUSER/.ssh $T2

# Start it
# Use sudo to bypass file descriptor problems
sudo lxc-start -n $NAME -d
sleep 1

if ! [ -z "$PUPPETMASTER" ] ; then
	# Install packages
	run2 apt-get -y install puppet

	# Clear any existing certificate
	runmaster puppet cert clean $NAME.$DOMAIN

	# Fix puppet config
	T=$R/etc/default/puppet
	mv $T $T.old
	cat $T.old \
		| sed 's/START=no/START=yes/' \
		| sed "s/DAEMON_OPTS=\"\"/DAEMON_OPTS=\"--server=$PUPPETMASTER --verbose\"/" \
		> $T
	rm -rf $T.old

	run2 puppet agent --server=$PUPPETMASTER --no-daemonize --onetime

	# sign the certificate
	runmaster puppet cert --sign $NAME.$DOMAIN

	run2 /etc/init.d/puppet start
fi

cat << _KOKO

LXC virtual box is ready!

Config file is at: $R0/config
Root fs is at: $R

Get a console with:
  lxc-console -n $NAME

Stop it with:
  lxc-stop -n $NAME

Start it with:
  lxc-start -n $NAME -d

_KOKO

Update: You can use the above code under the GPLv3 license.

In short: They are intercepting traffic and doing deep packet inspection without any warning or approval.

But wait, there’s more: In general they monitor web traffic (read: the data) and after intercepting an HTTP request the replay that (yes.. they replay the request).

Here’s an example:

78.149.130.80 – - [12/Mar/2012:22:47:23 +0100]
 "GET /korokokokokoLALALALA HTTP/1.1" 404 536 "-"
"Wget/1.13.4 (linux-gnu)"

62.24.252.133 – - [12/Mar/2012:22:47:55 +0100]
 "GET /korokokokokoLALALALA HTTP/1.0" 404 498
"http://<removed>/korokokokokoLALALALA"
"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;
.NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022;
.NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)"

The first request was performed by me and it was followed by a second one 32 seconds later (for the unbeliever: this is 100% reproducible). The IP address of the offender is always the same (62.24.252.133).

Digging a bit on this I found these:

• http://talktalkmembers.net/forums/showthread.php?t=54112
• http://www.whatdotheyknow.com/request/the_last_3_months_of_tt_ico

I don’t think there are enough things I can say about this. However, here are a couple of them:

• They shouldn’t do that
• They are a bunch of $#&@%)&#$%
• This actually doubles the web traffic that originates from the talktalk network
• It can be really harmful as it is possible to trigger a delete action (i.e. when GET is used instead of POST)
• It is completely unethical
• It is performed even when you have all the security features disabled
• Did I say that they are a bunch of @$#)*&%*#$ ?

In any case, I started exploiting this a bit:

Fortunately I’ve a domain under my control and a couple of servers. As such I used one of them that is already running apache and added this rule:

iptables -I OUTPUT -d 62.24.252.133 -p tcp --sport 80 \
  -m tcp --tcp-flags SYN '' -j REJECT --reject-with tcp-reset

After that I ran this from a PC at home:

for b in $(seq 0 9) ; do
 ( (
    for i in $(seq 22${b}00 22${b}99) ; do
      wget http://xxx.xxx.xxx/bad-talktalk-bad-bad-$i ;
    done
  ) & ) ;
done

The idea is to create an iptables rule at the server that matches outgoing TCP segments without the SYN flag (iow: segments after the initial 2 SYNs of the handshake) and reset that connection.  The result is that when that host (62.24.252.133) tries to re-fetch the page (i.e. replay the request):

• It initiates the TCP connection sending a SYN to the server which is accepted
• The server replies with SYN+ACK which is normally sent
• The offender receives the SYN+ACK so it goes to the ESTABLISHED state, sending an ACK plus some data
• The server receives the data and responds with an ACK
• The iptables rule takes effect, dropping the packet and responding to the server (itself) with a reset

After the above steps, the server closes the connection abnormally and the offender stays with a fully open connection and keeps trying to send the data.

The rational behind that was to exhaust the offender’s TCP ports by creating >60000 connections.

The good news is that the theory behind that works. The bad news is that the offender is very slow (most probably on purpose). The good news after that is that it keeps a backlog of the connections and tries to perform them all (or a big part of them).

My tests showed the offender trying to perform connections up to an hour after that.

Here are the results of itpables’ accounting:

Chain OUTPUT (policy ACCEPT 75792 packets, 16M bytes)
pkts bytes target     prot opt in     out     source               destination
14600  584K REJECT     tcp  –  *      *       0.0.0.0/0            62.24.252.133

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
28462 6088K ACCEPT     tcp  –  *      *       62.24.252.133        0.0.0.0/0

The first one is the output rule. The second one is a rule I added for accounting purposes.

So we ended up having 14600 resets sent and 28400 packets from the offender. (note: I only created about 3000 connections)

The day is over but I have other plans as well:

• Create a bunch (i.e. 100) alternate DNS names for the server and perform the requests against them, pushing the offender to perform more requests in parallel
• Write a python program that operates at client side and server side constructing fake TCP packets with predefined sequence numbers and fake IP addresses so that the offender will believe that it will have to follow more than one users.
• Study whether the offender it intelligent. It is possible that it only inspects packet payloads for HTTP requests instead of fully reconstructing the whole TCP stream. In that case I’ll only have to send a large number of data packets with HTTP requests

In short, one is able to kill xorg’s xscreensaver’s lock by just pressing alt-ctrl-* or alt-ctrl-/ (both * and / need to be from the keypad).

A workaround that was posted suggests to modify files in the system. If you don’t want to (like me – for various reasons) then you can do this on-the-fly.

Put the following script in a file and make it run whenever you log in to your X session (e.g. by putting it in ~/.kde/Autostart/ if you’re using KDE):

#!/bin/bash

xkbcomp :0 - > /tmp/xkbcomp
cat /tmp/xkbcomp \
 | sed -n '/key <KPMU> {/,/^ *}/ !p' \
 | sed -n '/key <KPDV> {/,/^ *}/ !p' \
 > /tmp/xkbcomp.new
xkbcomp /tmp/xkbcomp.new :0

On each login, this will get rid of the offending xkb entries.

Kwin crashes when enabling opengl effects. It doesn’t crash immediately but it crashes after specific actions so it is 100% reproducible. For example when exiting from desktop-grid effect.

The situation

I’m using:

• Radeon 4870 graphics card (RV770)
• Kernel 3.1.5 (but seems irrelevant)
• Open source ATI driver with KMS using Gallium
• Xorg 1.11.2.902 (but happened with previous versions)
• MESA 7.11.2
• KDE 4.7.4 from debian
• DRM 2.4.29
• xserver radeon driver 6.14.3

I’m not using the blur effect

The solution

cd to ~/.kde/env/ (create it if it doesn’t exist)

create a file named gl.sh (or any other name) with execute permissions (should not be needed) and with the following contents:

#!/bin/bash

export LIBGL_ALWAYS_INDIRECT=1

The first line should not be needed as this file most probably gets source’d, but it will not hurt.

The drawback

Every GL app you’ll be using will inherit the LIBGL_ALWAYS_INDIRECT from environment, which may cause problems. If you want to play (for example) a game then open a terminal and run:

unset LIBGL_ALWAYS_INDIRECT
nexuiz  # or whichever opengl app you want to launch

Note: Fireofx is one of the applications that may use GL.

Boxes with various kernel versions have weird free memory problems. After examining the memory usage it seems that processes don’t add up to the actual memory that is being used.

Taking a look at /proc/meminfo we see something like this:

MemTotal:      8161544 kB
MemFree:        115676 kB
Buffers:          3900 kB
Cached:         200520 kB
SwapCached:      42336 kB
Active:         546824 kB
Inactive:       138336 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      8161544 kB
LowFree:        115676 kB
SwapTotal:     2096472 kB
SwapFree:       547480 kB
Dirty:            1020 kB
Writeback:           0 kB
AnonPages:      453480 kB
Mapped:          66928 kB
Slab:          7250176 kB
PageTables:      75408 kB
...

Notice that Slab is about 7.5GB, almost the whole memory (8GB) (!).

Slab is the kernel memory and we can see where it is allocated by examining /proc/slabinfo. Here’s an excerpt:

# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
nfs_direct_cache       0      0    136   28    1 : tunables  120   60    8 : slabdata      0      0      0
nfs_write_data        62     63    832    9    2 : tunables   54   27    8 : slabdata      7      7      0
nfs_read_data        215    297    832    9    2 : tunables   54   27    8 : slabdata     33     33     54
nfs_inode_cache   5384386 5399040   1032    3    1 : tunables   24   12    8 : slabdata 1799680 1799680     40
nfs_page             534    750    128   30    1 : tunables  120   60    8 : slabdata     25     25    264
rpc_buffers            8      8   2048    2    1 : tunables   24   12    8 : slabdata      4      4      0
...

Notice the nfs_inode_cache which is 5.3M objects of 1032 bytes each, adding up to about 5.4GB.

The workaround

Looking a bit about this on the internet we see that this is most probably a bug. Fortunately there are two workaround: A slow and a fast one:

Slow workaround: Login to that box and run “sync”. Then leave it alone for a couple of minutes while the nfs_inode_cache memory goes down and down. It make take a couple of minutes before starting going down and there may be pauses in the process. It can take more than an hour to free the memory.

Fast workaround: Login to that box and run:

# sync
# echo 2 > /proc/sys/vm/drop_caches

I’m not sure why the first one works, but it looks like it is triggering a chain reaction that frees the memory.

• Have a git project (A)
• Have a second git project (B) that I want to merge to A under a directory
• This needs to be done once. After that, project B will not be re-sync to A’s subdirectory
• Need to preserve history

The actual situation: I have a git project that is named “drlaunch” and another git project that is named “debian”. “debian” is the packaging directory for drlaunch. The problem occurred because I used to have two svn trees, one for the project and one for the debian/ directory for making this a package for maemo.

I found a number of related things but all of them were complicated because they were doing more than I wanted. Finally, I came to this simple solution:

Under project drlaunch, there is a subdir drlaunch. I want to include the project debian under a directory named debian in the drlaunch project. The tree looks like this:

drlaunch (project)
\-- drlaunch (dir)

debian (project)

And at the end I want it to look like this:

drlaunch (project)
|-- drlaunch (dir)
\-- debian (dir)

The solution is as simple as this:

1. Go to the debian’s project dir and export all changes with format-patch:

   cd debian/
   mkdir ../1
   git format-patch --root -o ../1/
   rm ../1/0000-*
   

   (Note: The removal of the first file is required. The file should be empty and for me it triggers a git bug causing it to use 100% cpu indefinitely. Feel free to check it yourself)

2. Go to the drlaunch’s project dir and import all changes to a directory:

   cd drlaunch/
   git am --directory=debian/ ../1/*
   

3. Ta-da! Ready! Now compare the tree to be sure that nothing bad happend:

   diff -uR debian ../debian/
   

Don’t forget to commit your changes.

$

Here’s how to setup multiple monitors with xorg.conf when using the opensource radeon driver (tested with 6.14.1). The tricky part (and the one that took me aprox. 1 hour to figure) is to name the Monitors with the exact same name as the card’s outputs.

First, you need to launch X at least once with both monitors connected just to find out the output names. Look at /var/log/Xorg.0.log:

$ grep 'Output.*connected' /var/log/Xorg.0.log
(II) RADEON(0): Output HDMI-0 connected
(II) RADEON(0): Output DIN disconnected
(II) RADEON(0): Output VGA-0 disconnected
(II) RADEON(0): Output DVI-0 connected

From the above search you can see that the connected outputs are named HDMI-0 and DVI-0. You may be able to determine which monitor is connected to which output either by looking up its resolution:

(II) RADEON(0): Output HDMI-0 using initial mode 1920x1200

or other information in Xorg.0.log

Next you need to create or update /etc/X11/xorg.conf. The required relevant sections are as follows:

Section "Monitor"
        Identifier   "HDMI-0"
        Option          "Primary"       "On"
EndSection

Section "Monitor"
        Identifier   "DVI-0"
        Option          "LeftOf"        "HDMI-0"
EndSection

Section "Device"
        Identifier      "Card0"
        Driver          "radeon"
        BusID           "PCI:1:0:0"
        Screen          1
EndSection

Section "Device"
        Identifier      "Card1"
        Driver          "radeon"
        BusID           "PCI:1:0:1"
        Screen          1
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "HDMI-0"
        DefaultDepth    24
        SubSection "Display"
                Depth     24
                Modes   "1920x1200"
        EndSubSection
EndSection

Section "Screen"
        Identifier "Screen1"
        Device  "Card1"
        Monitor "DVI-0"
        DefaultDepth    24
        SubSection "Display"
                Depth 24
                Modes "1440x900"
        EndSubSection
EndSection

Section "ServerLayout"
        Identifier     "Layout0"
        Screen          "Screen0" 1440 0
        Screen          "Screen1" LeftOf "Screen0"
EndSection

Now I’m not sure about the second “LeftOf” because I stopped restarting X and KDM after it worked, but IIRC, it is not required.
As it was mentioned earlier, the tricky part is to named the Monitors as the outputs of the card (HDMI-0 and DVI-0 in my case).
Also, I remember that using the above naming for PciIDs is also required (observer that they are different) and I believe tht the “Monitor” statement inside the “Screen” section doesn’t affect anything.

If everything is setup correctly you should see this in Xorg.0.log:

(II) RADEON(0): Output HDMI-0 using monitor section HDMI-0
(II) RADEON(0): Output DVI-0 using monitor section DVI-0

which indicates that monitor sections where properly matched with outputs.

Feb 18 12:49:38 aetos check[982]: pyzor: [19952] error: TERMINATED, signal 15 (000f)

The problem was caused by wrong pyzor servers. Unfortunately, pyzor keeps a servers list in each home directory in file ~/.pyzor/servers. This is what this file used to have:

82.94.255.100:24441

This file is created automatically (with a proper value) so it is safe to remove it. That’s what it should have (for now):

public.pyzor.org:24441

In order to get rid of the error message all users’ files should be deleted:

find /home -name servers | grep pyzor/servers > /tmp/lst
# examine /tmp/lst by hand to verify that nothing bad is there
cd /home
cat /tmp/lst | xargs rm

That’s it. There should be no more “TERMINATED” messages.

Easily. If you implement the language using itself and the resulting interpreter is faster than the original then this means that the interpreted language manages to imprint the prorgammer’s intentions to the C language (or assembly) better than the programmer herself.

For example, I may create an interpreted language named V using C and try to make the implementation as fast as I can. Of course this means that I have to implement a number of data structures and handle them. Also I have to optimize code path etc etc.

Then I re-implement the V language using the V language itself. If the re-implementation if faster than the original implementation then this means that the interpreter’s logic produces faster code than me.

Well… here it is. The Python implementation in Python is faster than the Python implementation using C!

Read: It is very probable to end up with a faster program if you write it using python instead of C because the language will do better than you will in optimizing your data structures and your code. Just like it is better to write C than assembly and let your compiler to produce the optimized assembly code.

The following program has become my favorite showcase for python. To my knowledge, it is the smallest, easier to understand, portable, IPv6 compatible web browser in the world.

If you have IPv6 connectivity just lunch python and copy-paste it save it to a file and run it (it may crash python otherwise):

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

app=QApplication([])
win=QMainWindow()
w=QWebView(win)
win.setCentralWidget(w)
w.setUrl(QUrl("http://ipv6.google.com/"))
win.show()
app.exec_()

If you don’t then you can try the IPv4 version:

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

app=QApplication([])
win=QMainWindow()
w=QWebView(win)
win.setCentralWidget(w)
w.setUrl(QUrl("http://www.google.com/"))
win.show()
app.exec_()

In order to be able to run it you’ll need the Qt4 library and the python Qt bindings. If you’re under debian just run:

# apt-get install python-qt4

This should work at least under Linux, Windows, Maemo and perhaps Symbian.