Here’s the ones I found, while looking at only the first two pages of my Spam folder (about two days worth of spams):

• A Logitech.com shipment notification;
• My monthly Yak invoice;
• My monthly ‘your invoice is ready’ from Citibank;
• The OpenDNS newsletter;
• Two commit notifications from Google Code;
• Three ‘your password has been reset’ emails, from WordPress.org, and other less known bulletin boards.

This makes me sad for multiple reasons. One is that while I have been able to catch some of them easily enough (the various reset password systems I used did point out that their email could end up in our Spam folders), I just found the others. That means I probably missed at least some other emails.

The second reason I’m sad is that now, I’ll need to go through all those spam messages to find the ones I care about! Not something I expected to do this morning, nor something that is particularly pleasant… Plus, I’ll need to repeat that every day now!

And finally, this make me sad because I trusted the Gmail team. I understand that spam filtering is not simple, but I would have greatly preferred for them to tweak their algorithm to push the balance in the other direction. It’s much easier for us to flag the occasional spam emails that would end up in our inboxes than to have to go through thousands of emails to find important messages!

Let’s hope the Gmail-Spam-Filter team hears this, and works toward a good resolution in a timely fashion.

What about you? How many not-spam messages can you find in your Gmail Spam folder in the next few minutes?

If you’re running Fedora (and that would probably work on other distros too), there’s a command you can run, as root, that will allow such programs to open any of those ports, even if they’re run by a regular user.

setcap cap_net_bind_service=ep your-program-name

Example:

setcap cap_net_bind_service=ep /usr/local/bin/znc

You’ll then need to restart the program, if it was already running.

That’s it.

Kudos to stevea, a very prolific poster of FedoraForums.org (he nears 5k posts), for his answer to this question asked by another user.

I tried to think what I might have changed since it worked fine. I tried reseting the CMOS, disconnecting all hard drives (IDE, USB, SATA) that were connected, except my primary drive, to no avail. OS was still very slow to load, and when I did let it load, I still measured 1.5MB/s transfer speeds using HDTune…

I finally found a solution. Disconnecting the SATA data cable from the first SATA port on the motherboard (where it was always connected), and connecting that same cable into the last SATA port. Bingo! Instantly, I’m back transferring files at decent speeds. I don’t know the exact cause of the problem, and I didn’t yet try that 1st SATA port with other hard drives, to see if the problem is with the port, or the hard drive & port combination. What’s important is that it now works fine!

I have to thank this guy for the idea on how to fix this.
I guess I would have tried that at some point, but at least now I know I’m not the only one who had this problem. And I’m reposting the solution here, just to insure anyone else who faces this particular problem in the future can find this solution faster than I did!

TV Forecast is a nice widget that Matt Comi created. You tell it what TV shows you watch, and it will keep track of the upcoming episodes for those shows.

The only down side to that widget is that it data-scrape TV.com to get its data.
Not only is this illegal, but it also tends to break the widget every time TV.com change their layout in any way.

Getting tired of that, I decided to open the widget’s code, and change the data source to something more stable: TheTVDB.com
They provide a quite stable API to query their database, which is user-maintained.
TVRage.com has something similar, but my eyes hurt each time I go on their site, so I picked TheTVDB for now!

Update: Another good reason to pick TheTVDB over TVRage at this time: TVRage XML feeds are currently unavailable.

TheTVDB offer a search service, so changing the search function of the widget was easy enough.

Fetching the next episode information was trickier.
The API doesn’t offer an easy way to do that. They only provide XML data of all the episodes of a show; this is quite a lot to download for a small widget, just to know what’s the next episode…
So I created a middle-man.
This data proxy queries the API for an answer, and will then cache the result for 24 hours (48 hours for not running series; 1 week for ended series), before it will refresh its information again.
That way, each client running the widget can query the data proxy, which can use cached informations to return answers very fast, and in a very efficient way.

Note that the files packaged below are still Matt Comi’s property. I do not pretend to now own them in any way. I redistribute them here to allow end users to continue using his nice widget until he has time to fix his widget himself.

So… want to fix your own TV Forecast widget? Here’s how:

- Right click ~/Library/Widgets/TV Forecast.wdgt and select Show Package Contents.

This in how this should look before you touch anything:

- Copy the files found in this archive one by one into the TV Forecast.wdgt directory. Do not attempt to copy the TV folder itself found in my archive, or you’ll remove necessary files from the widget.
i.e. You need to copy the files inside it, but not the folder itself.

There’s one new file (TvShowParser2.js) that goes in the TV folder, the rest are files I modified, so you need to overwrite the existing files with mine.

Here’s how it should look after copying the new files:

- Reload (Cmd-R) the widget, or remove then re-add it to your Dashboard.

- Remove and re-add all TV shows in the widget’s configuration.

For the curious ones, here’s the diff of all my changes, plus the code for the data proxy script used by the widget. Feel free to use that script on your own server, and edit TV/Functions.js to point to your version of the script. It requires PHP 5 and MySQL, among other things…

on adding folder items to target_folder after receiving added_items
    set volumeName to "USBDrive1" -- This is the display name of your external HDD volume; any of them if you have more than one.
    repeat with added_item in added_items
        if the displayed name of (info for added_item) is equal to volumeName then
            volumeMounted()
            exit repeat
        end if
    end repeat
    quit application "System Events"
end adding folder items to

on volumeMounted()
    tell application "System Events"
        -- Detach Folder Action
        try
            delete folder action "TV Shows" -- This should match the name of the folder you'll attach the FA to; i.e. to attach a FA to "USBDrive1:Music:TV Shows", use "TV Shows" here.
        end try

        -- Re-Attach Folder Action
        attach action to folder "USBDrive1:Music:TV Shows" using "Mac Mini HD:Users:me:Library:Scripts:Folder Action Scripts:Import TV shows into iTunes.scpt" -- First parameter is the folder you want to attach to, the second is the scpt file you want to execute as a FA for that folder.
    end tell
end volumeMounted

To use this script: Attach this FA script to the /Volumes folder and it should fix this problem.
To attach a FA to /Volumes, hit Cmd-Shift-G after clicking the + in the folder column of Folder Actions Setup.app, and enter “/Volumes” then click Go, then Open.

Here’s what I did.

Mount Andrew Escobar’ FrontRow Enabled DMG, and open
/Volumes/Enabler_1.3/Enabler.app/Contents/Resources/Scripts/main.scpt
This is the script executed when you execute Enabler.app

main.scpt told me I needed those two patch files:
/Volumes/Enabler_1.3/.frameworkpatch
and
/Volumes/Enabler_1.3/.pluginpatch

Download the Mac OS X Update 10.4.7 Combo PPC from Apple.

Use Pacifist to extract
/System/Library/PrivateFrameworks/BezelServices.framework/Versions/A/BezelServices
and
/System/Library/LoginPlugins/BezelServices.loginPlugin/Contents/MacOS/BezelServices
from MacOSXUpdCombo10.4.7PPC.pkg

Those are the two files that FrontRow Enabler is patching when you click the ‘Enable FrontRow’ button; I found this info in main.scpt

Patch both files using FrontRow Enabler patches:
cd ~/Desktop/10.4.7-BezelServices.loginPlugin/Contents/MacOS
cp BezelServices BezelServices.bak
bspatch BezelServices BezelServices.patched ~/Desktop/pluginpatch

cd ~/Desktop/10.4.7-BezelServices.framework/Versions/A/
cp BezelServices BezelServices.bak
bspatch BezelServices BezelServices.patched ~/Desktop/frameworkpatch
Use hexdump to be able to see the binary data of each file in clear text:
cd ~/Desktop/10.4.7-BezelServices.loginPlugin/Contents/MacOS
hexdump BezelServices>BezelServices.hex
hexdump BezelServices.patched>BezelServices.patched.hex

cd ~/Desktop/10.4.7-BezelServices.framework/Versions/A/
hexdump BezelServices>BezelServices.hex
hexdump BezelServices.patched>BezelServices.patched.hex
diff the original and patched files to see what the patches changed:
cd ~/Desktop/10.4.7-BezelServices.loginPlugin/Contents/MacOS
diff BezelServices.hex BezelServices.patched.hex

512c512
< 00026f0 4800 01d1 8101 0058 3821 0050 7f83 e378
---
> 00026f0 4800 01d1 8101 0058 3821 0050 3860 0003
Ok, so now I know what bytes needed to be changed in 10.4.7 to enable FrontRow.
Now I just need to find the same bytes in the new 10.4.8 files, and create patches for those files.

cd ~/Desktop/10.4.8-BezelServices.loginPlugin/Contents/MacOS
hexdump BezelServices>BezelServices.hex
grep -B 1 "2f83 0000 419e" BezelServices.hex
...
--
000faf0 bfc1 fff8 9001 0008 9421 ffb0 4bff febd
000fb00 2f83 0000 419e 0020 8001 0058 3821 0050
--
...
Close enough… Ok, so BezelServices.loginPlugin/Contents/MacOS/BezelServices needs to get it’s 000fb03 byte changed from 00 to 01.

cd ~/Desktop/10.4.8-BezelServices.framework/Versions/A/
hexdump BezelServices>BezelServices.hex
grep "0050 7f83 e378" BezelServices.hex

00026f0 4800 01d1 8101 0058 3821 0050 7f83 e378
Well, what do you know… Exact match. And at the exact same location (00026f0) than the 10.4.7 file; I guess this patch doesn’t have to be changed after all.

Close to a solution now; just need to create a new .pluginpatch that will patch the correct byte, and it should work fine.

sudo port install bsdiff
cp BezelServices BezelServices.patched
Now to patch the correct byte, I need an hex editor.
Seems 0xed would do fine.

To verify my patch:
hexdump BezelServices.patched>BezelServices.patched.hex
diff BezelServices.hex BezelServices.patched.hex

3804c3804
< 000fb00 2f83 0000 419e 0020 8001 0058 3821 0050
---
> 000fb00 2f83 0001 419e 0020 8001 0058 3821 0050
Perfect.

bsdiff BezelServices BezelServices.patched .pluginpatch1048
Now let’s repackage FrontRow Enabler with this new patch.
And done!

You can grab the new Enabler1.3.1.dmg here.
Warning: Don’t install that on anything else than 10.4.8! You’ll break your OS X install!