For those of you that may be unaware, Firefox includes new Feed Preview capabilities in version 2.0. I discussed it briefly in a previous post:

A major issue that I have with RSS Preview is that Firefox will display this preview page even if the webmaster has already written an XSL transform to display the feed in human-readable form. I find this very frustrating, as I spent a lot of time styling the RSS feed for my site, making sure the look and feel matches that of the rest of the site, takes advantage of certain RSS elements available on my site that may not be available on others, etc. However, Firefox 2.0 ignores all of this and instead displays the feed using its own preview style. While this is a great feature for sites that only display raw XML, I strongly feel that Firefox should respect the webmaster's design if he's taken the time to create and specify a particular style/transform for the feed. At the very least there should be an option for users to enable the built-in preview style for all feeds rather than just raw feeds, with it set to only use the preview style for raw feeds by default.

As stated above, I think this is a great feature for sites that simply display raw XML output - I much prefer Firefox's Feed Preview page over that, as I'm sure most other Firefox users do. However, I still have a major problem with the fact that it will always override an RSS feed with this preview page, regardless of whether or not the developer has supplied his own style or extra content for the page. It's nice to know that I'm not alone on this, as evidenced by this 60+ post thread on the MozillaZine forums. Sadly, though, it seems that the core developers responsible for this change (ie, the ones that "matter") feel that their way is the way it should be done, users be damned. It's actually rather fascinating - read through that thread and count up how many people posted their objections, vs. how many people think it's a good idea. Then read through this bug report and do the same (also count the number of duplicates). Then read through this newsgroup thread and do the same. Anyone see a pattern?

I "solved" this problem for the feed on my own site with this lovely workaround added to the top of my feed:

This is a waste of space and bandwidth in order to appease Firefox 2.0's and Internet Explorer 7's feed sniffing.
By adding this extra and completely unnecessary text to the top of my feed, Firefox and IE7 will display the feed using
my own XSL stylesheet, as it should to begin with, rather than using it's built-in Feed Preview functionality.
You can thank the fine folks at Microsoft and the Mozilla Corporation for for the brain-dead implementation of what should be a very useful feature.

Thanks, Mozilla. Thanks, Microsoft. The reason I'm posting about this again today is because I recently came across some comments that seemed very familiar in VMware's RSS feed:

This is 512 bytes of nonsense, since the Firefox 2 developers, in one of the strangest decisions ever, decided they would obsolete XML styles by overriding them without permission. Furthermore, the developers appear to be disinterested in fixing this. Therefore, we use the unofficial workaround, which includes filling up the first 512 bytes of a document so that the sniffer doesn't encounter the RSS tag. I really enjoy using Firefox, but this particular behavior really annoys me! Anyway, since I'm almost at 512 characters, I'm going to ramble on for another minute in this comment, and then, without further adue, present you with a valid XML feed.

Thanks, Mozilla. In all seriousness, I truly appreciate the user-centric focus you take with your browser. The fact that I have a custom-made Get Firefox logo on my navbar, which is the one and only image/banner/link on my site that even remotely resembles an advertisement, should alone speak volumes of this. However, when such a large number of your own users come forward to ask that you fix an issue - not even remove it, just make it optional - please consider actually listening to what they say rather than responding with the same "our way is better than yours" comments over and over.

And while we're on the topic, please, for the love of all that is holy, fix this damn Tab/Window close bug. Once again, with so many of your own users reporting it as a problem (again, count the number of pro vs. con comments, as well as the number of duplicate bugs posted), consider the fact that the few of you who implemented this change just may be wrong. And once again, people are simple asking for an option here - not to completely do away with it, since some people seem to prefer this behavior, but make it optional for those that don't. At the very least, consider using the patch that I've already written.

Ok, that's enough ranting for now. I feel much better. :-)

I don't have much news to post as I'm out of town for the holidays, but I just wanted to wish everyone a safe and merry Christmas (especially those of you that are traveling). Enjoy the holidays!

It's taking longer than originally planned, but I'm happy to report that LegRoom v3 development is nearing completion. I'm still not quite ready to post a link to the development site (I still need to theme it, among other things), but since my last post about it in early November I've accomplished the following major tasks:

• Decided on a content management system (CMS)
• Ported static content (mostly anything that's not news posts and comments) to the new site
• Ported dynamic content (everything else, which includes news and comments) to the new site

Porting the static content took a while, as I needed to clean up a lot of the HTML and PHP in the process, but the real killer was the dynamic content. I had to write a rather long and complex PHP script to do the job, and while the results are not perfect (article formatting may not be correct, etc.), I'm pretty happy with the results.

The primary remaining issue at this point is the new LegRoom v3 theme. I also have various kinks to work out, but most of that can wait until the new site is operational. Optimistically I'm hoping that can be done before New Year's, but at worst I'm hoping by mid-January.

Stay tuned for a sneak peak.

I'm a bit late posting this (I believe it's already made it to Slashdot), but Michael Stutz recently published a good article on the IBM developerWorks site entitled, "Learn 10 good UNIX usage habits." From the introduction:

When you use a system often, you tend to fall into set usage patterns. Sometimes, you do not start the habit of doing things in the best possible way. Sometimes, you even pick up bad practices that lead to clutter and clumsiness. One of the best ways to correct such inadequacies is to conscientiously pick up good habits that counteract them. This article suggests 10 UNIX command-line habits worth picking up -- good habits that help you break many common usage foibles and make you more productive at the command line in the process. Each habit is described in more detail following the list of good habits.

It contains some very useful tips. I recommend that anyone using a CLI environment, regardless of your experience level, give it a read.

Full link:

http://www-128.ibm.com/developerworks/aix/library/au-badunixhabits.html

As found via Slashdot:

microbee writes: "On LKML's periodic GPL vs. binary kernel module discussion, Andrew Morton hinted that he favors refusing to load binary modules in 12 months. Greg Kroah-Hartman then posted a patch to do exactly that. Surprisingly Linus chimed in and called it 'stupid' and a 'political agenda,' and even compared it with the RIAA's tactics. Later in the same thread Greg withdrew his patch and apologized for not having thought it through."

Linus' post is a pretty good read on this debate. If you're unfamiliar with the topic, here is a brief overview. My personal take is that FOSS drivers are definitely the way to go, but being able to actually use my hardware takes precedence. If no viable (or comparable) FOSS driver exists, then I'd rather use a binary driver then simply not have full use of my hardware.

Anyway, as I said, it's a pretty interesting read. Here's a full link to Linus' post:

http://lkml.org/lkml/2006/12/13/370

SecurityFocus recently published a two-part article by Mikhael Felker covering security concerns with the password management functionality in both Internet Explorer and Mozilla Firefox. It's a pretty good read for anyone interested in such topics.

Here are the links:
http://www.securityfocus.com/infocus/1882
http://www.securityfocus.com/infocus/1883

LegRoom.net was down for a couple hours Thursday night, and again Saturday afternoon for a shorter period of time. This was due to a planned upgrade that didn't go quite as planned. However, all issues are now worked out.

So, what was the upgrade? The LegRoom.net server, as well as all associated network equipment, is now connected to a couple of brand new UPS backup units. These should provide about an hour of power for LegRroom.net should the main power fail/flicker/surge. This should hopefully keep things a bit more reliable in the future.

I just posted Universal Extractor 1.4.2. This version has a lot of improvements, including a fix for the crash issue in 1.4.1. Highlights include:

• Full internationalization support for installer
• New preferences page for installer to set history and debug options introduced in 1.4
• Four new languages included by default
• Various bug fixes for Windows 9x

The usual links:

Universal Extractor Download

Universal Extractor ChangeLog

Universal Extractor Feedback

Enjoy!

I made some improvements to the support scripts I use with my Inno Setup installers in the process of readying the Universal Extractor 1.4.2 release.

The biggest improvement was made to the Inno Setup CLI Help script. This script allows end-users to pass /?, /h, or /help to the installer package to get a list of available command line arguments. The new version supports custom parameters as well as the components and tasks lists that were available in the previous version. I also changed the delimiter, so if you use the script in your own installers, please be sure to read the ChangeLog.

I also updated the Modify Path Inno Setup script, but this was purely a documentation update to make it a bit more clear. No functionality changes were made.

As noted in the previous Universal Extractor post, there's an issue that can cause UniExtract to crash under certain circumstances. I've since had time to investigate the issue, and have determined UniExtract will crash anytime the archive is selected via the GUI browse button (the '...' button to the right of the "Archive/Installer to extract" field). This is due to an improper variable declaration that crept in during the 1.4.1 updates.

I've also determined that UniExtract will not crash if one of the other supported methods is used:

• right-click on file and use UniExtract context-menu integration
• drag-and-drop file onto UniExtract GUI
• select previous file from archive history

Of course, this isn't a solution, but it's a workaround for those of you that may have already installed it and are experiencing the issue. It also explains why some users have not reported it, as well as why I missed it during my testing (I generally test using the three methods above, which are faster for me than using the browse button).

I had planned on releasing 1.4.2 quickly to fix the issue, but there are some additional improvements that I want to make in 1.4.2 as well that's taking longer than I had anticipated to get working correctly. So, in the meantime I'm making available a "patch" (for lack of a better term) to fix the issue for current 1.4.1 users. You can download an updated version of the UniExtract.exe binary from here:

Edit: Removed download link. Please use UniExtract 1.4.2 instead.

Replace the copy of UniExtract.exe in your existing install with this new version, then use as you normally would. I should have a proper 1.4.2 release out within the next day or so, so unless you're currently affected by the crash issue, you may want to just hold off until then before upgrading.