If you’re looking to start a blog to promote your business, or boost your presence on the internet, you’ve probably heard of WordPress.

You may also have heard about the benefits of hosting your own instance of WordPress, but you’re intimidated by the idea of setting up and maintaining your own server, or trusting your business to a shared hosting solution.

What if I told you that I’ve got a solution that’ll let you run your WordPress blog, on your very own server, with automated backups and disaster recover, completely free?

Wait wait! I know it sounds too good to be true, but don’t leave just yet, hear me out…

Amazon AWS Free Tier

First, let me be straight with you. When I say “free” I’m referring to the free tier of Amazon’s virtual computing and storage platform AWS.

This free tier allows you to run their smallest instance free for one year. In practice you actually end up paying them a very small sum (around $0.12 average for me thus far) each month for transfer costs to run a low to medium traffic blog.

After your first year of free usage has expried, it’ll start to cost around $15 per month to keep using the same size instance.

Managed by RightScale

You may be looking at AWS and thinking that setting up your own server, and keeping it running and backed up would be a daunting task, and it can be. That’s where RightScale comes into the picture.

RightScale offers a Free Developer Edition that gives you access to their shared library of ServerTemplates.

In that library is one little gem that I published, expressly for the purpose of running a server that hosts my blog, a few sites for other domains I own, as well as all of the email traffic for my various domains.

In fact, you’re reading this right now from a server running from this ServerTemplate.

Full Disclosure

Before I give you the skinny on how to start using these tools to host a WordPress blog on your own virtual server, a few warnings are in order.

I am using Opscode Chef to configure the server. Chef support is currently in Beta on RightScale, meaning that they do not recommend you use it to configure and manage “Production” servers.

It also means that there can be some hiccups when you’re launching and configuring a server with this ServerTemplate.

So, don’t be surprised if the first time you launch your server, it doesn’t work. Try launching a second time.

Lastly, I can’t take any responsibility for any loss of self esteem, data, productivity, or sanity. You have been warned.

That said, I’m using this server to run the very blog you’re reading, and I haven’t had any significant glitches yet. RightScale is working as we speak to improve their support for Chef and things will only get better from here.

Haven’t scared you off yet? Okay, good.. Here we go..

20 Minute Quickstart

The RightScale management tool, and this ServerTemplate offer all sorts of cool functionality which we can explore later, but if you’re in a hurry to get started here’s all you need to know.

1. Go sign up for an AWS Account
2. Sign up for a RightScale Free Developer Edition
3. Enter your AWS credentials into the RightScale dashboard using these directions
4. Browse to my All-In-One ServerTemplate and click “Import”



5. Click “Add to Deployment”



6. Pick the AWS Cloud closest to you and click “OK”
7. Change the “Instance Type” dropdown to “t1.micro”, and select the “default” Security Group from the dropdown. You can also provide you server a name, then click “Add”



8. Click the “Play” button, provide inputs for the Database Administrator password, Postfix DB password, and EBS volume size, then click “Save and Launch”




And now.. We wait.. Until the instance is up and running..

9. Click on the server’s nickname, then navigate to the “Scripts” tab
10. Run the “rjg_utils::aio_ebs_volume_enable_continuous_backup” operational script to make sure your server is backed up daily
11. Run the “app_wordpress::deploy” operational script to setup WordPress for your domain



12. Navigate to your websites URL (we used http://ec2.ryangeyer.com in this example) and setup your WordPress preferences



13. Start Blogging!

What’s Next?

That’s really all there is to it. As I mentioned the ServerTemplate does a number of other cool things, which you can read about in it’s description.

The best part is that because this ServerTemplate is what I use for my own blog and email hosting duties, you can be sure that I’ll keep it up to date, secure, and be adding features fairly regularly.

Drop me a note

If you followed these directions, or if you’re using this ServerTemplate, or if you’re having trouble, by all means drop me a note in the comments here.

I’ll be happy to answer any questions I can, and I’d love to get a sense for how many people are out there running servers based on this template, it’ll keep me motivated to publish more stuff in the public ServerTemplate library!

As I was clearing out my RSS reader a few days back, I stopped to read a post on the Flickr dev blog about the “new” 640px image size. In the article they lament that they wished they had made “Large” copies of all uploaded images because it would make generating the new 640px size easier.

This got me thinking, what if they did want to convert every image ever uploaded to this new size and cache it? How would they do it? How much would it cost? The more I thought about it, the more curious I became, so I launched a little research project to see what I could find out, and to show how I would work through the problem.

Approach

How to resize?

I tried searching to find out exactly how Flickr is resizing their images, but it is apparently a well kept secret. There was a fair amount of speculation that they use Lanczos resampling, and my own research suggested it was a strong choice for quality resizing, so I chose to use it for the purposes of this experiment.

I wrote a very quick PHP script that uses ImageMagick with the Lanczos “filter” to do the work. This resizer was built with this particular experiment in mind, but it is fairly flexible. If you POST an image, and a value “largestDimInPx” it will resize the image and send it back as the response to the HTTP POST, thus the “RESTFul” name. The resizer also accepts an array of parameters which it sends back in the HTTP header. So if you were actually taking on a mass resizing project like we’re proposing, you can pass the unique ID of the photo in your system and get it back when the resize is complete.

You can find the code for it over on my GitHub.

Just how many images we talkin’?

Another carefully guarded secret it seems, is the total number of images that Flickr is currently hosting. I did a lot of searching and tried a few naughty tricks to see if I could get the API or website to tell me, but it was to no avail.

Some previous “official” numbers were as high as 6 billion images. So for the purposes of my test I assumed that they had 10 billion images that they wanted to resize to this new 640px image size.

CPU Cycles – Pick your poison

I have to assume that Flickr has a pretty impressive infrastructure built out, and that they have a huge amount of processing power at their disposal. Still, to accomplish something like this it’s unlikely that they’d reallocate existing resources. The task is too monumental to just have a couple servers work at it.

I also have to assume that they’re carefully optimizing their servers so that they don’t have to build and maintain more than necessary. So that begs the question, how do you get the processing horsepower necessary to convert all of these images?

Since I’ve recently been engrossed in creating and refining reusable RightScale ServerTemplates for our own servers in the AWS cloud, my thoughts for a solution instantly gravitated toward launching a bunch of servers in the cloud for this purpose then terminating them when the task was done. What I didn’t know is if this made more sense than, say, buying a bunch of servers and configuring them to do the same task.

In order to do some tests, I created ServerTemplate which can be launched on AWS using RightScale that will immediately be able to start resizing images posted to it using my aforementioned PHP resizer.

The experiment

What I learned in short was… This is a HUGE undertaking! I also found that while any approach would probably be cost prohibitive, performing this resizing task using on-demand servers in the cloud is still the cheapest route by far.

Assumptions

First, some of the assertions for this exercise.

• The server(s) performing the resize task will be of the m1.large type from AWS
• Flickr has 10 billion images to convert
• Those images are (on average 12MP and about 4MB
• The images are being resized so that the largest dimension is 640px

You’ll also find that as I describe the results, and the costs they represent, I conveniently exclude data transfer from my numbers. This is actually intentional. My goal is to compare just CPU time.

Yes, bandwidth has a tangible cost when you use it in the cloud. But the same is true for a bare metal server doing the same task, not to mention the networking hardware which must be acquired, configured, and maintained. So for the purposes of this experiment, only the cost of CPU cycles is really being examined.

Findings

With my new m1.large instance launched in the AWS cloud, and exposing the resizer service, I did a few tests to get a feel for just how long it would take to do all of this resizing. What I found out pretty quickly was that the actual task of resizing the image actually only took around 1 second, sometimes less! It should come as no surprise that the real time consumer in the process was I/O bandwidth.

Over my home cable connection (measures at 3.5Mbps up and 11.83Mbps down), using Firefox to post and FireBug to measure, it took an average of 12 seconds to complete the process of posting the image and receiving the response. If I removed the overhead of Firefox and simply used a bash script and cURL, that dropped considerably to 8 seconds.

In an effort to get a “best case scenario” measurement, I copied the file to be resized onto the AWS instance, and ran the same cURL command locally. On what can be effectively called “infinite” bandwidth, the process of posting, resizing, and fetching the result took about 2 seconds.

The tortoise and the hare

One very tangible benefit to using the cloud for this purpose though is the time to market for such a huge task. You can imagine that if Flickr did decide to go ahead with this, they wouldn’t really want to announce that they’ve started but that the process will take many months, or even years. Assuming again that the per image resize time is 2 seconds, it would take one server just over 633 years to convert all of the images. Something tells me that wouldn’t exactly go over well.

Say that they wanted to convert all of the images in one week, at 2 seconds per image for 10B images, it would require just over 33,000 servers to convert that many images in the cloud. What’s more is that it would take effectively “no time” to deploy that many servers, use them for a week, then terminate them. Try rolling out that many real, bare metal servers in that timeframe!

What’s it gonna cost?

You might look at those results and think that these times are fairly reasonable. However, if you take these figures and start multiplying them by ludicrously large numbers (like 10 billion for example), those reasonable numbers start to look very unreasonable.

Using these results, and (as I stated before) only accounting for CPU time, it would cost approximately $1.9M for Flickr to convert all of their images in the cloud. That is assuming that they’re connecting to the servers with effectively infinite bandwidth, ensuring that the upload and download transfer times for the image were less than 1 second (combined!). Seems like a lot of money, but then it’s a lot of images!

Compare that though, to building out a farm of bare metal servers to do the same task. We’ve already established that we’d need a little over 33,000 servers to be able to convert all of the images in a week. If we just take the lowest configuration Dell rack mounted server, the R-415 at a retail price of $4531, it would cost just over $149M, just for the hardware. Worse still, the Dell doesn’t actually have as much processing horsepower as an AWS m1.large does, so you’d probably significantly effect the time per image.

Conclusion

At the end of the day, any approach for converting all of those images would be cost prohibitive, and I’m betting Flickr won’t be taking on this project. Still, if I had to accomplish this task for real, I think I’ve demonstrated fairly convincingly that doing it in the cloud with on demand computing power is totally the way to go.

I’m not a mathematician or a statistician, and I did paint this topic with very broad strokes. You can check my work with the simple Google Spreadsheet I created to track my results. If this were an actual task, I’d be a bit more precise, but I wanted to show the differences between the approaches, without getting into too much minutia.

That said, discussion about factors I may have missed are welcome, I think you’ll find that the delta in price for just the CPU horsepower between the cloud and a bare metal solution more than absorb any real differences I may have excluded.

If you’re running servers in the cloud, particularly on Amazon’s AWS and haven’t heard about RightScale you owe it to yourself to check them out. I’ve been using their tools for launching and managing linux servers on AWS. They allow you to automate all of the tasks to launch a new box, and even run regular operational tasks, all with the use of RightScripts.

RightScripts are just glorified shell scripts which get downloaded from RightScale to your linux server running in any of the clouds they support, and executed with the parameters that you specify in the RightScale dashboard for that RightScript. Of course, as you start to get into more complex scenarios you’re likely to start writing and testing your scripts locally before saving them in the RightScale dashboard. That’s where RightScriptDiff comes in.

The only way to create or edit a RightScript as of this writing is through the RightScale dashboard. So you’re typing your script into a nice big textarea, where you can’t tab for indents or any of the other benefits you get from an editor like vim, emacs, or even *gasp* notepad.exe. As a result I started to write, and even test my scripts locally before I ever committed them to RightScale.

Going this route of course adds a fair amount of overhead to the process. You have to remember which scripts you’ve edited, then copy/paste them into the RightScale dashboard to update the script in their system. After a while I found I couldn’t keep up with the overhead, and I needed to find some good way to compare my local copies of scripts with the ones in my RightScale dashboard.

Thus was born RightScriptDiff. By supplying RightScriptDiff with your username, password, and account id for RightScale along with a path to a directory containing your local scripts, it will use the RightScale API to compare your local copy against the one stored in your RightScale account. If you’re thinking “why don’t you just synchronize the script using the API”, you’re on the right track. Sadly, the API doesn’t (yet) support RightScripts for anything but viewing, here’s hoping they open up that functionality a bit.

In order for RightScriptDiff to compare your local files, they must be named with a specific pattern, namely <rightscript_id>-<rightscript_name>.sh. Actually, the script name and the *.sh extension are optional, but that’s the convention I use so it’s easier to identify them. You can pass (almost) any argument to RightScriptDiff that you can to the “ls” command in *nix and OSX, so something like relative/path/to/RightScripts/*.sh is totally acceptable. This means you can also target just a single script if you’d like. RightScriptDiff uses the RightScript_ID section of the filename to look up the script using the RightScript API, then compares the script against your local copy. If they’re the same, you get a happy success message that there is no difference. If the files are different, a side by side diff is shown.

Here’s an example of a successful run;

[bash]
Ryan-Geyers-MacBook-Pro:RightScripts rgeyer$ rsDiff.sh
Please enter the path to scripts stored locally…
*.sh
Grabbing all RightScripts for user: ***** on account: *****. Be patient, this could take a while…
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 369k 100 369k 0 0 148k 0 0:00:02 0:00:02 –:–:– 182k
Found 1 nodes:
– NODE –

Local copy of 236067-LDAP Install OpenLDAP.sh does not differ from RightScale copy.
Found 1 nodes:
– NODE –

Local copy of 237784-LDAP Create Database.sh does not differ from RightScale copy.
Found 1 nodes:
– NODE –

Local copy of 237788-LDAP Set Config Admin Details.sh does not differ from RightScale copy.
Found 1 nodes:
– NODE –

Local copy of 237789-LDAP Tools Install.sh does not differ from RightScale copy.
Found 1 nodes:
– NODE –

Local copy of 238408-LDAP Enable Schema(s).sh does not differ from RightScale copy.
Found 1 nodes:
– NODE –

Local copy of 238454-LDAP DB S3 Backup.sh does not differ from RightScale copy.
Found 1 nodes:
– NODE –

Local copy of 238480-LDAP DB S3 Restore.sh does not differ from RightScale copy.
Found 1 nodes:
– NODE –

Local copy of 238481-LDAP DB S3 Enable Continuous Backup.sh does not differ from RightScale copy.
Found 1 nodes:
– NODE –

Local copy of 238497-LDAP DB S3 Disable Continuous Backup.sh does not differ from RightScale copy.
[/bash]

This is what it looks like when the scripts differ;

[bash]
Ryan-Geyers-MacBook-Pro:RightScripts rgeyer$ rsDiff.sh
Please enter the path to scripts stored locally…
237784*.sh
Grabbing all RightScripts for user: ***** on account: *****. Be patient, this could take a while…
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 369k 100 369k 0 0 172k 0 0:00:02 0:00:02 –:–:– 220k
Found 1 nodes:
– NODE –

Local copy of 237784-LDAP Create Database.sh differs from RightScale copy.. Diff below..
> sed -i "s/@@DATABASE_TYPE@@/$DATABASE_TYPE/g" $tmp_file
> sed -i "s/@@DB_CHECKPOINT@@/$DB_CHECKPOINT/g" $tmp_file
<
echo "Finishing up…"
[/bash]

As mentioned above RightScriptDiff requires three values, your RightScale account email address, password, and account number. You might notice that in both instances above I did not need to provide them and was prompted only for the path to my scripts. This is because I pre-defined my credentials and account before hand. There are a couple ways to provide this to RightScriptDiff, you can call rsDiff.sh with parameters (-e|–email=)<email-address> (-p|–password=)<password> (-a|–account_id=)<account_id>, or you can rename the supplied rsDiffAuth.sh.example file, to rsDiffAuth.sh and put your credentials in there.

After developing this, I discovered that I had edited one of my script files locally and the change wasn’t reflected in my RightScale dashboard, so it’s already proved useful to me. Hopefully this helps some other sysadmins building our their RightScale managed clouds.

You can download RightScriptDiff by running the following command. I wrote it on OSX 10.6.4, but it should work on most flavors of linux as well.

[bash]
svn export https://linode.nslms.com/svn_ro/RightScriptDiff/
[/bash]

* UPDATE: RightScriptDiff has a new home

[bash]
git clone git://github.com/rgeyer/RightScriptDiff.git
[/bash]

Chances are pretty good I’ll create a landing page for this, particularly if it becomes popular, so stay tuned here for updates!

Generally speaking, I don’t actively participate in the weekly #carchat on Twitter, but I do occasionally glean a few points as I watch it stream across my Twitter timeline.

Take for instance this week’s #carchat where I saw @banovsky say the following.

banovsky ||||||| TOPIC |||||||| Android OS in cars, yay or nay? (via @sandbarmark) #carchat

On May 13, 2010 12:49 am via TweetGrid

Now, I’ve built a CarPC and have some familiarity with the topic, and on the surface this seemed like a REALLY good idea, so I excitedly replied.

rjgeyer All the way Yay! RT @banovsky: ||||||| TOPIC |||||||| Android OS in cars, yay or nay? (via @sandbarmark) #carchat

On May 13, 2010 12:59 am via TwitterGadget

And apparently @bprosperi agreed;

bprosperi I like this idea RT @rjgeyer All the way Yay! RT @banovsky: |||||| TOPIC ||||||| Android OS in cars, yay or nay? (via @sandbarmark) #carchat

On May 13, 2010 1:01 am via twidroid

Admittedly however, my response was not based on any particular facts or prior research, it just sounded like a novel idea. So when I was challenged, I honestly didn’t have anything particularly intelligent to say.

banovsky @rjgeyer Why yay? #carchat

On May 13, 2010 1:00 am via TweetGrid

rjgeyer @banovsky Why not? I'm a big carpc fan, and ran windows, the flexibility and speed of an open source mobile OS appeals to me. #carchat

On May 13, 2010 1:04 am via TwitterGadget

That was pretty much it for that conversation, I was running out the door to head home from work, and there didn’t seem to be a lot of activity on that conversation topic. But the brief exchange did get me thinking. I’m going to be tackling the challenge of updating my CarPC and installing it in the Caddy at some point in the future, and it might make sense to consider my options in the Mobile OS arena. With that, I decided to refine my understanding a bit.

What I found, was actually quite disappointing! It seems that a lot of folks in the car computing community have given this topic a lot of consideration, starting all the way back when Android was first announced. The first several links of the search I did were all links back to the mp3car.com forums, and I observed a few common threads.

Screensize

Android is hyper focused on small mobile devices (read teeny screens), so while it’s very touch centric, which is good for car computing, existing apps will not scale well to the standard 7″ car computing touchscreen. Which means that any software which would be properly useful in a car, on the Android OS, would have to be built exclusively for that purpose. That seems fine on the surface, but it excludes you from the primary Android market, and creates a new niche which may be extraordinarily small, if it takes off at all.

Level of interactivity

Android expects the user to be engaged and actively interacting with the device. This is a reasonable expectation for a mobile phone that you’ll use to play games, use social networking, web browse, etc. But the car computing use case is VERY different, you want to be able to interact with the device with as little cognitive overhead as possible. This is the reason that the use of mobile phones is being outlawed in many states. So again, you’d have to build something exclusively for car computing, on a platform with an entirely different focus.

Pay it back

Android is based on Linux, but it is not true to the spirit and intent of Free Open Source Software (FOSS). Android has reinvented the wheel many times over, and created subsystems which do (almost) the same thing as a similar subsystem already available in Linux, but in a way that’s only useful on a mobile device. Fundamentally, this makes sense, since the problems they’re trying to solve are rather specific to the application. The problem though, is that none of that work done to “enhance” the FOSS software upon which Android is based is of any use to anyone but the Android team.

This problem would be even further compounded if Android OS were used in the context it was brought up by @sandbarmark for #carchat.

sandbarmark @banovsky Android OS in GM cars...yay or nay? #carchat

On May 13, 2010 12:48 am via TweetGrid

Can you imagine? Let’s suppose GM does decide to adopt the Android OS, and turn it into their own version of Ford’s wildly popular Sync entertainment system. Chances are they’re going to take the already very device specific Android OS, take a few key pieces from it, and write their own application suite on top of it. This would mean MORE duplicated work which would likely prove to be only useful to GM, and not to the Android community at large, or the Linux community to which it owes it’s existence!

My Conclusion

While at first blush, the idea of an “open” mobile OS powering in car entertainment devices seemed very attractive I don’t think it’s the answer. If GM is going to pursue building some software and hardware for in car entertainment, they should take a serious look at simply building on top of Linux, rather than having to work around the mobile-device-centric limitations of Android. Plus, if they did it right, the entire Linux community could benefit from their efforts.

If you’re reading this, it means that the DNS records have replicated and Random Musings is now fully hosted on my shiny Linode VPS!

I’ve been steadily growing out of my previous hosting solution over on Host My Site. All things being equal they’ve served me very well, but running WordPress started to demand more memory than they’d allocate for a shared hosting customer. Then there’s the limited functionality of the PHP stack which I was starting to run up against quite regularly.

I have to say I’m SUPER pleased with Linode so far. I signed up for it on the 21st, and by today I’ve got it completely setup hosting web and email for three domains, with another on the way. I was worried that it would cost me money, but when I account for the other hosting accounts I’ll be able to close I wind up money ahead. Sweet!

Hopefully this change will be seamless to ya’ll, might notice an increase in speed. Let me know if you see anything “odd”.

Okay, so as you may already know I’m a big fan of any software solution that does what I need in a portable and platform agnostic way, particularly if it does it “in the cloud“.

What you may not know, is that I’m addicted to Twitter and I’ve been going through desktop based Twitter clients faster than my Cadillac beer bongs fuel!  My affair with desktop clients started with TweetDeck, since it’s used by a lot of my friends on Twitter and it seemed to be a front runner.  The problem is that it’s in beta, and it’s a bit buggy still.  Worse yet, it doesn’t run on my linux box.  In fact, no decent Twitter client does work on my linux box.  I’ve also tried Twhirl, and DestroyTwitter.  Both of which lack all the features TweetDeck has, and none of which work “quite right” on my linux box.

And, as if to add insult to injury the company I work for has recently been acquired by a MUCH bigger company which is imposing a lot of new restrictions to the use of our desktop computers.  Meaning I’ll likely not be able to install a Twitter desktop app on my computer in about a month.

Enter TwitterGadget, pictured above.  It’s an iGoogle gadget so it runs in my browser, on windows or linux, without installing!  And it’s quite featureful too! It has built in URL shortening which is one of the features I miss most from other desktop apps.  The one feature I hope to be included soon is TweetShrink integration, but I’ll live without it.

Hopefully I won’t have to change Twitter clients for a while now! 

Well, I’m not exactly what you’d call an early adopter, and I’ve only recently rediscovered a place in my heart for Apple based computing devices.

That said, there was a lot of internal debate an struggle when it came time for me to upgrade from my Cingular 8525 HTC/Phone/PDA device. Initially, I was convinced that I wanted the newest HTC the Fuze, since it was a logical upgrade from what I had. But there was just soooo much hype about the iPhone, I had to give it a fair shake. Fortunately, my sister and brother-in-law each got one a few weeks before my wife and I were due to upgrade. I got a real good chance to check them out. After seeing the HUGE amount of apps, and overall support that existed for them, the choice was easy. Sign me up, I’m a lemming..

I’ve had my iPhone for two and a half weeks, and I’ve made a lot of changes, tweaked a lot of configuration, and jailbroke the device. The rest of this post will serve to document that for my own sake should I ever have to recover the device, but also to hopefully shed some light on why you might jailbreak your phone, and what apps a techie like me finds useful.

Read more after the break…

Freedom for your phone.

Jailbreaking was a topic I couldn’t find a satisfying answer to when I started researching it.  I knew that it would give me a greater degree of control over the device, that it would allow me to install software that wasn’t offically endorsed by Apple, and that it would give me access to the innards of the device… Metaphorically speaking.  I also knew that I’d feel weak if I didn’t do it.  But that aside I couldn’t think of a compelling reason to do it, nor did I see any "killer app" that would persuade me to jailbreak if I hadn’t already made the choice based on my status in the geek community.

That said, I won’t presume to know why jailbreaking your phone appeals to you.  Instead I’m going to very thoroughly outline what jailbreaking my phone accomplished for me.

SSH The "killer app"

Apps from Cydia: OpenSSH & Insomnia

My primary computer at home runs Gentoo Linux.  Now I do dual boot to Vista because there is stuff that I have to run windows for (iTunes to sync the phone namely), but I rarely fire her up and choose the Vista option.  That said, the ability to connect to my iPhone, over WiFi using SSH is the killer app for me.  I can access the entire file structure, transfer files to and from the device, and all sorts of other good stuff.

I’m using this SSH connection to sync my iPhone’s music library with Amarok.  Now this isn’t a totally seamless proposal.  The first step is to mount your iPhone’s file system as a directory on your linux box.  You can see a fairly good outline of that here.  Then, you also have to tweak a file to tell your iPhone that the library Amarok uploaded uses a previous version of the iTunes database.  You can read about this in Amarok’s on Wiki under the Devices with Firmware 2.x section of Media Devices.  Still very cool.

The Insomnia app simply makes the phone not go to sleep after a period of inactivity.  It’ll still shut the screen off to save power, but it keeps the WiFi powered up, and SSHD running.  This allows me to stay connected via SSH without diddling the screen or something to keep my connection alive.

Sync your calendar and contacts

 Apps from Cydia: NemusSync

You may know that I use GooSync to keep up my contacts and appointments on my calendar.  The AppStore has a few apps from Synthesis AG that’ll use SyncML to sync your contacts, todo list, and calendar with your iPhone.  With that said, the calendar part does not sync with your iPhones built in calendar.  Instead it maintains it’s own calendar and syncs all your appointments to that.

That’s fine and all, and I still use their app to sync my contacts, but I wasn’t too keen on the limitation of syncing my calendar.  Enter NemusSync it properly communicates with the built in calendar.  There are limitations of course.  For instance, all it does is sync the calendar, though the author has plans to sync todo items, and contacts in a future version.  More vexing however is that it is a manual sync.  You have to go into the app, and click a button to sync up.  I’ve actually worked out a solution for that, but that’s for another article.

Springboard customization and organization

Apps from Cydia: BossPrefs, Categories, Five Icon Dock, iBlank, QuickGold, WeatherIcon

Once you start adding a bunch of apps to your iPhone it can get cluttered in a hurry.  The screen which contains all the icons for your apps has been dubbed the "Springboard" by Apple, and the list of apps above all contribute in one way or another to keeping it clutter free.

Five Icon Dock

This should be fairly self explanatory, but it’s pretty handy.  It allows you to squeeze 5 icons down in the dock instead of just 4.

BossPrefs

BossPrefs, aside from having a lot of great functionality has a Hide Icon functionality that’s quite handy.  It’ll make any icon on your springboard disappear!  Now this is only really useful in combination with something that allows you to still access that app.  That’s where Categories, and QuickGold come in.  Read on to see how!

Categories

Categories allows you to have folders on your springboard.  Once you’ve selected one of these folders, you’ll be presented with a whole new screen with the apps that are in that category presented.  I’ll admit that I had some trouble with this app, and I don’t use it a ton.  But it does help to de-clutter the Springboard in a major way

QuickGold

QuickGold is quite possibly the most used application on my whole phone.  It does what the Google app for iPhone does, and more.  Basically, when you’re on the first page of your springboard and you press the home button, a search function pops up.  As you type, it searches and presents all sorts of stuff that matches the search.  Applications, contacts, web bookmarks, SMS conversations, web clips, safari history, and more.  You can configure what items get searched, and it holds the last 6 recently launched apps in a queue for you to easily click on without searching.

Primarily, I use this to get to apps which I’ve hidden, or buried too deep with Categories.  Needless to say, a SUPER useful app.

iBlank

iBlank creates a transparent icon on your springboard which you can use to make a custom layout if you want.  To be honest, I thought this was cool when I loaded it, but haven’t really used it since the first couple days I had the phone, and I’ve deleted most of the blank icons I’d created.

WeatherIcon

Are you sick of seeing sunny, and 72 degrees when you look at the weather icon?  This simple app replaces that icon with your actual weather conditions, as configured in the weather app.  Extraordinarily simple little customization, and something that Apple should have done to begin with.

Utilities Apple Forgot

Apps from Cydia: Backgrounder, Clippy, Docs, iRealSMS, LockCalendar, Notifier, Safari Download Plug-In

Backgrounder is AWESOME!  Got some app you want to run in the background while you do something else?  Backgrounder does that.  The main thing I use it for is Pandora.  I get to listen to my Pandora radio station while I do other stuff on the phone, like play games or text!

Clippy is the clipboard that Apple forgot, and is purportedly working on for a future update.  There is another solution called hClipboard which is evidently quite good as well, but I found and installed clippy first and it’s met all my needs.

Docs..  Pretty simple, it allows you to open all sorts of document types including Microsoft Word and PDF’s.  Can’t live without it!

iRealSMS is one of the very few apps I’ve paid for, and I think it’s TOTALLY worth every penny.  It’s a replacement SMS app that adds several cool features, and most importantly for me a landscape keyboard.  They have a trial period, I encourage you to check it out.

LockCalendar allows you to see your upcoming appointments superimposed over the lock screen.  Very handy to be able to see your schedule at a glance this way.

Notifier shows missed calls, new emails, new SMS messages, and other useful bits up in your status bar just next to the battery.  I find it very handy.

Safari Download Plug-In.  Speaks for itself, allows you to download files with Safari.  Sweet. 

Total visual customization

Apps from Cydia: WinterBoard, WbApp

Some of the items I’ve talked about before require Winterboard.  Winterboard in short is the total UI customization tool for the iPhone.  It allows you to change your icons, fonts, wallpapers, colors…  Pretty much everything about how the UI is drawn can be tweaked with Winterboard.

There are several total customization themes you can download through Cydia, or pieces you can change.  Right now, I’ve hidden all of the labels for my apps on the spring board, made my status bar and dock transparent, and changed my lock screen slider to a can of Mt. Dew.  This is just scratching the surface of what you can do with Winterboard.

WbApp provides some configuration tools for Winterboard, quite handy for themes that support it.

Okay, I think that’s enough for now.  Obviously there is a lot you can do with a jailbroken iPhone and this isn’t an exhaustive list of even the stuff I have loaded, but it should give you a good feel for why you might want to make the leap to jailbreak your phone.  I know I’m glad I did. 

When I performed my search for the perfect photo sharing solution, I fell in love with the Picasa desktop application. I even discovered that there is a linux version. However, as you’d likely expect, it didn’t really play nice as far as uploading photos to any photo sharing site other than Google’s Picasa Web Albums.

On windows, there is a great solution called picasa2flickr which passes the desired photo’s to the windows Flickr Uploader. Again, for obvious reasons, this doesn’t work well on linux.

So, having determined that it wasn’t worth my time to pursue trying to get Flickr uploads working from Picasa on Linux, I started evaluating many of the other native options on linux, such as digikam and fspot. While these more easily uploaded to Flickr, and had open API’s, none of them worked quite the way I wanted, so I abandoned my search for a good solution.

Then, on a whim I did a Google search just a couple hours after Andy O’Neill made a blog post about a button he wrote to import photos to Flickr from the Linux version of Picasa, named picflick.

I eagerly (re)installed Picasa3 on my Gentoo box using a beta ebuild found here. Then installed his button.

After playing with it for a bit, I realized a few things didn’t quite jive for me.

1) The script automatically resizes the image before uploading it to Flickr. I prefer to upload all of my images at their original resolution, so this was a bit of a road block for me.

2) The script used a Perl module to upload to Flickr. For the life of me, I couldn’t seem to figure out how to get it authorized with my Flickr account to actually permit uploads. I’m sure if I spent a bit more time and read a few more manuals I could have gotten it right, but it didn’t quite work “out-of-the-box” for me.

3) I’d prefer to see the progress being made, rather than the beeps and tray notifications that Andy’s script provided.

So, I stole the key part of his script, the part which translates Windows paths to *nix ones, and broke down the rest to simply pass the photos on to my preferred linux Flickr uploader, KFlickr

Here’s the contents of my script, including the win2native function written by Andy.

#!/bin/bash
DEBUG=1     # debug to $LOG
LOG=/tmp/picflick.log
PICASA_WINE_DIR="$HOME/.google\/picasa\/3.0\/drive_c"  # Relative to $HOME
PICASA_WINE_DIR_NATIVE=`echo $PICASA_WINE_DIR |sed 's|\\\\||g'`
function debug() {
        if [ $DEBUG -eq 1 ]; then
                echo "$*" >> $LOG
        fi
}
# wine2native(): convert wine filename to native linux filenames
# Arguments: _name_ of variable which holds path
# Example: wine2native file  # not wine2native $file
function wine2native() {
        VAR=$1
        eval "VAL=\$$1"
        debug "Wine path: $VAL"
        # use '|' to delimit the paths
        VAL=`echo "$VAL" | \
                sed "s|C:|$PICASA_WINE_DIR|" | \
                sed 's|\\\\|/|g'`
        debug "Source file: $VAL"
        eval "$VAR=\$VAL"
}
# check we have the required dependencies
which kflickr > /dev/null || die "You need to install kflickr"
file=$1
wine2native file
DIR=`dirname "$file"`
EXT=${file##*.}
debug "START_UPLOAD"
for file in "$@"; do
        wine2native file
        KFLICKR="$KFLICKR $file"
done
debug "Launching kflickr with the following args $KFLICKR"
kflickr $KFLICKR
debug "Done"

Now when I click the “Flickr” button in Picasa, it brings up the KFlickr app with all the pictures I selected ready to upload. Thanks for the inspiration, and code bits to make this work Andy, I was too lazy to actually figure out what was necessary to pull the image paths from Picasa and use them.

I just learned about a Bash History Meme originated at Planet Fedora from a blog I read regularly.

In short, you run the following command in bash, and show your results.

history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head

My results from my home box are as follows;

103 ls
59 cd
52 exit
38 vi
38 firefox
29 for
22 su
18 /opt/hdv/myworkflow.sh
14 ssh
13 diff

Seems I’m unwilling to simply close my terminal window in KDE, but instead have to type “exit”. The “myworkflow.sh” script is a work in progress which I hope to one day post about. It does stuff to help me convert and do post production on video from my HDV camcorder. I’ve been using “diff” to compare original files with modified ones for web updates I’ve been doing for clients.

Here’s the results from my web hosting box;

394 ls
212 cd
89 vi
77 exit
60 du
30 mv
28 rm
20 mkdir
19 pwd
12 cp

Suppose there’s nothing particularly interesting here. I was checking a file upload progress in a very nasty way by calling “du”, what can I say.. I’m lazy.

Not long ago I shared my bash script for creating thumbnails and manageable sized “big” images for an image gallery, or other image store. Well, today I had to update an existing gallery with a pretty significant number of new images. It occurred to me that I’d like to only convert new images rather than re-converting the whole lot. Then, I’d like to simply upload the new files to my server in some automated way.

So here’s the tools to do it. It assumes you have the same layout for your pictures on your local drive as I do, which is as follows.

• RootDirectoryForGallery — This contains the full resolution pictures directly from your camera, and the following directories.
  • web — This is a sub directory of RootDirectoryForGallery which contains the “big” web version of your image, and the thumbnails directory described below.
    • thumbnails — This is a sub directory of web, and contains the thumbnail sized versions of the images.

The first step, is to copy your new pictures from the digital camera to your RootDirectoryForGallery. Then, we want to get a list of the files that are new, so we run the following from the RootDirectoryForGallery.

diff . web/ | grep 'Only in \.: d' | awk '{print $4}' | grep jpg >> 3-6-08_update.diff

This creates a file in the RootDirectoryForGallery named “3-6-08_update.diff” which contains a list of only the new pictures, one per line. Now, we want to use our image thumbnail script to convert only the new images to the “big” and thumbnail sized images. I discovered that I needed to make a change to my script in order to do this. Namely in the for loop I needed to enclose the command used to list files in “$()”. The modified script is shown below. Notice the “$($SEARCH)” where there was previously just “$SEARCH”.

#!/bin/bash
SEARCH=$1
SIZE=$2
DEST=$3
if [ $# -lt 3 ]
then
echo "You must pass three arguments 1) The search string (usually *.jpg) 2) The destination size I.E. 500x374 3) The destination directory"
exit 1
fi
for i in $($SEARCH)
do
        echo "Converting $i"
        convert -resize $SIZE $i -resize $SIZE +profile '*' $DEST$i
done

So with our edited script we convert the files.

/opt/imagethumbnail.sh "cat 3-6-08_update.diff" "800x600" "web/"
/opt/imagethumbnail.sh "cat 3-6-08_update.diff" "150×112 "web/_thb_"

Lastly, we want to upload just the changed files to our server. We’ll use rsync for this. The paths, server name, and user name have been changed to protect the innocent.

rsync -e ssh -av /path/to/local/copy/ yourusername@yourserver.com:/path/to/www/server/copy/

And there you have it, with just a few simple commands you’ve created thumbnails of all of your images, and uploaded just the new ones to your server. Easy!