Try running:

google-chrome --user-agent="Mozilla/5.0 (Linux; U; Android 2.2.1; en-gb; Nexus One Build/FRG83D) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" "http://www.google.co.uk/m/search?site=apps"

And searching for “angry”

Packaging has interested me for awhile and of late I prefer the simple arch packaging where you just clone from a hg URL that’s importantly browsable from the Web.

Since I work with widgets, I’m often left thinking about how they compare to “the mature Debian way” of doing things.

The kill switch

This seems to be an Operator requirement, since Android and the Itunes App store I believe implements one.

On Debian and all other Linux distributions security is largely the responsibility of the user. That is to rarely manually remove or rather upgrade the package in question. It most cases an “evil” or dangerous package is detected by its maintainer or during the unstable->testing->stable transition by intrepid users, hence most removals happen in “unstable” and extremely rarely in “stable”. Security incidents are described in security advisories, which in turn are usually linked to a industry standard CVE identifier. However if a “stable” sysadmin fails to read and act upon a removal security advisory, there could be trouble ahead.

I personally like the upgrade approach as that’s very much in line of how the Web works. You update your way out of trouble, and that works for all parties.

Forced removal or disabling of an app (aka the kill switch) is a very disruptive experience. What happens if a user relies on that particular “bad” app to get his or her job done? There is no upgrade path for users.

Comparing the update process

Updates are a pain point. On Debian for example, they are done rather network inefficiently, as you need to download the entire package even though there might be a one line of change.

On mobiles, this problem worsens as network capacity is tightly limited and complex, where OTA push updates are (I’m not sure why) favoured. Furthermore Operators typically demand to test each update before deployment, making the process rather cumbersome and dangerously slow.

I personally think the manual upgrade path with efficient binary diffing is the way forward, much like the Web works.

And who does the updates ?

If a security issue is found on Debian, the security team or package maintainer usually assume responsibility for fixing the problem as quickly as possible.

In the WAC widget, Android & Apple App store world, the emphasis is squarely on the author to fix the problem or be banned/removed/killed. I would argue this is bad for users and the ecosystem at large, since continuity and stability is put at risk.

Of course it is more complicated than that. Add the whacky shrinkwrap & “freemium” business models and you generally put blame squarely on the original author. But can you? The picture is really muddled when intermediaries like Apple and alike who take a revenue share and conduct testing.

Do you think a intermediary has a right to change a product (violate “artistic” integrity) on its way to the end consumer? I’ll leave you to think about what happens in the real marketplace when you next go shopping.

#!/bin/sh -e
if test -f "$1" && grep -q ssh-rsa "$1" && test $(wc -l <"$1") -eq 1&& test "${1##*.}" == "pub"
then
        username=$(basename $1 .pub)
        echo Create account for $username ?
        read -p "Press [enter] to continue..."
else
        echo $0 requires a ssh pub key of the format username.pub
        exit
fi

sudo useradd -s /usr/bin/git-shell -m $username
sudo mkdir /home/$username/.ssh
sudo cp $1 /home/$username/.ssh/authorized_keys
sudo chown -R $username:$username /home/$username/.ssh/
sudo adduser $username git

echo ssh://$username@example.com/srv/git/test

Sort by third column using semi-colon as a delimiter:

wget http://weather.dabase.com/3day.txt -O /dev/stdout |  sort -n -t ";" -k 3

-n is for numeric sort.

The “side loading” use case on Androids is a bit difficult to say the least.

LG Optimus with an sdcard mounted:

/dev/block/vold/179:17 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0

With it unmounted or removed /mnt/sdcard or /sdcard exist, but obviously not mounted. This can actually be a problem as some apps assume /sdcard are mounted and there to write on. Doh.

On a Galaxy S, where there is an empty sdcard slot we can see:

/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

With an sdcard inserted and mounted:

/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:9 /mnt/sdcard/external_sd vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/external_sd/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0

Notice the weird external_sd bit. The Galaxy S mounts the physical sdcard on /mnt/sdcard/external_sd/ which is a bit daft unless they are trying to work around a problem.

The Nexus S from Samsung doesn’t have an sdcard, yet it still is mounted there:

/dev/block/vold/179:3 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0

In the menus, it’s called “USB storage”.

To conclude we can learn here that the physical sdcard has been deprecated really. I noticed a WRT that refused to install widgets from anywhere except /sdcard/, so when you didn’t have a physical sdcard installed, you’re kinda screwed. So now I guess Android has deprecated the sdcard, but unfortunately has kept the moint point name for historical reasons.

Without the physical sdcard, I must say it gets really hard to “side load”. For example I have never managed to “side load” with other non-internet technologies like bluetooth, which is a bit depressing. USB I gather won’t work because of the master slave model, though I don’t have a physical USB male to male to try.

Upgrading from a Nexus 1 was particularly painful since I had to re-install all the apps. Furthermore the App metadata like where I am with “Angry birds” is not carried over. So I’ve must have lost many several hours of setup & game progression!

Network settings, Bookmarks, passwords, cookies, email accounts, all need to be re-setup. Under Privacy settings there is “Back up my data” & “Automatic restore” option ticked, but it didn’t seem to work! Most definitely seems to be an opportunity to sort out the Android upgrade path.

The Nexus S screen is much better than the Nexus 1, however the battery life seems just as bad as the Nexus 1, if not worse. The lock and home keys are re-mapped, which I’m getting used to. Tbh, I prefer the home key on the right, but it is worrying how this small aspect is so fragmented already across Android devices! Pick up an Android and you will need to get used it’s mappings. Pick up an Iphone and you’re A for away.

Cons

• Slippery back. Place the mobile on my bed and it slips off!
• Terrible battery life, though the display is on a 30 second time out!
• Hard to tell when it’s upside down when taking it out my pocket
• I have a little lip on my screen, turns out to be “physical damage” out the box, but Carphone warehouse accuse me of doing it
• No Gtalk video enabled chat I want it, though this function kills my laptop, nevermind my mobile
• NFC reader consumes battery Can’t figure out the new Tags application even though a friend also has a Nexus S!

Pros

• Lightweight
• NFC reader!
• It’s what Google employees work with
• No mouse ball (less is more)
• The new vector drawn Maps is coool
• VOIP capability is exciting
• No notification light
• Reboot bug whilst making calls