While I'd much rather be running Adium/X, the jabber Multi User Chat support is rather irritating. On linux desktops, I run Gaim, so why fight it?

Gaim isn't native Cocoa, for starters. Under OS/X, pasting URL from/to Gaim is a royal pain (cntl+c to copy to the X11 copy buffer, then command-c to copy it to the OS/X copy buffer, ick!).

There is a manual setting under Preferences to allow you to specify a command to run when clicking on a URL. There wasn't much mention of it on the 'net, so I added a quick little applescript to accomplish this:

$ mkdir Scripts/
$ cat <<EOF > Scripts/openurl.scpt
on run argv
    tell application "Safari"
        activate
        open location argv
    end tell
end run
EOF

Then specify this script to run via osascript in preferences as:

/usr/bin/osascript /Users/icblenke/Scripts/openurl.scpt "%s"

Viola. Clicking on URLs via Gaim/X11 without all of that copying and pasting.

I wrote this little whitepaper a while back for Amy Zunk to document the function of the VideoKeg/VideoJukebox boxes. Documented here for posterity.

The primary goal of the video keg was to build a reliable video box that was easy to transport with enough space to store 3 days worth of Anime fan-subs.

The secondary goal of the video keg was to make a home PVR system for video playback and time-shifting, along with a video arcade and perhaps a web browser.

The tertiary goal of the video keg was to find an affordable hardware platform so that we could buy 4 of them immmediately to service the primary goal's need for 4 separate video rooms.

For a PVR, the machine neeed to be small, quiet, low-heat, and still fast enough to run the software video player and arcade games.

For portability, we decided to go with a smaller mini-ITX style cube box.

The primary goal suggests redundant drives, but due to the smaller form factor chassis and heat requirements, it was decided that recreating a harddrive should one encounter problems would be a minor task.

Looking at the primary goal, mplayer seemed to suit the need of playing media with a variety of codecs with a minimum of fuss. Easy to script, easy to extend, low overhead, with the ability to normalize audio and clean up dirty videos - mplayer was simply ideal. This lead to the requirement of a ~1Ghz or greater box. The secondary goals would be served as well, though MAME would like a bit more horsepower for some of the more complex emulators.

In the end, we settled on a Chyang Fun Cellbox CF-7989EPIA (1Ghz EPIA-MII 10000) turnkey system with 128M of RAM, a Samsung 160G harddrive, and a DVD-ROM drive.

• The cellbox is a small attractive easy to transport case.
• The EPIA-M comes with builtin audio, video, mpeg playback hardware, and a variety of other goodies for a VERY attractive price.
• The 128M stick was enough to run mplayer with an Xserver with plenty left over for PVR software.
• A 160G harddrive was the sweet spot cost wise at the time of purchase.

Once the boxes arrived, the decision at the time was which distribution to pick. If I'm managing more than one server for a given purpose, I like to use debian for package management. If this were a lone PVR box, I would have probably used Gentoo simply for the EPIA community support toward that end.

Starting off with Debian 3.1 Sarge, it was apparent a number of things needed fixing to get it to work with the embedded hardware.

Step 1, find patches and build a kernel.

Kernel patches

After roaming the net for hours, there really seems to be one good source for the latest in EPIA patches: the EPIA wiki:

http://www.epiawiki.org

The site has more of a Gentoo bent, but the patches work on a vanilla kernel just the same under debian.

CPU Optimizations

While building all packages, it seemed important to pay attention to optimizations to squeeze every last cycle out the 1Ghz processor. To that end, the generally recommended C3 Nehemiah CFLAGS are:

CFLAGS="-march=i686 -msse -mmmx -mfpmath=sse -Os -pipe -fomit-frame-pointer"

If you use gcc 3.3, there is a new arch designation for C3 Nehemiah CPUs:

-march=c3-2

Some in the commmunity think that the small 64k L1 cache on the C3 processors is causing starvation, and using -Os and not -funroll-loops actually helps performance:

CFLAGS="-march=i686 -msse -mmmx -mfpmath=sse -Os -pipe -fomit-frame-pointer"

Many others claim the following works best for them:

CFLAGS="-march=686 -O2 -pipe -fomit-frame-pointer -ffast-math -finline-functions -msse -mfpmath=sse,387"

As I was using gcc 3.3 at the time, and the middle ground seems less extreme, I went with -funroll-loops being bad, and back off to -O2:

CFLAGS="-march=c3-2 -msse -mmmx -mfpmath=sse,387 -O2 -pipe -ffast-math -finline-functions -fomit-frame-pointer"

MPlayer

Step one, after building an optimized kernel and loading the appropriate drivers, was to look at MPlayer and decide how to use it. There are video output drivers within MPlayer for the native Linux Framebuffer device, DirectFB, and X11 (XFree86/Xorg), among others.

Getting TVout to work with the viafb driver was tricky to say the least (more on that later).

Playing with mplayer for a while, it became apparent that the optimal playback CPU wise was using X11 with the Xv extension for video output.

XFree86 4.x/Xorg 6.8

Wether XFree86 or Xorg? This is really up to you. The Xorg project has some neat new things (like DRI enabled DDX) and a more "friendly" license that makes everyone happier. Newer distributions seem to be coming out with Xorg builds now, which is a problem for people who are forced to use older XFree86 binary drivers for their hardware (like ATI users).

For our purposes, the differences are moot. To that end, I decided to stick with the "debian way", and patch up the XFree86 4.3.0-dfsg package.

Video Driver

VIA uses their newer Unichrome chipset on newer motherboards, including the EPIA-M. Unforunately, VIA is horrible when it comes to OpenSourcing their efforts. You may download various binary drivers for specific versions and revisions of various distributions off of their VIA support site. There are also old video driver source snapshot releases floating about on there that simply won't work. Some have hacked at it and managed to get those old drivers working on newer handbuilt kernels, but it really isn't necessary anymore.

There is a sourceforge project now where development seems to be focused:

http://unichrome.sf.net

Occasionally, the unichrome project submits a release to Xorg for incorporation into their CVS repository.

There are a number of older drivers out there, along with HOWTOs on patching debian kernels with them.

The unichrome download page has a patch against the Debian XFree86 4.3.0-dfsg package.

DRI/DRM

The newer video driver also requires a newer DRM kernel module. The DRI project has split CVS off of SourceForge to freedesktop.org. You can visit the DRI wiki or the freedesktop.org site directly:

http://dri.sf.net
http://dri.freedesktop.org

Unfortunately, you can't use Debian's default xlibmesa-drm-src package.

To build the latest DRM drivers, I built a CVS snapshot.

Audio

Either OSS or ALSA would do. I'm a fan of ALSA however (newer code), and the debian alsa-driver package was a simple module addition to the kernel build.

$ module-assist auto-install alsa

The VIA EPIA-M motherboard uses the "vt8233" driver.

Writing the Video Keg

The video keg was based on a simple premise: always play video.

The first generation of the video keg was simple. Using a text file listing the filenames of video to play, loop through the list and run mplayer for each filename.

This had the unfortunate site effect of requireing a precalculated spreadsheet of the start time and length of every file in the list. As such, the posted times on the door to the video room would show a complex schedule that was suprisingly accurate.. until a video doesn't play correctly.

Watching 3 days worth of linear video watching for video that doesn't play correctly isn't for the feint of heart. This is the problem with Anime fan subs.

The second generation added scheduling element. If the filename starts with an equal sign ("="), there will be a command after it. Initially there will be one command, "waituntil". This command takes one argument, a time/date string to wait until.

When the video keg script is started up, it reads each line, waiting when appropriate. While waiting, it randomly plays commercials from a directory (sorted on number of times already played and length of playtime) and plays videos with play times shorter than the time available until the wait finishes.

As the keg knows the length of every video, it can calculate when it should be in middle of playback of something. If this is the case, the "-s" argument to mplayer is used to skip a calculated number of seconds into a video. This way, should a video keg lock up, crash, loose power, or otherwise stop, powering it back up will resume the video right where it left off.

If a video cannot play correctly, it dies or otherwise stops playing, and the next waituntil will wait with filler commercials. Brilliant.

Writing the Touch Screen

The "touch screen" box proved a new challenge.

Step 1: Find a touchscreen on EBay that will work with Linux. Step 2: ? Step 3: Profit.

The screen that arrived was an Elo Graphics touch screen with a serial interface. XFree86 already had a driver for it, so the no-brainer was to add a section for it in /etc/XF86Config-4:

Section "Inputdevice"                       
 Identifier "touchscreen1"
 Driver "elographics"               
 Option "Device" "/dev/ttyS0"     
 Option "AlwaysCore"                    
 Option "screenno" "0"                    
 Option "MinX" "0"                  
 Option "MaxX" "4000"                
 Option "MinY" "0"                   
 Option "MaxY" "4000"
 Option "UntouchDelay" "3"
 Option "ReportDelay" "1"
 Option "SendCoreEvents" "true"
EndSection

Then include that as an inputdevice to the ServerLayout section (after your existing mouse):

Section "ServerLayout" 
 ...
 InputDevice "touchscreen1"
 ...
EndSection

Viola. We have a touch screen. The input is as if it were a mouse. This makes development easy.

Deciding on what to develop in was simply enough: Perl. Just as the video keg was hacked together as an overnight perl script frontending a set of bourne scripts for playback, the touch screen would be developed overnight using the same rapid development mindset... only...

I want themes. Users want eye-candy. The default Perl::TK widgets don't take to easy theming. What I really want is a way to theme widgets like GTK...

Enter Perl::GTK2. That was easy.

Time to write the script:

Put a banner of text at the top: "Metrocon Video Touch Screen Jukebox".

Put a play button and a progress bar.

Put a tabbed listbox of all available video (each tab as a letter of the alphabet, and 0-9, for quick searching).

Spawn mplayer to play back video. Watch the output of mplayer to update the progress bar while the video is playing.

Allow the user to select other video while the video is playing, but don't let them click "Play" until the previous video is complete (grey out the button).

Ah, but there is dead air between viewings, what can we do with that dead time?

Simple enough: add commercials.

Create a commercials directory full of video to play, and another directory to record how many times each commercial has been played. Between user selections, start playing from the sorted list of commercials that have been played the least. If the user clicks play, schedule their video to play after the current commercial finishes playing.

QED.

Add standard GTK2 themes. Enjoy.

Polish & Branding

To "brand" this as a drop-dead simple device, I spent a bit of effort making the boot sequence pretty.

Finding the award bios flash tool for the motherboard and the bios modification tool for changing the graphics, I built a DOS Boot Floppy (Bart's modular boot floppy) and burned it as an el-torito bootable CD. Making space for the new graphic ("Linux evil inside") required removing the rhine PXE boot ROM from the flash image (no real loss).

Patching the kernel with bootsplash shows another graphic up until XFree86 starts up.

A while back, Roy Harms of Animemetro asked me to make a digital video solution for the free video rooms at the con.

The first solution was a simple perl script that used a text file to describe video to be played, and the times to start playing them. While waiting for the next show, commercials were played from a directory to fit the available time. http://ian.blenke.com/article/new#

The engine for this was really mplayer via XFree86 and the xv extension. With mplayer, avifile, and the appropriate win32codecs, just about everything is playable - perfect for a con video player of fan subs.

This script was thrown together over a few days. We ordered number of VIA Nehemiah based cube PCs and I built them out with a hand-crafted debian install with a kernel patch from the epia-wiki project.

Later, we talked about making a touchscreen version of the same. Rather than play things with a schedule, put all of the videos on tap to be played by the con-go'ers.

To this end, I whipped together a Perl Gtk2 interface. The decision was twofold: perl was the ideal way for me to interpret the output of a running mplayer process, Gtk2 was very themable, and I didn't want to spend an excessive amount of time putting this together.

The result was vjb.pl, a Perl Gtk2 frontend to mplayer that builds a playable list of material, presenting the user with an alphabet tabset, and interacting well as a touchscreen application.

This an archive of that script for future reference, should anyone else find it useful - have at it.

Mologogo is a j2me midp 2.0 midlet that allows you to use your phone as a GPS tracking tool (and find your nearby friends).

This is apparently making the rounds in the Web 2.0 community.

The last time I looked into this, only the Qualcomm phones had a BREW API to access the GPS info. Apparently things have progressed some in the J2ME world...

Puppet by ReductiveLabs is a ruby based client/server infrastructure for server management.

Very similar to cfengine in design: write "scripts" ("manifests" in puppet speak) that apply to servers running a puppet client. These manifests define how a server should be, and running the manifests will make hosts change to that state.

This is a client pull architecture, with a managed cert infrastructure for trust and encryption of the transport.

The best part: it's entirely ruby. Your manifests are ruby, and can do, in fewer lines of code, whatever is required to accomplish that automation's goal.

I'll be playing with it, to be sure.

Rage, my Rails based bloxsom replacement, is production ready. This is a test article publish using the new interface.

I'm finishing up the final import script now. Rage should be installed production shortly...

Weee!

Step 7 - Cleaning up your new project

Your project has a default page that should be removed:

rm -f public/index.html

Step 8 - Adding a route

To address the now missing main page, we should add a route for a root controller:

vi config/routes.rb

The default configuration has what we're looking for, just uncomment the line:

# You can have the root of your site routed by hooking up ''
# -- just remember to delete public/index.html.
map.connect '', :controller => "welcome"

Step 9 - Generating a controller

Now lets get things rolling by generating that welcome controller...

./script/generate controller Welcome

It will be an empty controller until we fill it in:

vi app/controller/welcome_controller.rb

Edit it so it has a default index render method:

class WelcomeController < ApplicationController
    def index
        render_text "Welcome"
    end
end

Now reload your page to http://localhost:3000/.

You have written your first Ruby on Rails code!

WSMTPD17.zip is a Winsock based SMTPD server written for Win16 and Winsock 1.1, back in 1993. This was the primary inspiration for [[wsanet8a]].

This was an update to wsmtpd16.

I had forgotten entirely about it until I stumbled across it again on the net.

Here is the changelog from 1.61 to 1.7:

wsmtpd17.zip v1.70 January 31, 1995

• Yes, it's been over a year. Time for some simple patches.
• Fixed the 80 character line limit problem (GPF on long lines)
• NT support added by a contributor (The patches I have from him don't have a return e-mail address. I lost some email in the past year :(
• Version numbers updated. Code cleaned up. Debugging rolled back in.
• Code compiled under Turbo C++/Win (This source should compile under either VC++ 16/32 or Turbo C++ without problems)

Instead of separating the comments and trackbacks in Rage, I've merged them together. The "0 trackbacks" link at the bottom of any article display will dynamically open a form for entering a "manual trackback", AJAX style.

This unification of code should simplify things a bit for now. Eventually, a threaded comment system might be fun to implement in addition to trackbacks.

So very close. Almost there.