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.

1. Country objects stored in the database.
2. Territory objects stored in the database.
3. Each country has 0 or more territories.
4. View functions to get territories by country, all territories, all countries, or a country.
5. Territories have abbreviations and names.
6. Countries have ISO 3166-1 Alpha 2 Names (2 digit unique abbreviations), ISO 3166-1 Alpha 3 names (3 digit unique abbreviations), and each uses its country code number as its id.

This opens up a lot of possibilities. Simply add 'locality' to your INSTALLED_APPS in your settings.py file, run syncdb to install the models and the initial data, and off you go. You can tie your own custom classes to countries and territories like any other Django object.

It’s really simple, but it’s really refreshing to finally be able to do things in a way that makes sense. The module is available on PyPI, so you can integrate it into your build process with `setuptools`.

I recently had an interesting scenario where I needed to run Wowza as a non-root user in order to keep file permissions the same across a number of servers, as I was recording video on one server and serving it over VOD on another.

Unix Permissions have always seriously confused me and vexed me to no end, but I found that the actual Wowza Media Server User’s Guide gives instructions on how to run the server as non-root. For a given user user with a primary group of user:

chown user:user /usr/local/WowzaMediaServer
chown -R user:user /usr/local/WowzaMediaServer-2.2.4
chmod -R 775 /usr/local/WowzaMediaServer-2.2.4
rm -f /var/run/WowzaMediaServer.lock /var/run/WowzaMediaServer.pid

If you’re a l33t h4ck3r like me, you can combine the last line like:

rm -f /var/run/WowzaMediaServer.{lock,pid}

…but only if you’re using Bash.

After you do this, modify both /usr/local/WowzaMediaServer/bin/startup.sh and /usr/local/WowzaMediaServer/bin/wms.sh to prepend sudo -u user to the 24th (or last) line. Basically, for the line that starts with $_EXECJAVA ..., it should now start with sudo -u user $_EXECJAVA ....

I’ve also put the Wowza docs on my Google Docs account so as to make them a lot easier to access. Find them below:

• Wowza Media Server User’s Guide
• Wowza Media Server Configuration Reference
• Wowza Media Server FMS-to-Wowza API Mapping
• Wowza Media Server Server-Side API Reference

Just posted an awesome new little tutorial on TerminalLinux.org on getting your awesome on with the X clipboard on your Linux machine. Automate and mass-transform your clipboard contents from your handy-dandy terminal!

# insert a tab at the beginning of each line of the contents of the clipboard
xclip -o | sed 's:^:\t:g' | xclip -selection clipboard

Introduction

At the very core of this topic is the question: “what is intellectual property?” What is patentable? Can you exclusively own an idea? Can you get a patent on a natural process? For example, if you invent a mathematical formula, can you “own” that idea and prevent others from using it? Can you write a symphony in 3/4 time and patent the concept of 3/4 time and own the exclusive rights to it? It sounds somewhat ridiculous, but at its core, the US Patent System has come to this point. Last time I checked, there was a big court case going down in the Supreme Court where eHarmony is attempting to patent a mathematical formula through which they “match” people. At first glimpse, this doesn’t seem to be too big of a deal, however, if you boil it down to its essential elements, it’s huge and unprecedented.

Mathematics as Intellectual Property

Imagine if you were Issac Newton, way back when, and you were able to effectively patent your latest and greatest discovery: gravity. Or, if you were Albert Einstein and you filed a patent on the theory of relativity. Henceforth, you would have a precedent by which to sue any individual or corporation which incorporated or benefited from your “idea.” Scared yet? Again, from far off, it doesn’t seem like too bad of a thing, but at its core, your rights are being violated. It’s one thing to say that you can patent a process by which you can quickly harvest and shear corn, but it’s something entirely different to say that you can patent math, something that isn’t invented so much as discovered. Math is natural law, and therefore cannot be patented.

Media as Intellectual Property

Let’s throw in another use case. Do you own any DVDs? Rather, do you actually own any of the DVDs you’ve purchased? Most DVDs are encrypted with something called CSS and are locked to only run within a specific region. Take your US-bought DVD to Europe and it might not play in a DVD player over there. Again, who owns your DVDs? Is it you or is it the company that is leasing their intellectual property to you? Why are they encrypting and locking down what is ostensibly your property? The claim is made that it’s to “protect intellectual property” via DRM, which, of course, stands for digital rights management: the means by which companies manage, restrict, and control your rights to digital media. In short, the answer is that no, you don’t really own DVDs. You are free to do with them what you’d like, so long as the owner is okay with it.

Companies use DRM to “protect their intellectual property.” However, this doesn’t make too much sense. All DRM technologies have been broken into, it’s only a matter of time. Moreover, you, the average user, aren’t going to rip your DVD library and sell copies or distribute it for free. You just want to own your content and to be free to do what you’d like with it.

Facebook as Intellectual Property

Think that you own and have rights over what you upload to Facebook? I hate to be a downer, but when it really comes down to it, you might not. Hey, I’m guilty of it too, but at the very least, I’m aware. On one hand, I use Facebook to keep in touch and to publish photos and status updates, but at its core, it’s a big problem in that Facebook may own everything I publish. With this, we have introduced the problem of intellectual property rights concerning Software as a Service.

Next Page »

Simply put, this means you can connect to and from your phone over SSH. Imagine being able to wirelessly push files from your phone over your home network. Imagine being able to tunnel VNC over SSH from your home computer to your phone so you can securely control your home computer even though you’re a hundred miles away. Yeah, pretty cool, right? Let’s get to it.

First things first. You must be running CyanogenMod 7 or later to do this. If you’re not, this isn’t the post for you. Move along. Second, this is going to take a little terminal trickery, so if you’re averse to working in a shell, go take some Pepto Bismol and come back. Also, if you’re new to SSH, you can do this, but you should probably read this book so you can understand how SSH works and how to set it up on your machine. Setting up a SSH server and client on your computer is way outside the scope here.

Let’s start by talking briefly about SSH security, specifically about using SSH keys rather than passwords. Keys are far more secure than passwords, and so we’re going to set up a key-based login system here. If you want to use passwords instead of keys, ignore the steps of this tutorial that read like “copy your key to …” and so and and so forth. DropBear can handle both passwords and keyfiles (so long as they’re generated by the DropBear key client), so you should be good either way. An important security problem to note up front is that DropBear currently does NOT support key passphrases! This may not seem like too big of a deal, but here’s what you need to know: if someone obtains access to your phone and your phone uses keys to authenticate with your machine(s), the person with your phone will have instant access to all devices which approve of your phone’s key. Let’s set up a scenario in which this would really, really suck:

Bob’s got a kickin-rad Android phone which is running CM7. He follows this tutorial like a true hacker and makes it so that he can connect to 3 public-facing computers over SSH using keys for authentication. Since DropBear keys don’t support passwords, Bob can literally connect to any of these computers without typing in any passwords. Bob likes this.

Bob goes to sleep that night, unaware that Jack Bauer is about to break into his house and steal his phone. Jack Bauer does so. Jack Bauer takes Bob’s phone. Jack Bauer now has complete access to those 3 computers. Jack Bauer connects to each computer and runs the following command: “rm -fr /home/$USER/”. This deletes the music, pictures, videos, and documents from all of the computers. Jack Bauer has pwned Bob’s computers.

Bob wakes up, but it’s too late.

Don’t let what happened to Bob happen to you. If you’re going to use DropBear keys, know what you’re getting yourself into. Guard your phone like Jack Bauer is going to break into your house at any given moment.

That being said, here we go. Make sure your phone is able to debug over USB, plug it in, and make sure it’s connected by running `adb devices`. If you can see your device’s id listed out, you’re ready to go. If you don’t know what “adb” is or how to install it, let me Google that for you. Next, run `adb remount`, then connect to your device using `adb shell`. You’ll now be dropped into a shell on the actual Android device. (*Note: if you want to do all of this stuff from your actual device, be my guest. It’s just much easier to type on a big physical keyboard in my opinion.) Next, type the following commands in order:

cd /
mkdir /data/dropbear/.ssh
ln -s /data/dropbear/.ssh /data/.ssh

Now, we’ve created an important directory and have also made a symbolic link to it at “/data/.ssh” which is easier and shorter to type than “/data/dropbear/.ssh”. Now, let’s create the server keys for the DropBear server:

dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_host_key
dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key

Cool. So, we created the server keys. Something very, very important to note is that for some reason, DropBear is very picky about file permissions. If the permissions aren’t set right, it will not work. I repeat, it will not work. Let’s take care of that now:

chmod 755 /data/dropbear /data/dropbear/.ssh /data/.ssh
chmod 644 /data/dropbear/dropbear_*_host_key

Ok. Now, we should be able to run our server properly. Now, let’s generate a client key:

dropbearkey -t rsa -f /data/.ssh/id_rsa
dropbearkey -y -f /data/.ssh/id_rsa | grep "^ssh-rsa" > /data/.ssh/id_rsa.pub
cat /data/.ssh/id_rsa.pub > /data/.ssh/authorized_keys
chmod 600 /data/.ssh/authorized_keys

Now, we have a way to identify ourselves to other machines when connecting. Now, let’s add some SSH keys to our device’s authorized keys so they can connect using SSH keys. This is assuming that your SSH key lives at ~/.ssh/id_rsa.pub. First, exit the shell by typing `exit`. Then run `adb push ~/.ssh/id_rsa.pub /sdcard/`. Now, connect to the device again via `adb shell`. Now run the following:

cat /sdcard/id_rsa.pub >> /data/.ssh/authorized_keys
chmod 600 /data/.ssh/authorized_keys
rm -f /sdcard/id_rsa.pub

This added the public key of your machine to the authorized keys of the DropBear server. You’ll now be able to connect to your Android device, after you’ve started the server of course. You can rinse and repeat the above commands to copy more keys to your authorized key file, just remember to set the permissions right or you’ll end up wasting a lot of time like I did.

Now, let’s make it so your machines can connect to your phone properly. Again, get out of the phone’s shell via `exit`, then run `adb pull /data/.ssh/id_rsa.pub .` then `cat /data/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys`. You’re all set.

The final step in all of this is to get your DropBear server working. First, `adb shell` into your phone and run the following:

dropbear -s -g -v

This will start the server in verbose mode (-v), only accepting keyed logins. Otherwise, anyone can connect to your phone as root with no password. Now, try connecting to your phone from another machine via `ssh ip-of-phone`. If you can connect, you’re good to go. Return to the open shell to your phone, run `killall dropbear` to stop the server. We’re going to get it to automatically start on boot, saving you time. Run the following on the phone:

echo -e '#!/system/bin/sh\n\ndropbear -s -g' > /data/local/userinit.sh
chmod +rx /data/local/userinit.sh

Restart your phone, try connecting, and if it works, we’re all done!

Oh, one more thing. If you want to connect from your phone to a computer using the key we generated earlier, run the following:

ssh -i /data/.ssh/id_rsa ip-of-machine

Hit up the comments if you run into any problems.