Here's how I setup my wireless on Debian.

Firstly, create a script in /usr/local/bin called wireless-mapping or something similar. Make sure the dialog package is installed.

#!/bin/bash

if [ -f /etc/default/wireless ] ; then
    . /etc/default/wireless
else
    echo Please setup /etc/default/wireless
fi

for profile in $WIRELESS_PROFILES
do
  LOCATION_NAME=$profile\_NAME
  LOCATION_DESCR=$profile\_DESCR

  DIALOG_ARGS="$DIALOG_ARGS \"${!LOCATION_NAME}\" \"${!LOCATION_DESCR}\""
done

LOCATION=`eval dialog --stdout --menu \"Select your wireless location\" 10 50 5 $DIALOG_ARGS`

echo eth2-$LOCATION

Then create a file /etc/default/wireless where you put descriptions of your wireless networks. Put each of your networks in WIRELESS_PROFILES and then setup a name and a description, like below.

#WIRELESS OPTIONS

WIRELESS_PROFILES="home keg nicta"

home_NAME="home"
home_DESCR="At home"

keg_NAME="keg"
keg_DESCR="keg private"

nicta_NAME="nicta"
nicta_DESCR="nicta (hack)"

Finally, you need to make the mapping in /etc/network/interfaces for each network. It should look something like this.

mapping eth2
    script /usr/local/bin/wireless-mapping

iface eth2-keg inet dhcp
      wireless-essid keg
      wireless-key [key]

iface eth2-home inet dhcp
      wireless-essid wienand
      wireless-key [key]

iface eth2-nicta inet dhcp
      wireless-essid nicta_wireless

Notice how the mapping for your ethernet card is the script, and then you have a bunch of interfaces defined as interface-name, where name is the name you chose in the /etc/defaults/wireless script.

All going well, next time you ifup eth2 you should see something like this

More from the "things you'd learn if you read the manual" department, although the manual as currently written is a little esoteric on this feature of hexdump.

$ hexdump -e ' [iterations]/[byte_count] "[format string]" '

As you might guess, this means apply format string to groups of byte_count bytes, iterations times. Format string is like printf.

You can of course chain multiple formats together, or put them in a file. So say you needed to clag some binary data into a C array, a-la firmware for loading into a driver. You could use

$ hexdump -v -e '6/4 "0x%08x, "' -e '"\n"' ./dump

to get something that fits in 80 columns and is almost ready to go.

If your laptop hard disk is so slow it sometimes seems like it would be faster to write the ones and zeros with a pencil on paper, a large apt-get update can take hours.

I have found most of the time is actually spent in /sbin/ldconfig. ldconfig is extremely disk intensive and a real bottle neck, and really only needs to be run once once you've finished, rather than every time a library is installed. Replacing ldconfig with a stub makes update times much more tolerable.

#!/bin/bash

exit 0

I think there has been some talk of apt being smart enough to only do it once for you, but current versions don't seem to implement this. When you're finished restore the old (real) binary and run it to update your shared library cache.

I might be a bit slow, but I finally figured out how to get a decent font (i.e. not anti-aliased) for gnome-terminal on Debian.

1. Ensure xfonts-100dpi is installed
2. dpkg-reconfigure fontconfig and answer yes to the question about bitmapped fonts.
3. You will now have under Desktop->Preferences->Fonts the ability to select the Fixed font.
4. Restart all gnome-terminals. The font may look a little weird before you do that.
5. Enjoy tabs without the fuzziness!

Update: it appears I'm not the only one who doesn't like the fuzzy fonts in my terminal.

Davyd Madeley suggested that rather than enabling bitmapped fonts you can just enable a single font with fontconfig. He gives this example (place it in /etc/fonts/conf.d).

He suggested

There was an issue of it choosing extra wide fonts sometimes. You can fix this by copying the version of Fixed you want (eg. 7x13.pcf.gz) into your ~/.fonts directory.

James Ballantine suggested copying the font as well, although for some reason his Firefox started to choose bitmapped fonts after following the above steps.

I can't really understand why, as it appears that bitmapped fonts are enabled by default on Debian; at least in my fontconfig package we have in the post-install script

case "$enable_bitmaps" in
"true")
#
# Bitmap fonts will be enabled by default, so there's no need
# to use this configuration file.  However, the file remains useful if
# you want to force bitmaps to be considered even when some application
# disables them.
#
#       ln -s $CONFDIR/$yes_bitmaps $CONFDIR/$bitmaps_prio$yes_bitmaps
        ;;
*)
        ln -s $CONFDIR/$no_bitmaps $CONFDIR/$bitmaps_prio$no_bitmaps
        ;;
esac

So the dpkg question is at least badly worded, but I haven't yet decided if this is a bug. Probably the only thing I did was install the xfonts-100dpi package which gave me the bitmapped fonts.

Any other feedback is appreciated.

After looking at some shell scripts today it seems the very handy pushd and popd aren't used enough in the wild.

If you're just popping into a new directory for a moment to do something, then want to return to the directory you came from, use pushd newdir; it will push the current directory to the top of the directory stack (actually the DIRSTACK environment variable) and cd you there.

When you're done, use popd to go back to where you came from. Obviously you can keep pushing onto the stack and nest your directory changes deeper. Never again shall you need to manually remember $PWD!

ianw@lime:~$ pushd /tmp
/tmp ~
ianw@lime:/tmp$ echo do something in /tmp
do something in /tmp
ianw@lime:/tmp$ popd
~
ianw@lime:~$

This may not be the best way to do things, but this was the combination I seemed to need to get an Apple Mighty Mouse working with an IA64 desktop and udev, including horizontal scrolling.

I found that the current event input drivers shipped with the Debian X.org release weren't quite up to the job for me; I ended up with something about not being able to connect to the brain. Upstream has a better version in CVS, but I had all sorts of problems with CVS X.org for IA64.

Firstly the udev rules. If you add to /etc/udev/rules.d/mightymouse.rules

KERNEL=="event*", SYSFS{manufacturer}="Mitsumi Electric", SYSFS{product}="Apple Optical USB Mouse", NAME="input/mightymouse", MODE="0644"

Your mouse should appear on /dev/input/mightymouse when you plug it in.

Next grab the X.org source with apt-get source xserver-xorg. Then in the exapanded directory go to debian/patches/general and do

wget http://bugs.debian.org/cgi-bin/bugreport.cgi/052_evdev.diff?bug=325807;msg=5;att=1

to get a backport (with an extra little bit I put in for the Mighty Mouse horizontal scroll). Then edit debian/patches/series to remove the 053_lnx_evdev.diff, 054_lnx_evdev_mouse.diff and 055_lnx_evdev_keyboard.diff patches from the list, and add 052_evdev.diff.

I'm a bit unclear as to how the manifest system works; I modified MAINIFEST.ia64.in to have the new usr/X11R6/lib/modules/input/evdev_drv.o file, but that didn't seem to get it included in the package. If anyone can tell me how it is supposed to work that would be great, and I'll update this.

So build with fakeroot debian/rules binary or similar, and install the new xserver-xorg package. I then had to hand copy from debian/tmp/usr/X11R6/lib/modules/input/evdev_drv.o to /usr/X11R6/lib/modules/input/evdev_drv.o because the manifest thing didn't work.

Anyway, finally modify your mouse section to look like

Section "InputDevice"
        Identifier      "Configured Mouse"
        Driver          "evdev"
        Option          "CorePointer"
        Option          "Device"                "/dev/input/mightymouse"
EndSection

and for me everything "just works", with the exception of Firefox which binds the horizontal scroll to the history buttons, which with such a small wheel makes surfing very hard. See this hint on how to fix it.

Say you have just make a new chroot environment with debootstrap but now need to run X applications underneath.

The first thing is to not set your display to be simply :0.0 as this will try to use the UNIX socket in /tmp which probably isn't in your chroot.

You need your X server capable of listening on the network, which requires turning off -nolisten tcp. If you usually start X via the startx command you can edit out flag in the /etc/X11/xinit/xserverrc, but if you start from gdm you'll need to look at /etc/gdm/gdm.conf and have a look at the DisallowTCP option.

Once you have restarted your X server should be ready to listen for network connections. In your chroot set your DISPLAY variable to be localhost:0 to force the network socket connection.

At this point you need to sort out allowing access, the easy option is to do something like xhost +localhost to allow yourself to connect.

The only other problem was that debootstrap seems to not make all the devices required. If you see something like

host:/# xterm
xterm: Error 32, errno 2: No such file or directory
Reason: get_pty: not enough ptys

try running MAKEDEV pty in /dev to make the devices you need.

A very handy way of getting things into the chroot environment is to bind mount them. You can do mount --bind olddir newdir to make olddir look just like newdir. This will break through the chroot, which is at times great and at times a security risk. You can make scripts to bind mount in home directories (and even /tmp to avoid the unix socket problem).

If you only have one RSS feed I would suggest it should be the Freshmeat.net release announcements; I'm surprised bloglines tells me there's only 7 people subscribed to it. It's quite high volume, but I make time to skim it because it's simply a great way to keep up to date with what cool software people are developing. How else would you find out about genius like the wheel o' yum?