Now that ext4 has been in the mainline Linux kernel for a while, and has become the default filesystem (replacing ext3) in Ubuntu, I decided to use it when creating a new filesystem on a backup disk recently.

I was blown away by how much faster the fsck operation is on ext4 compared to ext3.  For a partition of a few hundred gigabytes, where the fsck took around an hour on ext3, it took about a minute on ext4.  Apparently, overall performance is improved too, but this improvement in the filesystem-check process is just incredible.

To convert an existing ext3 filesystem to ext4, you just need a single command, followed by an fsck:

tune2fs -O extents,uninit_bg,dir_index /dev/sdXX
e2fsck -fD /dev/sdXX

Of course replace "sdXX" with your actual device name.  You can also include the -C0 option to e2fsck if you want a progress bar for the operation.  And note this from the kernel.org wiki:

Running fsck will complain about "One or more block group descriptor checksums are invalid" - this is expected and one of the reasons why tune2fs requests to fsck.

See this Ubuntu help page for more details, including how to do this conversion for your active root filesystem.

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 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.