Lifestyle Creep
As far as I know, this Mint blog post coined this phrase, but I actually like this post from diveintomark.org that covers the some topic of happiness through simple living (things like shedding material attachments).
Debian/Ubuntu Package Installation Shortcut
Alt-F2 then type
Here's an example where I install XBMC:
Then just click Install:
This example is with Ubuntu's default window manager, GNOME, but should work basically the same way in any other window manager, just not as pretty. *ducks*
apt:packagenameSimple, quick, and should work in any window manager. Just remember that package names are case sensitive and almost always lowercase.
Here's an example where I install XBMC:
Then just click Install:
This example is with Ubuntu's default window manager, GNOME, but should work basically the same way in any other window manager, just not as pretty. *ducks*
Synergy for HTPC control
Synergy. Great app.
Synergy for HTPC control. Great application.
Setup is pretty simple, but the Synergy HOWTO on the Ubuntu Community Documentation was pretty horrendous. I decided I'd give back a little and did a major clean up/rewrite of it and now it is actually usable.
The one technical contribution I made was to speed up the X/GDM scripts slightly. Instead of:
Now if someone would just write a synergy client for the Android platform I could get rid of Gmote and all it's quirks.
Synergy for HTPC control. Great application.
Setup is pretty simple, but the Synergy HOWTO on the Ubuntu Community Documentation was pretty horrendous. I decided I'd give back a little and did a major clean up/rewrite of it and now it is actually usable.
The one technical contribution I made was to speed up the X/GDM scripts slightly. Instead of:
/usr/bin/killall synergys sleep 1 /usr/bin/synergysIt is now:
/usr/bin/killall synergys while [ $(pgrep -x synergys) ]; do sleep 0.1; done /usr/bin/synergysYou could say it saves less than a second. Or, you could say it's about a 10x speedup :-)
Now if someone would just write a synergy client for the Android platform I could get rid of Gmote and all it's quirks.
Waking Up is Hard to Do
Since I couldn't possibly write it any better, this is plagarized from the user page of a random Gnome developer:
Conclusion: I have a cruel alter ego who wakes up when the alarm goes off, disables it for who knows what reason, laughs mischeviously, and then goes back to bed.
- 2:00 AM: Set alarm for 10 am (physical switch)
- 2:03 AM: Tape piece of paper over alarm with the text "Why are you ruining my life?"
- 2:07 AM: Go to bed
- 2:15 AM: Fall asleep
- ??? AM: Alarm is switched off, and the piece of paper is retaped over the alarm by a mysterious force. Abducted by aliens? Gremlins? Cruel alter ego?
- 12:17 PM: Wake up with no memory of the alarm being disabled. Paper is still taped over the alarm like the alarm was never turned off (?!?)
- 12:18 PM: Perform thorough exam for signs of alien abduction: scars, incisions, chips in the back of my neck, probes in various orifices. Results, negative
- 12:19 PM: Inspect apartment security fixtures. Deadbolt: in place. Physical chain slider thing: in place. Pole blocking sliding glass door: in place. Grill over fan vent in bathroom: in place. Gremlin trap: empty
Solution: Tie myself up before going to bed.
Problem: How do I get out of bed when I'm back to my calm mild mannered normal self?
Better FOSS QA Testing
I just had a random thought when I came across the following in the Changelog for VirtualBox 3.1:
This is great, except – Wait, no, that's not what I meant to say. This sucks. Of all those beta users who downloaded gizmo-0.9beta how many actually tried using, say, the HTTP proxy feature? Or ran the application over a dial-up connection? Or ran on 64-bit OS X?
There are all kinds a solutions to this problem, all of which could be integrated into one of the many software project managment tools out there like code.google.com, Trac, sf.net, etc.
Ask for an email address when before reaching the beta download link and follow up a week later asking the user to fill out a quick report about the environment they ran the software in and, optionally, a list of the programs features they used. Click a green check next to the feature if it worked properly, and a red X if the feature did not work. After the form is submitted, post a screen with links to the effect of "Click here to submit a bug report for your problems you experienced with xyz"
Take that one step further and ask for permission to collect information about the environment the first time it launches. If the user is willing to loose anonymity they can also enter their email address and the form they they are emailed one week later will be pre-populated with as much information about their environment/usage experience as possible.
Even better, turn this data into any number of cool visualizations which are publicly available in real time. Developers can quickly see what aspects of the software are problematic and, more importantly, what environments have not been test much (or at all). Hopefully they would decide to make some sort of concerted effort to get test coverage for those areas. And by making the data public and easily accessible in the form of pretty charts, users can see how well tested the application is on their particular platform/processor/new-fangled-peripheral.
Okay, that's enough ranting for tonight.
Mac OS X hosts (64 bit): don't interpret mouse wheel events as left click (bug #5049)This seems like something basic that should have been caught in a beta release, but it didn't because there is no way to monitor the use case coverage. The typical QA process for most FOSS applications is to release a Beta version, watch the bug reports pour in, fix them, and repeat.
This is great, except – Wait, no, that's not what I meant to say. This sucks. Of all those beta users who downloaded gizmo-0.9beta how many actually tried using, say, the HTTP proxy feature? Or ran the application over a dial-up connection? Or ran on 64-bit OS X?
There are all kinds a solutions to this problem, all of which could be integrated into one of the many software project managment tools out there like code.google.com, Trac, sf.net, etc.
Ask for an email address when before reaching the beta download link and follow up a week later asking the user to fill out a quick report about the environment they ran the software in and, optionally, a list of the programs features they used. Click a green check next to the feature if it worked properly, and a red X if the feature did not work. After the form is submitted, post a screen with links to the effect of "Click here to submit a bug report for your problems you experienced with xyz"
Take that one step further and ask for permission to collect information about the environment the first time it launches. If the user is willing to loose anonymity they can also enter their email address and the form they they are emailed one week later will be pre-populated with as much information about their environment/usage experience as possible.
Even better, turn this data into any number of cool visualizations which are publicly available in real time. Developers can quickly see what aspects of the software are problematic and, more importantly, what environments have not been test much (or at all). Hopefully they would decide to make some sort of concerted effort to get test coverage for those areas. And by making the data public and easily accessible in the form of pretty charts, users can see how well tested the application is on their particular platform/processor/new-fangled-peripheral.
Okay, that's enough ranting for tonight.
Easy, automated backups with rdiff-backup
Let me start by saying rdiff-backup is exactly the tool I set out to find when looking for a backup solution. It makes use of librsync so you get all the goodness of the rsync remote-delta optimization algorithm, plus incremental backups. To top it off, your most recent backup is stored as a simple mirror so recovering your most recent backup of a given file is just a matter of (s)cp'ing it.
To setup automated, unattended backups (the holy grail of data backups) I used a good HOWTO guide for setting up unattended backups. so I won't duplicate that; I'll just summarize and detail the parts that are unique to Debian or ARM/embedded systems (I'm running Debian squeeze on a SheevaPlug). For simplicity, I'll use the same machine names as were used in the original HOWTO – kitty for the backup server and fishie for the machine to be backed up. I'm only backing up one home directory on fishie for a hypothetical user we'll call nemo.
- First, install rdiff-backup on kittie and fishie:
sudo apt-get install rdiff-backup
- Create an account for your backup bot:
adduser --system --group --disabled-login --disabled-password --home /var/backupbot backupbot
My 1 TB USB hard drive is mounted at /var so that is where I place the home directory. This also follows the FHS guidelines. - Create a public/private key pair for backupbot, copy it to the authorized_keys file of nemo@fishie, then test it:
sudo -s -u backupbot ssh-keygen -f ~backupbot/.ssh/id_fishie ssh-copy-id -i ~backupbot/.ssh/id_fishie.pub nemo@fishie ssh nemo@fishie
- Assuming the above commands worked, you should now be logged in as nemo@fishie. Open an editor and prepend the following to the long line of gibberish that was just added to ~nemo/.ssh/authorized_keys
command="rdiff-backup --server --restrict-read-only /home",from="kittie",no-port-forwarding,no-X11-forwarding,no-pty
Now any SSH session that is authenticated using this key will (1) automatically launch rdiff-backup in server mode and (2) have several SSH features disabled (for extra security). - As backupbot, open ~backupbot/.ssh/config (sudo -u backupbot emacs ~backupbot/.ssh/config) and enter the following:
host nemo-backup hostname fishie user nemo identityfile /backup/.ssh/id_fishie compression no protocol 2Some notes about these options:
- I don't use root to log into the remote machines because I'm only backing up home directories. This means you should take care to not to create files within your home directory that you do not have read access to (or at least keep them confined to one subdirectory so that rdiff-backup can skip them with a simple --exclude option). To find and fix any files that you may have already created while (e.g.) running as root use the following command:
sudo find ~nemo -not -user nemo -exec chown nemo:nemo {} + - The first time I ran a backup I used 'compression yes'. I promise never to do that to you again, poor little SheevaPlug. If you have a slower link speed or a faster CPU then compression may make sense. For more optimization you may want to experiment with 'cipher blowfish' option. It can supposedly run at 88% of the speed of 'cipher none' but I haven't had a chance to play with it myself.
- I don't use root to log into the remote machines because I'm only backing up home directories. This means you should take care to not to create files within your home directory that you do not have read access to (or at least keep them confined to one subdirectory so that rdiff-backup can skip them with a simple --exclude option). To find and fix any files that you may have already created while (e.g.) running as root use the following command:
- The last step is to automate the backup. Run sudo -u backupbot EDITOR=emacs crontab -e. Add the following crontab line:
30 0 * * * rdiff-backup nemo-backup::/home/nemo /var/backupbot/nemo && rdiff-backup --remove-older-than 3M /var/backupbot/nemo && echo "Backup successful"
This will run a backup every night at 12:30 AM and delete any incremental backups older than 3 months.
Ugh... Why the paranoia, Transmission!?
Just wasted an hour because of the janky configuration setup for an otherwise great BitTorrent daemon, Transmission. Basically, the default configuration for Transmission that ships with Debian has RPC authentication turned on in two places. Finally discovered this by reading the README in /etc/transmission-daemon (*blush*). This pointed me to Message #24 of bug 539936 which explained things nicely. Solution summary:
- Stop transmission-daemon
- Turn off RPC authentication in
/etc/transmission-daemon/settings.json
- Turn off --auth parameter in
/etc/default/transmission-daemon
- Restart transmission-daemon