Ways in which the Kindle Fire fails...now fix them

There are plenty of negative reviews out there about the new Kindle Fire. In my opinion many of those reviews unfairly try to draw comparisons between Amazon's device and the iPad. Here I look at the unit irrespective of what comes out of Cupertino. I'm not interested in bashing Amazon or their product(s). Nor am I attempting to be apologetic for their failings.

100% Grade-A Fail 

1. Power button
1. It's inconveniently located (at the bottom of the device)
2. Resting the device on a table for reading is impractical as the power is constantly activated (unless you use a case or hold the device upside down)
2. Speakers
1. Low quality
2. Low volume
3. Volume Control
1. There is no hardware access to the volume settings (no slider or rocker). When playing a video or using an app you have to:
1. Activate the menu system (not required in all cases)
2. Tap on the setting icon at the top of the device
3. Slide the Volume slider to the desired value
4. Hope that your application isn't paused during this process because otherwise you'll be repeating steps 2 and 3 until you get it just right.
4. Multiple-Account support
1. one account <--> one device works in some (read: many) contexts. But with device like this it just makes sense to support multiple accounts (and by accounts I mean specifically Amazon accounts) 
5. Performance
1. Silk
1. It's not fast (admittedly this may change overtime as they mine behavior from the millions of users they have)
2. Touch Response and Processing
1. Sometimes the device doesn't register touches
2. Sometimes the touches seem to register instantly other times they seem to register quite a while after the touch event
3. Sometimes (read: frequently) a 'tap' is registered as a swipe (and vice versa) 
6. Specs
1. RAM
1. only 512 (it does make a difference especially with bloated Dalvik apps)
2. Storage
1. Dear Amazon, in an effort to make your devices more affordable please feel free to either keep the internal capacity to something under 8GB or exclude things like SD-Card slots. DO NOT DO BOTH!!!

Fail Lite

1. Content Offerings
1. News Stand - Magazines are poorly formatted for the device. The content is neither rich nor interactive
2. Apps - A sparse subset of the apps in the Amazon App Store are available for the Fire. Few compelling titles exist (evidenced by the fact that the daily free title is consistently #1 in the store). Finding titles that might appeal to a user based on their age is very difficult. The categories they have are pretty broad and not very helpful .
3. Docs - The built in PDF reader is one step above worthless. It works great if your PDF was formatted specifically for a 1024x600 display, otherwise you'll find that resizing and panning are slow and often cause you drum your fingers on the table top as you wait for the rendering engine to redraw the text you're trying to read.
2. Keyboard - The built-in keyboard is mediocre. The least they could do is allow LastPass integration so that you can use LastPass to fill in your account credentials from time to time.

Even So...

I'm not displeased with my purchase. My original intention was to get the device for myself, do some development on/for it and get them for my nieces and nephews. I do not think that the Kindle Fire is as kid friendly as is the Nook Color/Tablet. Touchy Books are oddly formatted on the Fire but look great on the Nook offerings. Finding age appropriate material is much more difficult on the Fire than on the Nook. This causes quite the quandary as Amazon has a much better ecosystem for a device like this, they just lack the polish. Were I buying based only on the device offerings as they exist today, I'd probably get the young ones Nook Tablets. I think, though, that is more of an investment in a platform and I feel Amazon has all the right ingredients to make the best platform. Barnes and Noble just doesn't have the same synergy across Music, Movies, Books, Apps, etc... 

Some quick functions from my .shrc_local

It's pretty well known that I have a fairly hefty .shrc which I created sometime ago to address the little things that bugged me when going from FreeBSD to say Linux or from OS X to maybe Cygwin ( ${deityOfYourChoice:="God"} help me ).  When I published it, I tried to make sure that it was both functional for the general public (ok.. admittedly a self-selecting sub-sub-sub culture of the general public) and generic enough to not get in the way of people who want to extend it for their specific needs.
Enter: .shrc_local. There are other places where one could make customizations and I actively encourage that, but if you just want something simple you can create a ~/.shrc_local and drop it in there.

Here is one example of that (pulled directly from my .shrc_local):

rvm(){
    #Quick wrapper function to make RVM (https://rvm.beginrescueend.com/) work
    #if you're using a sane shell instead of 'bash'. Bash still needs to be 
    #installed as RVM depends on it. This function simply wraps around bash
    #passing in the init script (~/.rvm/scripts/rvm) and the parameters so that
    #you aren't stuck when your default shell is something other than bash or 
    #zsh
    echo "
        source ${HOME}/.rvm/scripts/rvm 
        rvm $*
    " | bash
}

Here is another:

update_pkgsrc(){
    #Quick function to update my pkgsrc source tree.
    export CVSROOT=anoncvs@anoncvs.NetBSD.org:/cvsroot
    cd /usr/local/pkgsrc
    cvs update -A -Pd
}

I hope others will find these useful but if not.. at least I've posted them somewhere so that I can find them easily instead of searching through my tarsnap archives.. ;-)

tmux is awesome: how I use it for development with web2py

Thank goodness for BSD hackers. GNU Screen is a very nice piece of software. Tmux, however, is flippin awesome. The simple concept of Windows with Panes is enough to make me forever discontent with the any other terminal multiplexer. It's a useful feature and one that I employ in many of my scripts.

The above is an example of a multi-pane window. It's the result of the following script that I use when I do development in web2py. The left side can be used to track down debugging messages or even open a vi/vim session. The upper right pane is where my web2py server is running and I can pop in to restart it as needed. The middle and bottom right panes are used for making (frequent) commits my version control system of choice (fossil) and running tests (web2py makes it really easy to run tests from the command line). 

TMUX Script: 

#! /bin/sh

create_session(){

    #get to our main directory
    cd ~/prog/web2py/generic

    #Create new empty session (detached)
    tmux new-session -d -s ${1}

    #Split first window (vertically
    tmux split-window -h  -t ${1}:0  '{
        while [ "${restart_answer:-yes}" != "no" ]; do
            ./web2py.py --no-cron -a "admin"
            echo ""
            echo "Press ENTER to restart web2py"
            echo "Enter \"no\" to quit"
            read restart_answer
        done ;}'
    
    cd /Users/gcw/prog/web2py/generic/applications
    tmux split-window -v -t ${1}:0 -p 65
    tmux split-window -v -t ${1}:0 -p 50
    tmux select-pane -t ${1}:0
    
}

create_session web2py-generic

Everything get's started up in up in detatched mode which means that when I want to connect to it I just run 'tmux attach -t web2py-generic and I'm in.

pkgsrc alogside homebrew

UPDATE [07/02/12] : This post has been completely obsoleted by the content in a newer post about setting up a Mac more generally. Installing Pkgsrc & Homebrew are covered in detail with updates that address homebrew's change to prevent installing as a user not in the admin group as well as using the git mirror for pkgsrc. I'll keep the content here for historical purposes but you should really follow what's in the new post: Fresh Mac Setup



I live on the unix command line. Many mac users gasp in horror when the see me at a prompt that they think is "DOS" or something. They think I've broken my Macbook Pro and this is the way I 'fix' it. When I try to explain to them that I'm more at home with a keyboard and a blinking cursor than with a mouse/touchpad inside a GUI they just don't get it. On the other side you have people who say "well if you like the command line so much why not just use Ubuntu". The short answer is: with very few exceptions (Slackware, Gentoo and Funtoo), every Linux distribution I've used makes me want to slap the developers and stab the users/zealots who peddle that crap. <FlameOff> The Linux kernel is nothing less than a coup, to be admired for all of the hours of sheer genius that resulted in the very rich functionality it holds. Why no Linux distributions are as equally inspiring a mystery. </FlameOff> Save your shouts of protest, I've used Redhat (before RHEL and Fedora after) , LinuxMint (hell I run one of the mirrors), Trisquel, Debian, YellowDog, Ubuntu, Mandrake, Mandriva, Yggdrasil, Suse and they all leave me running back to a good old sensible BSD.


While I've never been much of a fan of NetBSD in particular, one would have to concede that they did a really good thing by making pkgsrc so flexible. The fact that runs on every modern Unix(-like) system is just plain awesome. Since OS X is Unix, pkgsrc just fits. I've used fink (bleh), macports (nice but much less flexible) and Homebrew (great but very incomplete). In fact I still use Homebrew as my defualt solution for unix tools. The problem is that they are pretty restrictive as to what they will accept and the formulae tend to be pretty slim on options. So when I need more flexibility in what available I reach for pkgsrc.


One of the pluses with homebrew is that it expects to be installed in /usr/local and to have all of it's packages installed and linked under /usr/local/. The kicker is that /usr/local should be set to permissions that allow an unprivileged user manage and install applications. All the others default to installing things as root. My setup:

1. Make sure Xcode is installed
2. As an admin user :
1. sudo mkdir -p /usr/local/src
2. sudo chown -R [USERID]:staff /usr/local/ #replace [USERID] with your normal user id
3. sudo chmod 775 /usr/local/* 
3. As normal (unprivileged) user:
1. Install homebrew:
1. ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
2. Install git:
1. brew install git
3. update brew formulae (just incase):
1. brew update
4. Install pkgsrc:
1. cd /usr/local/
2. curl ftp://ftp.netbsd.org/pub/pkgsrc/pkgsrc-2011Q1/pkgsrc.tar.gz | tar xzvf -
3. cd pkgsrc/bootstrap
4. ./bootstrap --pkgdbdir /usr/local/var/db/pkg --unprivileged --prefix /usr/local/pkg

At  step 3.4.2 we use the tarball path given at http://www.netbsd.org/docs/software/packages.html#bootstrap This path will likely change in the near future. So get the latest copy for your purposes.

In 3.4.4 we setup pkgsrc to install to /usr/local/pkg so more of our binaries will be in /usr/local/pkg/bin or /usr/local/pkg/sbin. It's important to modify your PATH and MANPATH variables. You generally want pkgsrc apps to be found AFTER their homebrew counterparts. If you don't know what those last to sentences mean, please stop before you break your computer. 

In the end you'll have a working pkgsrc install alongside your homebrew install. You can install packages from either system without needing to escalate to an administrative user.

Here Strings, echo, sed and ed

It's not uncommon to see people (mis)using sed in simple scripts to modify files. A pretty typical pattern is something like:

for i in $({some operation that returns file names}) ; do 
    sed -i -e 's/old/new/' ${1}
done

For (at least) the BSD and GNU versions of sed: -i means edit this file in place and -e simply tells it to execute the following command(s) on the file(s) given.

UPDATE (03/22/11): To clarify, my point here is that using sed to edit files in place is bad practice, generally speaking. Creating a stream with which to edit the contents of one file as it's placed into a new file is not, here, my gripe.

I've never been a fan of using sed in this manner. The reasons are many but let's go with "sed is a stream editor and that's not a stream there". Basically the usage above is turning a specialized tool (stream editor) into a generic tool (file editor). Instead of overloading sed with this type of work, I generally use ed which was designed to edit files (not streams). I'd use something like:

for i in $({some operation that returns file names}) ; do
    ed ${i} <<-EOF
%s/old/new/
w
q
EOF
done


This usage is a bit more verbose but avoids ambiguity and possible incompatibility with -i. While both BSD and GNU version of sed have -i they implement it differently. The BSD version expects an extension for the backup file that's created. For GNUbies this probably isn't an issue. All of their systems are GNU/Linux and they only ever have to work with GNU sed. For those of us who work on unix systems of various flavors it's a bit more pertinent.

If you're working on the command line and don't want to bother with a multi-line here document just to do a simple file edit you do have options.

printf (both the shell built-in and standalone utility) can be used to reliably send control characters (including the newline character) to STDOUT which can then be piped into the ed command:

for i in $({some operation that returns file names}) ; do

    printf '\%s/old/new/\nw\nq\n' | ed ${i}

done

Unfortunately you have to escape the % character that you want passed through because otherwise it looks like you're saying '%s' which has special meaning for printf.

Another option if you're using a modern ksh93 work-a-like is to use here strings in combination with string formatting:

for i in $({some operation that returns file names}) ; do

    ed ${i} <<< $'%s/old/new/\nw\nq\n'

done