Open Source

Open source tools and software

Removing the Password from a PDF

I have a few ebooks I’ve purchased online that came as password protected PDFs. While mildly annoying while trying to read them on a desktop system, it’s patently absurd when I try to move them over to the iPad to use. There are a bunch of hacks floating around describing how to use conversion software to remove the password. Such as convert to a postscript file and then back to a PDF. Generally you end up with a pretty crappy PDF out the other end. You always loose hyperlinks (table of content or index), and a lot of times the formatting can get screwy. Fortunately I found a few comments mentioning qpdf, which is in the default repos for Ubuntu at least:

  • sudo apt-get install qpdf
  • qpdf --password=******** --decrypt lame_pass_version.pdf happy_version.pdf

Yay! No more crashing iBooks trying to read stuff I paid money for. And there’s an actual preview of the cover on the bookshelf now. Amazing.

WordPress Updated

I did the update to WordPress 3.0 and added a new theme for the blog (you’ll have to actually visit the site to see, most of you read through RSS). Most of my motivation was getting something in there that looks better on mobile devices. The theme I have on now does a completely fluid layout instead of fixed width, so it looks a lot better on iPhone/iPad/Android. Also on the list of stuff to try out is the WordPress Mobile Pack that Andrea and James released.

Definitely recommend doing the upgrade and switching around themes. Especially for viewing on iPhone/Android devices. The Mystique theme is what I’m currently using by the way. On the settings page it has a toggle for fixed/fluid layout. Ahh, nice and simple.

Long Running Background Scripts with CodeIgniter

I’ve been working on a project using CodeIgniter recently, and have been trying to clean some stuff up so that long running background scripts use the same code as the live system. Sane, every framework has some way of wiring it up so you can run command line tasks using the same framework as you’re running for web requests, and CodeIgniter is no exception. For some reason stuff that used to run find as bare mysql scripts kept running out of memory when I ran it within CI. Turns out the DB wrapper actually stores all the queries it runs in a big array. Not an issue when processing web requests I’m sure, but definitely an issue when you’re running big background tasks. If you want to keep your scripts from running out of memory it’s easy enough to do:

$this->db->save_queries = false;

Zend Server Community Edition vs Snow Leopard

After upgrading to Snow Leopard we’ve had only one real issue so far, Zend Server Community Edition didn’t want to start up. Well, technically, parts of it. The apache instance was running, by mysql and the admin interface were dead. I found this post about watchdog errors, but even after putting in the fix for lighthttpd I still wasn’t getting the services starting up. Same deal for Tony. Poking around in the startup files it looked like mysql data was owned by user 103, and the mysql scripts were trying to start as user ‘zend’, however I have no zend user on my system. I wasn’t able to find anything about it, but I figured hell, let me give it a try and create a user Zend. This is the command to run from the terminal (funky huh?):

sudo dscl . -create /Users/zend UniqueID 103

Which creates a zend user.. somewhere.. I’m not familiar with that bit of OS X magic yet. It’s not in /etc/passwd, but if you ‘ls -l /usr/local/zend/mysql’ you should see the data directory owned by zend again. Now just restart and you should be peachy:

sudo /usr/local/zend/bin/zendctl.sh restart

Works for Tony and I at least, so we figured we would share. голова болит секс голова болит секс

Not Sure I Buy the Android Fragmentation Argument

There seems to be a lot of “take it for granted” style discussion around the possibility of Android fragmentation. Without strong top down control of the platform, folks seem to think that we’re going to end up with hundreds of versions of Android, all slightly different. This was the nightmare that mobile Java became. There were large engineering teams dedicated to and specialized in taking your write-once-run-anywhere app and actually getting it to work on the volume of handsets you wanted to hit.

It’s true that technically anyone who wants to build a slightly different version of Android can, so in that sense there CAN be fragmentation. However, the ecosystem has also fundamentally changed. Before we had the carriers tightly controlling the channel, dictating what was in and out in terms of hardware, enforcing strict standards on the software they pushed to users, and doing everything they could to keep anyone else from pushing software to users. In that world the burden of dealing with fragmentation was with the developers, and the benefit went to the carriers. The carriers controlled the channel, so fragmentation continued.

The one lesson that everyone in mobile seems to have learned over the last year was that the carriers were really bad at determining the right hardware and managing that application and content catalog. It’s why everyone is jumping on the App Store Bandwagon. One of the side-effects of that is that it breaks the strongly controlled content and application channel. If ATT decides that their Android version is going to do Bluetooth slightly different, sure, go ahead. But how can they strongarm Android developers who produce Bluetooth apps into making an ATT specific version? The control isn’t really there any more. Developers might do it, but only if ATT is offering up enough incremental sales revenue to make the port worthwhile. Right now developers frequently do it cause they’re contractually obligated to if they want ATT to promote their app.

Anyone who’s worked in open source knows that forks are technically possible, but practically uncommon. When the “market” is completely open folks tend to follow a path that serves them best. And it’s a reinforcing path. Even when someone with vested interest tries to keep a fork distinct, normally the burden ends up being more on the controller than anyone else. Forks tend to get folded back or die off pretty quickly. I think the same thing should happen with Android. Sure, people might try at the start to get a leg up by including proprietary features and customizations. But in the long run if Android as a whole works, the only person they’re hurting with a fork is themselves (to the tune of a decreased application catalog). And although it’s possible for them to create a custom application catalog with some differentiation in the short term and attempt to keep that differentiation going, there’s no difference between that and the strongly controlled channel that we currently see failing today. The cost of trying to do so will outweigh the benefit of joining the mainline. толстые проститутки

The Subjective Meaning of "Platform Maturity"

I posted yesterday about wanting to use my phone to publish my location in realtime, and I got a bunch of fantastic responses both in the comments and as emails (thanks folks!) I fooled around with some of them with varying degrees of success. Nokia Sport Tracker seems like it would be great! However, I can’t figure out how to make the phone app do it’s job. Maybe my fault, I have an E71 and it’s not listed as a supported model. I’ll have to dig out my N95 and try that one. However, on the Android side, I put FirePin on my phone and was able to upload and share out info about my route (course, it only has to points, cause I have the phone on wifi only right now). FirePin supposedly also works with FireEagle based on the comments I got. But I can’t figure out how that’s supposed to work.

Generally I’ve been hearing frequently about how location based services are really starting to happen this time around. Yea, yea, I know. That’s what we’ve said every year for the last decade. Don’t even bother, I’ve heard it all before. However, this time we have some open platforms with GPS built into the handset, which means there’s a way to work around most of the problems inherent in the carrier based system we had before. Any by “problems” I mean “crippling cost structure”. I can kinda understand how that seems like a more mature market for location based services. Because end users can grant permission to an application for it to directly grab location info, there are all kinds of services out there.

However, I would hardly count that as platform maturity. That’s a degree of market maturity, but not platform maturity. Sure, it’s easier to build a location based app. Just plop your application into any one of the silos that folks have built to control the deployment of your application and management of your data, and blammo! New app. Yea, not the way I normally think about these things. Which is not to belittle the efforts like FireEagle, I just think there are a few missing bits.

Here’s the kinds of stuff I was expecting to see:

  • A somewhat generic app that records location information. Recording information to a local file seems to be pretty decent, I guess there are standards floating around for that. However, there doesn’t seem to be much of a standardized interface/protocol for streaming location information up to a server. GPSGate has a protocol that seems to operate over UDP and TCP, but that doesn’t seem to be an accepted public format.
  • Some server component that I can chuck on one of my machines to accept samples sent up by that little client shim.
  • Basic tools to display those samples on a map. Google has provided most of the backbone and made it pretty simple to use. But there’s also Openstreetmap for those who are Google alergic.

That basic set of functionality is a write-once bit of infrastructure. It gets us out of the “Oh yea, FirePin is great!! Wait, no, you can’t use it on your Nokia”. Not that the tools won’t evolve. But there should be an open set of base clients for all the different mobile platforms, and then anyone who wants to build a web app that pulls in location info can just say “Okay, add local.rowehl.com:9900 to your location client to start updating the Mike-o-matic pile of gold finder app with your current location” Instead we have all these different point solution client applications, frequently hardcoded to send location to a given server. Dumb.

Debian and X11 on the G1

There’s a package now for installing X11 on the G1, which builds on the Debian for G1 package. I haven’t fooled around with the stuff yet, but what am I interested in running with access to the full set of Debian software? Well that should be obvious. Metaspoit of course. Cellular interface + Wifi interface + handheld device + automated security scanning = fun!

Installing RC33 on a Dev G1

A friend over at Google provided me with an unlocked Android phone, which I’ve been poking around with here and there doing some development. I hadn’t really poked around with the phone itself all that much, meaning looking at hacks and usage tricks and whatnot. Yesterday I decided I wanted to update to the latest firmware (RC33) however, so the journey began. I have my G1 running on the AT&T network, which is where some of the complexity comes from.

I started out with the normal instructions for manually installing the RC33 update, which are pretty actually slick and simple. However, I was getting a failed check when trying to install the firmware. I assume there’s some internal ID that identifies the phone as a TMobile phone or not, and my dev phone doesn’t have that, so the installer was throwing some assertion failure check. So I figured I would try out one of the jailbroken images if I’m going to have to muck around for a while anyway.

There is an alternative version of the RC33 update available, called the JF33 sometimes, and other times the JF RC33. The JF stands for Jesusfreak, the forum user who repacks the roms and has apparently provided test keys that can be used to downgrade a unit. Once you know what you’re looking for, there are tons of posts in forums and blogs all over the place. The problem is just figuring out what you need to search for.

The process goes something like this:

It was a bit of an involved process to get through. And at first when I installed the RC29 firmware and had to re-activate, I was afraid I wasn’t going to be able to do so without a TMobile SIM. Just a bit of APN hackery took care of that however. Phew! Now I have Latitude working in maps, and root access in the terminal. W00t! Back to developing now.

Shim Services

I’ve been sick for the last few days. Perfect time to put a bit of a dent in that ever-growing pile of unread books next to my bed! Which I began doing without hesitation, until I kept running into cross-references to other books in Dreaming In Code. Some of the books I know I’ve read, others I know I should definitely pick up, others I’m not sure about. Have I read them? Do I own them? As I scan my bookshelves looking for my copy of The Soul of a New Machine I re-realize that I’ve already cleared the unread book stack a few times. Now there’s a bunch of still-very-interesting unread stuff mixed in with the filed-away-for-reference stuff. Maybe it was because I was reading Dreaming In Code that I began suffering from delusions of adequacy, but I thought “I must organize this!”. Maybe it was just the Nyquil talking.

First thought was along the lines of “there must be some software out there that will do this for me already.” Lots of stuff for OS X, but I’m on a Linux system most of the time. And the the most promising of the Linux based cataloging software crashes immediately on window move or resize on my 64-bit desktop system. Maybe that’s not the way to go. I want something quick, easy, and hopefully composable into other usages.

How about something for Android? I’ve been fooling around with developing some Android stuff. And they have Zebra Crossing, a prepackaged lib for barcode scanning. I should be able to find something floating around out there that should make it easy to just scan a whole bunch of barcodes. I can use that to make a big list of ISBNs, and then feed the stuff into a combination of ISBNdb.com and Amazon lookups to make myself a database of my books.

In poking around looking for a simple barcode scanning notepad kind of app I saw the Oilcan app sitting on my Android desktop. Oilcan is a browser wrapper that lets you plugin Greasemonkey style extension scripts into the native Android browser. One of the examples that comes with Oilcan is an extension that allows you to scan barcodes directly into the input box on m.half.com.

It took about 5 minutes to turn that into something that would use a page on my own server to make me a database of scanned ISBN numbers. No native coding required, which I thought was pretty interesting. One thing to pay attention to is the supper aggro caching that the Android browser does, make sure you insert cache control headers and meta tags. Instead of ending up with a one time throw-away tool to create a list of ISBNs, I’ve ended up with an online service that I can use to toss other barcode based info up to my server.

And most importantly, I’ve found a way to use creative coding to procrastinate my way around actually getting done what I set out to accomplish. Happy 2009 everyone!

Continuing Symbian Signed Conversation

One of the points I was harping on at and around the Symbian Partner conf were my perceived issued with the Symbian Signed effort. As a developer I get no benefit out of the initiative, but I’ve commonly felt some pained incurred by it. David Wood also just posted about the basic principles of software signing, so apparently it’s on his mind too.

I’ve already put down a bunch of my gripes about the current system. But if we want to break it down to basics, there are a few questions that I think we need to answer about a signing process. I was going to try to lay then down in some form of coherent order, but I have a rapidly evolving situation that needs some tending to. So here they are in jumbled rough form:

  • Signing is trusting. In the SSL world that’s trusting that the server at the end of the connection is owned by the people who are supposed to own it. Who are we trusting in signing a Symbian app?
  • There’s trusting that the app provider isn’t going to do anything nefarious.
  • There’s trusting that the OS will only allow the app to do things it was signed to do (nice bit of work there, I like this part of the signing process actually)
  • There’s trusting that is something goes wrong with the app you can get help.. which is unaddressed.
  • Part of what the carriers/operators really want is a reduction in support calls/cost. This doesn’t help that. Actually, there’s a mistaken perception on the part of users that their carrier/operator is the person to call when an app goes wrong. I don’t call Comcast when a virus screws up my PC
  • Why are these things really important in the mobile world when they’re left to sort themselves out (internet style) in the PC realm? Is it constrained devices and bandwidth really? Or is carrier/operator cost the principal driver?
  • If it’s really constrained devices and bandwidth, why can’t I – the user – manage rights outside of the signing infrastructure? Why doesn’t signing set default rights and let me choose what I want to grant or remove manually after the install?
  • Signing shouldn’t be the only mechanism of trust extension. Look at the Maemo installer for an example of well done application installation process. Installing a package brings in a feed of updates, repository for apt installs actually, that brings in updates. Build the trust mechanism into that, I should be able to trust the people I want to trust. It’s great that the operating system can enforce some set of restrictions for a set of applications signed by an “official source”. But if I want to trust Google directly, let me trust Google.

Damnit, gotta run. Give David some feedback if you can, I think he’s headed in a good direction with this conversation.