Last week I got the dreaded flashing amber battery indicator on my ThinkPad X60, and it wasn’t the good kind of flashing.
It turns out that my battery was susceptible to failure by a known issue affecting some ThinkPad batteries. On Tuesday night I emailed Lenovo support, on Wednesday I received a response, and two days later there was a brand-new battery sitting on my doorstep.
Thanks, Lenovo.
The iPhone gets at most 8 hours of battery life during active internet and phone use, but lasts for 24 hours when the LCD is off during audio playback.
That’s a substantial difference in power consumption when the LCD is off. Granted, I’m sure it employs a myriad of other power optimizations during audio playback and standby mode, but my best guess is that turning off the LCD probably has the single greatest effect on battery life.
Leave it to Apple to design a product that encourages people to press a sleep button every single time they put the device down. It’s hard enough for a lot of people to remember to shutdown their computers overnight, let alone do something as simple as turn the off the lights when they leave the room. Yet something inherent in the design of the iPhone compels its users to press the sleep button in between every short use of the phone.
Why don’t we do this on laptops?
I’m not talking about putting them into sleep mode in the traditional meaning of the word, but why isn’t it common practice to switch off power to the LCD when you’re momentarily not using it?
In class last week, I realized that I was using my laptop only about every 4-5 minutes, which was just long enough for the “black” screensaver to kick in, but the whole time I wished there was a way to just go straight to powering down the LCD instead of having to wait the 30 minutes for it to happen automatically.
By pure coincidence, I stumbled across this post over at Ubuntu Brainstorm a few days later, which almost exactly describes what I had been wanting. No one’s come up with a real working implementation of the idea yet, but several commenters suggested the following command,
xset dpms force off (more info)
which will immediately put the screen into a power saving mode. It wakes back up after keyboard or mouse input, just like a screensaver.
This could be integrated into all kinds of clever scripts, but all I want is a quick hotkey to run it. I used the Commands settings in CompizConfig (there are probably a hundred other ways to do this) to establish the following hotkey:
<Super>Z: sleep 0.2s && xset dpms force off
sleep 0.2s is there to delay the command just long enough that the press of the hotkey itself doesn’t immediately wake the screen back up.
I also thought it would be nice to do this when locking the screen too. Accomplishing this was just a matter of disabling the original <Control><Alt>L hotkey and establishing a replacement:
<Control><Alt>L: gnome-screensaver-command --lock && sleep 2s && xset dpms force off
Most laptops already power off the LCD the when you close the lid, so I’ve heard it suggested that people should just use that instead. It does save power, but it’s just not as convenient as it could be. It takes more time to close the lid than it does to tap a hotkey, and opening the lid back up again is one extra step that could be avoided. In many situations, such as in the classroom, it would be considered inappropriate to repeatedly open and close a laptop all the time. It makes noise and it’s visually distracting. Besides, it’s not uncommon for people to want their laptops to enter a full suspended mode when the lid is closed, which makes the lid mechanism unusable for a quick LCD switch off in the first place.
Vimperator is the smartest thing I’ve seen in a very long time. If you haven’t heard of it, just go check it out. It’s one of those life-changing sort of things that’s just better experienced firsthand.
Now what could make Vimperator even better? You guessed it, Vimperator with Colemak. We’ve already got a Colemak mapping for Vim (thanks, everyone), so it only makes sense that there should be a mapping for Vimperator as well.
Download it. (Updated for Vimperator 1.0)
And let me know what you think. Naturally, this is all very experimental stuff.
For some context, here’s the .vimperatorrc I’m currently using:
" Colemak remapping
source ~/.vimperator/colemak.vim
” Restore normal window title
set titlestring=Mozilla Firefox
” Show the address bar
set guioptions=T
” Open all dialogs in a new tab
set newtab=all
” Disable the audible bell
set visualbell
” Select all
imap <C-a> <C-v><C-a>
” Use the nicer address bar
noremap o <A-d>
noremap t :tabopen<CR>
” Easier pass-through
noremap ‘ <C-v>
noremap ” <C-q>
noremap \ ‘
I noticed today that there was a fairly large discrepancy between the disk usage of my storage drive and that of its rdiff-backup mirror. And the difference in size was not an error of excess on the side of caution - the storage drive contained 189GB of data, but the backup only 106GB. What accounted for the 83GB of un-backed up data?
To find out, I decided a diff of the filesystem contents would be appropriate, or whatever the filesytem analogue of a diff might be. Google didn’t yield favorable results fast enough for me, so I figured I’d just throw a recursive directory listing into a typical diff utility and see what comes out.
That turned out to be a bad idea. Each recursive directory listing was about 20MB / 500,000 lines long, and Meld really didn’t like that. I afterwards discovered that Meld actually has a directory comparison feature too, but it appears to be intended for project source directories and, not unexpectedly, choked again on the dual root filesystem scans.
Now diffs are cool, but I don’t really need that much resolution of detail when trying to find 83GB of difference. Gnome’s Disk Usage Analyzer ended up being just what I needed in this situation. Check it out:
The difference is easy to spot. And luckily I was able to recognize the culprit as a collection of archives that I moved from an external disk not long ago.
That made it sufficiently clear that the only thing going wrong was that for some reason backups just weren’t happening. And while that is still a bad thing, it’s far preferable to the monstrous irrecoverable corruption scenarios my wandering mind had been envisioning this whole time.
When it comes to rebooting a frozen Linux system, QWERTY keyboard users have it easy; spell “busier” backwards or simply raise some elephants.
Typing REISUB gets a little trickier on alternative keyboard layouts, however. While the familiar fancypants GUI might be properly informed of an unusual key arrangement, these low-level kernel commands remain forever mapped to their original QWERTY locations. What used to be REISUB on a QWERTY keyboard becomes P.COGX on Dvorak, and PFURLB on Colemak. I use a custom variant of Colemak with a few keys switched around to my personal preference. On this layout, REISUB becomes GFUSLB.
But is it really such a great idea to blindly reboot your computer immediately after it has catastrophically frozen? When I realize I’ve done something bad enough to make my Linux system freeze, I like to take a short breather, power down, and think about what went wrong. I like to have a chance to think about what I need to do when the system boots back up. I might, for example, have to catch GRUB to insert a one-time boot option, and with only a three-second time window to do that, I have to know it ahead of time. So instead of REISUB, I really prefer to turn off the system with REISUO, or on my keyboard layout, GFUSLY.
That’s really hard to remember. It’s not even pronounceable - So what’s needed here is a good mnemonic. I asked around and got the following suggestions:
That last one stuck best, and I’ve since used it several times to shut down frozen systems.
This is an odd one. For some crazy reason, updates to my ThinkPad X60’s screen produce noise in the audio out jack. The larger the area updated, the louder the noise.
I think it’s a hardware thing. Pulling the plug out of the jack just a little bit makes the noise go away.
Not sure how to look into potential causes of this.
