HTML shows as entities... whoops!

But alas, I use Opera, and strangely, this version doesn’t play well. Many links flat out don’t work, there’s weird Flash that Flashblock blocks with every page load, and worst yet, the thing is actually parsing A LOT incorrectly. Check out the below screenshot, and be sure to click on it for the full size version.

At first glance, you might think to yourself – that’s nice of Google, warning you that they are about to charge your card, a service which they do automatically to prevent you from having to take any action or lose your data. Except if you see this:

Apparently, they want me to pay $25 for 6GB of space, but everyone else gets the same thing for $20? My reward for being an early Google adopter is that I get to pay a steeper fee?

Is Google the next “Boston Market,” expanding too fast to keep quality at the same level? Lately, it seems like Google’s apps are quirkier, their service flakier, and their support non-existent. Is it a mistake to continue to entrust all of our data to Google?

click image for full picture

So I created a new tag D&psc=CONTACTS — and guess what? — it has some funny results. It searches all of your contacts’ photos for the letter D (which is common in default photo names, such as DSC001.jpg). Then I thought, “I wonder if I browse the JS source if I can find a command that is passed via URL GET variable that can be instantiated via an intentionally malcrafted tag?” I have posted on the Google USENET group and filed a bug through the standard complaint form. I consider this pretty big news, but I don’t want to submit it to digg or Slashdot or post on OSNews until someone has a chance to implement a fix, which is probably pretty trivial (URL encode the tag links) or fix it properly (validate tags on creation).

Anyway, I’m psyched, because I understand it’s pretty rare to find a bug in Google’s code.

As I’ve also detailed before, I have some problems with Firefox. In particular, a certain Firefox bug has pissed me off so much, not because of the bug, but rather, the fact that the Mozilla devs appear/appeared to be perfectly content with their decision, despite the arguments. I have blown off Firefox at home for the also-Gecko-based Camino. I am seriously considering blowing off Firefox at work for Opera.

But this is the real reason. It’s not just their XML arrogance. It’s this: Firefox is a mess when it comes to memory.

Click on the image for a full size view

Let’s break it down: Firefox allows developers to write extensions that utilize XUL, which means memory leaks could come from poorly written extensions. But as a user, my response is: I don’t care. If writing extensions can cause a WEB BROWSER to eat up over 1/2GB of memory, you’ve got a problem! Fix chrome! Fix XUL! Limit what the extensions can do! Otherwise, someone is going to release “Trusted Firefox,” or worse, offshoot Firefox to something simpler, something that is to Firefox what Firefox was to Seamonkey.

Camino, which doesn’t use XUL by the way, is much less featureful – sometimes annoyingly so, but guess what – it can runs for weeks without so much as a burp. This is Firefox after less than 24 hours with 6 tabs open, and the last 15 hours were of complete inactivity (overnight, while I was home).

I suspect this could be AJAX related (Gmail is always one tab). But since Firefox is my gateway to the web, it’s responsible for making sure the web plays nice through that window and correcting any behavior that makes it unhappy. And frankly, lately, it’s letting me down.

This is the bug, check it out and please vote for it.

Update: 17 minutes after I added my comment, the bug was re-opened. Thanks, Jake Olefsky!

So, I’ve written an elementary, temporary workaround for the multiple categories problem with Magpie. Essentially, rather than concatonating the categories, this script will use only the last entry in the RSS/Atom feed. It’s pretty basic, but it’s tested on PHP4 and PHP5 and it doesn’t change much code.

To use it, just save this file as rss_parse.inc and replace it in your magpie install. It’s based off of 0.7a, which is from the latest release of Magpie at this time, 0.72. You can find the code at http://firsttube.com/s/rss_parse.inc.phps.

bug in flip lite. apparently, yours truly did some poor function research. but i can’t be the only one to not realize that the time format for strftime() is not the same as date().

so, if you set $_locale to TRUE, you’ll find that unless you HAPPEN to use characters that work, you could end up with something very different than you though. worse, the locale is still server time – not client time. i would have assume that the http get request would include some sort of locale identifier which would be used in the strftime() gen, but no. not the case, apparently,

so i redid the time portion, and it will now customize, but not on a per client basis. instead, on a timezone basis using putenv() and strftime(). yes, this is all pretty geeky. but it works, dammit.