Somebody named Charles sent me a private message a few days ago asking for help with an issue he's having with AutoFLAC. Charles, if you read this, please either send me an e-mail or port your question to the Hydrogenaudio AutoFLAC thread instead and I'll get back to you. Due to a couple technical reasons I'd rather not discuss here, I have no way to contact you based on your private message.
The website migration continues in full force. I spent the last few days:
- Fine-tuning the theme; I'm pretty darn excited about it at this point
- Integrating a few modules to provide some needed capabilities
- Porting over custom and page-specific styles (such as the code blocks on my software pages)
- Updating the style of many of the static content pages to better reflect the new theme
- Reorganizing some of the menus and blocks to make navigation a bit easier
- Figuring out how to work around various Drupal oddities, such as the fact that it will not let you move the "My account" menu item to another menu block, or even rename the label
It's been a busy few days. :-) I still have a few more things to take care of, including the all-important database migration. Stay tuned.
In yet-another project that seems to be dragging out forever, I'm finally ready to begin final migration to the new LegRoom site. Anyone interested may check out a preview of the site here: http://drupal.legroom.net/
As you can probably guess by the URL, it's built with Drupal, and is currently running a slightly customized version of the default Garland theme (new for version 5.x). I originally planned on creating a completely original theme for the site, but it was taking longer to develop than I had anticipated. So, I plan on using this theme for the migration and initial few months of production while I work out any remaining kinks, then switch to that custom theme down the line when I have more time to work on it.
If you check out the site now, one of the things you'll notice right away is the lack of dynamic content (eg, news posts, comments, etc.). I've been working on a conversation script to migrate as much of the content as possible (or relevant) from my current PostNuke site. It's nearing completion, and I'll make the final conversion just before officially going live with the new site. More details about this conversion process will be posted later.
Most other, "static" content (such as my software pages) is already on there, though some of it is a little out of date now. This will all be brought back into sync during the week, and I hope to finish the conversion script for the dynamic content by this weekend. I fully intend on having the new site fully up and running by next Monday.
I don't plan on making any more changes to my PostNuke site from this point forward (other than status update posts like this) in order to simplify the migration process; I don't want to deal with updating and maintaining two separate websites for any longer than necessary.
I'd like to thank Steve Beitz (thisbeitz.com) for his continued assistance with design work for LegRoom.net. He's provided the main layout and design styles for the website since the very first version in late 2001, and even worked up a last-minute logo for the new site just last night. Thanks for all your help, Steve.
Finally, I'd like to mention that comments about and suggestions for the new site are most certainly welcome. I still have a bit of work to do before everything finalized, so now is the best time to share your comments.
Ok, so now that I have at least a couple hours of sleep to operate on, I'd like to briefly review some of the main features in Universal Extractor 1.5.
First of all, let's talk about the biggest change. This would be the inclusion of TrID. As discussed in this previous post, TrID is used to scan input files and determine the filetype through a signature analysis. The benefit here is that a Zip file (for example) will ALWAYS be supported, regardless of the file's extension. So, whether the file is named file.zip, file.jar, file.odt, file.dumbextension, as long as it is a Zip file it will be detected as such and extracted. This should greatly increase UniExtract's ability to reliably detect filetypes. Extensions are still used as a backup identifier in case the TrID scan is unsuccessful.
The next most important feature is the greatly increased format support. I've added support for several new installer formats, some lesser known and/or older archive formats, and updated support for a large number of existing formats. This release should more closely live up to its name than ever before. :-)
What else? I've added a few options to UniExtract itself, such as appending missing file extensions when possible, removing duplicate files, etc. These can be set in UniExtract.ini or during runtime when appropriate. I've also made some more enhancements to the installer to support these new options. I added four new translations to the release, thanks to some very generous contributions. I also made a significant number of changes/enhancements to UniExtract itself to make it more robust in certain scenarios, simply some of the code, and increase performance where possible.
The last couple items worth mentioning are bug fixes. There was an issue with 1.4.2 that prevented it from extracting files from some installers or self-extracting archives that had been compressed with UPX. One such package is the Firefox installer, which is why it was quite noticeable for me. I also updated the Inno Setup installer to version 5.1.9, which includes many updates for Windows Vista. I don't run Vista myself, so I can't support it's use or guarantee that UniExtract will run properly, but from some initial feedback it seems to be working pretty well so far. I'll explore this further as soon as I get access to a Vista system for testing.
I think that about covers it. If you haven't already done so, you can download and read more about Universal Extract from the following links. Enjoy.
Update: 02/22/2007 09:20 CST
I just pushed out an updated version of the 1.5 release. The original release was still labeled "beta", although it was final. I also included the Spanish translation. No other changes were made, so if you don't mind the fact that beta is included in the title (and you don't speak Spanish), there's no reason you download it again if you already have it installed.
After a ridiculously delayed development cycle, Universal Extractor 1.5 has finally been released. There are a LOT of changes and additions in this release, including some core functionality changes. Unfortunately, though, I'm way too tired right now to discuss any of them. :-)
I'll post a follow-up story tomorrow with more details regarding what's new, what's changed, etc. In the meantime, feel free to start playing with the new release. I think you'll find it a very significant improvement over previous versions.
I just posted an update to Convert to FLAC (convtoflac.sh). If you're unfamiliar with this app, it's a small but rather nifty BASH script that can transcode audio files from any lossless format to FLAC. So if you have a bunch of Monkey's Audio files, for example (which has very limited support under Linux), you could use Convert to FLAC to easily transcode all of your .ape files to .flac files with no loss of quality or meta-information. Granted, this app has a rather limited potential user-base, but if you're a Linux user and you work with lossless audio, you may want to check it out.
This update adds support for FLAC and WAV input files, allows the FLAC compression level to be set, and cleans up some more typos in the documentation section. Complete details, ChangeLog, and download links can be found on the Convert to FLAC page.
I'm currently working on the next version of Universal Extractor. During my research into what features should be included in the new release, I came across a couple of new applications that will provide a substantial benefit to Universal Extractor.
In no particular order, the first is cmdTotal. This tiny assembly program "is a generic approach to make it possible to use any Total Commander WCX packer plugin from a command line." This has been something of a personal holy grail for me, as there are a number of extremely useful plugins for Total Commander that could greatly benefit Universal Extractor, but in the past could never be used because Total Commander itself is a shareware product. cmdTotal changes that by letting my use these plugins directly from Universal Extractor. Thanks to cmdTotal and the associated plugins, I've been able to add support for five entirely new formats, as well as expand support for six existing formats. I'd like to thank Adam at KaKeeware for making this possible, as well as the personal assistance he provided to help make it work correctly with Universal Extractor.
Up next is TrID. TrID is a "utility designed to identify file types from their binary signatures." The ability to identify filetypes based on their signature rather than relying on their extension has been another long standing item on my todo list. I had looked at a few such applications in the past, as well as toyed with the idea of writing my own, but nothing was quite appropriate for integration with Universal Extractor. When I came across TrID, however, I instantly realized I had found what I was looking for. This program integrates very easily with Universal Extractor, recognizes a large number a filetypes by default (currently 2377), and is very extensible. I've been able to add definitions for several additional filetypes to TrID, as well as tune existing definitions to better suit my requirements. This has allowed me to greatly increase the reliability and robustness of Universal Extractor's filetype detection, and instantly expands its file support by adding recognition of any file that matches a particular supported signature regardless of extension. For example, I was recently asked to add support for OpenOffice documents, which use the ZIP format for storage. I tested a few samples with the 1.5 beta version, and it worked right away without the need for any code changes! I'd like to thank Marko Pontello for writing this immensely useful application, and for giving me permission to include it with Universal Extractor.
Thanks again guys!
Here are the full links to the product pages. Check them out!
I'd like to send a big, heartfelt "fuck you" to all of the assholes that have been posting comment spam to my site of the last year or so. Thank you so much for repeatedly wasting my time and energy on such pointless and meaningless work.
As I've mentioned in previous posts, the next version of my site is currently in development. Preventing (or at least severely limiting) comment spam is one of the primary design goals, so hopefully this should be much less of a problem in the future. I'd like to ask anyone out there who has experience with this problem - how have you dealt with it? My next site is built on Drupal. Are there any Drupal-specific modules or techniques that you would recommend? I've been doing research into this area myself, but I'd be very interested in hearing some first hand experience of what works (as well as what doesn't).
As for the current iteration of LegRoom, I've written a script that will let me easily:
- Delete the malicious registered user that is posting the spam
- Delete all spam comments made by that user
- Update all articles with the correct number of legitimate comments
Needless to say, this script saves a ton of time compared to searching for and deleting all spam comments one at a time. Big thanks to my buddy Bill for helping me with some of the SQL statements involved.
I'm making this available to anyone else that may be able to benefit from it. If you run a PostNuke site and have issues with comment spam, you should certainly check it out. If you download it, though, please pay attention to the PostNuke version listed in the Requirements. I strongly recommend testing on a backup copy of your database before running it, especially if you have a different version. This script has only been tested against the listed version, so please be careful not to delete any valid data.
You can download a copy of the script from here:
Have fun nuking those comments. :-)
Security guru Bruce Schneier has written a rather fascinating article on password composition and cracking. Security professionals in general would be interested in this, but in truth anyone using computer systems (read: you) should read and pay attention to this article.
Interesting statistics from the article: 24% of all analyzed passwords are recovered within minutes; up to 65% are cracked within one month.
You can read the full article at this link:
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. :-)