Installation

First, we’ll need to install buildout-starter which will automate everything for us. If you’re on a Linux variant or on OSX, make sure that pip or easy_install as well as Python are installed on your machine. On Windows, naturally it’s a bit harder, and you’ll have to install from source to get things rolling.

On Unix/Linux/OSX, either run this:

sudo pip install buildout-starter

…or this:

sudo easy_install buildout-starter

to install buildout-starter on your machine.

Now that it’s hopefully installed, we’ll be able to quickly throw together a project to generate a simple Python script.

A Bare-Bones Python Project

To generate a bare-bones Python project, simply run this from your favorite terminal:

buildout-start myprojectname

A new Buildout-ready project will be generated for you in the myprojectname directory.

Git Repository Generation

If you have Git installed and you’d like to automate the creation of a Git repository and a default .gitignore file, you can pass --git as a paramater to buildout-start like this:

buildout-start --git myprojectname

That will create your project as well as initialize a Git repository in it, saving you a few steps. It also creates a .gitignore file as mentioned above, ignoring all project build folders.

Eclipse PyDev Integration/Support

If you’re working in Eclipse with PyDev, you can also enable PyDev support at project creation time by passing the --pydev flag:

buildout-start --pydev myprojectname

This will generate an Eclipse .project and .pydevproject file in your project’s base directory, ready to integrate with Eclipse. Don’t forget to run bin/buildout after changing dependencies for these files to be updated with the right paths to their corresponding eggs.

IPython Shell Support

If you’re like me and prefer using the IPython shell instead of the default Python shell, as it provides many more features, you can easily add this to your project’s configuration at project creation time by passing the --ipython flag:

buildout-start --ipython myprojectname

In addition to the bin/python interpreter generated by default, you’ll also now have one at bin/ipython which, unsurprisingly, points to an IPython shell for your project.

Django Project Generation

buildout-starter also features Django project generation, which saves even more time in configuration. Simply pass the --django flag to the script to generate a Django project as opposed to a bare-bones Python project:

buildout-start --django myproject

This will create everything needed for Django project development. We’ll discuss this a bit more in the next part of the tutorial.

Custom Python-safe Package Names

If your project name contains any non-alphanumeric characters, you’ll quickly realize that buildout-starter sanitizes them to get rid of non-Python identifier characters. Hyphens are converted to underscores, but everything else is wiped out. If you’d like to specify a custom sanitized project name, you can do so by passing the -p or --package-name flag with a sanitized project name:

buildout-start -p myproject my-project

By default, a project created with the name my-project would have its name sanitized to my_project. Since we don’t want that to happen (we’d rather get rid of the hyphen/underscore altogether), we pass the -p flag with a value of myproject to specify that we want the package name to be myproject instead of the generated my_project.

Mix and Match Flags

All flags specified above can be mixed and matched to generate a project as needed:

buildout-start -p myproject --django --ipython --pydev --git my-project

This will generate a project named my-project with a package name of myproject. The project will be a Django project, with PyDev support, and an IPython interpreter. Additionally, a Git repository will be initialized in the project directory. Awesome!

In the next tutorial, we’ll discuss how to make and work with a simple Python project.

First, make sure you’ve installed Faenza as root and that the command ls /usr/share/icons/Faenza doesn’t report a missing directory. Next, we’ll create directories to make sure that both sides have the right folders. This only needs to be done once:

$ sudo mkdir /usr/share/icons/elementary/apps/{16,22,24,32,48,64,96,128,scalable}

The above command might generate errors due to pre-existent directories, but that’s not a problem, we just want to make sure that they’re there for this next step. We’ll now create symbolic links to the icons, to save a little space on disk and avoid duplication of data:

$ for size in 16 22 24 32 48 64 96 ; do 
    sudo ln -s /usr/share/icons/{Faenza,elementary}/apps/$size/skype.png
done
$ sudo ln -s /usr/share/icons/{Faenza,elementary}/apps/scalable/skype.svg

Note the last line, which ends in svg, this is a scalable SVG vector rather than a baked PNG image.

Finally, we’ll rebuild GNOME’s icon cache, so that our theme will begin using the icons right away:

$ sudo gtk-update-icon-cache -f /usr/share/icons/elementary

With that, we’re all done and you should see your beautiful new icons. You might have to restart programs for things to start working as expected, but otherwise, everything should be in proper order

For my purposes, I wanted to back up my entire music library, which is about 35 gigabytes of data. Due to the fact that Amazon doesn’t store folder structures, we’ll need to create archives of what we’d like to store. We’ll do that and split our archive into 200MB blocks out of convenience. I’m not currently aware of any per-file maximum size on Glacier, but it’s much easier to retry a 200MB upload rather than a 35GB one. Plus, this will make it much easier to script our uploads in a way that makes it easy to validate that our uploads completed properly. To zip up our music library, we’ll use tar and split, standard Linux utilities. I’ll be applying GZip compression to my tar archive, though this is not strictly necessary or even beneficial in our case, since most music files are already compressed using much more advanced algorithms than standard compression methods.

$ BACKUP_TIME="$(date +%Y%m%d%H%M%S)"
$ tar cvzf - ~/Music | split --bytes=200MB - "music.backup.$BACKUP_TIME.tar.gz."

What this will do is create a tar.gz archive split every 200MB into files looking like "music.backup.20130120120503.tar.gz.aa". The date is generated before we do any real work, and the aa suffix will change on the archive count, so you’ll have archives ending in aa, ab, ac, etc. If you’re as paranoid as you should be, you’d now encrypt these archive using a GPG key, but that’s outside of the scope of this tutorial for now.

Now that we have our data, we’ll use a Python script library called glacier-cmd to upload our files and perform other operations on our Glacier vaults. Let’s get that library installed:

$ sudo apt-get install python-setuptools git
$ git clone git://github.com/uskudnik/amazon-glacier-cmd-interface.git
$ cd amazon-glacier-cmd-interface
$ sudo python setup.py install

Everything should now be installed for us to be able to start our backup process. All we need to do before we start uploading is to setup our configuration file and create our vault. First, create a file at ~/.glacier-cmd filled with the following contents:

[aws]
access_key=YOUR_AWS_ACCESS_KEY
access_secret=YOUR_AWS_ACCESS_SECRET

[glacier]
region=YOUR_AWS_REGION
logfile=~/.glacier-cmd.log
loglevel=INFO
output=print

You’ll need to supply your AWS access/secret keys to proper variables as well as configure the AWS region. I’m in us-west-1, but you may wish to store your information in a different region.

Last step before uploading: create our Glacier vault. Choose a really awesome globally-unique vault name and create it like so:

$ glacier-cmd mkvault "my-super-ridiculously-awesome-longterm-backup-solution"

Provided that it completes properly, we’re in business. Now, let’s get onto the uploading. Since I’ve split my file into 200MB chunks, I’d like to upload them one at a time, moving completed uploads into another folder. For this, I’ve devised a pretty quick find/while loop to find my backup files, and run a series of commands on them.

$ find . -maxdepth 1 -type f -name "music.backup.*.tar.gz.*" | sort | while read file ; do
    echo "Uploading $(basename "$file") to Amazon Glacier."
    glacier-cmd upload --description "$(basename "$file")" \
        my-super-ridiculously-awesome-longterm-backup-solution "$file" && \
        mv "$file" "Completed Backups" 
done

I use a find command to locate all files matching the "music.backup.*.tar.gz" pattern in the current directory only. I pass each found file to the while loop and it makes each file available as the $file variable in the loop. Before each file is uploaded, I echo a status message to let me know which file I’m currently uploading. I then do the actual upload using the glacier-cmd we installed before, setting the description of each uploaded file to the actual filename. If the upload completes without an issue, I then move the uploaded file into the “Completed Backups” folder so that I can know the file was uploaded successfully.

After your upload completes in a few days, you can use other commands of the glacier-cmd utility to query the status of your vault. Remember that inventories take about 4 hours or so, so don’t expect to get a directory listing back so quickly. Welcome to long-term backup with Glacier!

To start, we’ll use Jinja, since I like it a bit better than Django and it seems to be faster and more lightweight. First, ensure that the Jinja2 library is installed on your system. Since I’m on a Debian/Ubuntu derivative, this is as easy as sudo apt-get install python-jinja2. Now, let’s template!

$ python -c "import jinja2 ; print jinja2.Template(\"Hello, World\").render()"
Hello, World

Let’s use a filter to convert the amount of bytes in one megabyte into a more readable value:

$ python -c "import jinja2 ; print jinja.Template(\"{{ bytes|filesizeformat }}\").render(bytes=\"1500000\")"
1.5 MB

Due to an issue in Jinja2 which hasn’t been largely released yet (as of 2012-01-16), the filesizeformat filter has an issue which will cause values to render as 0.0 MB instead of the expected result.

Awesome, now onto the same thing in Django. Make sure that Django is installed and continue:

$ python -c "from django.template import Template,Context ; from django.conf import settings ; settings.configure() ; print Template(\"Hello, World\").render(Context())"
Hello, World

As you can see, Django is a lot more verbose to get the same result. In any case, we’ll move on to formatting file sizes:

$ python -c "from django.template import Template,Context ; from django.conf import settings ; settings.configure() ; print Template(\"{{ bytes|filesizeformat }}\").render(Context({\"bytes\":\"1572864\"}))"
1.5MB

These simple examples should allow you to do some pretty rad stuff with command-line templating in Django and Jinja2.

First, there are two different ways of changing options for the trackpad. For now, we’ll default to using the command-line synclient tool in order to play around with values. Simply running synclient will list out all available options in additions to their present values. I like to back this file up before I make changes, so let’s do that now:

$ synclient |& tee ~/Downloads/synclient.backup

Great. Now, let’s get started by setting some values that really should be set by default. When using multiple monitors or even just really wide monitors, trackpad movement is horizontally extremely sensitive but vertically, it’s incredible insensitive. (Meanie.) For this hack, let’s make it permanent because it’ll make everything better anyway and doesn’t really come with too many risks. For some reason, we can’t test this with synclient, but the rest of the hacks, we’ll be able to test just fine from the commandline. Let’s create an Xorg configuration file for the device. Create a new file called /etc/X11/xorg.conf.d/60-apple-magic-trackpad.conf. Open it in your favorite editor and add the following:

Section "InputClass"
    Identifier "Apple Magic Trackpad"
    Driver "synaptics"
    
    MatchUSBID "05ac:030e"
    MatchIsTouchpad "on"

    Option "VertResolution" "75"
    Option "HorizResolution" "75"
EndSection

Unfortunately, you’ll need to restart X in order to see changes, so log out and log back in again and now you’ll see your cursor move much more intuitively in all directions.

Now, let’s get on to the fun stuff.

Fix right-click delay time

I’ve had an issue where, when two-finger clicking (ie: right-clicking), the mouse-up event would trigger too quickly and send a single click, thus instantly selecting the first item in a right-click menu. In my browser, when trying to copy text or to open a link in a new tab, it would automatically select the first item in the right-click mouse, which happened to be “Back” and would send me to the previous page. Not fun. Not fun at all. To fix this, we can tweak a synaptics property called EmulateMidButtonTime. To apply the fix temporarily, do the following:

$ synclient EmulateMidButtonTime=100

Experiment with different values to make sure that you’ve got something that works first, then we’ll add this as an option to the Xorg configuration file mentioned above. Simply add the following line underneath the other Option directives before EndSection:

Option "EmulateMidButtonTime" "100"

Increase Overall Sensitivity

There are many properties that control sensitivity, but for now, we’ll tweak the MinSpeed and the MaxSpeed synaptics properties to increase the sensitivity. First, set the MinSpeed to something higher than it is by default. On my machine, I have this set to 1.75. Set this temporarily using synclient like this:

$ synclient MinSpeed=1.75

Once you have MinSpeed at a value that you like, set MaxSpeed to a value a bit higher than MinSpeed to get the best experience.

$ synclient MaxSpeed=2.0

Finally, we’ll tweak another property that determines how fast the mouse speed will change between MinSpeed and MaxSpeed. Change this using the AccelFactor property:

$ synclient AccelFactor=0.1

Once you’re all set, add these as properties to your Xorg configuration file mentioned above:

Option "MinSpeed" "1.75"
Option "MaxSpeed" "2.0"
Option "AccelFactor" "0.1"

Increase/Flip Vertical and Horizontal Scroll Sensitivity

Tweaking the VertScrollDelta and HorizScrollDelta properties will control how fast you scroll. If you set these to negative values, you’ll also get what’s known as natural scrolling in OSX, or inverted scrolling. This will mean that as you drag two fingers up on the trackpad, you’ll scroll down, rather than up. In any case, the standard scrolling is too slow for me, so basically set these properties to positive values if you’re interested in increasing sensitivity without flipping axes:

$ synclient VertScrollDelta=-100
$ synclient HorizScrollDelta=-100

When you’re happy, again, just add these options to your Xorg configuration file before EndSection:

Option "VertScrollDelta" "-100"
Option "HorizScrollDelta" "-100"

Conclusion

In the end, my /etc/X11/xorg.conf.d/60-apple-magic-trackpad.conf file looks like this:

# Configuration for fine-tuning only the Apple Magic Trackpad.
Section "InputClass"
    Identifier "Apple Magic Trackpad"
    Driver "synaptics"

    # Match only the Apple Magic Trackpad
    MatchUSBID "05ac:030e"
    MatchIsTouchpad "on"

    # Set resolution tweaks for better response
    Option "VertResolution" "75"
    Option "HorizResolution" "75"

    # Set a timeout for multi finger click so accidental double-clicks don't
    # happen when right clicking and other gestures
    Option "EmulateMidButtonTime" "100"

    # Increase sensitivity
    Option "MinSpeed" "1.75"
    Option "MaxSpeed" "2.00"
    Option "AccelFactor" "0.1"

    # Scrolling   
    Option "VertScrollDelta" "-100"
    Option "HorizScrollDelta" "-100"
EndSection

Enjoy!

I just recently built a brand new machine and noticed that I wasn’t seeing my Bluetooth chip. After a bunch of digging, I found that my Broadcom combo chip which came with my ASUS Maximus V motherboard hosted both a BCM43228 WiFi module and a BCM20702A0 Bluetooth module. Stranger still is that the Bluetooth chip is actually an embedded USB device running on the PCI port.

In any case, due to Ubuntu/upstream kernel backports policy, it doesn’t look like a fix will be backported down to current versions of the Linux kernel and it seems that this patch won’t be included till kernel 3.8, which is a long way away as I sit here typing on kernel 3.2. After a bunch of hacking, I finally came up with a way to activate the card and use it, and have also came up with a DKMS module for the patch so that kernel updates won’t break the patch. This may void your warranty and I accept no responsibility for anything, at all, ever. This is written for Debian and Ubuntu derivatives, but may work on other distributions.

Before doing anything, verify that you have the same card as me before you go through any of this madness. Make sure that if you run lsusb | grep "0b05:e042", you see some output. If you don’t, you’re don’t have the same card as me and this fix won’t help you at all.

First, download your build environment for building the Linux kernel.

sudo apt-get install build-essential linux-headers-$(uname -r)
apt-get source linux-source 3.2.0

Don’t run that second line as root. Note that I didn’t write sudo apt-get source linux-source-3.2.0. I wrote apt-get source linux-3.2.0 and I meant it. It’s not a typo.

Now, cd into your new kernel source directory: ./linux-source-3.2.0. We’re going to manually patch the btusb driver in order to enable support for our card. Open up ./drivers/bluetooth/btusb.c in your favorite editor and find a line that looks like this:

/* Broadcom BCM20702A0 */

Immediately underneath that line, add the following line:

{ USB_DEVICE(0x0b05, 0x17b5) }

This will match your Bluetooth card’s hardware id.

Now, download the Bash scripts and DKMS configuration file from this Gist and put them in your current Linux kernel source directory. Make sure to chmod +x *.sh to enable the Bash scripts to run.

Finally, copy over everything in this directory to /usr/src/btusb-0.6. We’ll now test building the module. If everything went correctly, the following two commands will build and install the kernel module, restarting Bluetooth in the process, allowing you to see your beautiful Bluetooth card:

sudo dkms build -m btusb -v 0.6
sudo dkms install -m btusb -v 0.6

Now, enjoy your Bluetooth chip. Seriously.

If you’ve been following the blog, you probably noticed that I recently had a lot of issues with Bluetooth on my MacBook Pro running Ubuntu, and then had them resolved by an awesome commenter. Apparently, if you disable Bluetooth coexistence protection in the B43 driver, then Bluetooth will be able to coexist with WiFi. I have no idea how this makes sense, so don’t ask

I demonstrated how to do this with modprobe:

# remove b43
sudo modprobe -r b43
# reinsert b43, with the right settings
sudo modprobe b43 btcoex=0

Unfortunately, this doesn’t work permanently, as whenever you reboot, the B43 driver is loaded with the evil Bluetooth coexistence setting enabled (again, this means that Bluetooth will not work). Thus, we need a permanent solution! Pop open your favorite text editor as root and edit /etc/modprobe.d/options and append the following line:

options b43 btcoex=0

Voila! Go ahead and reboot to test your settings. No more modprobing every time you boot!

Of course, I had to come up with rational justifications by which to actually allow myself to in any way support Apple:

1. The deplorable state of notebook hardware and build quality. Quite honestly, it’s a joke these days trying to find some awesome notebook hardware to run Linux on. There’s System76 and the new Lenovo notebooks, but does anything really even come close in comparison to a MacBook Pro? Stylistically and functionally, this thing is brilliant, bar none.
2. My work required me to have a super high-powered notebook for travel. At the time of writing, I’m getting ready for a business trip and after a number of bad experiences (read: terrible performance) trying to run TeamViewer, Skype, and Eclipse at once, my $500 Gateway notebook had reached the outer limits of its capabilities. It was time to go extreme.
3. I didn’t buy it directly from Apple. I bought it through a reseller to try and take away the hit to my conscience. I’m kind of idealist when it comes to the way software should be done and I couldn’t disagree more with Apple’s closed policy.

With all of these excuses rationalizations in hand, I picked this thing up on a trip down to San Diego. I checked with a friend about compatibility, as he had already done much of the footwork of installing Ubuntu on a MacBook Pro. (Ok, he installed Mint but at the end of the day, Mint’s still just a Ubuntu spin.) Armed with a little bit of information and quite a bit of willpower, I set out to accomplish the unthinkable: installing an open source operating system on a machine made for the highest levels of corporate, proprietary evil. It was time to begin.

Hardware

For the record, I got a MacBook Pro with the following specs:

Since I was already going all out, I thought I’d just go all the way with it and manually upgrade the RAM and hard disk:

If you haven’t heard of the new hybrid drives, you should really check them out. Essentially, you have a fast 7200RPM traditional hard disk drive with an integrated solid state drive to make your writes and reads that much faster. They’re not pure SSD fast, but it’s a heck of a lot faster than a 5400RPM drive or a regular 7200RPM hard disk drive. I have definitely noticed a striking performance increase. Again, it’s not an SSD, but it’s closer, without compromising on storage space.

I purchased one with a glossy screen because I like the design; it looks beautiful, but is nearly impossible to work on. The glare is so bad, you might as well be programming in front of a mirror at times. The alternative, buying one with a matte screen, was not really an option for me, as the matte displays come with an ugly greyish border around the screen, rather than a sleek black border:

It looks… terrible. Whoever thought of putting a grey border around the screen, when black looks SO cool? On the flip side of things, look at the glare from the glossy screen! AM I TAKING CRAZY PILLS?!?

My solution was to buy one of these, an anti-glare screen cover to allow me to keep my beautiful looking display design AND have a matte display:

Winning! The cover is kind of a pain to put on, but it works great once you get it just right. (If you have any dust anywhere in your home, it will magically stick to your screen while trying to put it on, forming bubbles: not good.) My wife is a total screen protector application master, and we were able to get it on with just about no spots! There’s a video on how to do it here.

Putting the RAM in wasn’t so hard, though I was a bit paranoid as you can’t “undo” bricking hardware. It went along really nicely and was pretty straightforward.

Installing the hard drive was a little more difficult, but again, not something that was a major deal-breaker. I employed some l337 hacks to copy over the contents of the preexisting drive, then installed it and it worked like a champ.

Software/Configuration

Though I thought that hardware would be the main uncharted territory, configuring the operating systems, bootloader, and software was by far the most time consuming. It took me about a week straight to get this thing up to speed. I installed Linux Mint 12 at least once and Ubuntu 11.10 three times, I think, but in the end, I got it working.

The biggest initial barrier to getting this thing running was the bootloader. Since Apple uses something called EFI as a bootloader instead of BIOS, which is what you’re used to, getting things to install entails getting a better bootloader than the locked-down version that Apple has installed by default, which doesn’t let you do anything “dangerous” like have the ability to install other operating systems

What we need is a bootloader which will let us run OSX as well as boot into Linux and Windows if we want to. rEFIt “fits” the bill, as it’s the main way of being able to do this. Unfortunately, due to changes in Mac’s new OSX Lion (10.7.x) operating system, rEFIt isn’t so easy to install anymore. I tried to auto-install it and it didn’t show up at all. I then tried to run one of their scripts to enable it always, and it still didn’t show up. Then I noticed that it wasn’t letting me log into OSX anymore. Great. Also, before I tried any of this, I realized that OSX wouldn’t let me use their “Disk Utility” program to resize my OSX partition. As I’m not really planning on using OSX, this was kind of a bummer.

After I schlepped to the Apple Store and met with one of their “geniuses,” I was informed that by default, OSX Lion comes with another “Recovery Partition” which is hidden from Disk Utility, which was causing my disk resize operations to fail. Again, great. This is what you get when dealing with Apple. I had him reinstall Lion, as it doesn’t come with any install media whatsoever, as well as resize my OSX partition to be 100GB. He resized it to be 1000⁴ bytes, which actually turns out to be around 93GB, but whatever. I almost couldn’t care less about OSX at this point. In any case, major fail in assuming that a kilobyte is 1000 bytes, etc.)

I came home, made backups and tried to make a restore CD, though that didn’t really work, and tried again. I installed rEFIt manually and things worked great. I simply copied over the efi/ folder in the tarball to the root of my OSX partition, then ran the /efi/refit/enable.sh script to enable it (as root of course). I rebooted and, lo and behold, rEFIt!

Awesomeness! Now it was time to install Linux. Following Scott’s guide to installing Linux on a MacBook Pro, I installed Linux Mint 12 (amd64) to a 500GB ext4 partition. I also created a 4GB swap partition, and made sure to install the bootloader not to /dev/sda but instead to my Linux partition, /dev/sda4. Oh, it’s also important to note that in order to do this, I had to both create a CD/DVD of the install disc in addition to a USB startup disk with the same OS. Plug in the USB stick, insert the CD, and then try installing. Some weird bug, but it wasn’t too hard to overlook.

Linux Mint installed without a hitch, though I was noticing some glitchiness in the UI, but I assumed it’d go away when running from the hard disk. It booted up great, and then things started quickly going downhill. Every so often, GNOME Shell or the compositor would flat-out restart. There were other glitchy things about it, but I eventually decided to install Ubuntu 11.10 stock to try and get a better experience.

Ubuntu installed great and Unity, at least for a couple of minutes, was a sight for sore eyes. Things worked a lot better. I compiled the BCM4331 wireless driver and tried to do some major tweaks with the fglrx driver, then figured it’d probably be better to start from scratch. So I installed Ubuntu again.

Having been through the process a couple times before, it got easier with time. Multitouch worked out of the box with Unity, and I could three-finger pinch to maximize/restore windows and three-finger drag to move windows around. Nice!

As noted elsewhere, the main issue with running Linux on 8,X MacBook Pros is wireless driver support. You either have to wrap the Windows driver with ndiswrapper or compile the current open source driver yourself. I opted for the latter, and it wasn’t so hard to compile and install. It more or less works great, but there are two outstanding issues with it:

1. It stays connected to the access point, but loses internet capabilities intermittently. This really stinks for long downloads and Skype calls.
2. It hardcore interferes with Bluetooth. High-bandwidth devices like headphones can hardly connect and if you can actually get them to, they won’t be clear and consistent. You also can’t scan for new devices while running the wireless driver. (I lost 4 days of my life to this, more later.)

Apart from those issues, there are really only a few things that don’t work as planned:

1. The trackpad dies every so often. You can still do multi-finger gestures, but moving the cursor fails.
2. You can only change screen brightness in OSX.
3. You can’t change trackpad sensitivity.
4. In order for things like animations to look smooth, you need to do this.
5. You desperately need to install a package to control your fans, lest your computer blow up.

Please, before you go any further, download this package and install it if you haven’t already and you’re reading this from a MacBook Pro on Ubuntu. Otherwise, your computer will overheat and blow up. Not a good move, bro.

Compatibility Chart

I figured it’d probably be easier to visualize compatibility with the hardware and software with a nice table describing each item of importance.

In the end, it’s basically awesome running Ubuntu on a MacBook Pro. This thing is wicked fast and a pleasure to code on. I’ve been able to encode 1080p HD video at around 60 frames per second. I can run Windows in VirtualBox wicked fast. Hopefully, I’ll be able to find the time to follow up on this post with an installation guide.

Essentially, what it boils down to is this: the b43 Linux driver that you’ve compiled and installed interferes hardcore with the adjacent Bluetooth chip on your MacBook.

Let’s do a little test to demonstrate. While connected to a WiFi network with b43, put a Bluetooth device into pairing mode near your machine. Make sure the bluez package is installed. Next, run the following:

$ hcitool scan
Scanning...

You’ll probably see it say Scanning... and then… nothing. It won’t see your device. Period.

Let’s continue with our experiment. Unload the b43 module with sudo rmmod b43. Your internet will go down if you’re on WiFi. Now, run hcitool scan again.

$ hcitool scan
Scanning...
    XX:XX:XX:XX:XX:XX    Nexus One

Aha! Found you! So, it seems that the problem is with the driver itself. This is kind of a bummer, to say the least, but hopefully they’ll have it patched soon. Until then, sudo modprobe b43 and continue on, weary warrior.

For the record and for Google, I’m running a 2011 MacBook Pro 8,3 with Ubuntu 11.10 Oneiric Ocelot 64bit/amd64.

Update: A Working Workaround!

As noted by Benoit in the comments below, you can actually get things working with a little workaround. First, unload the b43 driver from the kernel:

$ sudo rmmod b43

Next, reload the module, turning Bluetooth coexistence support off:

$ sudo modprobe b43 btcoex=0

As counterintuitive as it seems, it works! Hooray! I’m now able to listen to music with my Bluetooth headphones and use the built in B4331 wireless card in my MacBook at the same time!!! The only issue I’ve encountered is that when you’re spiking and getting really high upload/download rates, you’ll notice that Bluetooth audio skips a bit. Luckily, this is a pretty minimal problem and doesn’t prevent you from using your Bluetooth or your B4331 WiFi card in your MacBook Pro.