The Netbook Newbie's Guide to Linux
Back to the Bluez
Asus Eee PC users may be less lucky with Bluetooth. The very full instructions on the Eee PC User Group web page point out that "the Eee install of Linux comes with Bluetooth support enabled, but there is no way to configure or use it from the graphical interface. The command-line must be used".
Readers of previous episodes here shouldn't have much of a problem with that. But the User Group guidelines go on to add, fatefully: "However, this is trivial."
'Trivial' in the special sense of 'not possible', that is - at least if my experience is anything to go by. Although Linux seems recognise the Bluetooth dongle as powered up, I simply couldn't get its LED to flash at all.
A quick chat with Phil Simes on Cambridge Silicon Radio's support desk confirmed that the problem might be that the Asus machine was delivering marginally less power than the dongle was expecting. As the latest generation of Eee PCs are already Bluetooth enabled there didn't seem much point in pursuing this.
Has anyone else got this working? If you have, please let me know how, by posting a comment or emailing me using the byline link above.
In the very early days of Unix, features like Bluetooth capability - not that such a thing existed then - would be compiled into the kernel, but for over a decade now the practice has been to create them as separate modules, optionally loadable either by user intervention or - more commonly - automatically on demand. Plug in your Bluetooth USB dongle: the operating system recognises it and loads the relevant modules. All modern operating systems work like this.
But unlike Windows, or Mac OS X, the kernel at the heart of the Linux operating system - or, strictly speaking, the Linux at the core of the GNU/Linux system - has been evolving very fast. So although a Mac OS X "kernel extension" (a
.kext) created five years ago might be expected to work with the current Mac OS X, a kernel module compiled to run with some random version of Linux probably won't work with the 18.104.22.168lw kernel at the heart of the AA1's Linpus.
This has always been true of Linux/Unix, and although it sounds like a headache, it's actually part of the great strength of an operating system that runs across a huge range of different hardware. It works because kernel modules are traditionally distributed as source code, something made possible by the fact that every full version of Linux is also a development system, with its own set of compilers, linkers and all the other paraphernalia necessary to crunch source code into binary executables.
Every version of Linux - except, that is, for the pre-cooked, locked-down Linuxes turning up on today's netbooks. In the case of the AA1, I see that it may not be as grim as that. The Package Manager - which you can get to if you followed the instructions for attaining the AA1's "advanced mode" in Episode 3 - promises a set of Development Tools and Libraries, which should bring Linpus up to full spec. I haven't installed any of this because the spirit of this series is not to get too hairy.
The official Acer 'Bluetooth Patch' presents itself as a script file. The abiding Unix advantage of doing a lot of stuff using plain text shell scripts is that they're transparent - you can read 'em to find out what they think they're doing. All the scripts in
/etc/init.d that start up the various Linux services, for example, work along these lines. But not this 'Bluetooth Patch' script.
Some of it is readable. The opening comment line says that it's been constructed with a utility called
Makeself is a utility devised by Stéphane Peter that makes
.tgz files self-extractable. The
.tgz files are embedded in the Makeself scripts, so although they run like scripts, they're mostly full of binary code that completely conceals their actions.
At least that's how it seemed. I dropped an email to Stéphane suggesting that short of setting up a VMware Linpus sandbox, running the script and then walking through the whole system with
find, I couldn't think of any way of determining the workings of this kind of script that can create executables or other scripts at will, and then run them. So, is
Makeself evil? I asked him.
No, he says. No less so than any other installer. He explained that you can quiz a
Makeself file from the command line about its contents:
[user@localhost bluetooth.sh]$ ./bluetooth.sh --info Identification: install bluetooth patch Target directory: bluetooth Uncompressed size: 9768 KB Compression: gzip Date of packaging: Sat Oct 11 14:37:37 CST 2008 Built with Makeself version 2.1.4 on linux-gnu Build command was: /usr/bin/makeself.sh \ "bluetooth" \ "bluetooth.sh" \ "install bluetooth patch" \ "./install.sh" Script run after extraction: ./install.sh bluetooth will be removed after extraction
Stephane goes on to say: "To examine the contents of the archive itself, and thus get a better idea of what happens, you can use the
--target options to simply extract the files, ie.
sh makeself.run --noexec --target /tmp/archive
You can then just peruse the contents of
/tmp/archive in this example."