Yes, it's summer time, get ready for almost raw i/o, or slightly cooked!
The simplest possible DNS-based service which I could write to explore Amazon's DNS offering has to be dynamic DNS, so I set one up..
The record skx.dhcp.io can be updated to point to your current IP by running:curl http://dhcp.io/set/efa6961c-f3dd-11e3-955b-00163e0816a2
Or to a fixed IP:curl http://dhcp.io/set/efa6961c-f3dd-11e3-955b-00163e0816a2/126.96.36.199
The code is modular and pretty nice, and the Amazon integration is simple.
(Although I need to write code to allow users to sign-up. I'll do that if it seems useful, I suspect there are already enough free ddns providers out there - though I might be the first to support IPv6 when I commit my next chunk of work!)
tl;dr I like the MIT license, mutt, tagging things, and synchronising my data between my devices.Simplicity
As I meander through my life and career, one thing stands out as becoming more and more important as time goes by; I've noticed a definite trend in myself towards desiring simplicity above all else.
When I say that, I don't mean that I have a hankering to live in a cave and subsist on fruit. I like the complicated things that my life involves but I increasingly like to deal with them in simple ways. I find that I don't have the appetite or inclination to see an argument through nor the patience for dealing with irrationality; I'll just state my case clearly and succinctly and step away until everyone has calmed down and can accept my point.
When it comes to code, the difference is clear. If starting something new, I'll write down a set of features I want then refine them until I have a clear idea of how the system works before writing a single line of code. If I'm brave, I'll embrace TDD. In the old days, I'd get a vague idea in my head and design the rest in my head while I'm churning out code.
Recently, as an example, I refactored someone else's code from a general-purpose, multi-featured single class into several small functions that are individually very short and meaningful and all hang together to perform just the required behaviour and nothing else.
This all leads me deeper and deeper into the Unix philosophy (of which I've always been a fan) of having lots of tools that each do one thing well that can be combined in any way necessary. Which leads me into deeper and deeper suspicion of the GNU environment (see my rant about netcat). I'm not saying GNU is bad, it's just that I'm less immediately bought into the GNU way being always the right way.
Related to my bent for simplicity, I choose to license the things I write under the MIT license these days where I'd previously chosen the GPL. Socialism is a nice ideal but in practice it's just too complex to work as intended. Both benevolent dictatorship and co-operative anarchy are much simpler and seem far more likely to result in a better society (though not both at once ;)). I guess that sums up how I feel about the GPL these days. #cueflamewarDiscoveries
With apologies to the Linux Voice crew, here are a few discoveries I've made recently:offlineimap
I don't know why I hadn't investigated this before but offlineimap has recently made dealing with my email much more bearable. For years I've been switching between various GUI clients and in recent months I'd decided to switch to mutt and make a real go of it. I've been enjoying mutt but not it's in-built IMAP support. Offlineimap means I don't have to care about mutt's weaknesses and I can just focus on its strengths as the best client for reading, replying to, sorting, and above all deleting email :)notmuch
On a very related note, I also discovered notmuch which is a tool for indexing and tagging a collection of email. I'm now using mutt-kz (because it integrates with notmuch) to sort my email into (virtual) folders based on tags that I apply both through hooks in offlineimap and in the course of dealing manually with my email. Notmuch also makes it very easy to find old emails when I need to refer back to something.syncthing
I've never been very good at backups. I've never had the patience to set up something robust and to ensure that the right things will be plugged in to the right machines and that they'll be at the right network locations at the right times based on a carefully designed backup schedule. Because of my crappy attitude I've lost some precious data in the past.
Through the Bad Voltage podcast, I discoverd Syncthing which is sort of like a replacement for dropbox except that it synchronises folders between your own machines rather than between your machine(s) and a (possibly evil) server.
To summarise how it works, once you've got the service running on two machines, you copy the ID from each to the other and then specify repositories which are just directories that you give a shared name so that machine A can store files from the "Photos" repository in one place while machine B stores them in another place. Adding extra machines to the network is easy and each repository can be configured to share with any number of the machines in your network.
My current set up is:
Home desktop machine (media server)
Linode VPS (where this blog is hosted)
My Nexus 4 phone
One with an eCryptfs folder where I store private keys and the like - shared between my desktop, laptop, and VPS
podcasts - my VPS downloads podcasts into this folder directly from RSS feeds and synchronises to my laptop and phone
photos - synced between my desktop, VPS and laptop because I want to make sure I never lose them
It's incredibly simple to use and configure and thus far, it works very well and gives me just what I needed.
It is unfortunate that some of the client libraries are inefficient, but I'm enjoying my exposure to Amazon's Route53 API.
(This is unrelated to the previous post(s) about operating a DNS service..)
For an idea of scale I host just over 170 zones at the moment.
For the first 25 zones Amazon would charge $0.50 a month, then $0.10 after that. Which would mean:25 * $0.50 + 150 * $0.10 = $12.50
That seems reasonably .. reasonable.
It seems Mozilla is targeting emerging markets and developing nations with $25 cell phones. This is tremendous news, and an admirable focus for Mozilla, but it is not without risk.
Bringing simple, accessible technology to these markets can have a profound impact. As an example, in 2001, 134 million Nigerians shared 500,000 land-lines (as covered by Jack Ewing in Businessweek back in 2007). That year the government started encouraging wireless market competition and by 2007 Nigeria had 30 million cellular subscribers.
This generated market competition and better products, but more importantly, we have seen time and time again that access to technology such as cell phones improves education, provides opportunities for people to start small businesses, and in many cases is a contributing factor for bringing people out of poverty.
So, cell phones are having a profound impact in these nations, but the question is, will it work with FirefoxOS?
I am not sure.
In Mozilla’s defence, they have done an admirable job with FirefoxOS. They have built a powerful platform, based on open web technology, and they lined up a raft of carriers to launch with. They have a strong brand, an active and passionate community, and like so many other success stories, they already have a popular existing product (their browser) to get them into meetings and headlines.
Success though is judged by many different factors, and having a raft of carriers and products on the market is not enough. If they ship in volume but get high return rates, it could kill them, as is common for many new product launches.
What I don’t know is whether this volume/return-rate balance plays such a critical role in developing markets. I would imagine that return rates could be higher (such as someone who has never used a cell phone before taking it back because it is just too alien to them). On the other hand, I wonder if those consumers there are willing to put up with more quirks just to get access to the cell network and potentially the Internet.
What seems clear to me is that success here has little to do with the elegance or design of FirefoxOS (or any other product for that matter). It is instead about delivering incredibly dependable hardware. In developing nations people have less access to energy (for charging devices) and have to work harder to obtain it, and have lower access to support resources for how to use new technology. As such, it really needs to just work. This factor, I imagine, is going to be more outside of Mozilla’s hands.
So, in a nutshell, if the $25 phones fail to meet expectations, it may not be Mozilla’s fault. Likewise, if they are successful, it may not be to their credit.