Linux Basics - Rename Files

Oh god this was depressing. Say you have a bunch of .jpeg files you want to make into .jpg files. A filemanager on its own is pretty useless for this in either windows or linux. You may now decide to use a bulk rename utility. If you do this, you will be immediately sent in-fucking-sane by a user interface looking like this.

The second option, if you wish to preserve your grip on reality, is to use the command line. In windows the command to rename all .jpeg files to .jpg looks like this:

rename *.jpeg *.jpg

The '*' is a wildcard standing for any filename. So far, so good. The linux version of the command looks like this:

rename -v 's/\.jpeg$/\.jpg/' *.jpeg

I will accept that this is less mind meltingly unintuitive then the hideous UI cited above, but it is a close run thing.

Oh, and another thing. Apparently the usual way to rename files in Linux is to [m]o[v]e them like this:

mv oldfilename newfilename

If you realise that [c]o[p]y is cp, [m]o[v]e is mv, then you may think that [r]ena[m]e is rm. That would be a bad thing, because rm is actually [r]e[m]ove. Apparently no-one thinks this is all utterly bizarre.

Linux Basics - Download and Run Files

In general most advanced distributions of Linux are far more sensible about software installation than windows. Instead of having programs scattered far and wide across the interweb, they are usually collected together in a collection, or repository of files.

Sometime software will depend to some extent on other pieces of software. In windows this can manifest itself in the need for visual basic runtimes, or .net installations. You download a useful looking bit of software, install it, and run it only to find you need to download a FURTHER application 10 times the size just to get the sod to work.

No difference in Linux, except, as I say with more advanced distributions. What is important about the repositories is that not only is all the software in the same place BUT each bit of software knows what OTHER bits of software from the same repository it needs to run. So when you install the software it automatically downloads and installs all the other software it needs to function.

However, sometimes you do want to install some software from outside the standard repositories. If you try to do this in the windows way (right click link, save to disk, double click resulting icon, you are fucked. But it will not tell you what has gone wrong.

What you need to do is tell Linux it can run, or execute the program you have just downloaded. You can do this using most file managers by right clicking, looking for 'permissions'. There should then be an option, probably a checkbox, to turn on the 'execute' permission for the file. Alternatively you can do this on the command line by running the command:

chmod +x /path/to/nameoffile

This [ch]anges the [mod]e of the file [nameoffile] in the directory [/path/to] by [+]adding the e[x]ecute permission, but only for the current user. This means that if you have any other user accounts on the system, they will not be able to execute the file, which may be fine by you. To allow [a]ll users to execute the file, put an 'a' before the '+' sign, so it looks like this:

chmod a+x /path/to/nameoffile

By way of example, here is how you download and install Adobe's 'air' application:

wget http://airdownload.adobe.com/air/lin/download/1.5/AdobeAIRInstaller.bin
chmod +x AdobeAIRInstaller.bin
./AdobeAIRInstaller.bin

You can just copy and paste all three of those commands into a terminal window and it will install. You do not need to open your browser. The first command goes to a file on the [w]eb and [get]s it for you. It downloads the file to the directory you run the command from. We should now know what the second command does. The third command executes the file from [./] the current directory.

Linux Basics - Network Connection Details

If converting from windows, and you find yourself without a network connection (highly likely if using wireless) do not hammer in 'ipconfig', for it shall not work. Try 'ifconfig' instead.

Linux Basics - Copy/Paste in Terminal

One of the things about linux which really irritates me is the complete lack of documentation of the first things you have to learn. It is as if once people learn these lessons, they do not give them a second thought and assume that the next generation will also absorb them by osmosis.

In a valiant attempt to stop that happening, I present some basics:

To copy text in a terminal window, do not highlight it and press CTRL+C. God no, that would be - oh what's the word - fucking logical. Instead highlight the text and either right click and select copy, or press CTRL+ALT+C.

To paste the text you have just copied, do not try CTRL+V ... etc ..., press CTRL+ALT+V.

Using Evolution with Exchange Server

Evolution is to Outlook, as Thunderbird is to Outlook Express. While Thunderbird will let you get your email from your ISP, and from Google (and sometimes, when it fecking works, hotmail), Evolution's big selling point is that it works with Exchange. Exchange being Microsoft's email server.

To get Evolution working in either Ubuntu or Arch you need to install the following packages:

evolution evolution-exchange

When you have installed these, you configure Evolution as follows:
Add an account and specify type as Exchange Server.
You then set these variables:
Receiving E-mail → Username = [domain]/[logon_name]
Receiving E-mail → OWA URL is https://[mail_server_name]/exchange
Receiving Options → Global Catalogue Server Name = [mail_server_ip_address]
Default → Sent Messages Folder = set to Exchange not Local
The system should auto find the exchange account if you click authenticate.
Public Folders are accessed by going Folder → Subscriptions, and choosing Exchange Server.
[domain] examples would be, smoobandit.com, smoobanditprivate.local

Once you pop in your password you should find that Evolution connects and starts downloading all your mail.

However, this is buggier than a trap for Indiana Jones. Every so often, including more than once per day, it will fubar its connection to the exchange server. It either denies there is any mail, or tells you you have 3 messages in the last 3 months. Sometimes this is accompanied by an error saying that it has lost connection to the backend something or other. Sometimes not. The only way to fix this, that I have found, is to open a terminal and run these commands:

evolution --force-shutdown
cd ~/.evolution/mail/exchange
sudo rm -rfv ./[domain]

Then re-run Evolution and it will re-sync to Exchange. This is OK, unless you have something stored locally and not on the server. For instance, if you were drafting an email when the connection fubarred, then you would lose that because it would only be stored locally. Bastard.

Testing Windows 7

So, there is a release candidate of Windows 7 out. I want to test this by using it in a virtual machine. It installs fine, but will not see the VMWare network, audio or USB drivers. Goddammit.

To solve the network problem you need to ensure that you are using the e1000 virtual hardware. In order words, your .vmx file needs to include:

ethernet0.virtualDev = "e1000"

To get the USB working, you need to ensure that both scsi and ehci are running, with these lines in your .vmx file

scsi0.present = "TRUE"
scsi0.pciSlotNumber = "18"
ehci.present = "TRUE"
ehci.pciSlotNumber = "19"

I have no fucking idea how to get the audio to work.

[UPDATE]
This software fucking hates me. Once I had setup all of the above, USB worked flawlessly in the Virtual Machine. However, once I shut it down and restarted, it was fubarred. I checked the .vmx file and found to my horror that the .pciSlotNumbers for scsi- and ehci were now '-1'. Brilliant, why the fuck has it done that? Solution - change it back to the text above and WRITE PROTECT the .vmx file. Job done.

Linux Documentation

I have complained before about the really crappy documentation that you encounter when trying to trawl through linux manuals. Two recent examples may shed some light on the nature of my complaint.

Firstly, in my last post I talked about the xdg-mime command and how it is used to change the default application for various filetypes. What I did not say was how frustrating the documentation was to deal with. For instance, go and look at the manual page for xdg-mime. It all starts well enough:

xdg-mime — command line tool for querying information about file type handling and adding descriptions for new file types

That's a nice intro, and sets the scene well. We know what we are talking about. Also, the description gives us some more useful information:

The xdg-mime program can be used to query information about file types and to add descriptions for new file types.

Good. Good. Keep it coming. Lets have a look at the synopsis of the command:

xdg-mime query { filetype | default }

Right, so we type "xdg-mime query" and then what? Oh - filetype. Right, so I am interested in PDFs. Lets try:

xdg-mime query pdf

Aaaaaaand:

xdg-mime: unknown query type 'pdf'

Fucking great. The system must know about PDFs because it is opening them now (with GIMP, which is fucking annoying and the whole point of this little command line adventure). What could I be doing wrong?

Slowly the light dawns. When it says 'filetype' that is not a variable, that is literally what you type. So you follow 'xdg-mime query' with the word 'filetype'. Right, brilliant. So why the fuck could the error report not say:

xdg-mime: unknown query type 'pdf'.  Valid querys are 'filetype' and 'default'.

It's not that hard to type out six words.

OK, so we follow 'xdg-mime query' with either "filetype" or "default". I can follow that. Fine. So what do I type after filetype or default? Lets see...

query filetype FILE: Returns the file type of FILE in the form of a MIME type.

Right, so I now try:

xdg-mime query filetype forfuckssake.pdf:

Aaaaaand:

xdg-mime: file 'forfuckssake.pdf:' does not exist

Yes it fucking does I am looking at it! So I check the spelling, and the path. I try "./" before the filename, because god knows linux gets picky about finding stuff not in the path - even when you are in the same fecking directory as the file you want to use! Nada.

Then a further little light dawns. See the colon at the end of the filename? What if maybe, just maybe, that shouldn't be fucking there? What if the instructions, which specifically appended a colon to the end of the filename, and which I am following carefully, not just being slap happy with my colons in general, were put together with all the skill and panache of a recovering alcoholic with the DTs trying to construct a house of cards? Leave off the colon = command works as it should. Genius.

Secondly, I have been farting around with the larch system for making live usb installations of Arch. One of which I am using to post this, as a matter of fact. To cut a long story short, I wanted to add some extra packages to the install which were not in the repositories. The Larch manual states:

It is possible to include your own 'custom' packages in the installation. Maybe ones you have compiled yourself, e.g. from the AUR, or modified versions (fixes or customizations) of standard packages. To do this you need to put your packages in a directory and run gen-repo - which requires python - on this directory (run it without arguments to get usage instructions). Then place an entry for this new repository in your 'pacman.conf' (in the profile or else in the working directory). If your packages replace some in the existing repositories, your custom repository needs to come before those repositories in 'pacman.conf'. Any packages you want installed now just need to be listed in addedpacks.

Larch also sets up a pacman.conf file which contains this little nugget of information:

# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#Server = file:///path/to/custom

This sounds promising and looks straightforwards. So I put my packages in a directory, run gen-repo and make a change to pacman.conf. Only I can't fucking find gen-repo. I mean it is not in the directory I installed larch into. Where the fuck can it be? I eventually trace it to ./larch/run/ where I find it is actually called gen_repo, not gen-repo. Fan-fucking-tastic waste of time.

So I then run the command on the directory I have assembled my custom packages in. It makes a new file in that directory called nameofdirectory.db.tar.gz.

Right so I ask you now - how do I "place an entry for this new repository in" my pacman.conf file? I try referencing this new file directly in the Server: line. That doesn't work. I try just making the server line link to the directory the new file is in. That still doesn't work.

I eventually discover, through trial and error no less, that what I should have been doing was to have the Server: line point to the directory the new file was in, uncomment the line #[custom] above AND change the word 'custom' in it to the NAME of the new file LESS the .db.tar.gz bit. Oh - of course, silly me, how fucking simple. I mean, it is all laid out so clearly in those helpful manual files. All these steps are so fucking transparent I nearly walked right into them.

Give me fucking strength. Is it something to do with linux? Are the developers so fucking delighted to get their software to actually work that they piss off down the pub as soon as it compiles? With the inevitable result that they are shit-faced drunk when it comes to writing the documentation? And then, THEN, when you ask a question you are told to RTFM? Really? Well stick your RTFM right UYFA.

Setting Default Applications in Arch LXDE

LXDE being a very basic desktop environment, there is not much in the way of GUI tools to change your default applications. So for instance when you double click on a PDF does that open in pdfviewer or evince? Or, in a staggering approach to logic, GIMP?

You need to know two things about a file - what its MIME type is, and what application is set to run that file type.

You find out the first element by using the filename of a type you are interested in, in this command in terminal:

xdg-mime query filetype filewithatypeIaminterestedin.pdf

The output will look a bit like this:

application/pdf; charset=binary

For our present purposes, the first part of the response is the important bit. It tells us that the MIME type is "application/pdf". You can now run the following to find out what application is set to run this:

xdg-mime query default application/pdf

Where "application/pdf" is obviously whatever was spat out by the previous command. The results of this command, should be a .desktop file. This is the file in /usr/share/applications which has all the important information about an application. To change this you run the following command:

xdg-mime default epdfview.desktop application/pdf

Mount Windows Shares in Arch

Oh for fucks sake this is difficult. It should be easy, really it should be easy, but the combination of shitty documentation, and crap network authentication standards leads to a mess.

It should work, on a temporary basis with these commands:

mkdir /media/network
mount -t cifs "//server/share/" /media/network -o username=myusername,password=mypassword

There should be a way to do all this automatically with smbnetfs, but that software is currently fucked.

Otherwise, this might have stood a chance:

pacman -S smbnetfs
modprobe fuse
nano /etc/fuse.conf #uncomment 'user_allow_other'
/etc/rc.d/smbnetfs start

This does stand a chance, actually. Just not with anything that should, god forbid, use some kind of username/password security. Configuration is in:

/etc/smbnetfs/.smb/smbnetfs.conf

Which failing a forced manual mount would look like this:

cd /mnt/smbnet/DOMAIN:myusername:mypassword@server

But that fails with the delightfully informative "Transport endpoint is not connected", which makes about as much intuitive sense as "Your wurfle strip has sturbified, you must re-cognificate your panzel-struder".

VGA Screen on Boot

When booting a PC before you get to the spanky graphical interface it defaults to a crummy text based interface with 80 columns, each with 25 rows. Or is it 80 rows of 25 columns?

Anyway.

It looks crap. Most operating systems try to hide this from you, whether it be with a Windows 98 graphic, an XP flag, Vista's minimalist approach, or Ubuntu's orange Knight Rider-esque effort. Behind the fancy graphics, and the desperate cylon impression, a whole lot is going on. Messages whirr past as various parts of the PC spring into life - hard disk here, clock there, now a network connection, there a keymap configuration. Some mature operating systems let you see what is going on, presumably on the basis that if you are experienced enough to be using them, you won't soil yourself when you see some system messages in text.

The down side to this is that the messages REALLY whirr past when you only have 25 rows available to display them. The solution is to choose another screen format to use on boot. I first saw this approach on Mac OSX, and I thought it looked really good. So - how to get this with Linux?

It turns out that it is really easy - you just add

vga=xxx

to the end of your kernel line (where xxx is a three digit number). You can do this by either editing your /boot/grub/menu.lst file or by opting to choose a kernel on boot, pressing 'e' to edit the kernel and adding that text at the end.

I did this.

It did not work.

I got a message to the effect that the mode I sought could not be found. Or something equally fucking useless in terms of diagnostics. If you have clicked through to the link above you will see how many mode numbers there are. I tried them. None of them fucking worked. I tried using hex numbers instead - by prefixing the hex translation with '0x' (so 0x317 is 773). It didn't fucking work. Every search I tried on this offered up the helpful advice of "try adding vga=xxx to the end of your kernel line by ...". Fucking great.

It was after several hours of frustration that I hit on a brilliant idea. You see, I also have a 30" LCD TV connected by VGA to another PC. The TV can do 1280x768, and thus is technically HDTV ready. However, I bought it before the whole HDTV thing kicked off, so it doesn't claim to be HDTV ready, and it doesn't have an HDMI port. Monitors tell the PC what resolutions they support by way of the EDID system. Using XP originally, it was only detected as a 1024x768 monitor, but the Nvidia drivers for XP allow you to over-ride the detected resolutions. So I could happily use it as a 1280x768.

In due course I upgraded the machine to Vista, mainly to benefit from the more mature Media Center software. Again the monitor defaulted to 1024x768. No problem, thought I, just tell the nvidia driver to over-ride this back to 1280x768. Clicky-clicky. Hmm, can't seem to find the option for this. Googly-googly. Vista will NOT let drivers over-ride the settings from the monitor. Oh for fucks sake. I am not 12. At this point I descended into a hell of Powerstrip settings, EDID bios reprogramming, and (worst of all) INCORRECT FUCKING ASPECT RATIOS. All of this just because some incompetent half-wit can't program a fucking bios chip with the correctly supported screen resolutions. How hard can it be? 1024x768, 1280x768 - there you go I managed it fine!

On the third day I rose, clutching a pair of pliers, a DVI pin out diagram, and a VGA-DVI adaptor. Once I had ripped out the pins that communicated the WRONG information about the TV to the PC, Vista would let me set the resolution to whatever the hell I liked. Fantastic.

So, back to our story. I thought to myself, could the monitor be lying its arse off to the bios? I mean, sure it works fine once you have booted a gui, but maybe Captain Hamfisted Knobcheese III, EDID bios programmer extraordinaire is back on the scene. I found somewhere the boot option:

edd=off

This stops the monitor bullshitting the PC about what it can and cannot do. Tried it. It works. Genius. So if you continue to have problems after using vga=xxx, then you need to add this to get your funky VGA graphics on boot:

edd=off vga=xxx

Ethernet in Compaq Mini 700

As noted below, I have a Compaq Mini 700. It is a great little machine, useful keyboard, good screen, plenty of storage and decent battery life. I just use it with my wireless connection at home, and it works flawlessly.

In the office though, I appear to sit in a wireless dead sport, which obliges me to use an ethernet cable to get access to the network.

In a spirited attempt to bring some unpredictability and surprise to my life, plugging in the ethernet cable does nothing, while unplugging the cable instantly crashes the whole machine. Genius, absolute genius. Apparently, what you need to do, is plug the cable in, turn on the machine, use the network connection, turn off the machine and THEN unplug the cable. Oh, unless you have the power cable plugged in, in which case it won't instantly crash when you unplug the cable, but it still won't work when you plug it in when on.

This is, of course, all designed to make me swear and throw the machine out of the window, at one stroke invalidating the warranty AND increasing Compaq's profits when I go to buy another one.

It turns out there is an actual proper solution to this problem. You need to tell the operating system that it can use acpi. Or that acpi can use the OS. Or something to do with acpi anyway; the whole thing is as transparent as a foot thick sheet of fucking lead. Whatever it is you need to do you do it by adding a setting to your boot configuration. You need to run this command:

sudo cp /boot/grub/menu.lst /boot/grub/menu.backupincasethisfuckseverythingup
sudo gedit /boot/grub/menu.lst

You then look for this section, about halfway down the file:

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
##      kopt_2_6_8=root=/dev/hdc1 ro
##      kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=UUID=long-string-of-letters-and-numbers ro

What you want to do to fix the problem is to make the last line of this section look like this:

# kopt=root=UUID=long-string-of-letters-and-numbers ro acpi_os_name=Linux

The reason you do this is because ubuntu gets clever when it updates its kernel. It also re-writes the menu.lst file. If you just went through this list and changed the ACTUAL kernel settings then this fix would work. Until you downloaded a kernel update at which point it would instantly fubar. Having made the change to the default options section, you can force a rebuild of the menu.lst by using this command:

sudo update-grub

Now, even if the kernel is updated the acpi (whatever that is) change will remain in place. Once you reboot your machine, you will find the ethernet cable slips in and out easier than some disgusting sexual metaphor.

Installing Dropbox in Arch

There is this really useful bit of software called Dropbox, which syncs a directory on your machine with a network server and your other machines. It also handles version control and backups. It runs on XP and Linux and as such is very useful.

On Ubuntu it will install perfectly happily, but on other distributions it takes a little bit more work. The following instructions work for Arch running the LXDE desktop.

Step One.
Download the Linux version from here. Then extract the contents into your home, or ~/ folder. The contents should just be a folder called .dropbox-dist.

Step Two.
Download two command line utilities to setup the non-ubuntu version by running these commands in terminal:

wget http://dl.getdropbox.com/u/6995/dbmakefakelib.py
wget http://dl.getdropbox.com/u/6995/dbreadconfig.py

Step Three.
Make a folder in your home directory to store the files being shared by running this command in terminal:

mkdir ~/Dropbox 

Step Four.
Run the two scripts that you downloaded earlier to get an ID code for the machine that you are using. The first script test runs Dropbox to generate the local databases with your host_id. If the dropbox program pops up, just ignore it. It will be have quite flakily. Rely on the command line, it will tell you when 15 seconds have passed. Just close dropbox at that stage, and run the next command. If you get any error codes when running the first command, try running it whenyou are offline - i.e. disconnect from the internet.

python dbmakefakelib.py
python dbreadconfig.py 

Copy the host_id from the subsequent text output.

Step Five.
Open a browser window and use this link (where HOSTID is the host_id you copied in the previous step):

https://www.getdropbox.com/cli_link?host_id=HOSTID

Log in with your user name and password.

Step Six.
Desktops which follow the free desktop system store information for their application menus in .desktop files which are then automatically assembled into a menu structure. You need to setup a menu icon for Dropbox by running the following command in terminal (you NEED to make sure to change the USER below to the name of your user account):

echo '[Desktop Entry]
Name=Dropbox
GenericName=Network Storage
Comment=Secure backup, sync and sharing made easy
Exec=/home/USER/.dropbox-dist/dropboxd
Icon=/usr/share/pixmaps/dropbox.png
Terminal=false
Type=Application
Categories=Network;' | sudo tee -a /usr/share/applications/dropbox.desktop

That command will make a new file in /usr/share/applications/ called dropbox.desktop. That's the folder which LXDE uses. Other distributions and Desktop Environments may vary. You will find icons for all other installed applications in the same folder. Important note - installing the .desktop folder here will make the application appear in all users menus. It is possible to install it to a personal folder in home, which may be preferable.

Step Seven.
To make it look nice you will need an icon, which you can get and copy to the right place by running these commands:

wget http://aur.archlinux.org/packages/dropbox/dropbox/dropbox.png
sudo mv ./dropbox.png /usr/share/pixmaps/dropbox.png

Step Eight.
You will want Dropbox to run when your user logs in, so that it is available automatically. The free desktop model makes provision for this and you can set it up by running these commands:

mkdir  ~/.config/autostart
cp /usr/share/applications/dropbox.desktop ~/.config/autostart/ 

The first command [m]a[k]es a [dir]ectory in your home (~) folder called config with another folder inside called autostart. The [.] before config means the folder is hidden.
The second command [c]o[p]ies the desktop file we made in Step Six to the autostart folder, causing it to be run when the user owning the home directory logs in.

Step Nine.
You can now run Dropbox from the menu, where an Icon has magically appeared, or restart your machine. All the configuration of the client should have been achieved by Step Five, so it should start syncing right away.

Disable Password Check on Resume in Ubuntu

Once I discovered the joys of gconf, see previous post, I found another delightful change that solved a problem.

If I suspend my netbook to RAM, it is because I want to quickly turn it off and on, rather than waiting the 65-70 seconds it takes to go from power off to a usable desktop. I do NOT want to faff about typing in a password each time I restore from RAM, because that would ruin the whole "quickly on" bit.

So, to do this, I used:

gconf-editor

to change the following setting:

/apps/gnome-power-manager/lock/suspend

to false by unchecking it. Job done.

Turn Off Screen Saver in Ubuntu

OK, so CRTs are, like, so 20th Century. If you left them running showing the same image for days on end, like the log on screen in a computer lab, you would eventually find that image burnt onto the screen itself. This is bad. So we invented the screensaver, a bit of software which detects when you have not typed anything or moved the mouse for a while and either blanks your screen, rifles through your pictures collection, or shows some high art animation usually involving toasters. This stops the insides of the CRT from being damaged.

However:
a) no one uses CRTs anymore
b) LCDs do not burn in
c) sometimes I want to leave the screen displaying information without the fucking screen going dark every ten minutes.

Now, I am an intelligent guy, so I go to the System -> Preferences -> Screensaver tool and uncheck the "Activate Screensaver when computer is idle" dialogue box. That should do it?

After ten minutes: blank screen. Oh for fucks sake. So I go to the Power Management options from the Screensaver tool. I tell it 'Never' to put the display to sleep.

After ten minutes: blank screen. Oh for fucks sake. I have to activate the god damned trackpad every nine minutes or so to avoid the screen blanking. Brilliant. I seriously consider trying to activate the trackpad automatically every 9 minutes.

It turns out (and by it turns out I mean after spending the better part of my life trawling through google and forum searches) that you need to change a setting in the gconf file. Whatever the gconf file is. You do this by running this command in a terminal:

gconf-editor

You then navigate through the tree structure until you get to:

/apps/gnome-screensaver/idle_activation_enabled

which you set to false by unchecking it. Hey Ubuntu developers, when someone unchecks the "Activate Screensaver when computer is idle" turn off this bloody setting.

Now, here at the end of all things, sam, I finally have an LCD which does not go dark every 10 minutes.

Compaq Mini 700 Sound in Ubuntu Jaunty

I also have a Compaq Mini 700 netbook, which is for all practical intents and purposes that same as the HP Mini 1000.

So I installed Ubuntu Jaunty on this machine. Thankfully the network card either doesn't use firmware, or the firmware is open sourced, because the networking functioned out of the box. I therefore did not have to go through the will sapping sequence of steps outlined in earlier posts just to get the damn thing working.

Woo, and if I may add, Hoo.

Until that is, I tried to play some sounds. Nothing, no noise, just nothing. Oh, for fucks sake, why is nothing ever simple. Right, time to roll up my sleeves.

It turns out that ALSA version 1.0.18, which is the version used in Jaunty, does not support the speakers on the Compaq Mini. This is particularly frustrating, because version 1.0.17, such as used in Ubuntu Intrepid, does support the speakers. Yes, let's advance our software by removing functionality, fucking spiffing. You can check if you have this problem; stick some headphones in the machine, if you get sound from the headphones but not the speaker, congratulations.

To fix this delightful issue, you need to install ALSA 1.0.19. Will Ubuntu let you do this automatically? No. As far as I can see at this stage, you have three options.

Option A.
Download the source code for ALSA 1.0.19 or later and build the software from source EVERYTIME AN AUTOMATIC UPDATE FUCKS WITH THE SOUNDS SETTINGS.

Option B.
Use a handy PPA which does Option A for you automatically.

Option C.
Shake your head in disbelief and take up basket weaving as a hobby instead.

As you may have guessed, I plumped for Option B. I tried Option A, but then I have also tried amateur fire-breathing and I found it about as painful.

Step One.
So to get the bloody sound working, open a terminal and type, or paste the following into it:

echo 'deb http://ppa.launchpad.net/minichoco-team/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/minichoco-team/ppa/ubuntu jaunty main' | sudo tee -a /etc/apt/sources.list

Your sources.list is a text file which has a list of internet places where Ubuntu can download system files. This command adds a PPA to this list. This is a non-official source of ubuntu software, but which can now be accessed automatically.

Step Two.
Get the Ubuntu Package management software to speak to the PPA by running the following commands in a terminal:

sudo apt-get update
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 9220067F
sudo apt-get update
sudo apt-get upgrade

Step Three.
Install the source code for ALSA 1.0.19 by running the following command:

sudo apt-get install alsa-source module-assistant

Step Four.
You only have an intel sound card in your Compaq/HP mini don't you? You don't need the flexibility of running any soundcard under the sun in your tiny netbook do you? No. Tell the configuration file for ALSA this by editing it:

gksudo gedit  /etc/alsa/alsa-source.conf 

On line 11 you make it read ALSA_CARDS="hda-intel" rather than ALSA_CARDS="all". You do not have to do this, it just speeds the whole thing up. If you enjoy watching progress bars crawl across the screen, or this sounds a bit scary, then ignore this step altogether.

Step Five.
Compile the ALSA Source code. Sounds scary doesn't it? Nah, just run this command in a terminal:

sudo m-a a-i alsa-source

This uses the [m]odule-[a]ssistant program to [a]uto-[i]install the ALSA source code for your current kernel. The beauty of this is that if an update fucks up your sound again, you just rerun this command, and it will work again. That's considerably easier than fucking about with make, make install, every time you do an update.

Step Six.
Restart ALSA to run 1.0.19 rather than 1.0.18, by either rebooting or running this in a terminal:

sudo alsa force-reload

Step Seven.
Don't you just love it when you sweat blood through six steps like we have just done, only to find that the OS then mutes your speakers everytime you log in. Delightful isn't it. What, you mean you don't like that? Well, picky, just edit your rc.local file by running this command:

gksudo gedit /etc/rc.local

And add this text before the line reading exit(0):

amixer set Speaker unmute
amixer set Speaker 100%
amixer set 'PC Beep' mute
amixer set Master 70%

rc.local is a list of commands run when the system boots, not unlike the old autoexec.bat file in DOS. amixer is a command line utility which is used to change the sound settings. This means that you could run the above commands quite happily in a terminal. Putting them in rc.local just means that they run everytime you start the machine. If you need an explanation of the complicated tech-speak options which follow the 'amixer' command above, then I am afraid you are too stupid to own a computer. Take it back to the shop.

Wireless Firmware Through a Virtual Machine

Herein I present yet another way of getting a hold of the firmware you need to have a functioning wireless connection on a Linux Live CD, which you may wish to use because:

a) you do not already have a working wireless connection on a Linux machine otherwise you wouldn't be reading this crap; or
b) you do not have a 50m CAT5 network cable to connect to your router; or
c) ndiswrapper won't work - staggering I know.
d) life is too damn short to read the instructions on how to make ndiswrapper work.

For this method you will need:

A computer with a working internet connection (wired, wireless, doesn't matter) capable of running some sort of virtualisation software, such as Virtual PC, VMWare Player, or VirtualBox.
An Ubuntu Live CD image.
A USB Key

Step One.
Setup your virtual machine so that it boots from your Live CD image, and shares your Host machine's internet connection. The exact method will vary depending on which of the virtualisation software options you choose. You will need a sensible amount of RAM dedicated to the virtual machine - say 512Mb, and you do not need to bother with a Hard Disk image, we will not be installing.

Step Two.
Boot the Live CD in the Virtual environment.

Step Three.
Check the internet connection is working, by opening a web browser. If not working, go back to Step One and fix it.

Step Four.
Install b43-fwcutter.
Open a terminal window and type:

sudo apt-get install b43-fwcutter

'apt-get' is an ubuntu command to download a piece of software from the ubuntu servers. The install option installs the software once it has been downloaded. The 'b43-fwcutter' program is a utility to get the firmware that is the holy grail of this post. As part of the installation procedure you will be asked to agree to download and install the firmware. Say yes. If you panic and say no, then rerunning the above command will not work. Instead you have to run:

sudo dpkg-reconfigure b43-fwcutter

Step Five.
If you now look in /lib/firmware/ you will find the b43 folder referred to in my first post. You can just copy the contents of that folder onto your usb key and use them in the way described in said post. If your virtualisation software will not let you use a USB key (I don't think that the free version of virtualbox will) then archive the b43 folder (down to a massive 40k) and gmail or hotmail it to yourself. Exit to your host operating system, get your email attachment, open it and save to your USB key.

Step Six.
Proceed as per the first post, Step Three.

Wireless Firmware Through Ndiswrapper

In my previous post, I set out a way to load broadcom firmware into a running Live CD distribution.

I said you had to firstly copy the firmware from an installation with wireless up and running which some what defeated the point. In order to avoid turning the last post into War and fucking Peace I avoided getting bogged down in the alternative ways to get a hold of the broadcom firmware files. I present hereunder the ndiswrapper method. You will need:

An Ubuntu Live CD
A USB Key
The Windows drivers for the card
Ndiswrapper deb files.

Step One.
Download the latest ubuntu live cd, and burn or use unetbootin to install it to a usb stick.

Step Two.
Download the windows wireless drivers for your card. Extract the file and find the 'Drivers' folder. It should contain three files, *.sys, *.inf, and *.cat. Those three are all you need. Copy them to a folder on the USB Key called 'drivers'.

Step Three.
Download the ndiswrapper deb files.
Ndiswrapper is a linux utility to wrap windows drivers up in linux code so they can be used on linux. It may be installed already on your Live CD. Best to get the .deb files (ubuntu install files) just in case.
You will need to download ndiswrapper-common, ndiswrapper-utils, and ndisgtk. Copy the .deb files into the 'drivers' folder on your USB Key.

Step Four.
Boot the Live CD. Mount your USB key.

Step Five.
Make sure that no ndiswrapper installation is hanging about already by running these commands in a terminal window:

sudo modprobe -r ndiswrapper
sudo ndiswrapper -r bcmwl5
sudo apt-get remove ndiswrapper-utils-1.9
sudo rm -r /etc/ndiswrapper/
sudo rm -r /etc/modprobe.d/ndiswrapper

Step Six.
Install ndiswrapper.
Open a terminal window, and navigate to your usb key 'drivers' directory. For instance:

cd /media/disk/drivers

Then run these commands [WARNING make sure the file names match up. So, if you have downloaded a more up to date version of these, change the file names. Run the 'ls' command to check the full filenames]:

sudo dpkg -i ./ndiswrapper-common_1.50-1ubuntu1_all.deb
sudo dpkg -i ./ndiswrapper-utils-1.9_1.50-1ubuntu1_i386.deb
sudo dpkg -i ./ndisgtk_0.8.3-1_i386.deb

The './' before the filename just tells linux that the file that comes next is in the current folder.

Step Seven.
Run ndiswrapper from the terminal using this command:

sudo ndisgtk

You then use the gui that pops up to locate the *.inf file for the appropriate driver. This is the file you copied in Step Two above.

Step Eight.
At this stage you may think you have managed to get wireless functioning, after all there is a nice box on the screen saying 'Hardware Detected: Yes'. Oh, you poor naive fool. The chances are that the b43 driver module is still hogging the wireless card. To check this run in a terminal:

sudo lshw -C network 

and check for driver=b43... instead of driver=ndis...
If that is the case run these commands in terminal:

sudo rmmod b43
sudo rmmod b44
sudo rmmod b43legacy
sudo rmmod wl
sudo rmmod ssb
sudo rmmod ndiswrapper
sudo modprobe ndiswrapper
sudo modprobe ssb
sudo modprobe b44 

You then run the:

sudo lshw -C network 

command again, and the b43 should have changed to ndis...

Step Nine.
Log onto your wireless network using network manager.

Step Ten.
Install b43-fwcutter.
Open a terminal window and type:

sudo apt-get install b43-fwcutter

'apt-get' is an ubuntu command to download a piece of software from the ubuntu servers. The install option installs the software once it has been downloaded. The 'b43-fwcutter' program is a utility to get the firmware that is the holy grail of this post. As part of the installation procedure you will be asked to agree to download and install the firmware. Say yes. If you panic and say no, then rerunning the above command will not work. Instead you have to run:

sudo dpkg-reconfigure b43-fwcutter

Step Eleven.
If you now look in /lib/firmware/ you will find the b43 folder referred to in my previous post. You can just copy the contents of that folder onto your usb stick and use them in the way described in said post.

Step Twelve.
(This is the important bit)
Save the b43 folder and it's contents somewhere safe. You will reuse this everytime you want to install linux or boot a Live CD on your machine. It is really easy - it is a tiny directory. It p7zips to 40k. But remember - do not email to anyone that needs it and can't be arsed going through the previous eleven steps, because that would be wrong.

Broadcom Firmware on Live CD

I use linksys wmp54gs wireless cards on my desktop and server machines. I want to try a linux distribution. I download a Live CD and boot the machine. I get crap screen resolution and no internet connection. There is no obvious reason why this is the case.

It turns out, after much googling, that my wireless cards use a chipset made by broadcom. Linux is supposed to have the drivers for this chipset built in. So what gives?

Well, it turns out that it you need TWO pieces of software to get this card working. You need the driver which, as with more mainstream operating systems, sits between the OS and the hardware. There is indeed an open source version of this which is bundled into the linux OS (or kernel). However, you ALSO need the firmware. This is code which runs on the wireless card itself. There is no open source firmware bundled into the linux kernel.

If one is being charitible, one would say that modern network cards are actually mini computers in their own right, and therefore need their own software loaded onto them. If one was feeling cynical one would say that the manufacturers are a bunch of bastards who value obfuscation of function over ease of use. After all, if you try to reverse engineer a network card missing its firmware you are not going to get very far.

Still if you wanted to get a hold of broadcom firmware, it is not difficult. They give it away. They just do not allow anyone else to give it away. With Windows, for instance, all of this is transparent because the driver CD you got or the driver you downloaded comes with the firmware in it. With linux, however, it is a problem because Broadcom will not allow any linux distribution to put the firmware on the CD. Because they are gits.

The solution is to download the firmware once you have booted the CD. Which is a great idea. Oh, except for that rare situation were you do not have an internet connection because your fucking wireless connection is not working. Welcome to the chicken and egg dilemma. You can't get your internet connection working until you get your internet connection working.

With a Windows PC you would, at this point, slip in the driver CD and load up the necessary drivers/firmware from that. No linux drivers on the CD though. Bugger. The windows alternative to a driver CD would be to download the drivers from broadcom on some other machine and move them by USB (or whatever) to the wireless-less machine.

I should point out at this stage that there is a webpage which tries to explain all this. It is a master piece of how not to get across information to someone who just cannot get a god damned wireless card to work. The headline story - that firmware is independent of the drivers - is halfway down the fucking page. The first sentence of the whole page reads "The b43 drivers (bcm43xx in mainline kernels, b43 and b43legacy in wireless-2.6 and 2.6.24 and later) are drivers for the 802.11 B/G family of wireless chips Broadcom produces." In terms of communication, it just goes downhill from there. I expect more from the number two google search result for "linux wireless broadcom".

What I therefore now present is a way to load the firmware onto a running Live CD.

Step Zero.
You need the firmware files. You can get them one of four ways. You can use a PC which already has a working wireless connection in Linux. See above for the amusing catch-22-ness of this solution. Alternatively you can temporarily use windows drivers to at least get online and download them in Linux, or you could use a virtual machine running on a PC with some other OS connected to the internet, or you can use a wired connection. What you could NOT do is leave a comment here asking for a zip of the extracted firmware files, because I am not allowed to distribute them and could not email them to you in a helpful manner. I will deal with using windows drivers and virtual machines in another post, so lets just assume you have somehow got the firmware files installed on your running PC.

Step One.
Get a USB key. Make a directory on the key called, firmware.
I talk a lot about Live CD images above, but really I normally use unetbootin to put the Live CD on a USB key. There should be room on the key to put the firmware on afterwards, it is not that big. You could also partition the key and put the firmware in a different partition to the Live CD image, which would let you swap around Live CD images without having to redo the first few steps here. Partitioning is a whole other topic though.

Step Two.
Copy the folder /lib/firmware/b43 to the usb key firmware directory.
All the linux firmware is kept in the /lib/firmware directory. I understand that some distributions keep the firmware somewhere else. If you have one of those I would recommend trying to find out where your /lib/firmware directory is.

Step Three.
Boot the Live CD (or USB, you know what I mean).
Mount your USB key. If using a sensible distribution, this is as simple as plugging it in. If not you will have to acquaint yourself with the contents of the /dev/ and /media/ directories and the mount command.

Step Four.
On the assumption that your usb key has been mounted to /media/disk, which mine invariably is, you can then just run the following commands in a terminal window:

sudo mkdir /lib/firmware/b43

This [m]a[k]es a folder (or [dir]ectory) in your local /lib/firmware/ folder ready for the firmware. Because this command affects the system area of linux the [s]uper[u]ser (or root) needs to [do] this command.

Step Five.

sudo cp /media/disk/firmware/*.* /lib/firmware/b43/

This copies the firmware file from your USB key to the local system. Note the [/disk/] part of the command - if your USB key mounts to somewhere else you need to change that.

Step Six.

sudo rmmod b43

This shutsdown the wireless driver. Techically it [r]e[m]oves the broadcom driver [mod]ule 'b43'. For these purposes a module is something which deals with hardware and could be in the kernel, but is kept out. It can be loaded or shutdown at will - think of it as a running program.

Step Seven.

sudo modprobe b43

This runs the wireless driver again. This time it will find the b43 folder in /lib/firmware/ and load the files from it onto the card. Assuming this works, you can then configure your internet connection using your usual Live CD network manager.