BBC History of Music and Technology – 01 – The Story of Sound Recording
I was just listening to the discussion of the Samsung SwiftKey keyboard vulnerability from Security Now! episode 513, and I came up with a simple DNS-based mitigation that a user could implement to protect themselves.
Without any user interaction, the user’s phone makes a plaintext http GET request to a SwiftKey update server, and this request can be hijacked and malicious code injected into the phone by any man-in-the-middle bad actor. According to NowSecure, the discoverer of the vulnerability, the request looks like this:
With a rooted Android phone, a user could edit their
/etc/hosts file to redirect the hostname of the update server (
localhost, preventing the http GET request from ever leaving the phone. In other words, the user is hijacking the request to the update server before a bad guy gets the opportunity to do the same.
With a non-rooted phone, there are DNS Resolver apps that can be installed that do the same kind of redirection to
Will this kind of mitigation work? Since I don’t have an Android phone to test against, this is just a thought experiment for myself.
Why is Lent 40 days long, why is Passion Week 7 days, and why was Jesus “in the earth” for 3 days? Further, why do we celebrate his birth on the solstice and his resurrection on the equinox?
This essay by Alvin Boyd Kuhn explains it all, and it blew my mind. Good reading for an Easter weekend.
Teresa and I use a single Dropbox account to share files between our computers. I also use the same account to store (and sync) plain-text notes on my iPad and iPhone (I use the apps PlainText and iA Writer). In case things go wrong with these apps, the syncing, or with Dropbox itself, I want to backup my Dropbox files and keep past snapshots of the backups so I can go back in time.
rdiff-backup can do this. It is a command-line tool written in Python that:
…backs up one directory to another, possibly over a network. The target directory ends up a copy of the source directory, but extra reverse diffs are stored in a special subdirectory of that target directory, so you can still recover files lost some time ago. The idea is to combine the best features of a mirror and an incremental backup.
To make this all happen, I have Dropbox installed, signed-in, and running on my Linux desktop/server, which runs Ubuntu 11.04 Natty with Gnome 2.
# aptitude install rdiff-backup
I use the directory
/backup/ to hold all my backup targets, so I can run
rdiff-backup like this:
$ rdiff-backup \ --exclude $HOME/Dropbox/.dropbox \ --exclude $HOME/Dropbox/.dropbox.cache \ $HOME/Dropbox /backup/Dropbox
Every time I run
rdiff-backup like this, it creates a new snapshot of my Dropbox files. Old snapshots are kept until I decide to purge them (if at all). To purge any snapshots older than two months, for example, I run this command:
$ rdiff-backup --force --remove-older-than 2M /backup/Dropbox
I run the above two commands in an
@hourly crontab script to keep this all happening automatically.
Browsing Past Snapshots
rdiff-backup has its own commands for digging into the files stored in the past snapshots, but it requires exactly knowing the filenames and backup times. Another tool, rdiff-backup-fs solves this problem by mounting the rdiff-backup backup directory as a FUSE filesystem, allowing me to
find my way through a directory tree of all snapshots.
After installing FUSE and
rdiff-backup-fs, I mount my Dropbox snapshot tree with this command:
$ rdiff-backup-fs ~/mnt /backup/Dropbox
Note that the order of the arguments for mounting source and target are backwards compared to the canonical
A long listing of my 10-oldest snapshots looks like this:
$ ls -lF ~/mnt/ | head -10 total 0 dr-xr-xr-x 1 root root 4096 2013-03-10 13:52 2013-01-06T05:00:01/ dr-xr-xr-x 1 root root 4096 2013-03-10 13:52 2013-01-06T06:00:01/ dr-xr-xr-x 1 root root 4096 2013-03-10 13:52 2013-01-06T07:00:01/ dr-xr-xr-x 1 root root 4096 2013-03-10 13:52 2013-01-06T08:00:01/ dr-xr-xr-x 1 root root 4096 2013-03-10 13:52 2013-01-06T09:00:01/ dr-xr-xr-x 1 root root 4096 2013-03-10 13:52 2013-01-06T10:00:01/ dr-xr-xr-x 1 root root 4096 2013-03-10 13:52 2013-01-06T11:00:01/ dr-xr-xr-x 1 root root 4096 2013-03-10 13:52 2013-01-06T12:00:01/ dr-xr-xr-x 1 root root 4096 2013-03-10 13:52 2013-01-06T13:00:01/
I can then explore all my snapshots at once with any tools wish.
When done, I unmount the rdiff-backup-fs filesystem with:
$ /bin/fusermount -u ~/mnt
Last Thursday, I put Teresa in the water at the town of Peace River to begin her 9-day solo kayak expedition to Fort Vermilion. You can follow her progress by clicking on the map below:
I recently needed to update the BIOS on a Dell Inspiron 630m laptop. The file, available from Dell support, is a DOS executable named MX51_A04.EXE.
I had two problems with this file: (1) Windows would not boot, so I couldn’t run the file using Windows. (2) The laptop had no floppy drive, so I couldn’t easily boot into DOS.
Now, one can solve this problem by booting from a FreeDOS LiveCD to run the file. But then you have to figure out how to get and run the MX51_A04.EXE file from within the FreeDOS environment. Various websites suggested methods using USB flash drives, but I couldn’t get this to work.
Instead, I was able to add the file to the LiveCD ISO image before I burnt the CD. Here’s how it worked:
- Download the FreeDOS LiveCD called fdfullcd.iso (153MB).
- Under Linux or Windows, install and run ISO Master.
- Load the fdfullcd.iso in ISO Master and then add the MX51_A04.EXE file to it.
- Save the modified ISO under a new name.
- Burn the modified ISO to a CD and boot from that.
- When you boot the laptop using this modified FreeDOS LiveCD, be sure to choose the LiveCD mode and not the install option.
- Once you have a DOS prompt, the command X: will switch you to the X: drive, where you’ll find the contents of the CD and the BIOS update file.
- Run it, cross your fingers, and reboot.
I like using the online dictionary at die.net because it’s fast and clean.
It’s easy to query, also. Just append your word to the end of the URL. For example:
It describes itself as offering “free cross-referenced definitions, spelling correction, and word searches from WordNet, Webster’s, FOLDOC, and a variety of specialized sources.”
On serverfault.com, Rory McCann asked, “What’s the best terminal editor to suggest to a Unix newbie? i.e. not vi or Emacs.”
This answer, which purposefully ignores the original poster’s restriction, says it best:
Because time invested in learning an editor is productive only as long as you keep using that editor. All those less expressive options are poor choices for the long run, and will be abandoned eventually. At which point the time spent learning them is wasted, and the user still has to learn Emacs or vi.
In other words, the best (most expressive) tool for the job is one of Emacs or vi, and so you’ll eventually switch to one of them. It ultimately doesn’t matter which one you choose, but you would be smart to invest yourself into learning one of them.
For the record, I’m a vim user, and I love using it.
My favourite song of all time is “The Christmas Song” as arranged by Shigeru Umebayashi. It comes from the soundtrack of the brilliant film 2046, whose story takes place in and around Christmas.
Listening to it really makes me happy. It’s light and bouncy, and really swings.
I hope you enjoy it too!
“The Christmas Song” by Shigeru Umebayashi (4.5 MB ogg)
I just learned tonight that Wil Wheaton has a new podcast out, called Memories of the Futurecast.
The podcast is a promotion of his latest book, Memories of the Future, Volume One, which is Wil’s going-down-memory-lane review of the first 13 episodes of Star Trek: The Next Generation.
I listened to the first episode of the podcast already, and I’m looking forward to hearing the rest (12 of 13 have been published so far, as I write this). I enjoy everything Wil Wheaton does.