Thus the overall fuel-to-motion efficiency of an electric motored car is: (59 ~ 62%) * 93% * battery_efficiency. Battery efficiency of Li-Ion batteries is well above 90% if I recall correctly. But assuming the worst, electric cars are at least 49% fuel-to-motion efficient.
In contrast, the fuel-to-motion efficiency of a car powered by an internal combustion engine hovers in the 35% range today due to market constraints on cars.
Note well that this analysis is generous to internal combustion engine automobiles because it does not account for the difference in energy cost for refining crude oil into typical automotive fuels like gasoline or diesel.
All network admins operate in the political domain. Several people here have mentioned that SSH forwarding works in China as I'm sure it does in Iran and Pakistan. Standard SSH on port 22 may just be too useful a tool socially and economically to block. As a consultant I find it rare to visit a shop that blocks SSH anymore even though most of the security admins that I know are well aware that with Putty you can forward any port inside to any port outside as you wish. Of the admins that I meet, most shrug this off as a non-problem saying:I know that users can circumvent any block on my firewall using SSH and port forwarding but the vast majority of my users don't have the arcane knowledge to do that.
We might not be the right people to ask since anyone on Slashdot could find Putty and the right configurations to do this in 15 minutes of searching on Google. And that assumes that the person asking is stuck on MS Windows. In Linux or OS X it's built into the OS.
I'd disagree that SSH is the best way to do this. A VPN is better because using a VPN allows you to hide in a class of users that the attacker wants to court and curry the favor of. The Chinese government wants our business so they must consent to our business people using strong encryption on our communications back home. SSH forwarding is one way to do this but a VPN is a much more common part of corporate IT security policy. If SSH is socio/economically difficult to block, a VPN is even more so.
Furthermore, since most of the methods that people use to discover brute forcing attempts rely on a high rate of attack, these slow attacks are immune. I'm not sure how the oft mentioned denyhosts works but the author of the original article is using FreeBSD and OpenBSD with the pf filewall which can blackhole brute forcers based on rate of attack. Using the pf method with settings aggressive enough to catch the latest round of attacks runs a high risk of blocking valid users. I'm seeing the same issue as the original article's author and I've noticed as he has that my OpenBSD boxes have not been targeted. FreeBSD, NetBSD, Ubuntu and Debian on the other hand.
My suggestion: Use Public Keys as much as possible. Systems allowing only Public Keys are immune to these attacks and you don't get the nasty log messages as well. If you must allow passwords disallow them for root. You can get root access by configuring sudo for users and via Public Keys for scripts.
# PasswordAuthentication no ## Best -- Public keys required for login
# PasswordAuthentication yes ## Only if you must.
# PermitRootLogin no ## Best -- root cannot login remotely.
# PermitRootLogin without-password ## Better -- root can login via key but not with a password.
Not sure I agree on the predatory ink pricing but I solidly see your point if you are looking at their cheapest inkjet printer. For color output I have an HP 2250 that I've been happy with. Ink is $130 for all four cartridges but lasts about 2000 pages. The 2250 was marketed as a SOHO printer when I bought it in the late 1990s (perhaps 1999) I bought the postscript cartridge and maxed the memory later. It's okay but the cost to print is considerably higher than the laser but I expected that when I bought it. My experience with the 2250 led me to convince my father-in-law to buy an HP 7210 all-in-one. This was a solidly bad decision. The ink is expensive, and the networking is completely non-standard. I spent a week chasing network bugs with it before kicking it to static IP. Even after that the driver software basically hung up windows at shutdown or reboot.This was for lack of a routine to handle the UserDrivenShutdown() event.
The program isn't debugged until the last user is dead.