Reminds me of the old JANET joke:
If you have a free PSS account please dial 999 and ask to be arrested.
Found an interesting wrinkle in the Linux handling of ulimits for maximum memory size and data segment size – they are not enforced by current glibc / kernel configurations in certain conditions.
I tracked this down to the fact that somewhere around glibc 2.3 the malloc() implementation was ripped out and replaced with one that uses mmap() for allocations of 128KB or more. The kicker is that the kernel mmap() implementation only cares about the virtual memory ulimit (RLIMIT_AS) for enforcement, the others are just ignored!
So currently an application which uses small allocations (<128KB) will find malloc() failing when they hit their max mem / data seg size ulimit whereas an application that grabs RAM in larger chunks will sail happily past that without a care in the world..
Bug, feature or undefined behaviour ? You decide.. 🙂
Caveat: Whilst the below works for me for those particular applications you may find that other 32-bit only applications require a fuller 32-bit environment, which you can get using a separate install of a 32-bit Ubuntu (often called a “chrooted environment”) – please see the corresponding Ubuntu Wiki page for more information.
I have a new AMD64 compatible system (an Intel quad core box) which comes with an ASUS DRW-1814BLT Lightscribe DVD burner. Problem is that I’m running a 64-bit version of KUbuntu Linux (as it’ll have 8GB RAM once the final sticks arrive) and the closed source Lightscribe software is 32-bit only and won’t install without a bit of prodding.
So, to help others, this is the hack that I did to install it successfully.
First I had previously installed the 32-bit compatibility libraries for AMD64 thus:
$ sudo apt-get install ia32-libs
Then I installed fakeroot and alien and converted both of them to TAR files thus:
$ fakeroot alien -t lightscribe-220.127.116.11-linux-2.6-intel.deb
$ fakeroot alien -t 4L-1.0-r6.i586.rpm
Then I converted the two tar files straight back into .deb’s:
$ fakeroot alien lightscribe-18.104.22.168.tgz
$ fakeroot alien 4L-1.0.tgz
Then it’s the usual installation procedure of:
$ sudo dpkg -i ./lightscribe_22.214.171.124-2_all.deb
$ sudo dpkg -i 4l_1.0-2_all.deb
and it seems to work (though I have no Lightscribe media to test with yet!):
$ 4L-cli enumerate
Drive path: /dev/sr0
Full name: ASUS DRW-1814BLT 1.13 132
Drive inner radius: 21700
Drive outer radius: 58700
Update: I’ve since spotted that dpkg has a –force-architecture option, this may avoid the need for converting the lightscribe package.
Update 2: It works! I’ve successfully used the GUI to label a CD as a test.
Update 3: Paul Bailey has distilled the above into a simple recipe.
Bruce Schneier has written good things on why this “war on terror” is going badly wrong. Go read..
We’ve opened up a new front on the war on terror. It’s an attack on the unique, the unorthodox, the unexpected; it’s a war on different. If you act different, you might find yourself investigated, questioned, and even arrested — even if you did nothing wrong, and had no intention of doing anything wrong. The problem is a combination of citizen informants and a CYA attitude among police that results in a knee-jerk escalation of reported threats.
The problem is that ordinary citizens don’t know what a real terrorist threat looks like. They can’t tell the difference between a bomb and a tape dispenser, electronic name badge, CD player, bat detector, or a trash sculpture; or the difference between terrorist plotters and imams, musicians, or architects. All they know is that something makes them uneasy, usually based on fear, media hype, or just something being different.