Network packet filters were ‘in’ around this time, as part of the then trend towards microkernel operating systems. The idea was that you move as much as possible out of the kernel into user process/memory space, so that it was easier to modify. The network packet filter would identify and extract the content from all network packets and dispatch them to the appropriate user process.

However, two factors subsequently turned the tide and networking code back into the kernel:

1. the growth of the Internet and the corresponding importance of high performance networking
2. the lack of any real need to modify packet handling on a regular or ad-hoc basis outside of academic environments (everyone uses some form of Ethernet and UDP/TCP pretty much all the time, and not much else)

The project focused on optimizing the process of identifying and decoding packets – basically building a list of patterns to match for an applying them efficiently against incoming packets. In theory, the algorithms I applied worked pretty well compared to existing approaches, but I was never able to do any real world testing. This was partly due to time constraints on the project, but also due to the security culture in the computer lab at the time, which basically amounted to:

• Never let a (undergraduate) student have root
• Don’t let a student see any of the UNIX (DEC Ultrix in our case) source code related to security or the kernel
• Don’t let a students access the network with their own device

So I wasn’t even allowed to do my own promiscuous network sniffing to get real data to test against – my supervisor had to do it! Universities might still be like this except for Linux!

The project was supervised by Derek McAuley who was a great teacher and mentor. The original, complete with typos (the OCR ate them when I scanned it) and my grade (can you guess?) can be found in the library of the computer lab at Cambridge.

Sound good? I recently wrote  about my experience on how this applies to the world of commercial Learning Management Systems for LINE’s HeadLINE newsletter. You can read the full article here: http://www.line.co.uk/viewpoints/what-gmail-and-the-ipad-have-in-common-and-most-lmss-dont.

In an article in the FT, the former state telcos in France, Spain and Germany are all making comments along the following lines: “Google should share some of its online advertising revenue with the telecoms groups, so as to compensate the network operators for carrying the technology company’s bandwidth-hungry content” (César Alierta, chairman of Telefónica).

Sorry, but I don’t buy it. I pay CableCom (Swiss cable company) the equivalent of about 90 USD / month for their fastest domestic broadband connection (25/2.5 MBit/s), and I pay SwissCom (former Swiss state telco) every month for a data allowance. If this isn’t enough to pay for the required infrastructure, then they should charge me more or provide less bandwidth for the same money. I can either pay up or switch to another provider.

And there’s the rub – the telcos might want to be more than “dumb pipes” but that’s essentially what they are, and it’s not in the interests of consumers for them to be more than that. If my web services are tied to my internet connection, then I can’t switch easily, nor can I choose to get my mobile and fixed line internet from different providers. Think about that .com email address you had when you first got on the internet. You give yourself far more flexibility if you go with Yahoo/Gmail/Hotmail etc.

So the telcos have become dumb pipes because that’s what a fairly efficient market supported by government regulation has delivered over the last ten years. And they take money from their consumers, so there’s no automatic moral case for them to take money from providers – nor do they have the leverage to force this to happen (unless they decide to act as a cartel!)

Good for you and me, and a shame they can’t move on from complaining about this and work on being the best plumbers they possible can be.

Unfortunately I couldn’t get it to work with any software on my BlackBerry Curve (8520), but it works perfectly with the barcode reader on the T-Mobile G1 (Android):

It’s a pretty cool (and actually quite useful) piece of software, but it does rather remind me of acoustic coupler modems (see pic), early modems that made noises into a normal telephone handset rather than plugging straight into the wall. Like these old modems, Barcoder is using a human interface (in this case the screen) to get small amounts of data from one very sophisticated device to another – William Gibson would be proud.

Image: MaximumPC.com

It also makes me wonder where we’ve gone wrong in terms of computer / cellphone interaction, that we can’t easily push a line of ASCII text from a laptop to our mobiles – wasn’t Bluetooth meant to solve that? A question for another post.

Ian Leader: I’ve been using a LinkSys (now Cisco) WRT54GL as my home WiFi / router / firewall for about four years, and particularly since the OpenWrt initiative released the WhiteRussian version of their open source firmware, it’s been a joy to use: a fully-featured, flexible web GUI with both simple and advanced administration modes, access to a very wide range of linux packages, and a plugin architecture in the web GUI that allows you to add and configure a great deal of them without getting your hands dirty.

However, the hardware’s old and doesn’t support 802.11N wifi, so I bought a Fonera 2.0n. As well as 802.11N, it’s got a host of other features like USB support (for storage or webcams, or…) and applications to handle uploads and downloads to Picasa, FaceBook, Torrents and other applications / protocols. It’s also based on OpenWrt, and uses a version of the same Luci user interface.

Unfortunately, for my setup there was one key difference: There’s a module called dnsmasq on both platforms that runs a DNS server (amongst other things), and allows you to specify DNS entries for local servers. In OpenWrt WhiteRusian this is pretty simple: You add entries to /etc/hosts.local in the normal format e.g.

192.168.1.100 server1

Then reboot the device (this is pretty brute force, but simpler than remembering which init.d / rc.d script to run). Other settings like the DNS suffix (e.g. myhouse.mydomain.com) can be set in the web UI.

The Fonera doesn’t play nicely like this, and there simply doesn’t seem to be any file pre-configured where you can add entries, nor does it let you set the DNS suffix through the web UI. Here’s how I made it work:

1. First, you need to install the devloper version of the firmware so that you can access a command line on the device using SSH. Get it here and install according to these instructions – it takes about 5 minutes.
2. Download an SSH client (e.g. Putty) and log into your router (same IP address and credentials that you use on the web UI)
3. Create the file /etc/hosts.local and add your DNS entries (see /etc/hosts for format)
4. Edit the file /etc/config/dhcp and replace the section ‘config dnsmasq’ with the following (the important changes are in bold):

config dnsmasq
 option domainneeded     0
 option boguspriv        1
 option filterwin2k      '0'  #enable for dial on demand
 option localise_queries 1
 option local    '/lan/'
 option domain   'myhouse.mycompany.com'
 option expandhosts      1
 option nonegcache       0
 option authoritative    1
 option readethers       1
 option leasefile        '/tmp/dhcp.leases'
 option resolvfile       '/tmp/resolv.conf.auto'
 option addnhosts        '/etc/hosts.local'

Finally, reboot.

A bit more complicated…

Although I’m glad that FON have based the 2.0n on an open firmware, and are not locking down the hardware with encryption keys, I can’t help feeling that they’ve taken a GUI that is simple, powerful and flexible, and dumbed it down for no good reason (remember, the standard OpenWRT WhiteRussian Web UI already has beginner and advanced modes). Why not let OpenWrt do the heavy lifting, and focus on adding the extra modules like the facebook upload app and torrent port.

This would possibly make the value-added features over the Fonera available on other non-FON hardware, but should this be a concern for FON? It’s a question of their purpose: I’ve always thought that FON was about creating a useful community of shared Hotspots, not selling WiFi routers, so I believe they should focus on putting hotspots in useful places (e.g. airports) and making their open hotspot s/w available on as many platforms as possible, not building their own hardware and user interfaces. Or maybe that’s not working: FON are about to ship a European version of the Peek non-wifi, email-only device, which they describe as “Perfect for those moments when you can’t find WiFi”.

The article looks at the benefits of bringing these complementary areas together within organisations – a trend that is definitely underway. It also considers organisational structures and other issues that have impeded widespread implementation of technology platforms that bring knowledge, learning and communications together within corporations.

Read the full article here.

They left it almost to the last minute, but yesterday, Roadsync 5.0 for Symbian S60 was released, an now includes support for Google apps: push IMAP email, in addition to calendar and contacts sync through ActiveSync that’s been available since the summer.

I’m pleased to say that it does exactly what it says on the tin:

• It works with gmail.com and Google apps
• It syncs email to your device
• It lets you send email
• You don’t need to pay any service fees, or give your Google Apps password to any third party site
• it syncs the read unread status of your emails in both directions

It’s the last two points that might set it above the Blackberry. A Curve 8520 arrived in the post for me yesterday – the first time I’ve ever had a BlackBerry – and while I’m very impressed, the fact that it will only sync the read status of email in one direction (Blackberry -> Google Apps) seems completely unnecessary, as well as being quite annoying.  Given how long BlackBerry have been in the email game, I’m really surprised by this.

What about the cost? RoadSync 5.0 costs 50 USD – which is about the same as five months of the ‘BlackBerry option’ at SwissCom – so about 1/2 the price if you consider that RoadSync has been upgraded about once a year since 2007 (of course it’s still more expensive than on an iPhone or Android device – free s/w from Google and no service charges – but I need something to tide me over until we know what the Nexus One really is).

The BlackBerry still wins on one count though – you can have as many mailboxes as you like, whereas RoadSync only supports a connection to a single server. So you can’t sync both Google Apps for work and your personal Gmail. My only other complaint is that status flags / stars aren’t synchronised (Gmail does support this), although if you set a status flag on the device, it sets the email as unread in Google Apps – which is not really the right way to do it…

Anyway, on the whole, very posititive. Merry Christmas!

Since inception, it has taken around 12 months and a lot of discussions to get the programme off the ground.  As with any business proposition I had to articulate my rationale and justification for the project – my attempt was a white paper called “A Perfect (Disruptive) Storm”.  For the purposes of history and for those might be interested in attempting this in their own region a copy of the final “draft” of the paper is available below.

Note since this white paper there have been a number of structural changes to the final programme.

So why have Google got themselves into the hardware game after many different quotes from Eric Schmidt to the contrary?  By creating the Nexus One, I believe that Google have created their own Android “Gold Standard” against which all other Android phones will be measured.  This is in part to challenge hardware manufacturers and more importantly to control network operators.

Having had the  pleasure of using both a G1 (home) and an iPhone (work) simultaneously I have discovered that both have their pros and cons but neither is quite the perfect phone and I think the market is still wide open.  Both have great features but neither has all, so in my mind it is all about who can recognise their deficiencies and adapt quickly.

After a month with the iPhone, I would suggest the following:

1. Hardware – the iPhone’s build quality is fantastic and the touch screen is more responsive – no contest the iPhone wins hands down.
2. Battery – lets just say that I have seen a few iPhone users look very jealously at me at 4 o’clock in the afternoon when I kick out the old G1 battery and replace it with a new one.
3. “Flashy light” – this has me completely stumped- why doesn’t the iPhone include one of those Blackberry lights which indicate when you have an email (or tweet or SMS)?  No wonder the iPhone battery is always flat – users spend all their life switching it on to check if they have new email.
4. Multi-tasking – this is a real winner for Android – my email, twitter and multiple other apps run quietly in the background with no profound impact on battery life.  Only since I became a full time iPhone user have I discovered why iPhone users are constantly fiddling with their phones – its not because they’re addictive, its because they are constantly checking their email and then twitter etc.  Another reason for their batteries being constantly flat.
5. User interface – this is down to personal taste.  There are good things about both.  I prefer the bigger screen of the iPhone but I prefer the way Android organises its apps.
6. Multi-touch – well Android has none, so I guess the iPhone wins this one.
7. Apps – as with UI this is personal choice.  Android was rubbish but is improving quickly.  Do I need 100,000 apps? Probably not, I use around 10-15 apps of which 5 regularly.
8. Flip out keyboard – having used the iPhone for a month I am not completely convinced a flip out keyboard is necessary.  The Android on screen keyboard is rubbish.  Why?  The screen is too small and the less responsive that the iPhone.

So I guess if the Nexus One improved build quality, had a bigger and more responsive screen, a swappable battery, “flashy light”, multi-tasking, multi-touch and on screen keyboard we might have a new gold standard in smartphones. I guess Google just got really frustrated that manufacturers failed to compete with Apple.

The second point – which I think is more important – is controlling network operators.  There is a growing consensus that Android is pretty easy to code for, the background processing is a real winner and their self-regulated marketplace is substantially better than the Apple Apps Store.  But fragmentation of the Android code comes up again and again.  Is there a way to retain control of the code but allow for some divergence?  I guess the Nexus One is Google’s attempt at this.

By creating the Google phone (aka the Nexus One), the Android team have ultimately a code base on which developers can create “Google certified” applications.  Network operators can diverge from the code base but at their own risk – do they want the embarrassment of building an Android phone that won’t run particular apps?

This is likely to piss off the hardware manufacturers and network operators in the short term, but in the longer term it will benefit both.  It is essential that the Android is considered competitive rather than “second best” and developers must have confidence that their apps can and will work across multiple devices.

I guess Santa won’t be coming early this year … but may be after Xmas

The functionality more or less mirrors the public Google groups, while providing a variety of access options from closed teams to company-wide groups to public groups.

There seem to be some minor glitches – for example, two test groups I set up took several hours to appear after I created them:

but overall it works well.

Surprisingly (for Google), the biggest weakness seems to be in search - as it’s not possible to search from one box across groups, sites and docs – the three components that together would make a pretty effective Intranet for most small and medium sized companies. This is compounded by the fact that the Google mini can’t index Google Apps because it doesn’t support search across single sign-on sites. The Google search appliance can do this, but the starting price for that box is an order of magnitude higher than the mini, and very hard to justify for most SMEs, especially in the current financial climate.