Parrying

This moment when Daigo parried Chun Li’s super and countered with an ultimate combo cancelled into his own super, turning around the entire match and defeating his opponent in the process. This went down in history as one of, if not, the ultimate tournament comeback.

EDIT: He pulled it off AGAIN! And in mid-battle! He still lost the match, though :-(

How difficult is it to do that parry-and-counter combination? Pretty difficult if this is anything to go by…

C25K – Week 9 Day 3

I completed C25K Week 9 Day 3 (4.83 km), in 27:32, pace 05:42 min/km, with @RunDouble http://rndb.co/R5BK

The final run of the training plan. I went slow on this run, but kept the speed fairly constant throughout the run.

The next run is a full, non-stop 5K. Aiming for around 28:00 (my current 5K PB is 21:28), then will try out the Nike+ 5K trainer again, then either use the C210K at RunDouble, or Nike+’s 10K trainer.

Work has been interfering with my running schedule recently, and my Fuelband picked up on that:

Nike+ - Chromium_001

Worst mobile networks for London rail commuters revealed – Telegraph

A new study has revealed the shocking state of mobile connectivity on commuter routes into and out of London.
The study by Global Wireless Solutions (GWS) rigorously tested the ten most popular commuter routes, and found that one in three mobile internet tasks and one in seven voice calls on commuter trains fails.

EE, O2 and Vodafone all rely heavily on their older 2G networks and ‘half-rate codecs’ (which increase network capacity at the expense of audio quality) to cover commuters. This means that call quality can be poor and many data packets are dropped.

Overall, the study found that Three (which does not have a 2G network) is most reliable network for commuters who like to talk, while Vodafone’s subscribers get the best 3G data service and EE subscribers get the best 4G data service.

Worst mobile networks for London rail commuters revealed – Telegraph.

File Backups – Thoughts

I have used rsnapshot a lot in the past to provide snapshots in time for my backup purposes, and I loved how I was able to to pull data from remote machines to backup locally. However, doing the reverse seemed to be a lot trickier. I wanted to push backups to a server instead of have the server pull data. Because when the server started its backup routine, some machines may be switched off. So rather than the server be responsible for backing up the clients, I wanted the clients to be responsible for backing themselves up onto the server itself.

rsnapshot didn’t seem to lend itself to easily to do this, but then I thought “why not use sshfs?”. With sshfs, I can mount a directory from a remote SSH server on the local filesystem as a directory, use that as a the snapshot root and it should work. The only downside is that since rsnapshot must run as root to do a full system file backup, it also means the sshfs must be mounted as root too, and therefore it tries to connect as root to the remote server. This might be fine if you wanted to do a full remote system backup, but enabling root SSH access is a potential security hole. Possible workaround this by making a standard user who is a member of the root or admin group (haven’t checked whether this would work yet.)

Then I found out about rdiff-backup.

rdiff, for those unfamiliar with the term, is rsync diff (or reverse diff, depending on your school of thought.) It uses the rsync algorithm (the same used by rsnapshot) to create a diff file (or delta) which, when applied to a file, can produce another file – a bit like patching using a patch file. Since we only save the differences between a file and its other version, the actual storage space is low.

rsnapshot utilises hard links to store same versions of files across multiple backups, but has a full copy of each new version. rdiff-backup stores the latest version, and stores diffs that enable you to go back to a previous point in time.

In this sense, rsnapshot works like a full backup style, storing each new version in its entirety, whereas rdiff-backup works as full-plus-(reverse) differential. Restoring from the latest backup on either tool takes the same time, but restoring from an older backup would take longer for rdiff-backup, because it would have to assemble that particular version of the files via the diff files, whereas with rsnapshot, the full version is stored (although at the cost of more space). rdiff-backup works great for files which change often, but change only slightly. Rsnapshot works great for files which change rarely, but change entirely. Using a combination of both might be a good idea (say, use Rsnapshot for /home and rdiff-backup for /var and /etc)

%d bloggers like this: