I've had a Palm Treo 700p for a couple years and a Treo 650p before that, both with Sprint as a wireless carrier. The 700p acted up a few months ago, so I took it into a Sprint repair center. They promptly wiped it, upgraded the firmware and gave it back to me as "fixed." Only, it wasn't fixed. I'm not sure, but I think the firmware they upgraded me to wasn't intended to ever run on a 700p, but I'm not sure. As a result, the phone has kinda-sorta worked since then.

I've read on Engadget about a new phone exclusive to Sprint from Samsung called the Instinct. At first glance, it looks eerily similar to an Apple iPhone, but as I read more about it, it looked like it might be a good fit for me.

Boy, was I wrong.

Before I go into some specifics, let me just say that Samsung and Sprint can easily save this phone. All they need to do is open it up just a little more and listen to the "corporate" users.

What I liked

One thing I liked about the Instinct is that it does not run Windows Mobile. I've avoided Win-Mo on principle, but have helped other people with problems on Win-Mo devices and have experienced the frustration that is running Win-Mo. Using a Palm Treo vs. a Win-Mo Treo is the difference between night and day. One operates like cold tar (and has a lower video resolution) while the other is relatively stable and snappy.

The Instict is an awesome phone, it just isn't quite a "smartphone" and definitely isn't a geek's phone.

The "haptic feedback" is very cool: The phone generates a mild vibration when you touch an active icon on the touchscreen, thereby giving you physical feedback that you've activated a button or other onscreen feature. This goes a long way toward alleviating the "flatness" problem a lot of touchscreen devices have.

The Instinct has a very nice GPS navigation program that plots routes and gives you turn-by-turn directions. This is an amazing feature for a mobile handset that nets you $129 after rebate.

The sound quality of the phone is very, very good, both as a handset and as a speakerphone. Kudos to Samsung for that.

The web browser is "okay." It's better than the Blazer browser on the Treo, but it's not quite what it wants to be which is a browser that people will want to use more frequently than just when they're desperate for something off the Web.

The camera (still and video software is included) is, by far, the best cell phone camera I've ever used. Wow! It lacks a flash, but performed pretty dang well in low-light.

The Instinct has "visual voicemail" which is bound to become a de facto feature on new phones moving forward. Very cool.

Plugging the phone into a USB port on my laptop running Linux worked well. Linux detected a USB mass storage device and let me mount it. If I understand correctly, it's just acting as a card reader for the mini-SD card. This gives you access to all the non-phone media like pictures, movies, and music.

What I really didn't like

E-mail was a dealbreaker. The Samsung/Sprint e-mail client software tried to be very accomodating and provides wizards for setting up mobile e-mail accounts for popular webmail sites like AOL, Hotmail, Yahoo!, and GMail, but doesn't quite deliver as more than a basic e-mail client in any other regard. It does let you set up multiple POP or IMAP accounts and supports SSL-encrypted access for privacy wheres supported. However, I don't believe it's a true IMAP client because it only displays 25 of your most recent messages (I think you can bump that up to 100 in the settings) and doesn't let you access IMAP folders other than Sent, Inbox, and Trash.

Browsing HTML e-mail messages is lame because, while the Instict does take a stab at parsing the HTML, it only displays the text and does not give you any links which you can click on to view on the phone's browser.

E-mail attachment support is nonexistent.

While I don't care, the Instinct only offers a bare minimum support for Exchange users via Outlook Web Access and doesn't sync with Exchange (or anything else, for that matter).

Speaking of synchronization, Sprint does offer a remote sync feature that let's you store your contacts and other data on a remote server. The benefit of this is that if your phone is stolen or broken, you still have access to your address book. Additionally, Sprint provides a web-based facility for you to manage your contacts.

I thought this was going to be cool. I could just export my contacts from KDE's address book and import them into Sprint's web facility and, voila, all the contacts I've had on my Treo would instantly be available to me on the Instinct.

The Sprint import facility had instructions for Outlook users to export their contacts as a CSV file and even went as far as to indicate what column names were valid and would be recognized by the import routine. I tweaked the CSV file my system generated to match the column headings Sprint wanted. The import process took several minutes and then told me it couldn't import anything. Game over.

The in-phone address book is terribly lacking. For starters, there's 's no way to store a company name with an entry, only last name or first name.

Text messaging was... okay, but cumbersome.

Typing text on the Instinct is not too bad, but has some serious caveats. While the text entry routine provides spellcheck on-the-fly, it doesn't provide spelling or grammar correction on the fly at all. That seems odd considering just about every phone I've used the last ten years or so has had that. It should at least auto-conjugate and insert apostrophes when I type "cant" or "doesnt." Nope, won't do it. Even a lone "i" surrounded by whitespace on either side remains lower case. It's smart enough to capitalize the first letter after punctuation and it will highlight mispelled words (including my un-conjugated conjunctions). Tapping on a mispelled word will offer suggestions, but this is a time-consuming affair!

I registered as a developer on Sprint's Developer website hoping to create some cool third-party apps for the Instinct -- fill in some of the gaps, but got discouraged rather quickly.

In one of the developer forum posts, a developer asks, "Is there a desktop USB SDK for access to the Calendar, Notes or any other built-in data? " A Samsung developer replied: "There is no USB SDK/API supported on the Instinct."

The Sprint sales representative who helped me purchase the Instinct told me, up front, the Instinct did not support tethering so I could not use it as a wireless modem for a laptop. I thought I'd investigate that a little further before I gave up on it -- see if it looked like it would be forthcoming as an official capability or as a third-party software add-on, but it doesn't look good.

End result?

I'll be taking the Instinct back to Sprint in the next day and will either purchase a Palm Centro instead or give their technicians another shot at fixing my 700p.

Samsung and Sprint need to assign some hardware interaction and usability people to this phone. Not only are most of the applications painfully minimalistic and basic, they're not as easy to use as they could or should be. 

Again, this could be a good smartphone for Sprint if they give more attention to the needs of "professional" users.

Listen to any kind of syndicated talk radio program and you'll usually hear about some companion website the program has. Usually, there are a handful of free things you can get on a program's website, but many of these sites have a pay-to-play members' area where the really good content is. This includes MP3 downloads of the shows, access to live audio and/or video streams, special behind-the-scenes content, forums, desktop backgrounds, etc.

The MP3 downloads are very convenient for people who don't have the luxury of sitting in front of a radio (or driving a car) for a solid three hours while a radio program is broadcast (with advertisements). It's also a boon for people who find radio advertisements annoying.

The only problem with the MP3 downloads is that theme music and produced portions of the program can not, by law, be included in the MP3 file because otherwise the MP3 would be a copyright violation.

Live streams, on the other hand, are not subject to the above described restriction because they're like a broadcast in nature. They're not a time-shift of the original program. So, if you listen to the live stream or even listen to a pre-recorded program as a stream, music and produced segments may be included.

I listen to the Glenn Beck radio program quite often. I used to download the MP3 files to listen to in the car, but it got annoying everytime Glenn and his producers would put together a segment like "Sportscasters at the 2031 animal-human hybrid baseball games", or "The History Of the Democratic Superdelegates" and I would hear Glenn say, "Listen to this... [pause] Oh man! That was great! Wasn't that great, Stu? Oh yeah! Alright! Dan? Wasn't that just the best? Yeah. Oh yeah."

I decided I needed to figure out how to save a stream.

I knew it was possible. Lots of software applications exist for any operating systems that will convert audio from a live stream into a static WAV file or similar. The open source program mplayer is one such example.

Breaking it down

First of all, I needed to figure out how the stream content made its way to my computer.

After I've logged into the Glenn Beck website as an Insider, I can click a link to listen to a stream of a particular hour of the program (or the whole program) in Windows Media format or RealAudio format. I figured I'd have better luck extracting the audio from the Windows Media format, so I went that route. Instead of just clicking the link and letting my web browser find some program that could handle the content, I saved the content to a file and then looked at the file.

The file it saved was a fairly straightforward XML file that looked something like this:

<ASX VERSION="3.0">
  <TITLE>Glenn Beck</TITLE>
  <AUTHOR>Premiere Radio Networks</AUTHOR>
  <COPYRIGHT>Copyright 2008</COPYRIGHT>

 <ENTRY>

    <TITLE>Glenn Beck 1</TITLE>

    <AUTHOR>Premiere Radio Networks</AUTHOR>

    <COPYRIGHT>Copyright 2008</COPYRIGHT>
 

    <REF HREF="mms://a0011.v67134.c6713.g.vm.akamaistream.net/7/0011/6713/v08060322/glennbeck.download.akamai.com/6713/_!/shows/2008/06/03/GLENNBECKWIN20080603.WMA?auth=blahblahblahblahblah" />

    <REF HREF="http://a0011.v67134.c6713.g.vm.akamaistream.net/7/0011/6713/v08060322/glennbeck.download.akamai.com/6713/_!/shows/2008/06/03/GLENNBECKWIN20080603.WMA?auth=blahblahblahblahblahblah
  </ENTRY>

  <ENTRY>

    <TITLE>Glenn Beck 2</TITLE>

    <AUTHOR>Premiere Radio Networks</AUTHOR>

    <COPYRIGHT>Copyright 2008</COPYRIGHT>

    

    <REF HREF="mms://a0011.v67134.c6713.g.vm.akamaistream.net/7/0011/6713/v08060322/glennbeck.download.akamai.com/6713/_!/shows/2008/06/03/GLENNBECKWIN20080603_CLIP01.WMA?auth=blahblahblahblahblahblah" />

    <REF HREF="http://a0011.v67134.c6713.g.vm.akamaistream.net/7/0011/6713/v08060322/glennbeck.download.akamai.com/6713/_!/shows/2008/06/03/GLENNBECKWIN20080603_CLIP01.WMA?auth=blahblahblahblahandblah" />

  </ENTRY>

...and so on.

This XML defines the MMS URLs for each segment of the show. There are several segments each hour. These individual MMS URLs are what I needed to feed to the application that was going to convert the audio stream to a file. In my case, I decided to use mplayer because it's just so good at everything it does!

The command line for doing the stream-to-file conversion looks like this:

mplayer -vc null -vo null -ao pcm:fast:file=dumpfile.wav \
    'mms://a0011.v67134.c6713.g.vm.akamaistream.net/blahblahblah...'

The real magic in the above command is where I use -ao pcm to tell mplayer to use the PCM file writer audio output driver (instead of sending the audio to my speakers).

This gives me a WAV file which I'll want to convert to an MP3 or Ogg-Vorbis file.

To convert a WAV file generated by the mplayer command above to an MP3 file, I use the open source lame tool:

lame -mf -q2 dumpfile.wav GlennBeck.mp3

Or, convert it to Ogg-Vorbis (the completely open and better-sounding-than-MP3 lossy audio codec):

oggenc -q2 --downmix -o GlennBeck.ogg dumpfile.wav

I've now covered the basic mechanical components of converting an audio stream into an MP3 or Ogg-Vorbis file. Next I automate it all.

Automation

Because I'm a long-time Perl junkie, I investigated how I could use a Perl script to act as the glue between the components and get the whole process of capturing a stream and converting it to MP3 or Ogg-Vorbis.

In the above walk-through, I manually logged into the Glenn Beck website with my web browser. To really completely automate this puppy, I wanted the script to log in for me. It didn't take me very long to figure out the Perl CPAN module WWW::Mechanize was what I needed to use.

WWW::Mechanize does several handy things for the programmer. It loads and parses web pages and can follow links, populate forms, and other basic kinds of interaction. It keeps track of its own cookies and session data too.

To get into the Insider area of the Glenn Beck website, members must enter their username and password on the Insider login page.

Looking at the HTML source for this page, I learned the form was named "aform", the username field was named "iUName", and the password field was named "iPassword".

I now had all the information I needed for WWW::Mechanize to log in:

my $agent = WWW::Mechanize->new(
    cookie_jar  => {},
);
   
my $resp = $agent->get('http://www.glennbeck.com/content/insider');
   
if($resp->is_success) {
    $resp = $agent->submit_form(
        form_name   =>  'aform',
        fields      =>  {   'iUName'    =>  'myusername',
                                'iPassword' =>  'shhhhhhhh!', },
        button      =>  'submit');

Walking through the code above: First, I create the WWW::Mechanize object with an in-memory cookie jar (cookie_jar => {}). Next, I use the object to get() the log-in page. If everything works well so far, I tell the object to find the form named "aform", fill in the username and password fields, and submit the form.

One thing I realized as I was debugging my script was that after I logged in on the Insider page, I was immediately redirected to another page. In order for my script to work, it needed to follow the redirect. This was an easy fix:

my $agent = WWW::Mechanize->new(
    cookie_jar  => {},
    redirect_ok => 1,
);

The page I got redirected to has the links on it for the streaming audio, so I'm exactly where I want to be if I want to capture and convert the latest and greatest Glenn Beck Program audio stream.

WWW::Mechanize can find links within the page with a variety of methods. One of these leverages Perl's excellent support for regular expressions. You can also search for links by the order in which they appear. The link I'm looking for looks like this:

<a href="http://www.premiereinteractive.com/cgi-bin/members.cgi?stream=shows/GLENNBECKWIN20080604&site=glennbeck&type=win_show"><img src="http://media.glennbeck.com/images/common/header_media5off.jpg" name="icon5" width="26" height="34" border="0" id="icon5" onMouseOver="MM_swapImage('icon5','','http://media.glennbeck.com/images/common/header_media5on.jpg',1)" onMouseOut="MM_swapImgRestore()" /></a>

So, my script has the following:

$link = $agent->find_link( url_regex => qr/${datestr}.*win_show$/);
$resp = $agent->get($link);

This assumes I have a scalar variable $datestr that contains a formatted date for the show I want to capture.

Originally, I was going to use one of Perl's several XML-parsing modules to make sense of the XML in the stream link, but in the end all I needed was a regular expression to extract the mms: URLs.

my $xml = $resp->decoded_content;
my (@urls) = $xml =~ m/HREF="(mms:[^"]+)"/msg;

This gives me a list of URLs stored in @urls. Now I just need to feed them to mplayer:

$i = 1;
foreach my $u (@urls) {
    my $seq = sprintf("%02d", $i);
    my @cmd = ( 'mplayer', 
            '-vc', 'null', 
            '-vo', 'null',
            '-ao', "pcm:fast:file=${datestr}-${seq}.wav", 
            $u);
    system(@cmd);
    if ($? == -1) {
        print "failed to execute: $!\n";
    }
    elsif ($? & 127) {
        printf "child died with signal %d, %s coredump\n",
        ($? & 127),  ($? & 128) ? 'with' : 'without';
    }
    else {
        printf "child exited with value %d\n", $? >> 8;
    }

    $i++;
}

This little ditty creates an output file for each of the segment streams. These are named something like 20080604-05.wav.

When the loop is finished, I have several WAV files sitting on the disk. Now I need to somehow sew them all together into one big WAV file so I can convert it to an MP3 or Ogg-Vorbis file. For this, I turn to sox. I decided to have the Perl script generate a shell script to run all the sox and lame commands needed.

open FH, ">/tmp/${datestr}.sh";
foreach my $j (1..($i-1)) {
    my $seq = sprintf("%02d", $j);
    print FH 'sox ', "${datestr}-${seq}.wav", " -t raw - | cat >> /tmp/${datestr}.raw", "\n";
}
print FH 'sox -w -s -c 1 -r 22050 ', "/tmp/${datestr}.raw ${datestr}.wav\n";
print FH "lame -mf -q2 ${datestr}.wav ${datestr}.mp3 ";
print FH "--tt \"Glenn Beck Show - $datestr\" ";
print FH "--ta \"Glenn Beck\" --add-id3v2\n";
close FH;

Then, I run the shell script:

system('sh', "/tmp/${datestr}.sh");

Finally, I do a little cleanup:

unlink "/tmp/${datestr}.sh", "/tmp/${datestr}.raw", map({"${datestr}-$_.wav"} (1..($i-1)));

And, I'm done. There are many other ways I could have gone about doing this, but I found a way that worked and ran with it. I'd love to hear from people who have done something similar and how they did it.

On Tuesday, 13 May 2008, the Fedora Project released the latest version of their Linux distribution, Fedora 9.

I was able to get my hands on Fedora 9 the previous Friday after it was discovered "in the wild" on BitTorrent networks. I promptly installed it on my Dell Latitude D830 laptop that I use every day for work.

The downside to installing a Linux distribution like Fedora before it is officially released is that you have no access to any updates. You're kind of on your own with what you've got until the official release date.

I wasn't too terribly worried about any of that. After all, Fedora 7 and Fedora 8 were, for the most part, very stable from the get-go.

I think I may have been wise to have waited. Over the last week, I've encountered all sorts of issues. Some have been related to specific hardware I'm using while others are general OS issues. A significant chunk of the issues I've run into are a direct result of my running KDE as my desktop environment. Fedora 9 includes KDE version 4 which is a ground-up rewrite of the fundamentals of KDE.

The experience has given me some flashbacks to 2003 when Red Hat Linux 9 came out with GNOME 2.2. I had been a GNOME user for a couple of years (and used AfterStep as my primary desktop environment before that) and was content with the way the Sawfish window manager worked in GNOME up until Red Hat Linux 9. Now GNOME used the Metacity window manager and I couldn't stand the thing. Where were all my configuration options? What happened to everything I had come to rely on? Well, GNOME had tucked it all away... and made everything work slower while they were at it.

I switched to KDE and found it had advanced leaps and bounds since I had looked at it last. It was mature, reliable, and, most of all, it offered plenty for me as a "configuration nut" to appreciate.

Fast forward to now. KDE4 is cool, very cool, but it's lacking a lot of stuff KDE3 had, understandably. I'm sure it's all forthcoming in due time, but I want it now!

So, below is my current list of annoyances. Some are still outstanding while others I have taken steps to resolve and have documented those steps below so that others may benefit.

Fedora 9 Annoyances

• nVidia video driver - I've got a nVidia Corporation Quadro NVS 140M tucked away in this laptop and to get 2D and 3D accelerated performance out of it, I must use the proprietary nVidia driver available for Linux. I usually get this from the fine Livna repository for Fedora. The kmod-nvidia driver was available from Livna, but it didn't work. I got it to function (details coming) but it's far from perfect.
• Tap-to-click not working on Synaptics touchpad - This is a documented bug and I'm sure Fedora will be pushing a fix soon. In the meantime Bob Kashani at Berkeley has gracefully provided a fix.
• kmix applet is missing - This one is annoying. I have grown very accustomed to having the kmix applet in my KDE taskbar. This gives me a handy mixer utility to control my sound. Without it, I'm forced to launch the kmix application every time I want to adjust the mixer. Lame.
• Font irregularities (related to NVidia?) - Application fonts between KDE and GTK/GNOME applications display differently. This has suddenly been a problem, but it isn't the first time I've seen it. I also saw it with Firefox 3 betas under Fedora 8, but only on this particular system (my laptop) and not on other systems. I blame the nVidia driver.
• Multimedia buttons - The volume up/down and mute buttons just worked out of the box with Fedora 8. With Fedora 9, KDE is completely ignorant of them.
• NetworkManager forgets everything - In Fedora 7, there was a separate KDE NetworkManager component called knetworkmanager which integrated seemlessly into KDE, but major changes within the NetworkManager community forced the Fedora project to adopt the GNOME NetworkManager work for KDE users in Fedora 8 (and Fedora 9). The problem in Fedora is that NetworkManager doesn't seem to be using the GNOME keyring system at all. Every time I connect to a secure wireless network, I have to enter the encryption key or passphrase because it isn't getting saved anywhere.
• KPilot not syncing with Palm Treo 700p via USB - This was fixed with the first Kernel update!
• KDE configuration lacks depth - This is due to the rewrite of everything, but there are things that really bug me: No configuration of the Compose key and I haven't found a way to turn off the silly "Pong" sound the system plays every time I move between virtual desktops.
• No web browser can load Zimbra admin login page - I didn't have any problems with Firefox 2, but neither Firefox 3b5 nor Konqueror can load the Zimbra admin page. Konqueror complains about a script out of control and Firefox 3b5 just sits and spins.
• gpk-application sucks - Pirut (and pup) are gone and now we have this PackageKit suite of applications for managing packages. I think it's a good idea in the long run, but gpk-application has a long way to go before it catches up with how well pirut worked. Just let me install many packages at once, why don't ya?!

Well, there's that for starters. I'll probably be blogging more in the future about these problems in more detail, including, hopefully, how to solve or work around them.

After the MiniDV videotape camcorders and before the explosion of hard disk camcorders,
several manufacturers were making these camcorders that would record directly to DVD media. A handful of them recorded to full-size DVD media, but most recorded to a small (~3 inches in diameter) mini-DVD media. One of these discs can hold about 30 minutes of SD (740x480, 30 frames per second) video or about 1.4GB of data.

A couple years ago, I was working on a video editing project and one of my sources was from one of these mini-DVD camcorders. One of the perks of the mini-DVD format is you can throw it right into a DVD player and it plays it, without much grief, like a normal DVD movie. There's even a scene-selection menu that shows you thumbnails of images to select scenes recorded on the DVD.

I think the mini-DVD format was a great idea for people who just want to videotape an event and throw it in the DVD player, but it's not so good for someone who wants to edit the video on the computer. The camcorder manufacturers probably shipped the cameras with some kind of conversion program to extract the video from the discs and convert it into an editable format, but since I didn't own one of these mini-DVD camcorders, I didn't have such software.

A little googling and I found the answer!

Check out this command:

mplayer dvd://1 -dumpstream -dumpfile dvd.vob

This mplayer command may be familiar to those who rip video from DVDs to convert it to an MPEG4 format or something similar.

I can't edit a VOB file, so I needed to convert the VOB into, preferably, an AVI. Most of the AVIs I edit are DV format AVIs that I get off my DV camcorders. I knew if I could get the video on the mini-DVD into that format, I'd be in heaven. I didn't find a direct way to do this, but I did find two more steps that would do it.

ffmpeg -i dvd.vob -target dv dvd.dv
cat dvd.dv | dvgrab -f dv2 -s 0 -stdin

The first command (ffmpeg) converts the VOB into raw DV data. This is data you could stream to a camcorder and store on a tape. It's not in an AVI container, but it's close. The next command (dvgrab) is usually used for capturing video from IEEE 1394 (Firewire) video devices, but being that it has an option (-stdin) for reading data from standard input, we can use it to convert our raw DV data to an AVI.

Voila!

Aaron's a good guy and a productive contributor to the local open source community, but he's blogging again about how we should all stop using proprietary instant messaging protocols and only use open protocols like Jabber/XMPP.

I'm a long-time satisfied user of open source software and of Jabber/XMPP instant messaging. I would love to see the whole world embrace Jabber as the One True Instant Messaging Protocol just as the whole world has embraced SMTP as the only viable protocol for sending e-mail. That being said, I am repulsed by Aaron's "you shouldn't use that software because it's not Free Software" message.

I know many in the open source culture have had more than their fair share of the Richard Stallman Kool-Aid and believe religiously there is something morally wrong with software that doesn't come with source code and a license to do whatever you want with it. I'm not one of those people and I think it's an immoral philosophy.

In my opinion, open source software is about choice and having choices. You should use whatever software fits your need best. I don't think the fundamental principle behind open source or Free software should be to stigmatize people from using non-open, non-Free software.

Now, I'm not defending the practices of the purveyors of proprietary instant messaging protocols. Clearly, Yahoo, MSN, and AOL have all exhibited their various dark sides trying to circumvent the interaction of unofficial client software (both open source and otherwise) with their chat systems. But, they have the right to do so! Eventually they'll learn it's futile. :)

If you write software for the public to use, you have choices on how you want to distribute it:

• You can withhold the source code and charge for the use of it.
• You can withhold the source code but give the software away for free.
• You can provide source code.

I'm generalizing here, but my point here is that it doesn't really matter how your software is developed or distributed. The public will choose based on many variables such as cost, ease of use, accessibility, etc.

Not many people will actually care whether or not the source code is available. What most people will care about is how well the software works and what the cost is to them to use it. Cost is and always will be a compelling reason to choose open source software, but you can't ignore the features of the software itself.

Case in point: Adobe Photoshop is still priced quite high for the average user. While open source alternatives like GIMP continue to gain competitive ground on Photoshop, users continue to pay Adobe's price because Photoshop provides what they need and the price is worth the benefit.

On the other hand, if someone buys Adobe Photoshop to crop and resize photos, I think they're a complete idiot!

I think the software playing field is like any other market and the capitalist in me says, "Let the market decide!"

Wouldn't it be nice if no one ran Windows and everyone ran an open source operating system?! Yes! It would be AWESOME! In fact, I think Microsoft is doing a wonderful job of pushing many of their users in that direction with XP and Vista, but they're also trying very hard to produce software to convince users it's worth the price for the benefit they receive.

The Free/open alternatives should be able to (and usually do) compete on their own merits. We shouldn't go around telling people they're behaving in an immoral way for choosing the software they choose. We should definitely inform everyone of the benefits of using open source software, open protocols, open standards, etc., and, as a community, we can continue to improve the software we're personally involved with.

Now, as a note,I don't think many companies are adopting proprietary solutions for internal instant messaging. They're using some Jabber/XMPP platform (some of which are commercial, proprietary implementations). As this phenomenon spreads, as more people are using XMPP, I believe it will become the de facto standard and other protocols will either fade away, adapt to become compatible, or become niche. If and when it prevails it will be because it is the best solution and not because of the lobbying power of a bunch of self-righteous nerds.

Vocal supporters of this "abandon all proprietary messaging platforms" bandwagon are opposed to the efforts of projects like Pidgin -- an open source, multi-protocol messaging client -- which they claim only perpetuates the use of these bad closed, proprietary messaging platforms.

Hogwash! Pidgin is an excellent example of open source software that was created to meet growing demands of users. Is it perfect? No! But it epitomizes open source software and continues to evolve toward more of what its users may want.

I'm going to continue to use Pidgin as it does a fantastic job of simultaneously allowing me to converse with my contacts via AIM/ICQ, Yahoo! IM, MSN Messenger, Google Talk (based on XMPP), several IRC servers, and several Jabber/XMPP servers. For what it's worth, I communicate via IRC and Jabber more than anything else.

I think this will be the last interview video from the 2007 Utah Open Source Conference. This is Derek Carter of NeverBlock talking about Xen, virtualization, and his history using and teaching about Linux and open source software.

I think I may be able to put together video for one more conference session, but otherwise, we're pretty much done with video for the 2007 conference. We're looking forward to doing a better job of recording all the keynotes and sessions at the 2008 conference.

You can see this video and many others by going to my YouTube Open Source TV playlist, or by visiting the UTOSF YouTube group.

I've uploaded two more videos to YouTube for OpenSourceTV.tv.

First, we have an interview with Clint Savage of the Utah Open Source Foundation and the main driving force behind last year's first Utah Open Source Conference.

Next, we have an interview with Scott Paul Robertson (AKA "spr") who gave a presentation at UTOSC 2007 on Django and who is also the author of one of my favorite open source utilities: oggify.

I've got at least one more interview to edit and upload and we also have other content coming soon as well.

You can see Clint's interview and Scott's interview and many others by going to my YouTube Open Source TV playlist, or by visiting the UTOSF YouTube group.

Our good friend Jesse recently posted an article on his blog saying, "NOW is the time [for Perl] to step up!!!" Jesse mentioned a discussion going on inside the Ruby on Rails community in which at least one significant member expressed frustration with the lack of intelligent software architecture methodology put into Rails. I think he called other RoR contibutors "a bunch of half-trained PHP morons," which goes a long way -- in my book, anyway -- toward describing something akin to building an automobile out of toothpicks and rubber cement.

Jesse suggests this is the perfect time for Catalyst to make a entrance. I couldn't agree more.

Catalyst is a Perl web application development framework that compares, in some ways, to Ruby on Rails. Catalyst does a fine job of providing developers with a solid MVC framework for developing web applications, but I think what makes Catalyst so formidable is that it also leverages much of the excellent Perl code available from CPAN, the global distributed repository of reusable Perl component code.

Yeah, Catalyst is awesome. I'm thrilled to be using it for a project at work right now. That may come as a surprise to people who have heard me describe KnowledgeBlue as purely-Java shop, but the company is adapting to better exploit the skills available just as I am taking steps to learn more about Java development.

Catalyst needs a lot more (well-written) documentation. There is an excellent tutorial -- Catalyst::Manual::Tutorial -- that is distributed in POD format as part of the Catalyst::Manual package, but even after going through this tutorial, a Catalyst newbie is likely to still be doing some head scratching.

The tutorial is great, really. It walks through setting up a connection to a database backend with DBIx::Class, creating templates using the all-powerful Perl Template Toolkit, and using the Catalyst tools to magically provide authentication and program flow.

The problem, however, is that Catalyst, can do so much, it can be difficult to grasp how to do simple things. The complexity of deploying a simple application approaches what a JSP developer must do. The difference is that after a JSP developer edits several configuration, source, and HTML files, he or she has a simple web application that says "Hello World." The Catalyst developer might spend the same amount of time and end up with a "Hello World" application in a very extensible MVC framework. From there, it requires a minimal amount of work to extend the application, for example, to send its output in PDF format or to get its "Hello World" message from a web service.

In addition to wrapping your mind around all that Catalyst can do and how to do it is the large number of Perl packages you must install. This is less of a burden than it used to be because a lot of Linux distributions provide the fundamental packages necessary for Catalyst development like Catalyst::Runtime, Catalyst::Devel, and Catalyst::Manual, but to really develop kick-ass applications, you've still got to install other packages like HTML::FormFu, Template::Alloy, DBIx::Class, and others in addition to their corresponding Catalyst glue modules.

I think this blog posting may be the first in a long series of brain dumps on Catalyst. I hope I can make it easier for others to transition into Catalyst development.

Interested persons may download the first semi-public release of Apache-FileStore here.

Does anyone care? I hope so.

One thing I'm going to try to do before going back to work on 2 January is get a Perl application released to the general public that Iodynamics was working on partly for a client and partly as a pet project. It's called FileStore and it's a mod_perl application for giving users Web-friendly access to files stored on a server.

The original inspiration for FileStore was Apache::FileManager which is still available via CPAN. Apache::FileManager was great... until Apache version 2 came out. I spent some time in the Apache::FileManager code to see how hard it would be to get it working under mod_perl version 2 and ended up wanting to cause bodily harm to Phillip Collins, its author.

I originally wrote Iodynamics::FileStore for internal use within our company several years ago. A handful of clients saw the benefit of using it to grant employees Web-access to Samba servers, but otherwise it was relegated to use only within our network. While it was a mod_perl handler, it relied heavily on Lincoln Stein's CGI.pm module for, well, everything. All the HTML was generated on the fly from CGI.pm calls. While that made for a compact self-contained application, it made it difficult to maintain and customize.

Another big weakness with Iodynamics::FileStore was that there was no built-in user authentication. It was typically deployed in a location configured for basic authentication with Apache. Once you made it past the basic username and password prompt, you had as many priviledges as anyone else- usually "777" permissions to the filesystem being served by the application.

So, in early 2007, I started redesigning the FileStore application thinking we could turn it into some sort of Web service people might actually pay for: An online, Web-based file server accessible from anywhere. Something like Alfresco, I guess, but without all the crap that gets in the way of being productive. (Can you tell I'm not too fond of Alfresco?)

Stephen Weeks and I took the original FileStore concept and added rudimentary role-based user authentication/authorization functions. We also created Template Toolkit templates to supplant all the CGI.pm presentation code. I worked with David Baker to design some simple icons for things like "Upload," "Copy," "Rename," and "Delete."

Then, Iodynamics went the way of the cuckoo.

A month or so ago, David Baker asked me about the FileStore project- wondering if he could use it for a personal project. I dusted off the code and installed it on his server and started thinking about releasing it for public consumption.

I'm ready to start doing just that. Eventually, I'd like to get Apache::FileStore in CPAN, but a lot of administrative work will need to be done on the project before that can happen. A minimal test suite will need to be written as well as documentation in POD format.

In the meantime, here's a screenshot. I'll make a tarball available soon.