The Netbook Newbie's Guide to Linux
Back to the Bluez
With the kernel modules in place, we're still not quite ready to rock and roll. First, we'll have to ensure that the new modules are added to the system module inventory, a text file called
modules.dep. This list makes sure that any module that requires the presence of other modules to work properly gets everything it needs at load time.
Yast's Advanced Daemon Configuration shows that the MSI Wind comes with Bluetooth software capability already installed
Managing this string of dependencies is a complex business, but happily you don't have to edit
modules.dep manually - just run a tool dedicated to this task:
modules.dep automatically. And now we're ready to load our new modules into the kernel and get Bluetooth running. The official Acer patch has already installed the script to do this in
/etc/init.d, among all the other boot-time scripts. So we just run:
...and if all's well the blue light on the dongle should start flashing. Bluetooth is working.
Now is probably the time to reboot, to make sure the Bluetooth init script is doing its job properly - loading the relevant modules and installing a Bluetooth symbol among the other notification icons down at the bottom right of the screen:
When you scan from your phone for Bluetooth devices, you should see a new one with a name like
localhost-0. Right clicking on the AA1's new Bluetooth notification icon brings up a dialogue that allows you to change this to something more informative.
MSI Wind owners don't have to do any of this - Bluez is already installed and ready to run, even if there's no on-board Bluetooth hardware.
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.