For the record, this is because GCC got stricter over time about including C headers. If you download blackbox_0.70.1-34.debian.tar.xz from a mirror and uncompress it, you'll find a list of patches, among which fix-ftbfs-gcc-4.3.diff which adds the missing #include directives. The problems will only start if the package ends up orphaned.

For a CLI, I'd definitely recommend weechat for the reasons given by pekman, plus sensible defaults (e.g. creates a separate window for each server).

For a GUI, if you only have one computer, Hexchat is definitely the way to go.

If you have several computers on your local network, however, Quassel is worth a try. You can install quassel-core on one machine (for instance a raspberry pi) and use quassel-client from any other machine to access your session. I find it a very interesting alternative to running Hexchat in VNC (or a similar way of keeping a GUI in a remote session).

Hi,

I disagree about LVM. I think it's something you never knew you needed until it's too late:

• With the proper file systems in use (some of them won't shrink...), you can resize your partitions on-the-fly, instead of having to reboot on a live CD

• Whatever your file system is, you can create a snapshot for backup purposes

• If you somehow run out of space, you can add a hard drive in your computer and extend your logical volume (and your partitions) transparently

Now it's story time. A few years ago, I only had a laptop, whose hard drive was failing. I needed to copy hundreds of GBs of data to a new HDD, but with a USB2 interface in the middle, it was going to take ages, and prevent me from working. But since I had LVM, I could actually do a live migration, and transfer my whole system onto the new HDD while still working, business as usual.

So I always install using LVM, just in case. The performance hit is, as far as I know, minimal, and there are great long-term advantages.

Also, from what's left of my Spanish, it seems that you're recommending to use only primary partitions because logical partitions are slower. I've never heard of that problem before. There should be no difference whatsoever.

A slightly more complete solution

First, I commented out /etc/acpi/events/powerbtn-acpi-support:

#event=button[ /]power
#action=/etc/acpi/powerbtn-acpi-support.sh

This ensures that my laptop doesn't shutdown (or do anything special) when I press on the power button by mistake (it happens...).

Then I wrote a generic handler in /etc/acpi/events/default:

event=.*
action=/etc/acpi/default.sh %e

This is going to intercept every ACPI event and call a single script with all available arguments. I do not understand the design decision behind the ACPI daemon, with this concept of event files calling scripts, that tend to be so short and to multiply, so I prefer to put all the logic in a single script. Feel free to do it your own way

Finally, the file where the magic happens, /etc/acpi/default.sh:

#!/bin/sh

# log every event in /var/log/messages (can be commented later on)
logger "ACPI event $*"

case "$1" in
    button/sleep)
        [ $2 = "SBTN" ] && pm-suspend
    ;;
    button/lid)
        [ $2 = "LID" ] && [ $3 = "close" ] && pm-suspend
    ;;    
esac

The actual values on someone else's system could be different, this is why it is convenient to log everything when testing the script.

Also, you do not need to restart your acpid service, you can just reload it (though I don't know whether that makes a real difference):

 # /etc/init.d/acpid reload