Thursday, March 31, 2011

elementary OS: T minus 9 hours and counting

if you've been to the elementary OS website lately, you've probably noticed it now consists of a countdown timer:

it looks like it's counting down to midnight (00.00) april 1 (UTC), so I'm guessing that's when elementary OS will finally be released.

I can't wait! with a slick, clean interface and many of the elementary team's apps that I've posted about before, this just might be good enough to replace Ubuntu. I know I'll definitely be checking it out.

Wednesday, March 30, 2011

heimdal 1.4 missing lib/otp/

I was compiling Heimdal kerberos 1.4 on RHEL 5.6 and got the following error:

/usr/bin/ld: cannot open linker script file ./ No such file or directory

After some poking around, it appears that lib/otp/ is missing from the 1.4 source, which is weird since I downloaded it right from the big "Download 1.4" link from their website (, which links to

So, to fix the problem, you can download the missing file right from their git repo, here:

Just place it in heimdal-1.4/lib/otp, and you should be good to go.

So the whole process would look something like this:

tar xvf heimdal-1.4.tar.gz
wget --no-check-certificate -P heimdal-1.4/lib/otp

...and then you can go on with the configure, make, etc. to build it.

Of course if you don't care about OTP (one time password) support, you can just disable this altogether when compiling and not worry about the missing file. Just add the "--disable-otp" flag when running the configure command:

./configure --disable-otp

Thursday, March 24, 2011

AT&T to purchase T-Mobile; corporations: 1 consumers: 0

With the recently announced purchase of T-Mobile USA by AT&T, it's evident that the only winners are going to be AT&T and T-Mobile themselves.

There's nothing good in this for the consumers. T-Mobile is the cheapest out of the four major nationwide carriers in the US. They're definitely cheaper than AT&T. With them gone, US customers will be forced to pay higher rates. AT&T claims that by acquiring T-Mobile they can lower their costs, and supposedly (1) they're going to pass on some of that savings with the customers. Sure they will. When's the last time you heard of a major corporation lowering prices, unless it was forced to by competition? If they can get away with making more money, they're going to do everything in their power to do just that.

And that brings me to my next point: competition. With T-Mobile out of the picture, there's less competition. Somehow or another AT&T is actually claiming there's plenty of competition! (2) What a joke. It doesn't take a PhD in economics to realize that less corporations in a given market = less competition = higher prices.

To top it off, T-Mobile is one of the few US carriers (along with AT&T) using a GSM-based network. Most people probably don't care, but for those who travel and want to use their phone outside the country, the options are already limited, and will be even worse after the merger. So if you want a GSM carrier, guess who that leaves? AT&T. Not only will you have to put up with higher prices, but you'll have to put up with their silliness, like blocking non-Android market apps on Android phones.

Ultimately the consumers are the losers in this deal.

1 "AT&T has promised to spread some of that windfall around"

2 "'The U.S. wireless industry is one of the most fiercely competitive markets in the world and will remain so after this deal'"

Thursday, March 17, 2011

Make free wifi/data calls on your android device

Update: I've blogged more recently on better ways to do this, so you might want to head here instead:  Free wifi/data calls on your smartphone, part 2

Note: this will only allow you to make calls to US numbers, excluding Alaska and Hawaii, as that's all the Whistle Phone service supports. See the last paragraph of this post for alternative options.

  1. Go to, download their software to your desktop, and register for a free account.

  2. Download the CSipSimple app from the android market
    Here's the QR code:
  3. Open CSipSimple, choose the integration you want, then click Add Account. Then scroll down to Generic wizards --> Advanced.

    • Account name: whatever you want

    • Caller ID: your whistle phone number

    • Server:

    • Username: your whistle phone number

    • Password: your whistle phone account password

    • Use TCP: leave unchecked

    • Proxy:
And that should be it. You can now make calls using your Android device's data connection (wifi, 3G, 4G). If you chose to integrate with the native dialer, just make sure to choose the whistle phone account you created. If not, just open up the CSipSimple app to make calls.

For outgoing calls, it seems to take a good while to connect (about 15 seconds), then you have to listen to 10-second ad. Incoming calls seem to go through pretty quickly, though, and neither you nor the calling party has to listen to any ads.

The CSipSimple app mentions lots of other SIP providers, so maybe one of them is free and has better connection times for outgoing calls (perhaps even ad-free), or will even allow you to call different countries for free, but I haven't checked any of the others out yet.

Update: since I posted this, Whistle Phone limited inbound and outbound calls to 20 minutes. you can read more about that here: also, I did take the time to look into the other US SIP providers mentioned in the CSipSimple app, and none of them allows you to make free calls except to users using their service. but if you do hear of a better SIP provider, let me know!

Thursday, March 10, 2011

windows woes

It's days like today that I'm grateful I'm only a minimal Windows user... I decided to reformat my Windows XP virtual machine today, and I've spent half my day installing updates, rebooting, installing more, over and over again. I literally don't think I can count on one hand the number of times I've had to reboot. Which seems crazy to me considering I started out with SP3.

Then I get to deal with the frustration of downloading software that's bundled with other software I don't want. Take Adobe Reader, for example. First of all, it comes bundled with some Mcafee software I don't want. Thankfully that's an easy fix: I just uncheck a checkbox. But then, it tries to force me to install a browser plugin. Not seeing an easy way around that, after some Googling I found this page, where I could download the redistributable installation files, although (unless Adobe Reader's just really big), I'm pretty sure I ended up downloading way more than I needed. As if all that wasn't enough, it configures AdobeARM and Reader_sl to load on startup. I have no idea what they do, but I disabled them.

I'd prefer to use something like Foxit, but Adobe must be getting wise to the mass defections from their bloated software, because they seem to be continually inventing new ways to force you to use their software.

Then I look at my hard drive, and I've already used 10G, just for Windows itself, Forefront security client, vmware vSphere, and MS office. I really don't know how all you windows folks do it. I'm guessing it's because you haven't realized there's anything better out there (which in my opinion constitutes just about anything else) ;)

Well, gotta go. My VM just finished another batch of updates. I need to reboot and do it all over again...

after posting this I realized it's pretty whiney. I probably should have waited until I was less frustrated to post. obviously not all of my complaints in this post even deal with windows itself, and are directed more toward crummy, bloated apps like Adobe Reader. of course, it's still nice that GNU/Linux only makes me reboot for kernel updates, and that it takes up less space :)

Wednesday, March 9, 2011

python's only problem: concurrency

python has its naysayers, but that's what jealousy will do to you :) seriously though, python does have one major issue: concurrent/parallel programming. now I'm no engineer, and I'm sure this is an oversimplification, but three ways of accomplishing this are:

  1. using multiple threads

  2. using multiple processes

  3. event-based programming

the main killer out of these three is trying to do multi-threaded programming in python. the short answer: don't. when Python was designed, it was given the philosophy that people using it should have to worry about as little as possible under the hood. while that's great, the way the python threading library was designed makes it inefficient for CPU-bound tasks. essentially, the more threads you use in python for CPU-bound tasks, the slower your code will be. ironically the problem seems to be even worse on machines with multiple processors. the problem has a name: the Global Interpreter Lock (GIL). you can read more about it here:

there's also a great presentation that explains the problem pretty well if you have time to watch it. I'll put it at the bottom of this post.

then there's the issue of event-based programming. the problem in this arena (in my opinion, of course) is that there are too many choices for event-based programming, and none of them are included in the python standard library, so there's no standard as of yet.

lastly there's multi-process programming, which thankfully is in a better place than the other two. although it's only been fairly recently (within the last couple of years), python now has a multiprocessing module in the standard library. so if you're looking to write some concurrent/parallel code, I'd say start with here before wading through the alternatives that aren't in the standard library:

as the speed of computing becomes increasingly more about multiple processors than faster clock speed, the more important this issue will be. thankfully there's a standard solution (the multiprocessing module) as well as plenty of alternatives, and hopefully in the near future one or two of these alternatives will become standard, if not at least de facto.

here's a page that has links to some resources related to concurrency in python, as well as links to plenty of the afore-mentioned alternatives:

and here's that video I promised:
[ ?posts_id=2243379&dest=-1]

Tuesday, March 8, 2011

Python and MySQL autocommit


If your MySQL database is using the InnoDB engine, commit your changes after database transactions:

Or just turn on autocommit to automatically commit after every database transaction:


So I was using python's MySQLdb module to edit a mysql database, and I noticed that even though python was telling me my modifications were taking place, I wasn't seeing any changes. in addition, when I would log onto the database from something other than python and try to make changes, I would get this error:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Well apparently, the mysqldb module now disables mysql autocommit by default. so now, when I'm done with my transactions to the database, I need to commit my changes by calling the commit() function of the connection object. the connection object is what's returned when you call the MySQLdb.connect() function. I haven't really been using that object in my code other than to create the cursor object, which is what I normally use:

db = MySQLdb.connect(...)
cursor = db.cursor()

But the cursor can access the connection object, which I can then use to commit the changes:


The strange thing with all of this is that I just started noticing this problem, even though according to the MySQLdb module authors, this functionality (disabling autocommit by default) has been in place since version 1.2.0 of the module. but when I look at the package versions of python-mysqldb for Ubuntu (what I'm currently using and have been for a while), it looks like it's been past version 1.2.0 for the last several years:

Maybe this "feature" has just recently made it into Ubuntu's package for this module. or maybe I'm missing something else here. at any rate, at least I know what's going on.

You can see here for more information:

Okay, so apparently what happened is in my other code where I was modifying mysql databases, they used the default engine (MyISAM). the database I was having problems with was using the InnoDB engine, which is a transactional storage engine. this explains why I just now saw this issue.

More information here:

As well as an alternate solution: instead of committing after every transaction, I can turn autocommit on when I'm working with databases using the InnoDB engine, so they'll function just like the rest: