Lenovo laptops now feature what?

Each month, the online discount retailer Working Advantage has a sweepstakes for some hot item. For November 2012, it is a Lenovo IdeaPad Z580. I received the following email about it yesterday:

Working Advantage Lenovo IdeaPad Z580 November Giveaway features top sirloin steaks

Last time I checked, the IdeaPad Z580 had some neat features, but definitely did not come with top sirloin steaks! :razz:


Zoom 5341J cable modem

After moving back to the midwest United States, I was immediately reminded of the frustrations of dealing with the primary cable internet provider–Charter Communications. They offer fairly good speeds, and when considering the price, the performance-to-cost ratio is outstanding. However, the reliability of the service leaves a lot to be desired.

One of the primary problems when I lived here before was the really poor modems (and corresponding Charter-infected firmware) that they provided. Never fear, though, as I came back with my own modem… or so I thought. Apparently in June of 2012, Charter announced that customers can no longer use their own modems. So, with my service came a free lease of a Cisco DPC3010. Not a bad modem, barring the firmware that Charter has loaded onto it (which eliminates the administrative login credentials, and thus, one can’t look at the logs). Though there is a user account for logging in (Username: chtruser Password: charter), the administrative functionality has been removed. The modem, however, (and again, likely the fault of the Charter firmware, and not the Cisco modem itself) refused to channel bond on downstream (upstream bonding is not yet offered). As a result, my downstream speeds were abysmal by comparison to the rated speeds.

After arguing with the customer service team at Charter, I finally convinced them to provision my modem. I have a Zoom 5341J modem, which is a nice, affordable modem that supports up to 8 bonded downstream channels and up to 4 bonded upstream channels. Within its administrative interface, it also features information regarding the lock status, modulation, channel ID, frequency, power, SNR, and (un)correctable errors. The modem also has a hidden menu which can only be accessed by going directly to the URL:


replacing $MODEM_IP with the actual IP of the modem (which by default is, resulting in a full URL of This page shows all of the events in in the SNMP log, which is highly valuable information if you want to actively monitor your network status.

In any case, the new modem with the stock firmware (unmodified by Charter) is working beautifully with four bonded downstream channels (the maximum for my package). I strongly recommend the modem for its reliability and price point.


Keybindings and Openbox menu shortcuts for slock

After reviewing several solutions to a security problem regarding screen lockers, I’ve found that the easiest workaround for switching virtual terminals and killing the screen locker application is to start one’s X session with the following command:

exec startx

That way, even if someone switches to the virtual terminal that was used to start X and presses CTRL+C, he or she will only be presented with a login prompt (instead of having full reign of the user account responsible for starting the session). Now that there’s a reasonable workaround for that problem, I set out to make keybindings and menu shortcuts for Openbox that would take care of both locking the screen, and putting my displays to sleep. Conceptually, this was a straightforward task, and I accomplished it with the following:

Openbox menu item:
<item label="Lock screen + off">
<action name="execute"><execute>/usr/bin/slock</execute></action>
<action name="execute"><command>/usr/bin/xset dpms force off</command></action>

<keybind key="XF86Sleep">
<action name="execute">
<action name="execute">
<command>/usr/bin/xset dpms force off</command>

The only problem is that it doesn’t work every time. Though it tends to work nicely, there are times where slock will start, but the displays will not honour the xset command to go to sleep (I guess that when it comes to bedtime, monitors are a bit finicky like children :razz: ). I have tried adding a sleep time before the commands, thinking that there was some HID activity causing the wake, but that didn’t rectify the problem. If anyone has a proposed solution to the seemingly random failure of xset putting the displays to sleep, please let me know by leaving a comment.