bogen.org

Sarah and I bought each other smartphones for our birthdays. They aren’t any of the big so-called feature phones like the Droid X or iPhone 4. Rather, we got Samsung Intercepts for Virgin Mobile. I won’t go into all the reasons that we went the low-end route but you can shorthand many of them with one word, “money”.

In the past, when I saw people with their heads buried in smartphones I always looked down on them for what seemed like their complete obsession with a cell phone. Now that I have one of my own, I totally get it.

The phone is great for letting me check my e-mail pretty much anywhere I want. It has a slide-out keyboard which means that I can relatively rapidly type e-mails and text messages. The screen is bright and the camera isn’t awful. And all of that is nice, but what really makes it a great device to own is that fact that it’s basically a general purpose computing device that you can carry around with you and that extends the Internet to places far from a telephone line, Ethernet jack, or wi-fi network. I’ve used the phone to stream Internet radio stations in the car. I’ve checked Internet prices on products while in the store. I can update my online notebook full of books to read and ideas to ponder from just about anywhere. We’ve used it to pull up Google Maps in the car when we got turned around in a part of town we rarely visit. I can catch-up on all the latest baseball and hockey news from just about anywhere. Want to know what the weather forecast is? I can pull that up easily too. Forget something to read during a bus ride? No problem. Pull up the New York Times or the USA Today.

In short, having a smartphone is a little like carrying around an always-on, usually-connected laptop that also happens to fit in your pocket.

For years, I’ve used software called Geeklog to manage my website. It was functional and secure, but a much larger package than I needed for a simple blog. It was also a major pain to upgrade and to change its appearance. So, I rarely upgraded it as a result.

Recently, I discovered a method—that wasn’t perfect but was pretty good—for moving my data to a different software package. So, I made the switch. You’ve likely noticed the change in appearance and functionality.

The hope is that I can upgrade this software more easily than the old stuff.

Over at HomeStarRunner.com Strong Bad gives a great introduction to common technologies[Flash]. This is not to be missed if you’re confused about the place of calculators and floppy disks in the modern world.

Bruce Schneier has opened the floodgates for people to respond with their own ideas on How To Survive a Robot Uprising. Some of the ideas are absolutely hilarious (at least, they are hilarious to the highly technical).

Seen in a manual for a clustered file system:

When you install as directed on new machines, you will rarely encounter the need for troubleshooting.

The elevator at my doctor’s office has a clear user interface problem.The building in which the office is located has three floors above ground and one below ground. The buttons in the elevator are laid out in the following fashion:

         []2            []3

         []LL           []1

The most common destination is floor 1, the lobby. However, something like three out of four patients using the elevator get in and press “LL” when they want to leave the building. After a moment of thought, they invariably then reach out and press the “1″ button.

The root of the problem is that instead of calling the below ground floor a “basement” like nearly every other building the world, this elevator terms the basement the “lower level.” While I’m sure this does wonders for the psychology of the workers who occupy the basement…err..lower level, it really hoses everyone else.

When patients enter the elevator, they see “L,” and because they are invariably thinking about their recently ended appointment, their Brain shortcuts to “L = Lobby. We want the lobby to leave the building. You, Hand. Press the button on the lower left.”

About this time, the Eye gets through to the Brain on the backup circuit and says, “Hey, dummy. That’s ‘LL,’ not ‘L’. Chances are that doesn’t mean lobby.” You can usually see people refocusing their attention on the buttons and the sign above them about at this instant. The Brain asks the Eye for a second or third glance at the whole mess as it processes the facts. Then, the Brain tells the Hand to press the “1″ button while it instructs the rest of the Body to look slightly sheepish for the benefit of the other elevator passengers.

If the clinic could just get over its “Lower Level” obsession and get with that hip modern term “Basement” it could then rid the elevator of the confusing “LL” button label. Almost nobody gets into an elevator and presses a button labeled “B” to get back to the building lobby.

Sarah gave a presentation yesterday at the University of Wisconsin-Madison’s GISDay. The subject of her presentation was Geodatases, which are different way of working with geospatial data.

She gave a very good speech, complete with screenshots and whatnot. It was nice to overhear several people who said that they were looking forward to hearing what she had to say.

For the last year or so, I’ve used CVS to keep my home directory under some sort of version control. However, once it became obvious that CVS was perhaps not the best package for my needs I started looking around for something better.

It did not take long for Subversion to appear on my short-list and, ultimately, be selected to replace CVS.

Why was I switching from CVS? Primarily because everything about it felt either woefully inadequate or clumsy or both.

• If I felt like renaming a file, it was time to head into the respository itself to do the dirty deed.
• If I wanted to add a directory and everything in it with just one command, CVS had no way to accomodate me.
• The branching and tagging were something that I never bothered to figure out.
• Deleting files always seemed like a clumsy process.
• etc., etc., etc.

Subversion makes performing many of these tasks much easier. For instance, I can move a directory or file by issuing the command:

svn move FILENAME NEW_FILENAME

No mucking around in the repository required.

Of course, due to the structure of the Subversion repository mucking around in the same is execessively difficult. Whereas CVS kept a directory tree that mirrored that of the source files, Subversion keeps everything in a set of Berkeley DB version 4 files. So, if something goes wrong in the database, you had better hope that

svnadmin recover REPOSITORY_PATH

can recover it or your bacon is cooked.

Using the cvs2svn tool, I was able to put all of my CVS history and repository relatively easily into a brand spankin’ new Subversion repository.

Some notes and information if you find yourself contemplating a move from CVS to Subversion:

1. Do Not under any circumstances delete your old CVS repository until a long while (a month, at least) after you’ve been using Subversion. cvs2svn has some funky options, and if you don’t use them correctly, it will helpfully corrupt some of your binary files. If something does go wrong, you’ll want that repository so that you can restore your working tree.
2. Try the cvs2svn conversion a few times before going live with a Subversion repository. You’ll want to make sure that your conversion command line is doing what you expect it to do and nothing else.
3. The command line I used to successfully convert my CVS repository to a Subversion repository (after some experimentation was):

   cvs2svn -v -s SVN_REPOSITORY_PATH --existing-svnrepos --trunk-only
   --no-default-eol --mime-types=PATH_TO_APACHE2_MIME.TYPES_FILE CVS_REPOSITORY_PATH

   If you are not using Apache2 to serve up for svn repository, you do not need to worry about assigning MIME types. What will seemingly hose your binary files is EOL translation. Use the option I used above unless you know what you are doing.

4. Your fingers may be in the habit of typing cvs to access the repository. If you are using bash you may want to add the following line to your ~/.bashrc file:

   alias cvs='svn'

5. Keywords in files placed under Subversion control are not expanded by default. Hence, you may with to add the following to your ~/.subversion/config file:

   [miscellany]
   enable-auto-props = yes
   global-ignores = *.o .*~ *~ *.log *.core
   
   [auto-props]
   *.pl = svn:keywords=Id;svn:eol-style=native;mime-type=text/plain
   *.sh = svn:keywords=Id;svn:eol-style=native;mime-type=text/plain
   *.txt = svn:keywords=Id;svn:eol-style=native;mime-type=text/plain
   *.plx = svn:keywords=Id;svn:eol-style=native;mime-type=text/plain
   *.html = svn:keywords=Id;svn:eol-style=native;mime-type=text/html
   *.css = svn:keywords=Id;svn:eol-style=native;mime-type=text/css
   *.pm = svn:keywords=Id;svn:eol-style=native;mime-type=text/plain
   *.cgi = svn:keywords=Id;svn:eol-style=native;mime-type=text/plain
   *.xml = svn:keywords=Id;svn:eol-style=native;mime-type=text/plain
   *.bat = svn:mime-type=text/plain;svn:eol-style=native
   *.bmp = svn:mime-type=image/bmp
   *.c = svn:mime-type=text/plain;svn:eol-style=native
   *.css = svn:mime-type=text/css;svn:eol-style=native
   *.cpp = svn:mime-type=text/plain;svn:eol-style=native
   *.cxx = svn:mime-type=text/plain;svn:eol-style=native
   *.gif = svn:mime-type=image/gif
   *.h = svn:mime-type=text/plain;svn:eol-style=native
   *.htm = svn:mime-type=text/html;svn:eol-style=native
   *.html = svn:mime-type=text/html;svn:eol-style=native
   *.ico = svn:mime-type=image/x-icon
   *.java = svn:mime-type=text/plain;svn:eol-style=native
   *.jpeg = svn:mime-type=image/jpeg
   *.jpg = svn:mime-type=image/jpeg
   *.m4 = svn:mime-type=text/plain;svn:eol-style=native
   *.pdf = svn:mime-type=application/pdf
   *.png = svn:mime-type=image/png
   *.py = svn:mime-type=text/plain;svn:eol-style=native;svn:executable
   *.rc = svn:mime-type=text/plain;svn:eol-style=native
   *.sgm = svn:mime-type=text/sgml;svn:eol-style=native
   *.sgml = svn:mime-type=text/sgml;svn:eol-style=native
   *.spec = svn:mime-type=text/plain;svn:eol-style=native
   *.sql = svn:mime-type=text/plain;svn:eol-style=native
   *.tif = svn:mime-type=image/tiff
   *.tiff = svn:mime-type=image/tiff
   *.text = svn:mime-type=text/plain;svn:eol-style=native
   *.xhtml = svn:eol-style=native
   *.sxw = svn:mime-type=application/vnd.sun.xml.writer
   *.stw = svn:mime-type=application/vnd.sun.xml.writer.template
   *.sxc = svn:mime-type=application/vnd.sun.xml.calc
   *.stc = svn:mime-type=application/vnd.sun.xml.calc.template
   *.sxd = svn:mime-type=application/vnd.sun.xml.draw
   *.std = svn:mime-type=application/vnd.sun.xml.draw.template
   *.sxi = svn:mime-type=application/vnd.sun.xml.impress
   *.sti = svn:mime-type=application/vnd.sun.xml.impress.template
   *.sxg = svn:mime-type=application/vnd.sun.xml.writer.global
   *.sxm = svn:mime-type=application/vnd.sun.xml.math
   *.doc = svn:mime-type=application/msword
   *.xls = svn:mime-type=application/vnd.ms-excel
   *.ppt = svn:mime-type=application/vnd.ms-powerpoint
   *.ogg = svn:mime-type=application/ogg
   *.gpg = svn:mime-type=applicaton/pgp
   *.gz  = svn:mime-type=application/x-gzip
   *.tgz = svn:mime-type=application/x-gzip
   *.tar = svn:mime-type=application/x-tar
   *.zip = svn:mime-type=application/zip
   *.mp3 = svn:mime-type=audio/mpeg
   

The useless disclaimers attached to e-mails by many corporate e-mail systems really rub me the wrong way.Since the disclaimers are all but unenforcable, they only serve to eat up resources like bandwidth, disk space, and processor time that could otherwise be used more productively.

For instance, today I got an e-mail message in which the actual message itself consisted of 48 characters.

The disclaimer attached to the bottom of the message totaled 1804 characters.

That means that for every letter my correspondant typed, I got over 37 characters of corporate disclaimer spam at the bottom of the message.

Since I learned how to do this once, promptly forgot, and then had to learn all over again, it only makes sense to document this procedure so I don’t have to reinvent the wheel again and again and again.

Heck, maybe other people can benefit from this, as well. There does not seem to be one particular site on the Internet that strings these commands together towards this same purpose.To make a one minute mp3 sample from another, full length, mp3, you’ll need something to decode the mp3 into raw audio, something else to process the raw audio, and finally, something to encode the resulting audio back into the mp3 format.

I use mpg123 to decode the particular portion of the mp3 I wish to sample.

sox is used to massage the sample and add fades. Apparently, there is an mp3 plugin module for sox that might allow one to skip using mpg123. However, I’m not sure you would have the same control over where to start playing the mp3 and how much to play.

lame is the mp3 encoder I installed on my system. Most likely, any other would work just fine.

The general form of the command line looks like this:

mpg123 -s -v --skip 3216 --frames 2340 <input.mp3> \
  | sox -t raw -r44100 -sw -c 2 - -t .wav - fade t 3 60 5 \
  | /usr/local/lame/bin/lame - <output.mp3>

The mpg123 command line reads like this: Use mpg123; send its output to stdout; use verbose output; skip ahead x-number of frames before starting to play; play x-number of frames. There are somewhere in the range of 38-39 frames per second of audio. So, in the example above, I’m skipping ahead roughly 83 seconds in the audio stream, and playing for roughly sixty-one seconds.

The sox command line tells sox that audio input is coming in raw, sample rate of 44100 Hertz, 16-bit words, signed-linear encoding, two channels on stdin. The audio should be sent to stdout in .wav format. Fade the audio using a linear fade. Fade in for three seconds, play for sixty seconds, and start a fade out 55 seconds into the audio.

This is the easiest part. Tell lame to take the incoming audio on stdin, encode it into mp3, and then stream it into the filename given on the command line.

Even thought SpamAssassin was doing a reasonable job, I was still spending time every day dealing with spam.

So, this morning, I upped the ante and deployed TMDA (Tagged Message Delivery Agent).TMDA works like this:

1. An e-mail comes into the system.
2. If that e-mail matches a whitelist, it is delivered.
3. If that e-mail was sent to an e-mail address that contains a special date string, and if that date string is active, then the e-mail is delivered.
4. If the e-mail matches any of numerous other flexible, user-established criteria, it is delivered.
5. If it matches none of these criteria, the incoming e-mail is quarantined. At the same time, an e-mail is sent back to the seeming originator of the e-mail, asking them to confirm that they sent the e-mail in question.
6. If a proper confirmation is received, the original e-mail is released and delivered.
7. If an improper confirmation is received, the e-mail is destroyed.
8. If no confirmation is received, the e-mail is destroyed.
   

TMDA is often derided as a solution that is nearly as bad as the problem it solves. At some level, I buy the arguments behind that statement. It does create more message traffic on the Internet and it can seemingly spam people with confirmation requests whose addresses were appropriated by spammers to affix to spam.

Using TDMA in partnership with SpamAssassin, as I’m doing, seems to be the right approach. TDMA only send confirmations about messages that SpamAssassin marks as ham (i.e., not spam). That reduces the number of confirmations sent by TDMA to one or two a week.

If you’re someone with whom I regularly correspond, you will most likely never even notice that I’m using TDMA. If you were to change e-mail addresses, and use the new e-mail address to e-mail me out of the blue, then you would notice as the new address would not be on one of my whitelists.

One of my favorite aspects of TDMA is the ability to created so-called dated e-mail addresses. Dated e-mail addresses seemingly expire after a pre-determined period of time. So, while the e-mail address is in the active window, e-mail flows through the address transparently. However, once that window closes, e-mail sent to the address will be subject to either destruction, bouncing, or confirmation. Now, I’m using dated e-mail addresses when I purchase something from someone on-line. If they get frisky with sending me newsletters I don’t want, the address they have will expire after a period of time (I generally choose a week) and I don’t have to worry about seeing their goofy, unwanted newsletters.

By the same token, I can now create e-mail addresses that only work for certain domains. So, I can use one address to buy tickets from United Airlines, but if they turn around and sell my e-mail address to someone else, that address will not function for the third party. Again, that is an excellent defense against spam as it prevents the third party from spamming me if my address is sold.

For the last couple of years, scripts I wrote have been automagically collecting information about the number of e-mails I get every day, and the number of spams I get every day.The idea was to keep track of the volume of spam that I get through time. I kept hoping against hope that someday, the volume of spam sent to one of my accounts would decrease. Obviously, that has not happened.

Since the numbers have been obvious and predictable for some time now, and since they show no signs of changing, and since I may soon switch to a different spam filtering method, the SpamStats Project ends today.

For the longest time (too long really), I hadn’t really bothered to learn much about how to use XML, nor had I made the leap into using XML. In the past few months, that situation has changed dramatically.After spending the time to figure out how to use XML, and where to use XML, I use it all over the place. All the config files I write for perl apps are written in XML. I’ve even gone back and rewritten perl apps that functioned just fine (for years, in some cases) just because the apps did not use XML and they seemed so clumsy without it.

Today, I went crazy with XML-RPC. I’d been hearing about that technology for some time, but had never had reason or time to figure out how to use it or why I might want to use it.

Replacing perl apps that called each other via basic CGI calls with perl apps that use XML-RPC was a brain-dead decision. In fact, the apps got significantly easier to write and understand once I dumped the kludgy CGI interconnection and moved strictly to XML-RPC.

If you need a quick and easy way to connect several disparate perl apps (even ones running on different platforms), I suggest taking a look at XML-RPC.

While I was out and about the other day, I saw an SUV that had the following bumper sticker affixed to it:

LOVE>FEARMost people might decipher that message to mean “Love is greater than fear.” I’m sure that is what the original author of the bumper sticker meant.

However, those of us who spend nearly all of our waking time working with Unix look at that message and think “Execute the program/script LOVE and write its STDOUT to a file named FEAR in the current directory.”

For the last few days, I’ve been using KDE 3.2.1 on my home computer. Since I’ve been using KDE 3.1 for the better part of a year, I was quite interested to see the changes in the new version of the software.My primary home computer is a Dell that is probably five years old. Not necessarily the newest kid on the block. It is currently running SuSE Linux 8.2.

Since the 3.2 branch of KDE was released, I’ve been watching various corners of the Internet to get an idea of just how mature and buggy it was. It seemed that there were several real problems with 3.2, but 3.2.1 had gotten generally good reviews, so I decided to upgrade.

The most obvious difference between 3.1 and 3.2.1 is the speed with which things seem to happen. The software is much snappier overall and several GUI effects I didn’t use in 3.1 because they seemed CPU pigs, have slimmed down noticeably in 3.2.1.

Konqueror has several new features, and perhaps the best one is spell-checking of HTML form input. For a blogging system like GeekLog that lacks a spellchecker, that sort of system is a life-saver.

Most of the mutlimedia apps. have been significantly upgraded, as well. Kscd has a new interface. Noatun has several new features.

There are certainly bugs to be found in the various apps, but for the most part, they aren’t critical.

One notable exception is Kopete. It still needs a great deal of work before it can compete with Gaim.

I’m sure the new look isn’t exactly flying under the rader. After years of creating a web log using tools I developed myself, I decided to move to a more complete web log/content management system.

Why the change?

Well, numerous reasons, really. Before moving to this new system, I was maintaining my own content and tools. In the techology world, this is known as “rolling your own.” Of course, this is also known as “reinventing the wheel.”

There are advantages to rolling your own solution. You always have complete control of the form and format of your data, for one. The tools always do what you tell them do, for another. However, there are also downsides. Your tools never advance any farther or faster than the amount of time you invest in to them. So, if you aren’t investing much time your tools, like I was, you remain stuck with a relatively primitive tool set.

Beyond getting new tools, I had some other goals. I wanted to make it possible for Sarah to write and post ideas and stories of her own on the site. Using my tools, she would first have to learn HTML, Cascading Style Sheets, and Unix (all of which combined is a veritable mountain of data to digest) before she could post a single sentence on-line. I also wanted to get a database on the site’s backend to simplify data storage and the like. I wanted an easier, more reliable way to generate RSS/RDF feeds. Finally, I wanted to expand the number of places (geographically) on the planet from which I (or Sarah) could post with ease. My old system was almost 100% geared towards posting from my home or office.

So, I decided to look around for a better way to get my content on-line. Research led me to believe that modern “content management” systems had matured to the point where many people were using them.

Hours later, the new site is born. The old information is still lurking in the background, and still in its old form. I decided to bring all my posts from 2004 into the new system and leave everything from before 2004 in the old form. There were several reasons for doing this (the primary one being that there are several links around the Internet that point to various pages/images in the old files), so the old files remain.

There are numerous advantages for you, the reader, in this new system. The first is that each individual story or blurb can be formatted for easy printing. It can also be easily e-mailed to a friend. You can leave comments on the site about what we write. You can even search the text of our writings for particular words and phrases.

Hopefully, you will all enjoy the new site. Let us know what you think of it.