Do you have any passwords that you never change?  Change them now, on New Year’s Day.  Your password is the only thing protecting your bank account from crooks, so if you never change it, or if you use a weak password, you’re just asking for trouble.

You’re also asking for trouble if you use the same password on multiple different websites.  In that case, someone who hacks/steals your password for one site now has access to all of your accounts.  Fortunately there is a relatively easy way to protect against this: use a "base" password but tweak it slightly for each different website you use.

For example, say your base word is "driveway".  By itself that’s a horrible password because a) it’s too short, and b) it’s in the dictionary.  You can make it much more secure by taking, say, the first 2 letters of the website where you use the password, and injecting them into it.  For example, if your bank’s website is www.toobigtofail.com, then you’d take the first 2 letters ("to") and put them into the password, resulting in "drivetoway".

Now just repeat that for every website you use, and you’ve solved the same-password-for-every-site problem, yet you still only really have to remember one password.  Of course there’s still a lot of room for improvement here -- ideally you’d have some uppercase letters and some numbers in the password as well -- but by simply increasing the length from 8 to 10 characters and by using a different password for each site, you’ve vastly improved the security of the password.

Download this FreeDOS bootable floppy disk image named FDOEM.144.gz.  Unzip it, which will give you a file called FDOEM.144.  Mount FDOEM.144 on a temporary mount point:

mkdir ~/tmp_mount_point
sudo mount -o loop FDOEM.144 ~/tmp_mount_point

Download your BIOS update from your motherboard manufacturer’s website, which should consist of a FOO.BIN file and a FLASH.EXE file (of course the actual filenames will differ).  Copy those 2 files into the ~/tmp_mount_point/ directory, then unmount it:

umount ~/tmp_mount_point

Now the FDOEM.144 file contains your BIOS update files, so you just need to write it to a bootable disk/disc.  To write it to a floppy disk, assuming that /dev/fd0 is your floppy:

dd if=FDOEM.144 of=/dev/fd0

Or to write it to a CD, you first need to create an ISO image file from it:

mkisofs -o biosupdate.iso -b FDOEM.144 FDOEM.144

Now just write the biosupdate.iso file to a CD.  In Ubuntu (Gnome), right-click it and choose "Write to Disc..."; or you can use any CD-writer app (K3B, Brasero, etc) to do it.

I recently tried to run SpinRite on a large SATA disk.  It booted OK and I was able to select the partitions and choose the SpinRite run level, but as soon as it tried to start the scan, it printed an "Invalid Opcode" error followed by a bunch of register addresses or memory locations.  This was on the "Selecting Drive For Use" screen.  SpinRite (and the system) was locked locked up at that point.

It turned out to be an easy fix: I just had to go into the BIOS, to the SATA mode setting, and change it from IDE to AHCI.  When I did this and then booted SpinRite again, I noticed that a bunch of the drive fields (hardware addrs, hardware irq, etc) were now listed as "unknown", but SpinRite was able to scan the disk now.

Over the weekend, we passed 1,000,000 visitors.  That’s a million individual visitors since April of 2005, which is when VisitorLog started counting them.

A million.  One meeeellion.  It’s kind of hard to imagine, actually.  Sure, some of the big guys blow through a million visitors in hours or days.  But we’re not the big guys -- we’re a small business, just like most of you.  Small businesses unite!

Speaking of clients, I thought it’d be neat to see a map of the globe showing the cities and countries where our clients come from.  (This is based on a Google Maps app that may or may not eventually turn into a product, but isn’t ready for the light of day just yet anyway.)  To be clear, this doesn’t contain nor display any names nor street addresses -- it’s just anonymized cities and countries.

These maps are showing just clients, not all visitors; that is, it’s people who actually bought a copy of FileChucker, or UserBase, or MailyList, etc.  And it’s only from the past 6 months or so; it doesn’t go all the way back to 2005 like the VisitorLog data.  But I think it’s a pretty neat visualization of the data in any case.

MySQL annoyingly provides no way to delete multiple tables matching a certain string.  For example, you can say "SELECT * FROM table WHERE name like ’foo%’", but there’s nothing similar for deleting tables.

So here’s a small simple Perl script to do just that.  Save it as droptables.pl, edit the 4 variables at the top, then run "perl droptables.pl".  Simple as that.

#!/usr/bin/perl

use strict;
use DBI;

my $hostname = '';
my $database = '';
my $username = '';
my $password = '';

my $dbh = DBI->connect("dbi:mysql:${database}:$hostname",
  $username, $password) or die "Error: $DBI::errstr\n";

my $sth = $dbh->prepare("SHOW TABLES");
$sth->execute or die "SQL Error: $DBI::errstr\n";
my $i = 0;
my @all_tables = ();
while(my $table = $sth->fetchrow_array)
{
  $i++;
  print "table $i: $table\n";
  push @all_tables, $table;
}
my $total_table_count = $i;

print "Enter string or regex to match tables to "
  . "delete (won't delete yet): ";
my $regex = <STDIN>;
chomp $regex;

$i = 0;
my @matching_tables = ();
foreach my $table (@all_tables)
{
  if($table =~ /$regex/i)
  {
    $i++;
    print "matching table $i: $table\n";
    push @matching_tables, $table;
  }
}
my $matching_table_count = $i;

if($matching_table_count)
{
  print "$matching_table_count out of $total_table_count "
    . "tables match, and will be deleted.\n";
  print "Delete tables now? [y/n] ";
  my $decision = <STDIN>;
  chomp $decision;

  $i = 0;
  if($decision =~ /y/i)
  {
    foreach my $table (@matching_tables)
    {
      $i++;
      print "deleting table $i: $table\n";
      my $sth = $dbh->prepare("DROP TABLE $table");
      $sth->execute or die "SQL Error: $DBI::errstr\n";
    }
  }
  else
  {
    print "Not deleting any tables.\n";
  }
}
else
{
  print "No matching tables.\n";
}

When you’re using Xcode to develop an iPhone app or a Mac app, you might decide that you need to rename your project.  In many cases this would mean not only renaming the actual executable file that gets produced, but also the names of various source code files, project folders, and the contents of various files within the project.

As far as I can tell, Xcode provides no way to do this.  There are a few settings that seem like they might do part of it, but every time I tried to use one of them within Xcode, it just resulted in errors and my project failing to build.  After many hours and much frustration with Xcode, I decided to try it the Unix way, and it worked.  The solution is a straightforward 3-step process:

1. First I closed Xcode, and made a backup of my project folder.  Then I went into my project folder and renamed every file and folder which contained "OldName" so that it now contained "NewName" instead.  This could be scripted pretty easily but my current project is a small one so I spent the ~5 minutes to manually rename the files and folders.

2. In the project folder, I ran the following command in a terminal, to update the contents of the files in the project:

find . -type f -exec sed -i 's/OldName/NewName/g' "{}" \;

3. I opened the now-renamed project in Xcode and clicked Build -> Clean All Targets.

After that, the project (with the new name) built successfully.

Ubuntu Linux, and probably other modern versions of Linux, include a built-in VNC server for remote desktop access.  In Ubuntu this is called vino-server and it’s enabled via Main Menu -> System -> Preferences -> Remote Desktop.

But since this runs as the user who’s logged in to Gnome, it only starts after that user is logged in.  So if you’re away from the PC and accessing it remotely, but something happens which causes/requires it to reboot, then when it comes back up, you won’t be able to access the VNC server because the user won’t be logged in.

The solution to this is actually simple as long as you have SSH enabled and you have root access (via "sudo su" for example) to the server.  Just SSH to it using your normal user account.  Then edit the /etc/gdm/gdm.conf file (actually it’s /etc/gdm/gdm.conf-custom on Ubuntu) and add the following lines to the [daemon] section:

AutomaticLoginEnable=true
AutomaticLogin=yourusername

Then either reboot the server by running "sudo shutdown -r now", or just restart gdm by running "sudo killall -HUP gdm".  Once gdm restarts, it will automatically login as the specified user, and your vino-server process will then start, so you can VNC into the system again.  Don’t forget to remove those auto-login lines from your gdm conf file when you’re done.

UPDATE: alternatively you could forget about vino and the Remote Desktop preferences altogether, and just install x11vnc on the remote system.  Once it’s installed you just run it from your SSH shell, passing "-rfbauth NNN" where NNN is the port number you want it to run on.  Then run your VNC viewer app on your local system to connect to the remote system on that port.

Recently my server was nearly overloaded by a web spider that was severely stupid and/or malfunctioning.  It was making multiple requests every second for totally nonsensical URLs.

When I first noticed my server slowing down, I checked my Apache access.log file.  Since encodable.com normally gets about 1000 visitors per day anyway, a visual inspection of the logfile did not make it immediately obvious which IP address was making the most requests.  There are lots of hits from my own IP, for example, but not enough to slow the server down.

One quick way to see which IP addresses are most active is to sort by them:

cat access.log |cut -d ' ' -f 1 |sort

The cut command there simply throws away all the output except for the first field on each line, which is the IP address.  Then we sort them.  We can then scroll up through the terminal window and get a quick-and-dirty visual indication of which IP is most prevalent.

But in my case, I had quite a few IPs with several hundred hits, and that’s not enough to cause a problem.  I needed to see which ones were in the thousands, but scrolling up through the terminal output it’s not especially easy to see the difference between say 500 lines and 1000 lines.

I needed an actual count of the number of times each IP address appeared the access log.  I came up with the following BASH one-liner to do it (split onto multiple lines here only for readability):

FILE=/path/to/access.log;
 for ip in `cat $FILE |cut -d ' ' -f 1 |sort |uniq`;
 do { COUNT=`grep ^$ip $FILE |wc -l`;
 if [[ "$COUNT" -gt "500" ]]; then echo "$COUNT:   $ip";
 fi }; done

First it creates a for-loop based on the output of the uniq command, so each iteration of the loop is for a different unique IP from the log.  It then greps the log for that IP and uses "wc -l" to count the lines in the output.  Finally, if the count is greater than 500, it displays the count and the IP, like so:

6975:   124.115.3.33
5648:   124.115.5.169
1514:   66.219.73.236
1451:   74.204.11.20

As you can see, the stupid spider was coming from the 124.115.* IP range.

UPDATE: even easier: the uniq command has a -c argument that does most of this work automatically.  It counts the occurrences of each unique line.  Then a quick sort -n and a tail shows the big ones.  Also, I tend to use "cut" as above, but one of the Dreamhost guys reminded me that awk may be a little more straightforward:

cat /path/to/access.log |awk '{print $1}' |sort
 |uniq -c |sort -n |tail