technobabbler

It’s amazing how blogging can get away from you. It’s been officially 11 months (!) since my last entry, and that wasn’t even a good one. Wow. But I’ll do better. Promise.

Ok, I realize Wal-Mart is the bane of a lot of peoples’ existence. I know that plenty of people have casually (and formally) boycotted them. Shrug. I won’t judge those actions, because I understand the desire to stand up for the little guy and all of that. However, while I see the bad, I’ve always looked at the company as an interesting model for success. I mean, you buy SO much product that you get it at a great price, then price it lower than the competitor. Your customers end up getting a good price, and keep coming back, and you make profit like crazy. It’s Business 101. Say what you want about the other things they do… but their company decisions usually make total business sense.

You might remember the recent announcement that Universal would be testing the market with DRM-free music with a handful of online retailers. I personally can’t wait because I really want to buy music online, but I run Linux. I was a massive iTunes advocate until I switched. Then suddenly I couldn’t buy music from them, or play the music I previously bought. Nice.

So that brings me to the current situation. I read about the Wal-Mart music store selling DRM-free music, and so I went to check it out. Eagerly awaiting, hoping some of my favorite bands might be there… and what do I see?

What are the system requirements for using Wal-Mart Music Downloads?

* Windows 2000 or XP (sorry, no Macintosh or Linux)

Are you serious? I mean, honestly… why? I fail to understand ANY reason that their music download service wouldn’t be able to download MP3 files to anything but a Windows machine. I just don’t get it. This isn’t a matter of them not designing their site for anything but IE, this is them actually saying you just can’t use it. “Mac? Nope. Linux? Sorry.”

The entire reason I’m writing this has to do with those aforementioned business decisions. They’ve surprised us in the past, selling various low-end computers that run Linux. I mean, that’s big. There’s a reason it was reported all over the place. One of the largest retailers in the world is selling Linux to the masses. Very cool. (Though, at the time of this writing I’m having a hard time actually finding any Linux products on the website.)

*clears throat

So to put it all together… They sell a Linux computer to a consumer, but refuse to sell them music that will play on that very same computer. And therein lies the conundrum.

A couple months ago the official udev version in Gentoo was ok living side-by-side with the coldplug package. At some point in the development, however, the two packages began to conflict. I tried at the time to unmerge coldplug and install udev, but… well… my wireless card (a built-in broadcom card) stopped working in the lappy. That’s not really good. I’m not sure why, but I didn’t really try to figure out the issue… I just masked >=udev-089 at the time.

Anyway, in case anyone had the same issue as me, I decided to give it another try and found that the latest (udev-110) works perfectly happy on my system now.

After making the switch to linux full-time, I needed an easy way to convert my old music collection to mp3s. Yes, yes… there are the DRM’d files from my purchases on iTunes, and I won’t go into converting them. Otherwise, I had some files in mp3, and quite a large amount in m4a. It’s fairly easy to do the conversion in linux, but it can get tedious if your library is huge. Here’s a little shell script I wrote to parse a given directory and convert mp4s easily. I hope it’ll be useful to someone!

You’ll need faad and lame installed, natch.

#!/bin/bash

find /media/music -name ‘*.m4a’ -print0 | xargs -0 -I {} bash -c ‘FILE=`(echo “{}” | sed -e “s/.m4a//g”)`; faad “$FILE.m4a”; lame -h -b 192 “$FILE.wav” “$FILE.mp3″; rm -f “$FILE.wav”‘

exit 0

Ever since I started using Linux, which at this point was about 10 years ago, I've used the Vi editor. It was included as the default editor for most distributions back then, and it was really all that I was accustomed to. The usually cryptic commands make it pretty difficult to pick up, and I think that difficulty is why many people dismiss it so much. If you give it a try though, you'd be surprised at what you can do with it.

An article recently at The Register gave some interesting background. Essentially, Vi was made to be usable over a 300 baud modem. At that speed, even small commands are burdensome to type, and screen painting is horrendous. So the small, one-letter commands in Vi had a specific purpose - speed and efficiency.

So that begs the question: In the age of high resolution and broadband, why would anyone in their right mind still use an editor from 1976? The answer, to be honest, isn't an easy one. Like I said, I personally started using Vi when I didn't know of any other choice. I learned three commands... 'a', ':q', and ':wq', and that was good enough for me. Those commands allowed me to edit any file I needed to edit on my Linux boxes, and I could do it quickly. As any Vi user will attest, once you learn the very basic commands, you find yourself using them everywhere, even when you're not using Vi. I think it's because they are SO easy to use, they just make sense.

At this point, I suppose I should start saying 'Vim', for fairness. Vim was created to give a user the power of Vi, but extend it to add many cool features. The abilities of Vim are a surprisingly long list. Most anything you can think of, Vim can manage it, and it still remains a text-based editor. A GUI exists for it, sure, but I honestly know no one who actually uses it. :)

These days, I've had the wonderful chance to use Vim in my every day work, and I must say, I love it. I keep 3-4 xterms open all day long, and Vim runs on all of them. Something I've noticed is that like Linux itself, using Vim every day allows you to learn some incredibly useful shortcuts that you may never have seen. That's my reason for writing this article... to educate those Vi users who only know the most basic commands, and to also help cement some of the useful shortcuts in my brain.

First, my (most recent) .vimrc file:

So some very useful things any newbie should know...

The '/' character, in command mode, starts a search. This search accepts regex, and can be global or one line. So the simplest use is to simply type '/something'. That command highlights every instance of the word 'something' in the file. While still in command mode, typing 'n' will go to the next search result. Quick and painless, right?

The search and replace syntax is pretty standard. The replace the abbreviation 'NY' with 'New York', simply type ':s/NY/New York/g'. That will replace it on the current line only. The expand it to the entire file, just add a '%' in front of the s: '%s/NY/New York/g'. Pretty simple, eh?

Here's something that's cool... split screen editing of the same file. Hit 'Ctrl-w s' and you'll now have two copies of the current file on the screen. Do it again, and you'll have three. 'Ctrl-w c' closes the current split. If you use the 'mouse=a' setting, clicking will switch between the different sections. Otherwise 'Ctrl-w uparrow/downarrow' will do it. There's a surprising lack of split-file editing capabilities in editors these days. Enjoy it!

Did you know about Visual mode? Hit 'v' in command mode and use the arrows to highlight lines. You can then use 'd' for delete (like the 'cut' command), 'y' to yank (like the 'copy' command), and 'p' to paste. If you have the 'mouse=a' setting enabled, click-drag will automatically enter Visual mode. So it's a quick clickdrag-y-click-p to copy and paste text between two places in the file. While you're at it, highlighting a chunk of text in Visual mode and hitting '<' and '>' will tab/untab the block. 2007-02-02 - You can also hit a number before you hit '<' or '>' to tab that number of times.

One thing I like to do is store commonly used methods in regular text files. If I need those methods, I can insert them directly into the current document with ':r filename'. That reads the entire file in and places it wherever your cursor was located in the file.

If you don't like the default colors that Vim uses, you can modify them. Take a look in /usr/share/vim/vim70/colors. Those are the default color schemes that come with Vim, and you can use them with the command ':colors [colorfile]'. You can also just use them as a starting point and include custom color commands in your .vimrc file.

I know there are more things that I do in Vim that I can't think of right now, so I'll come back and update this article now and then. I hope at least one or two of these functions were unknown when you started reading. If you're a Vim master and you've read this fafr, what are your favorite features? Please leave a comment!

Added: 2007-01-22

"$" means 'end'. It can mean the end of the line, or the end of the file. Typing ":$" goes directly to the last line. And on the subject of moving around in the file, use ':' and the line number to warp directly to a specific line.

Added: 2007-02-03

So recently I've started using (gasp!) Gvim, the 'GUI' for Vim. The thing that sold me on it wasn't so much the GUI features (I've disabled them all) but the font rendering features. For one, you can use true-type fonts, rather than being stuck with the one in xterm. The other thing though, is that it does AA on the fonts, which means dot values! So I'm now using Bitstream Vera Sans Mono 7.5. It doesn't seem like much, but try that in an xterm! :)

While I'm here, I've started using yet another feature. While in insert mode, with mouse=a enabled, double-click on a word. It enters visual mode and highlights the word. Now hit 'd' for delete, and it deletes the word and returns to insert mode.

Also, instead of using the method I detailed above for split-screen editing, I've started using :split and :vsplit. This allows you to split the current screen up quite a lot. Then, while in one of the split frames, type ':e path/to/file' and you now have multiple files open in the same window. That was HUGE to me! And since they're all within the same session of Vim, the copy/paste buffer will go between all of the files. That rids me of the need for the mouse=c functionality. Woo!

Added: 2007-02-13

It's funny how your methods change over time. The amazing thing is how often I find new ways of doing something in Vim. I explained somewhere above how to use Visual mode. Basically, if you have mouse=a set, you can just highlight characters and you'll automatically be in Visual. Here's something cool though: try moving your cursor to the middle of a line and hit Ctrl-v, then use the down arrow. You'll notice that instead of highlighting the entire line, it allows you to highlight a certain character region on your screen. This is Visual Block mode. Imagine if you had two columns of text and you wanted to move the second column a couple of tab stops over... Just put your cursor at the beginning of the column you want to move, Ctrl-v, down arrow to the end of the column, and then hit '>'. Neat, eh?

Sometimes you need to replace characters in a certain chunk of code, but not the whole document. Using either Visual or Visual Block mode, highlight the area you want the 'replace' to affect. Then you modify the normal pattern ":%s/something/something else/g", adding "\%V". So to replace 'Yay' with 'w00t' in a Visual area, you'd use ":%s/\%VYay/w00t/g". Easy as Pi. ;)

I've moved! I'm now in the amazing city of Austin, TX and into an equally amazing job. I love it, and the people I work with! One of the things I needed to get used to at the new place was using Gentoo on the desktop. Up until then, I had mainly standardized on Ubuntu in various flavors. I love the ease of use, and I love how... well... pretty it is. But coming from both camps, I wanted to give a basic breakdown of the differences, and why you might want to give Gentoo a try yourself.

The biggest difference between Gentoo and most other distributions is that every package installed in your system is compiled from scratch. There are benefits on both sides of the argument. In a binary distribution, the speed of installing apps is just amazing. Using apt is just... wonderful. The problems come in when you want to install an application that isn't in the apt repository, or when the version you want to install is much newer than the one in apt. At this point, your choices include either waiting a while (possibly a long time) for the version to get updated, or compiling your own. Simple enough, but what happens when you go to install an application that depends on the one you compiled? Apt doesn't see the compiled version in it's internal database, so it tries to install it's own. So your choice there is to install the other application from source as well. Don't get me wrong, apt is awesome. It's just that in certain instances, it would be nice to have a little more control.

In addition, think about compiling. Every application you compile has certain flags that enable different functionality. It might be a choice between using ALSA or OSS, or whether to let the app have SVG support... there are a million things. Well, in order to be all things to all people, the application in the apt repositories are compiled to work with pretty much everything. The side-effect of that is a potential for slowdowns. When you think about it, it only makes sense that the more you allow your program to do, the more CPU cycles it will take in running. And while one itsy bitsy flag enabling some random feature might not make a huge diff, what about scaling that across an entire operating system? If you have ever compiled your own kernel, it's the same reason you don't compile in every feature possible... you pick and choose for the most efficiency.

So those are the main reasons why I'm quickly becoming a Gentoo fan. I love Ubuntu for people who are new to Linux, but for those of us that know (or at least should know) a little more about our OS, Gentoo is a great fit.

Gentoo's package management system is called Portage. It consists of what are called 'ebuilds', which are basically just scripts that tell the Portage system how to compile a given application. So for every application that is available, there's an ebuild for it in the Portage tree. But there's more! Remember the version issues you run into with binary package managers? There are ebuilds available for many of the latest builds of various software, and nearly every version number in between. So by changing a few configs, you can install an older more stable version, or you can allow Portage to see and install some pretty bleeding-edge stuff. Not only that, but there are some builds that actually use CVS to bring down the absolute latest version, and compile it automatically.

It's hard to complain about the selection of software available on Gentoo through Portage. It's got pretty much everything and the kitchen sink available for installation. And the great thing is, like all package managers, it understands interaction between different software. That means if you go to install WhizBang package, and WhizBang requires the SupaSecret KungFoo package, Portage will compile SupaSecret first, and then compile WhizBang. Not only that, but there's even a program that will rebuild all of your dependencies, throughout the system, in case one gets hosed.

Binary package managers have methods (sometimes) for upgrading the system to the newest release. With Gentoo, the entire system is in a sort of continuous development. That means that there's no specific 'version' of Gentoo... you install it, and then compile the packages (whatever the newest versions are) that you want. It's very customized. That means that it's very easy to bring your system up to date... "emerge --sync && emerge -update -deep world" will go through and find everything in your system that's out of date, and update those packages. Swanky.

In all fairness, the advantages DO come with a price. The main thing that people complain about with Gentoo is the time that it takes to compile. For example, I installed it for the first time by myself on my laptop. It's an AMD64 3200+ system, and it took slightly over 15 hours of compiling before the system was really at a usable state. By usable, I include compiling X, Gnome, the KDE libraries, WiFi drivers, and the various software I normally use. At that point, I was able to start really going through and finding other applications that I wanted... I'd say, all things considered, I've probably spent around a week of the last 1.5 months compiling. Of course, a lot of that was just me getting used to the new system, playing, compiling, removing, etc. From a blank drive, the process would go a lot quicker now.

To be honest, when I first thought about having to wait for EVERYTHING to compile, I didn't like it. I was accustomed to the speed of binary managers that just download a compressed file and run an installer. Now though, I think I've adopted a slightly different view. Once the base system is done, compiling packages here and there really doesn't take much time since the dependencies are all already fulfilled. In short, I think the advantages are well worth the wait. If I'm about to install a program, I just have a synapse that fires telling me to go grab a cup of coffee while I wait. Not hard at all... a little more casual, in fact. While I certainly don't look forward to the time investment of installing another Gentoo system, the stability and efficiency is such that I don't think I would be happy any other way. And you know... there's also a big difference in the size of the OS... compiling everything individually keeps you from installing useless software that you'll never even look at. As of this writing, having nothing else on my list (at all!) in need of installation, and with a few things that could be removed, about 8 gigs are used. That includes data files and all. Compare that to a base install of a binary distro, or even (gasp!) Windows.

So there you go. If I've inspired you to try Gentoo, please let me know. If I can help you over some of the beginning hurdles, leave a comment and I'll get in touch. If not, maybe after a few years of getting more familiar with your Linux distribution, you'll decide it's worth it. If nothing else, I hope this has been educational.

Happy Desktop-Linuxing!

Once you have a few agents on your asterisk box, and especially if they are distributed throughout the building, you quickly find yourself in need of a way of easily seeing who is or isn't logged in. This helps with agent tracking, but it's also useful for those times that you're debugging your dialing stategies. So we're going to write a Python script that will run constantly and update a database with all of the agents' names and their current status. I've personally been running this for months with no issues as far as CPU load or instability in the Asterisk system.

First of all, you need to enable the manager interface. Look in /etc/asterisk/manager.conf. You'll need something to the effect of...

[general]
enabled = yes
port = 5038
bindaddr = 0.0.0.0

[joe]
secret = schmoe
read = system,call,log,verbose,command,agent,user
write = system,call,log,verbose,command,agent,user

So Asterisk will be listening on the localhost address, on port 5038. Our user 'joe' is set up with the password 'schmoe'. Now we need to connect to the server using Python. Here's the script:

As you can see, I'm using sockets to connect to the manager interface. You can actually open up the interactive interface to Python and type these commands individually if you'd like to see the output that you'll receive directly on the socket. Suffice it to say, the FOR statement starting on line 14 checks each line, looking for specific attributes that give us various info. In my case, I wanted to get the Agent ID, their Name, and their status. Once I have that information, I just insert it into a table that I created called ACD.

Something else that I should note is the FOR statement on line 33. This chunk writes a line to the same MySQL table with the total number of unanswered calls in the queue. This number allows me to know if customers are waiting unnecessarily long to get to an agent. You could obviously extend something like this to include timestamps, etc... allowing you to know average wait times and whatnot.

That's basically it! At this point, you should install the script on your asterisk box as a daemon. Otherwise, you'll need to keep a live SSH connection open specifically for this. Keep in mind, any time the Asterisk server dies for any reason, so does the manager interface, and your script. You'll need to either restart it manually, or let your daemon restart it.

If you can think of ways to improve this script... I'm sure there are many ways... please comment below!

I know it's not glamorous, but a basic need for any program is the ability to handle command-line arguments. Every CLI program seems to have extensive information on usage if you don't provide the right arguments, and it would be a good idea to provide your own users the same courtesy. So with just a couple of lines, as seen below, you will be able to expand your program with the ability to receive command-line args, and gracefully handle missing arguments.

So let's say you need the user to provide a filename and an action of some sort. You would use something like this:

It's a BASIC idea, but terribly useful. The script tries to store the two command-line args into variables. If that fails, it displays "Usage" info, waits 3 seconds, and exits.

I bought a USB webcam off of eBay quite some time ago, and I decided to connect it to my telescope with a little bit of hardware hackery. I'll have to see about posting a writeup on how I did that at a later time. Anyway, when I installed my camera software, I quickly found how horrible the program was. It gave a tiny preview of what the camera saw, and had no way of capturing images or video without waaaay too many clicks of the mouse. That's when I decided to write my own in Python.

The main libraries that I ended up using were VideoCapture, PIL, and pygame. As you'll see, it's not really difficult at all to make a useful webcam application.

Here's the code:

I decided to use pygame in order to build this because it can actually handle the fps that I need for video. I built something similar quite a while ago with wxPython, but it just wasn't fast enough at image swapping to make it work well.

A couple of noteworthy points:

• The function on line 15 is simply there to help automate displaying information on the screen. In my case, I display the number of screenshots I've saved to disk, and the current brightness and contrast levels. The function displays the text sent to it by writing it in dark gray, and then re-writing it in light gray over the top with a pixel offset. I found this helps a TON to make the text visible in different scenarios.
• Line 26 is where I actually apply the contrast and brightness changes. Lines 30-33 set up the number keys 1-4 to adjust contrast/brightness on the fly. This is terribly useful, in my experience.
• Lines 34 and 35 are setting up 'q' and 'w' to show the settings dialogs for the webcam... this is where you can set resolutions, exposure levels, etc.
• On line 36, and those under the if statement, I save the current image and name it using the current time... this insures no overlapping image names.

If you're trying to write a webcam app of your own, I hope this gets you pointed in the right direction. Let me know if you find this info useful!

Digg is a pretty great social bookmarking site that allows users to submit interesting articles in various categories for everyone to see. When you look at the front page of the site, you may think you could easily get information overload, but hey... I admit it... I've got the Cloud View set up as one of my home tabs in Firefox. If you don't go to Digg often, take a look. You might find something that really interests you!

To the point though, a lot of people go to great lengths to use Digg for promoting their articles. For that matter, you might find that other people submit your articles to Digg. If you're getting traffic though, wouldn't you like to increase it? The natural way is to give the reader the ability to Digg the article directly from your site, while reading your article. So if you want to add the neat "Digg This" box along with the live number of diggs to your article, here's how. Don't mess with the complicated descriptions that are all over the place... just use this as a template, and replace '[URL]' with the proper url of the Digg story that points to your page:

So there you go. Just insert that into your article, and you're good. As you can see, we give it a class of "diggthis", so you can apply a float, or border, or whatever you want to the box to make it fit in with your content.

Enjoy!