Henry Ford, a great inspirational figure in the history of technological development once said that “when everything seems to be going against you, remember that the airplane takes off against the wind, not with it”. Ford faced great technological challenges in building the Model T; a car that he wanted the average citizen to be able to afford back in the early 1900s. He committed his life to challenging the norm and bringing technology that touched the lives of real people.
While challenged with the status quo and at times by ignorance and entitlement, he merely saw “obstacles as those frightful things you see when you take your eyes off your goal”. Ford’s commitment to making technology available to all resulted in more than 15 million Model Ts being sold between 1908 and 1927.
After a brief a introduction from Steven Moffat, who described the story as “perfect” and this era of the show as “the best era, apart from all the other eras which are equally as good”, there was a surprise guest: Matthew Waterhouse (Adric) read a speech about his love of the Tom Baker era. A brief clip of Lis Sladen from an earlier BFI event was shown, a touching way to make sure her presence was felt.
“Robots” itself was cracking. I’ve seen it lots of times before, but the presentation on the large screen was great. I hadn’t realised how downright cheeky Leela is in this story, she’s almost cocky. The costumes are fabulous if utterly impractical and the robot masks spooky. The tension really ramps up in part three as the body count gets higher.
Halfway through the story, Mat Irvine gave us some insights into how the visual effects were managed in the BBC at the time “Robots” was being made.
The panel afterwards was fantastic. The smallest panel of the season so far, it featured Philip Hinchcliffe (Producer), Louise Jameson (Leela) and Tom Baker (The Doctor). Tom was on grand form, his stream of conciousness was hilarious and random. He also talked a little about his relationship with Lalla Ward, which I haven’t heard him do before. Philip and Louise both managed to get more than a few words in edgeways, which was no mean feat.
Afterwards a large group of podcasters reviewed the screening for another special episode of the Doctor Who Podcast, which will appear on-line soon. Chatting and sharing pizza with other fans makes the screenings even more fun. The Doctor Who Podcast special recording from the “Mind of Evil” BFI screening is still available.Pin It
Since libguestfs 1.20 it has been possible to use rsync to upload or download files to a disk image incrementally. This is one way to do backups, but note that it won’t work on live guests unless you take a snapshot.
rsync involves using a network connection into or out of the appliance, and is therefore a lot more involved to set up. The script below shows one way to do this, by running an rsync daemon on the host, and letting the libguestfs appliance connect to it.
The script runs rsync inside the appliance, copying /home from the attached disk image out to /tmp/backup on the host. If the operation is repeated, then only incrementally changed files will be copied out. (To incrementally delete files on the target, add the deletedest:true flag).
Note you will need to open port 2999 on your host’s firewall for this to work.#!/bin/bash - set -x # The target directory. mkdir -p /tmp/backup # Create the daemon. rm -f /tmp/rsyncd.pid cat <<EOF > /tmp/rsyncd.conf port = 2999 pid file = /tmp/rsyncd.pid [backup] path = /tmp/backup use chroot = false read only = false EOF rsync --daemon --config=/tmp/rsyncd.conf # Run guestfish and attach to the guest. guestfish --ro --network -a /dev/fedora/f19rawhidex32 -i <<EOF trace on rsync-out /home rsync://firstname.lastname@example.org:2999/backup archive:true EOF # Kill the rsync daemon. kill `cat /tmp/rsyncd.pid`
Slightly short notice but this month's pub meet will be in Guildford again at The Keystone on Portsmouth Road, on Wednesday 24th April from 6.30/7.00pm until whenever people have had enough! It is about a 5-7 minute walk from Guildford central station.
These are different to 'bring a box' meetings as it's more of a social gathering over beer and food, so if you're going to bring a device make sure it doesn't take up table space!
Inside there’s a ring for sockets and a lighting circuit. The windows and doors are pre-made double-glazed units.
It was back in 2009 that I got a Palm Pre, perhaps the first commercial demonstration of “HTML for (almost) everything”. The turbulent history of that device is well-known, but shouldn’t detract from the core idea of building the entire user experience and applications using web technologies.
So I’m excited about Firefox OS, but thus far I’ve been sceptical about the platform’s ability to get developer attention, to build an ecosystem, and to reach a scale that makes the platform viable in the long-term. It depends very much on Mozilla’s and Telefonica’s ability to execute, and to get other device manufacturers to actually ship hardware.
As a small nitpicking example of execution, there’s no nice semantic URL I can point you to for Firefox OS. The best I could find is http://www.mozilla.org/en-US/firefox/partners/ or possibly http://www.mozilla.org/en-US/firefox/partners/#os. For developers it’s a little better, with https://developer.mozilla.org/en/docs/Mozilla/Firefox_OS.
I could talk about my disappointment with Mozilla‘s engagement with LiMo Foundation, where they had the opportunity to become the de facto web runtime as well as to demonstrate to mobile operators how to effectively work in an open source and open development model. If that had worked, we could have seen a precursor of today’s Firefox OS in 2009, rather than waiting four more years. Maybe some version of Firefox OS would be ascendant, and not the Android hydra.
It’s churlish to criticise Mozilla alone, when the rest of the LiMo membership frittered away any opportunity for leadership in web runtimes because they couldn’t play nicely together, but I do think Mozilla missed a trick by not adopting a platform approach much sooner. Even as late as 2010 key people at Mozilla seemed to have their head in the clouds, when I had a heated discussion about the importance of web runtimes at GUADEC. I suspect that today’s Firefox OS is more the result of luck and external enthusiasm around B2G rather than any clearly-planned advance strategy.
Thankfully I think the team at Telefonica have a clear vision of what’s needed from Firefox OS, and with their experience of running “the thinking man’s developer engagement” (BlueVia), I suspect they also have a good idea of how to take it to the developer market.
One factor that’s changed my mind significantly about the likely success of Firefox OS was my trial of the Nokia Lumia. With a limited selection of apps in the Windows Phone app store, I was forced to rely rather more heavily on web apps for some core functionality and to fill the gaps, to get me through the day.
When the Palm Pre first launched, many websites were simply unusable from a mobile device. My time with the Lumia showed me how far along the mobile web has come (and how far it still lags behind), but one thing was clear: in the last few years, it’s now become possible to survive with web apps and a good mobile browser. Many companies need to address the desktop market with good websites even whilst building native apps. For those companies in particular, being Firefox OS-friendly is a simple step and a no-brainer.
What’s eye-catching about the geeksphone announcement is the pricing of the new devices: the Keon is €91, and the Peak is €149. That’s a great price for a smartphone. I was curious to see how the specifications stack up against similar phones, so I did a quick comparison using information from the encyclopaedic GSM Arena.
I compared published specifications against the last attempt at a “web runtime” mobile device, the HP Pre 3. I also compared against the iPhone 5 and iPhone 4S, the Samsung Galaxy SII / SIII / S4, and the Lumia 920.
The raw data is below in a spreadsheet, but from first glance these geeksphone handsets are not bad devices, with some obvious economic trade-offs – mostly around CPU and memory. When comparing prices you’ll probably want to factor in a good fast microSD card since the phones are light on storage. It will be interesting to see how well Firefox OS performs on those CPUs – but given announced future devices are even lower-spec, I would hope that lots of optimisation will make them sufficiently usable.
The Keon should be fine for development, but for normal use I’d most likely go for the Peak. Based on the specification, it seems like a realistic day-to-day device. At this price point, they are cheap enough to risk some money on for experimentation.
Of course the raw data doesn’t cover things like differences between chipsets in real life – see Why a Snapdragon S4 Galaxy SIII Is Awesome for an interesting discussion of this.
Finally – there’s a Firefox OS Hack Day coming up in the UK at the end of May – which should be a good opportunity to do some development with the devices.
The raw stats:
Note pricing data is approximate. If you notice any errors or can provide any more details, please let me know.
Dominic Cleal’s short introduction to the Augeas configuration API.
We use Augeas a lot in libguestfs and virt-v2v, and it’s been very effective for us.
I asked Dominic how he made this video.
He uses gtk-recordmydesktop, max 100/100 audio/video quality, 30fps, 2 channel audio at 48kHz.
Sound and video are recorded at the same time, with a Sennheiser headset.
Editing is done in kdenlive.
The cabin has a double wall which will contain insulation. Shown here is the ring main for the four sets of sockets around the room.
This trench will take 1 armoured mains cable and 2 cat 7 network cables.
With the annoying brute force wordpress hack going round, one way to protect your site(s) would be to use fail2ban, with a configuration something like (which I’ve shamelessly lifted from http://blog.somsip.com/2011/12/protecting-apache-webservers-from-wordpress-admin-login-dictionary-attacks/ ).
The below seems to be working, and given it’s relative simplicity it’s obvious how you’d go about changing to protect other POST based scripts from brute force attacks. Obviously it’s not going to work if the attacker changes IP often (but from scanning the logs so far, it doesn’t seem to be the case that they are).
Obvious caveats :
In /etc/fail2ban/jail.conf :[apache-wp-login] enabled = true port = http,https filter = apache-wp-login logpath = /var/www/vhosts/*/statistics/logs/access_log maxretry = 5 findtime = 120
And In /etc/fail2ban/filter.d/apache-wp-login.conf :[Definition] failregex = <HOST>.*] "POST /wp-login.php ignoreregex =
Also (not shown) they dug a trench down the side of the garden for electrics and network cables. We’re going to run some hefty armoured cable, plus two or three cat 7 network cables, covered with bricks and warning tape, at a depth of 18″ (mandated by building regulations).