The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Friday, April 01, 2005

The unfortunate results of adding a stock phrase to Chinese fortune cookie fortunes

Catch on fire with enthusiasm and people will come for miles to watch you burn …

… in bed.

Saturday, April 02, 2005

All that for something barely anyone saw

One of the problems of providing an RSS feed is that most of my readers read it and not the site here, thus the format change I did for April 1st was lost, along with most of my AdSense revenue (one of the few things I can report about is my gross earnings from Google, which to the nearest cent is $0.00)—I suppose I may get more revenue if I inline the ads, such as:

But I don't really want to do that (nor add ads to my RSS feed, so don't worry—well, except possibly for this entry but that depends on if your RSS agregator filters out the <SCRIPT> tag (it'll be interesting to see).

Anyway …

Last year's April Fools theme was greenbar printer paper, where (through the wonders of CSS) it appeared as if this was being printed out (in all caps no less) and it took me quite a while to find an appropriate image of greenbar paper for the background. This years idea was to do an old fasion monochrome monitor (green on black) with a slight resync problem (you can see a bright green line of the electron gun being swept across the screen). A bit easier to munge up than last year's imagry and one I could make myself.

At first I tried a paint program, but it was a rather primitive paint program and I had problems trying to do the 2048x100 image (2048 pixels wide to make sure it was wide enough not to repeat for anyone). Too many problems using the program, leading it to taking way too long.

It was then I remembered I had the GD library installed.

Trivial!

How trivial?

#include <stdio.h>
#include <stdlib.h>
#include "gd.h"

int main(void)
{
  FILE       *fpout;
  gdImagePtr  imout;
  int         background;
  int         line[3];

  imout = gdImageCreate(2048,100);

  background = gdImageColorAllocate(imout,16, 32,16);
  line[0]    = gdImageColorAllocate(imout,16, 64,16);
  line[1]    = gdImageColorAllocate(imout,16, 96,16);
  line[2]    = gdImageColorAllocate(imout,16,128,16);

  gdImageLine(imout,0,13,2047,23,line[0]);
  gdImageLine(imout,0,14,2047,24,line[1]);
  gdImageLine(imout,0,15,2047,25,line[2]);
  gdImageLine(imout,0,16,2047,26,line[1]);
  gdImageLine(imout,0,17,2047,27,line[0]);

  fpout = fopen("vidline.png","wb");
  gdImagePng(imout,fpout);
  fclose(fpout);
  gdImageDestroy(imout);
  return(EXIT_SUCCESS);
}

A crude attempt at anti-aliasing a beam across the page. Very poor results no matter how I did it. It was then I remembered my Foley-van Dam book (Computer Graphics: Principles and Practice by Foley, van Dam, Feiner and Hughes, 2nd Edition)—surely it must have a section on anti-aliasing lines. Indeed, § 3.17 had just what I wanted—code for drawing anti-aliased lines. A few minutes typing in the code (a page's worth) and I had myself one nice anti-aliased beam across the page.

int g_brightness[100];

/********************/

void init_colors(gdImagePtr img)
{
  int i;
  
  for (i = 0 ; i < 100 ; i++)
    g_brightness[i] = gdImageColorAllocate(img,16,132-i,16);
}

/******************/

void pset(gdImagePtr img,int x,int y,double dist)
{
  int    intensity;
  
  intensity = (int)(fabs(dist) / 1.5 * 100.0);
  gdImageSetPixel(img,x,y,g_brightness[intensity]);
}

/***********************/

void line(gdImagePtr img,int x1,int y1,int x2,int y2)
{
  int    dx;
  int    dy;
  int    incrE;
  int    incrNE;
  int    d;
  int    x;
  int    y;
  int    two_v_dx;
  double invDenom;
  double two_dx_invDenom;
  
  dx              = x2 - x1;
  dy              = y2 - y1;
  d               = 2 * dy - dx;
  incrE           = 2 * dy;
  incrNE          = 2 * (dy - dx);
  two_v_dx        = 0;		
  invDenom        = 1.0 / (2.0 * sqrt(dx*dx + dy+dy));
  two_dx_invDenom = 2.0 * (double)dx * invDenom;
  x               = x1;
  y               = y1;
  
  pset(img,x,y    ,0.0);
  pset(img,x,y + 1,two_dx_invDenom);
  pset(img,x,y - 1,two_dx_invDenom);
  
  while(x < x2)
  {
    if (d < 0)
    {
      two_v_dx = d + dx;
      d += incrE;
      x++;
    }
    else
    {
      two_v_dx = d - dx;
      d += incrNE;
      x++;
      y++;
    }
  
    pset(img,x,y    ,two_v_dx * invDenom);
    pset(img,x,y + 1,two_dx_invDenom - two_v_dx * invDenom);
    pset(img,x,y - 1,two_dx_invDenom + two_v_dx * invDenom);
  }
}

See what I go through for stuff nobody will see?

Sigh.

(If you are curious to see the styles, and you are using Firefox, you can use the menu View/Page Style to select which style you want).


Science in action

Another unexplained phenomenon: Do you know of anyone who can explain why I can hold my car's remote keyless entry fob to my chin and have its range tripled, or even quadrupled? Try it. Yeah, it works. Really!

There's the challenge for this week, folks. A cavity-resonance, antenna effect, or just what? Let us know your theories … !

An Interesting Phenomenon—The James Randi Educational Foundation Newsletter

I don't have a theory, but I did decide to test the phenomenon (do doo de do do!) to see if it really happens. Casa New Jersey is at the end of a dead-end street with very little traffic, so it was a simple matter to park Lake Lumina (my car—there's a long story attached to the name) at the end of the street and using a 300′ tape measure, mark off the distances.

[Lake Lumina at the end of the street] [The front of Lake Lumina is pretty long]

The tape measure was tucked underneath the front driver wheel (a convenient anchor point), but given that I don't really know where the keyless entry fob antenna is on the car, the measurements I did take could be anywhere from +4′ to -15′. So, with that in mind …

At certain intervals, I held the keyless entry fob five different ways:

[Fob at waist height] [Fob at shoulder height] [Fob against my chin, mouth closed] [Fob against my chin, mouth open] [Fob above head level—the so called “Don Martin” pose]

I'm sure I looked silly to the neighbors, but it's silliness in the name of science! Undaunted, and with the help of wlofie (who was standing by Lake Lumina) who used hand signals to indicate if the doors locked or unlocked, I proceeded to look silly while seeing how far I could lock and unlock my car.

The keyless entry fob is the original unit that came with my car and as such is seven years old, still with the original battery. Also, the fifth stance, the so called “Don Martin” pose, was suggested halfway through the experiment and I neglected to take samples at the shorter distances. I started out going 20 feet per attempt, then as the signal appeared to drop out, started shortening the distances to locate where the signal dropped.

Now, onto the results:

The range of a keyless entry fob under different holding techniques
Distance Fob at waist height Fob at shoulder height Fob against my chin, mouth closed Fob against my chin, mouth open Fob above head level—the so called “Don Martin” pose
Distance Fob at waist height Fob at shoulder height Fob against my chin, mouth closed Fob against my chin, mouth open Fob above head level—the so called “Don Martin” pose
20′ Yes No Yes Yes (not tested)
40′ Yes No Yes Yes (not tested)
50′ No Yes Yes Yes (not tested)
55′ No No Yes No Yes
60′ No No No No Yes
70′ No No Yes Yes Yes (sporadic)
80′ No No Yes Yes Yes
90′ No No Yes (sporadic) No No
100′ No No No No No

Holding the keyless entry fob to my chin did extend the range to twice that of just pointing towards the car, but nowhere three or four times the claimed distance. Also, the “Don Martin” pose also extended the range about twice the distance. So it's hard to say if it's due to a cavity-resonance atenna effect, or just the higher altitude the fob was held at increased the range (and there is that spurious result at 90′—perhaps the signal reflected oddly?). Who knows? I just generated some data that can be used in coming up with a theory.

Now, off to email the results to the James Randi Educational Foundation

Sunday, April 03, 2005

Spring forward!

This “springing forward” time change always catches me unaware.

Sigh.

On the plus side, I will now start getting home before dark, which is always a nice change.


House Chillin Party

Okay, Spring just announced the House Chillin' Party, Saturday, April 16th starting at noon.

All are invited to come and since this is a House Chillin' party, so no gifts other than the gift of company is required (oh, and a bit of wisdom on a scrap of paper).

Hope to see you here.


Is there some wierd bug in my code?

I might have a bug in this code.

Wednesday, April 06, 2005

What a cut-up

Sweet-n-Sour Chicken

Sween-n-sour sauce

Mix water and cornstarch until smooth. Add rest of the ingredients and heat over medium-low heat.

Cut up chicken (I use a whole breast) into bite sized chunks. Flour and cook in skillet over medium heat. Then add any cut up vegetables (green pepper and onions are good) and let cook for about a minute. Then add sauce and pineapple chunks; let simmer for a few minutes, then serve.

Oh, don't forget the rice.

I'd just like to note that the method for cutting up chicken explained at Cooking for Engineers is not only fast, but simple too! It's a much nicer method than the total lack of a method I was using before.

I still have to work on getting the breast meat off the bone though (which I typically use to make Chinese chicken nuggets sweet-n-sour chicken—one of the few dishes that I make that The Kids like).


“He who controls the router, controls the network.”

The Kids were noisy. Well, they're kids, they're inherently noisy.

But they supposed to be sleeping.

On a hunch, I logged into the firewall system (an old 486 running Linux) and ran monnet, a network monitor I wrote a few years ago as an educational exercise and sure enough, there was quite a bit of traffic from The Kids' computer upstairs.

Sure enough, they were playing Rune Scape.

Buy why yell when instead, I can have a bit of fun …

route add 10.0.1.161 reject

It suddenly got very quiet upstairs …

Heh heh heh.

Thursday, April 07, 2005

Odd Bug of the Day

Okay, this is a wierd bug.

If you visit the page for April 3rd you'll see three entries (the final one added today in trying to track down this bug). Now, if you go to the first entry of that day, then click “Next” you'll actually skip over the second entry (which doesn't show up at all) to the third entry. And from there, clicking “Previous” will either take you to the first entry for that day (which is what happens on my test server) or it take you back to the third entry (which is what is happening on the live server). On the plus side, it's happening on both systems. On the minus side, it's exibiting different behavior.

I don't know what it is about that second entry (which is about the House Chillin' Party) that mod_blog doesn't like …


Um … sure … this is easier …

I truely don't understand how control panels make life any easier.

I truely don't.

We have a customer with a dedicated server running Fedora Core 2 with Blech. Okay, fine. The customer wants to install a PHP script. Of course. The script requires a PHP function mhash():

However, you need to verify that the required PHP MHASH extension is available; otherwise, you will not be able to generate the required fingerprint.

The required MHASH extension comes with PHP and requires no additional cost.

Most web hosting providers install this extension along with PHP; however, in some circumstances, you may have to enable it yourself or ask your web host to enable it for you.

Lies! All lies!

It may very well come by default with PHP 4.3.10 but we're not running PHP 4.3.10 on this system, we're running PHP 4.3.4 and while the configure command (presented by phpinfo() is over 20 lines long, it doesn't contain --with-mhash.

There does, however, exist RPMs I can install. The mhash-0.9.1-2.i386.rpm installed fine, but php-mhash-4.3.10-2.4.2.i386.rpm failed because it needs PHP 4.3.10 or higher and like I said, we're only running PHP 4.3.4.

And what the XXXX does version “4.3.10-2.4.2” even mean? It's like the Linux Kernel Version Numbering Mess, only worse.

It's even more incredible that RedHat failed to include this module with PHP; it has every other conceivable module configured.

Grrrrr.

I suppose we could upgrade to PHP 4.3.10, but would that break Blech?

Oh wait … just found out the latest version of Blech can support PHP 4.3.10, but we're not running the latest version of Blech, so we'll need to upgrade that …

Aaaaaaaaaaaaaaaaaaah!

So tell me, in what way do control panels make life easier?

XXXX, in what ways do RPMs (or any other pre-compiled form of installation) make life easier? It's not like ./configure ; make ; make install is all that difficult …

Friday, April 08, 2005

A possible theory

Last Friday the James Randi Educational Foundation mentioned an odd phenomenon (do doo de do do!) and last Saturday I did some tests to see if it actually worked (kind of). This week the James Randi Educational Foundation followed up with some more information, as well as a possible theory (which fits in with my observations).

Sadly, my contributions weren't noted.

Monday, April 11, 2005

Updating servers

There's an interesting project lumbering down the pike (I do hope we get it) but it involves a large number of machines acting as one—I think the marketing term would be “enterprise cluster.” One of the interesting challenges involves updating each of the servers (did I mention there being a large number of them?) with content. There will be one master control processor (the MCP and N slaves. If the MCP copies the files out to each slave, then it's O(n) as an upper bound. However, if in addition to the MCP copying files, each slave starts copying as soon as it receives a copy, then it drops to O(log n) which is much better.

But is there a faster way?

Ideally, the files will be coped to each node, but is there a way to broadcast the file …

Broadcast.

IP has the concept of broadcasting.

Unfortunately, while IP can send broadcast packets, the reliable byte-oriented TCP protocol (built on top of IP) doesn't. TCP is meant to be a reliable data stream between two processes—a “one-to-one” type of communication. No, a broadcast copy will require the use of UDP, a connectionless protocol that is, unfortunately, unreliable (well, so is IP, but TCP includes mechanisms for reliability). But if it can be made to work, the time to copy a file to N nodes drops from O(log N) to O(1)—as fast as you can get.

And it seems like I'm not the only one to latch onto this idea.

[root unix]# ./mdp
mdp: Error! Must pick "client" mode (-D <cache/archive directory>),
       "server mode" (i.e. supply file(s) to transmit), or both.
       Use "-h" option for usage help.
mdp: error starting mdp
[root unix]# ./mdp -h
CmdMdpApp::ProcessCommands() invalid flag
mdp: error processing command-line options
[root unix]# 

(Sigh.)

Aside from programs that don't understand their own options, another aspect we're facing is adminstrating a large number of machines (and not the few dozen we have now). Towards that end, I've been reading all the articles at Infrastructures.org—a type of “best practices” in adminstrating a large number of systems.

The enterprise cluster concept simplifies how we maintain individual hosts. Upon adopting this mindset, it immediately becomes clear that all nodes in an enterprise cluster infrastructure need to be generic, each providing a commodity resource to the infrastructure. It becomes a relatively simple operation to add, delete, or replace any node.

Infrastructure Thinking

The one bit I do have problems with is the “Push vs. Pull” argument:

We swear by a pull methodology for maintaining infrastructures, using a tool like SUP, CVSup, an rsync server, or cfengine. Rather than push changes out to clients, each individual client machine needs to be responsible for polling the gold server at boot, and periodically afterwards, to maintain its own rev level.

Push vs. Pull

I'm not a fan of polling—the majority of polls won't return any new information and is just extra work on the part of the poller (and in this case, the extra network traffic). Also unspecified is how to handle the spike in traffic when there is an update. I'm sure in practice that each machine is set to semi-randomly poll the “gold server” least it suffer a network interface meltdown when hundreds—nay, thousands, of clients hit it at once for an update.

But their arguments about overly convoluted distribution scripts are compelling too. But in looking at broadcast copying (or multicast copying, take your pick) I'm wondering if a metter approach to the strict polling would be periodic broadcasting that an update is ready, and each server that receives the broadcast then contact the “gold server” for updates (and I'm talking about system updates, not just content being sent out).

Much to think about …


When multicast is slower than unicast

So I'm playing around with MDP and I am underwhelmed by its performance. I have it installed on five machines. The file I'm transfering is about 4.5MB in size and can be transferred in under 30 seconds using scp (and that's including the time it takes for me to type in a password), so to transfer the file to four machines (the fifth is doing the sending) should take around two minutes.

The first test I stopped after twelve minutes. Okay, so one of the machines is a bit flaky, so I decided to drop that one from the test and run the test again.

Ten minutes.

Also, because of the way multicast works, the sending process doesn't exactly end when the clients have the data just in case another process joins to receive the broadcast (I'm guessing, the documentation for MDP is scant and the help feature doesn't work) so this may not work for what we want to do.

Monday, April 25, 2005

The past two weeks

From: "Ken Maier" <XXXXXXXXXXXXXXXXXXX>
To: "'Sean 'Captain Napalm' Conner'" <SEAN@CONMAN.ORG>
Subject: RE: FW: The Boston Diaries Update Notification
Date: Mon, 4 Apr 2005 08:41:22 -0400

but as an aside, I'd like to thank you for keeping your blog updated and not falling into the category of people who start something and don't post to it anymore. I'm never sure what to read on your blog Sean and I'm always entertained. Keep up the good work! ;-)

Note that Ken sent that earlier this month. And what do I do in response? Not update for two weeks. Sigh. Since my last update I've:

Tuesday April 12th

Sometime in January I tried renewing my driver's license and renew my car's registration online but while it looked like it worked, I had yet to receive my driver's license or registration. So I set aide this day to look into this matter at the DMV office.

Or rather, offices. The closest office to handle driver licenses is in Lantana (only a couple of miles from Casa New Jersey) but they don't handle car registrations; that office is in Lake Worth (again, only a couple of miles away from Casa New Jersey, but in the other direction). No big deal, just take the day off from work (of course) and hit both offices.

My mistake was in not hitting the driver license office at 7:30 am.

When I arrived around noon, there was a mob of people outside. Pushing my way inside I found another mob of people waiting in line to get permission to wait in line. This convinced me that I might be better off trying to do this by phone. Only (after I got home) the phone was busy (imagine that) so I tried the online thang again. Seemed to work this time around.

Friday, April 15th

Taxes.

Ouch.

Just … ouch.

I've heard cries about simplifying the tax code, possibly going with a flat tax to make things simpler. Only it's not the actual tax calculation which is hard (if it's less than US$100,000.00 you look up the amount on a table, and if it's over that it's 25–35% of your income, depending upon how much it is and what your filing status is—but the worksheet for that is simple)—it's the definition of “income” which is hard. Lines six through fourty-two of Form 1040 exist just to figure out your taxable income (that's 36 lines and up to six schedules and four forms).

Having a flat tax won't make that go away.

Saturday, April 16th

The House Chillin' Party.

It was great! Most of the people invited showed up, and much food, drink and conversation was had. The rocket launch (The Kids found a model rocket when we moved in) was successful (once we figured out that the launch key had to be shoved way into the launch control unit), and the parachute deployment was successful, but the winds carried the rocket away to a private golf course an inaccessible area—I just hope we didn't scare any golfers indigenous populations with its landing.

By the way, the Words of Wisdom we asked people to bring where strung up across the living room.

Last week at work

At the House Chillin' Party I managed to talk to Mark and Rob about the broadcast copy idea I was working on (Rob is now a senior Unix administrator for Negiyo and they're responsible to updating and managing hundreds of servers across two dozen or so groups so any insight he has is great) and both didn't like the idea of multicast or broadcasting changes around. They also weren't keen on the idea of polling for updates. So I may just go with the O(log n) method of pushing files out.

So I slipped into another related project—that of monitoring a large number of servers. I do know that SNMP is used here to monitor the various routers and switches, but it seems that since I last looked at it (late 90s) it's been extended (since it is extensible) to include host information (you can even monitor processes! And installed packages! Wow!). So not only have I been installing NTP on all the servers (slowly, working my way through the list) but also SNMP.

Smirk also wants to use Cobalt RaQs for various infrastructure hosts, like DNS, since they use very little power (about 35W vs. 250W for a typical server). I've already set one up as a firewall, but more about this in the next entry.

That pretty much brings us up to date.


Installing Debian on a MIPS-based Cobalt RaQ

There are two major types of Cobalt RaQs, those based on the MIPS chip (RaQs 1 and 2, plus the Qubes) and those based upon the Intel Pentium chips (RaQs 3 and 4). They come with a version of Linux preinstalled, but they're an older kernel (2.0 or 2.2) and due to the limited nature of the firmware, it's not easy to upgrade them with a more modern Linux kernel.

It can be done.

But it takes some work.

This entry is about upgrading a Cobalt RaQ 1 or 2 (the MIPS based machines).

I had intended to install NetBSD but the install instructions seem to assume you have a bootable Cobalt RaQ to begin with. I didn't, since the unit I was given lacked a harddrive (as I found out); I didn't have the luxury of a booting Cobalt RaQ (it came without a harddrive).

Debian has a port to the Cobalt RaQ (MIPS, not the Intel). The instructions I initially found mentioned the “woody” release (a few years old now) and that distribution failed miserably. Poking around the Debian site lead to the “sarge” release, which worked wonderfully, but in getting it going you need to do quite a bit of work.

I'm not sure if RARP is required for this or not (the NetBSD instructions seemed to indicate it was) but since I had RARP support for a previous NetBSD install a few years ago it didn't hurt to use it. Getting the MAC address of the machine was a simple matter of a forced network based boot and sniffing the network traffic and then rarp -s 10.0.0.15 00:10:e0:00:68:10. In any case, you will need the MAC address of the Cobalt RaQ.

Then it's configuring of NFS. Easy enough to export the /nfsroot directory (yes, I had to create it) and to keep the potential problems down added the following to /etc/exports:

/nfsroot *(rw,no_root_squash,async)

Now, the final DHCP configuration that worked:

host kobold
{
  hardware      ethernet 00:10:E0:00:68:10;
  fixed-address 10.0.0.15;
  filename      "/boot/vmlinux.gz";
  option        root-path "/nfsroot";
  option        domain-name             "kobold.groomlake.area51";
  option        domain-name-servers     10.0.0.1;
  option        routers                 10.0.0.1;
  option        subnet-mask             255.255.255.0;
  option        broadcast-address       10.0.0.255;
  next-server   10.0.0.3;
  server-name   "10.0.0.3";
}

(yes, I know that .area51 is not a valid TLD; it's one I created a few years ago when playing with DNS and it's only used for the private network at Casa New Jersey).

Next step, getting the files that are needed to boot the Cobalt RaQ. If you don't mind Debian, these work. You'll need initrd.gz, vmlinux.gz and vmlinux_raq-2800.gz—while I did get default.colo it didn't seem to actually work but hey, it can't hurt to get it. All the files are placed in /nfsroot/boot/ on the NFS server, and marked executable (I also placed a copy in /nfsroot but that shouldn't matter).

Next step, getting those files loaded. Hook up to the serial console on the Cobalt RaQ (baud rate 115200, parity 8n1 and if that doesn't work, take a paper clip and hold in the button in the hole just to the right of the LCD screen while powering up; that will reset the serial console to 115200 8n1). While powering it on, hit the space bar to get the boot prompt, and type:

bfd /boot/vmlinuz.gz root=/dev/nfs nfsroot=/nfsroot

What you are loading is not Linux, but yet another boot loader that doesn't have the same restrictions as the one built in (it's CoLo, which can be used to replace the existing boot loader, or used in this chaining method). That will boot and if it fails to load the actual Linux kernel (which in my case it always did) you can simply (hah!) type:

ColoPrompt> nfs {dhcp-next-server} {dhcp-root-path} vmlinux-2.4.27-r5k-cobalt initrd.gz
ColoPrompt> execute rd_start=0x{initrd-start} rd_size=0x{initrd-size} console=ttyS0,{console-speed}

(and if that doesn't work, power cycle the Cobalt RaQ and try again—I had to do this twice to get the Debian Intaller running)

You are then running the Debian Installer and from there on out it's just like any other Linux installation. You partition the drives (for this system it's recommended you let it partition the drives), select the type of install and let it go. You'll end up with a usable, if rather bare, Linux system (right now it's compiling MySQL).

Tuesday, April 26, 2005

… and the cops go wizzing by …

The last time I saw this many cops was a few years ago when the bank our company was above was being robbed.* This time however, about two dozen cop cars (at least, maybe more) just flew by our office, sirens blaring and turned right at the corner into one of the many commercial parks in this section of Boca Raton, Florida. I figure we'll hear about it on the news later tonight, tomorrow at the latest.

* It was a Friday afternoon in '98 or '99 when the building we were in was surrouded by Boca's Finest. Shortly afterwards, the SWAT team showed up, and took positions around the building. A police officer managed to make it up the back stairs to our office and told us to keep the door locked. After a few tense hours the suspect was arrested—it turned out he was an escaped mental patient.


Waiting … waiting … waiting.

Compiling on the Cobalt RaQ2 isn't fast. It's actually rather sluggish when you come right down to it. Now whether that is a function of the MIPS chip, a slow bus speed, or a slow IDE drive, I can't say, although I suspect it may be a slow bus speed (the MIPS based SGI system I used at FAU, while only 33 MHz, was fast—the only things faster were the newer MIPS based SGIs).

Time it took to compile various packages on a 250MHz MIPS based Cobalt RaQ2
Package Real time User time System time
MySQL 4.1.11 312m, 31.074s 288m, 52.820s  20m, 32.900s
Bind 9.3.1 51m,  0.245s 47m,  2.640s  3m, 20.260s
Apache 2.0.54 84m, 26.658s 66m,  6.710s 16m, 45.680s
PHP 4.3.11 56m, 17.193s 45m, 44.070s  9m, 52.470s

These were just the packages I kept the compile times for—the rest (like OpenSSL or NTP were just as slow to compile.

I wonder though … if there is a way to tune the IDE drivers to get some better throughput …

Wednesday, April 27, 2005

… and the cops are still wizzing by …

Again with the cops, about two dozen or so screaming past our office and heading to the same place as yesterday (and nothing about it in the news). On the way home yesterday I did notice that the company they went to is a security related company, so perhaps this is some training mission.

Very wierd …


Taking away the spam filter's Little Orphan Annie Secret Decoder Ring

A few months ago I wrote about some character encoding problems I was having, namely that it was a real mess under the web. But apparently, it's not a mess with email.

We have a dedicated computer that does nothing but filter spam (and the statistics from that are depressing); you can add additional fitering via regular expressions. Smirk has been receiving quite a bit of foreign spam, stuff in Russian, Korean, Chinese, which he can't even read since it's in Cyrillic, Wansung and Hangul. But (for instance) some (if not most) of the email had subject lines like:

Subject: =?Windows-1251?B?amFlQGxlZWhvbS5uZXQg?=

where the character set is encoded within the subject line. So Smirk thought a regular expression like ^Subject: .*Windows-1251.* would work and filter out the spam in Cyrillic (with appropriate regular expressions for Wansung and Hangul).

Only it didn't work.

It caught subject lines that had “Windows-1251” as part of the legitimate subject line (I sent him a test message with the subject of “Did you get Windows-1251 yet?”) but not if it was part of an encoding. Which meant only one thing: the spam filtering system was applying the regular expressions to the decoded characters!

Well … that's certainly a surprise.

But it doesn't help the current problem. We're now waiting to hear back from the company if that “feature” can be turned off.


All I want to do is install Linux …

I finally received the go-ahead to convert my workstation from Microsoft Windows to Linux (well technically, I can install Linux on another workstation and swap it out for the Windows system I'm using now, but that's just an implementation detail).

Woot!

But I've been at this for five hours now and I've yet to even start installing Linux.

Boo!

First, I had to copy any important data off the machines (mine, and the current Windows system I will be installing Linux on). At first, I thought I could mount the office file server (which Smirk had finally finished setting up) but after spending almost an hour trying to get my machine to see that machine we gave up and used tar and scp (we have Cygwin installed on all the Windows systems here). Of course the machine I'll be using had a 10Mb network card which meant it took a long time to copy all the data to another computer.

Then it was time to install. The nearest distribution CDs available were for CentOS, a Linux distribution based off Red Hat's Fedora Core. P has it on his workstation, and at this point, I'm not particularly picky about my Linux distributions, just that can use one. So after swapping the network card for a 100Mb one, I put the CD in, and power up.

The Linux kernel is loaded, but that's it.

For about fifteen minutes.

Until I realize that P mentioned that he had made a CentOS boot disk that uses a serial console, not the video console.

Well then …

I found some Fedore Core 2 disks and boot that. It loads, but as it's loading up, I realize that I'm missing CD #2.

Okay, I can burn a CD while that's loading. Smirk has the disk images on his computer, so it's a simple matter of burning disc #2.

Ha ha, only if it were so easy.

I probably wasted close to another hour trying to figure out how to burn a CD on his computer. Which is running Windows. All I wanted to do was burn a file, which is a bit-for-bit image of a CD onto a blank CD. Under Unix, it's dd if=diskimage.iso of=/dev/cdrom. Under Windows … it's … a XXXXXXX nightmare. I “burned” three copies before I realized they weren't actually burned—the software just “simulated” the “burn” (only I didn't “notice” the “scare quotes” when it “burned” the “disk”). By then I noticed that the install program had just … stopped.

Bad CD?

Bad hardware?

The spectre of Bill Gates?

Hard to tell, but I decided to assume the CD was bad and burn a new disc #1, just as soon as I could figure out how to burn a disc on Smirk's computer.

I called Smirk, and he walked me though the process.

Only the computer refused to boot from the burned discs.

I then stepped the burn speed down and attempted another time.

I then stepped the burn speed down yet again to the slowest setting (4x) and am now waiting for the current burn to finish. If that doesn't work, I'll burn effigies of Bill Gates and Steve Ballmer and try again tomorrow.

Oooh! CD is finally done burning. Gotta go …


All I wanna do is burn Bill Gates and Steve Ballmer in effigy

Sigh

Thursday, April 28, 2005

A comfortable environment

I think burning Bill Gates and Steve Ballmer in effigy worked to remove any bad karma from the system (that, and changing the CD-ROM in the computer). I was able to finally get my Linux-based workstation going, and the first thing I did was install Fvwm (my window manager of choice—yes, I am old school).

Now I have a very comfortable environment with which to work in, and all is right with the world (and it doesn't hurt that it's been a quiet day at the office).


Again with the cops

It must be a training exercise.

Friday, April 29, 2005

Don't Panic

Wlofie and I saw The Hitchhiker's Guide to the Galaxy today. I kept my expectations lows and generally, when I do that, the result is usually better than coming in with too high expectations. Overall, the movie was good but there were the obvious bits of Hollywoodization to the story (some chase scenes, a silly love interest story). The thing to remember about H2G2 is that the story isn't faithful to itself in any of the mediums it's been translated to. The radio version is different than the book is different than the TV series is different than the play(s) (there were two) were different than the computer game and this movie is consistent in that it isn't consistent at all, which (given that the book trilogy is five books long) fits H2G2.

The cast (mainly of unknown actors) is spot on perfect (and I absolutely adored Zooey Deschanel (Zooey—what a cool name) as Trillian). The visuals (especially the Magrathea factory floor) are just wonderfully done. And the new bits done specifically for the film are inventive (one involves a rescue (I won't say who) by filling out the proper release forms of the proper color, in triplicate and signed by the proper party with the only injury being a rather nasty paper cut (although to be honest, any type of paper cut is rather nasty) and another one involving the Point-of-View gun).

If you are a fan of H2G2 don't expect something that slavishly follows any of the previous versions of H2G2 that have come before and just enjoy the ride. If you aren't a particular fan of the work, it may be worth to view this once it hits DVD.

Also, stick around for the the credits. There's an amusing bit from the Guide itself during the final credits (of the several animated segments in the movie, they all look to be animated with Macromedia Flash; the sequences in the TV series were I think more innovative even if they weren't done by an actual computer. It's not to say the sequences were bad—they weren't, but I think I preferred the TV sequences which had so much going on you couldn't get it all at once).

Obligatory Picture

[Don't hate me for my sock monkey headphones.]

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: http://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

http://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2017 by Sean Conner. All Rights Reserved.