Rebirth of a web site

2011/02/21 23:21:48

I just spent time giving birth to an Old Dominion University Computer Science web site at  It’s just one page now, with some course information, and some links back to this site.  I know, not very interesting.  Under the covers, though, is a testbed for the Semantic Web.  So far, I’ve got Dublin Core and Friend of a Friend (FOAF) implemented for that one page.  In the future, I intend to bring the lessons learned there over to this site.  Eventually, the two will begin to look more alike in both style and function.

Perhaps Web Science and Digital Libraries is really my thing. I spend an awful lot of time blogging about my own web sites.

Validation of the Creative Commons Markup

I also discovered that the Creative Commons license markup wouldn’t validate with the W3C validator. This was because my page was initially specified as XHTML, but the Creative Commons license link contains additional RDF metadata used by search engines and other software. A blog post suggested just removing the metadata, but I didn’t want to do that because I knew that metadata had been placed there by Creative Commons for a reason. That metadata is part of the RDFa standard, which is a way of embedding metadata into normal HTML and XHMTL.

It turns out that once you put that Creative Commons markup into your XHTML, it becomes XHTML + RDFa, which is a completely different document type. I felt good that I’d figured this out, and changed the page to use this instead.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "">

Now it validates fine as XHTML + RDFa.

Nifty floating image trick

You may wonder how I got the image to stay on the left and in the same spot, even though the visitor can scroll the page.  It is based on the following CSS, shamelessly stolen from the W3C themselves.

body {
    background-image: url(;
    background-repeat: no-repeat;
    background-position: top left;
    background-attachment: fixed;
   /* more CSS here */

That’s it. It’s quite elegant, and I spent more time making the image with Inkscape than I did actually writing the CSS to tell it to stay put.

Useful Links

I discovered the following useful sources for bringing that site to life:

Testing RAM on a Macbook Pro

2011/02/03 23:46:02

My Macbook Pro came with 4GB of RAM in 2 2GB modules.  In December, I ordered 8 GB (2 4GB modules) of RAM from Crucial so I could max out the RAM in the machine, as I intend to keep it for a while.

Early in January I started to see applications crash.  VMWare Fusion became almost unusable.  I had never seen this behavior from my Mac before, so figured the new RAM had something to do with it, but wanted to verify my assumption before blindly blaming Crucial for bad RAM.  At that point I had to learn how to best test RAM on a Mac.

On a PC, I would have booted a CD running memtest86, but none of my Internet research indicated that was possible for the Mac.

Instead, I had to install memtest and boot the machine into single user mode in order to run memtest with the least amount of interference from running programs. I wanted to document what I had done in a blog post so I could remember next time.

Note: This article involves configuring your Mac in a way that could make it difficult for you to boot it normally if you don’t know what you’re doing. If you don’t feel comfortable following these instructions, take your Mac to a technician who not only feels comfortable fixing your computer, but is also competent to do so.

To tell the Mac to boot into verbose 64-bit single user mode, go to Applications/Utilities/Terminal, and type:

sudo nvram boot-args="-s arch=x86_64 -v"

You may be asked for the password you type to make changes to the system, type the password and hit enter.

Reboot your Mac.

Your Mac will boot to a prompt.  You may be surprised at all of the text that goes by.   These are kernel messages that are normally hidden by the nifty Apple logo.

At the prompt type:

memtest all

This will attempt to test as much RAM as it can.  Remember that some of your RAM is being taken up by minimal amount of software that booted your machine into single user mode (the kernel and bash), so you won’t be able to test everything, but if the flaw was in the RAM being used by the software running at this point, the machine would have failed to boot.

If your RAM is good, the test will take hours and you will see something like:

Memtest version 4.22 (64-bit)
Copyright (C) 2004 Charles Cazabon
Copyright (C) 2004-2008 Tony Scaminaci (Macintosh port)
Licensed under the GNU General Public License version 2 only
Mac OS X 10.6.6 (10J567) running in single user mode
Memory Page Size:  4096
System has 2 Intel core(s) with SSE
Requested memory: 7555MB (7922552832 bytes)
Available memory: 7555MB (7922552832 bytes)
NOTE:  Memory request is too large, reducing to acceptable value...
Allocated memory:  7343MB (7700721344 bytes) at local address 0x00000000101000000
Attempting memory lock... locked successfully
Partitioning memory into 2 comparison buffers...
Buffer A: 3671MB (3850360672 bytes) starts at local address 0x0000000101000000
Buffer B: 3671 MB (3850360672 bytes) starts at local address 0x00000001e67fd760
Running 1 test sequence... (CTRL-C to quit)
Test sequence 1 of 1:
Running tests on full 7343MB region...
  Stuck Address       : ok
  Linear PRN            : ok
Running comparison tests using 3671MB buffer...
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV          : ok
  Compare OR           : ok
  Compare AND         : ok
  Sequential Increment:ok
  Solid Bits               :ok
  Block Sequential      :ok
  Checkerboard         :ok
  Bit Spread             :ok
  Bit Flip                  :ok
  Walking Ones         :ok
  Walking Zeroes       :ok
All tests passed!  Execution time:  7068 seconds.

If your RAM is bad, you will likely get a response really fast, and you will see something like:

*** Address Test Failed *** One or more DIMM address lines are non-functional.


FAILURE: possible bad address line at offset 0x06b3a4c8.


FAILURE: 0xbea1ce76 != 0xbea1ce7e at offset 0x06b3a4c8.


*** Memory Test Failed *** Please check transcript for details.

If you get a message like:

Attempting memory lock... ERROR: Memory lock failed - reason unknown.

WARNING: Testing with unlocked memory may be slower and less reliable

hit CTRL-C and make sure you booted into 64-bit mode by typing the following:

uname -m

If the command doesn’t return x86_64 then you are not running in 64-bit mode and your Mac can’t reach the RAM above 4GB. Please reference the above command for booting your Mac into single user mode, as it includes the flags to set it to 64-bit mode, then reboot.

If the command above does return x86_64, then you are running in 64-bit mode and this message is probably a preview of test failures to come.

If you have more than one module of RAM, then take all of them out, and place one in the machine, boot, and run the test. After that one finishes test, note the results, turn the Mac off, take the RAM module out, and put the next one in. This way you can figure out which module is bad.

When done, make sure you have good RAM in the machine, boot it again, and type:

sudo nvram boot-args=""

This will give you your “normal” Apple logo screen on boot.

I hope you will find this article as useful as I will the next time we need to test RAM on a Mac.

Today, Crucial was nice enough to send me some new RAM after I sent them the bad module.  So far, it appears to be passing memtest.  Cross your fingers for me!  :)