#! /usr/bin/perl
 
use strict;
use warnings;
 
die "$0\n\tGet warranty info from dell.\nUsage\n$0 [SERVICE TAG]\n" if !$ARGV[0];
 
my $service_tag = $ARGV[0];
 
use LWP::Simple;
use HTML::TableExtract; # Is in the CPAN, and exists in the debian repositories as libhtml-tableextract-perl
 
## Make a URL:
my $url_base = "http://support.euro.dell.com/support/topics/topic.aspx/emea/shared/support/my_systems_info/en/details";
my $url_params = "?c=uk&cs=ukbsdt1&l=en&s=gen";
my $url = $url_base.$url_params."&servicetag=".$service_tag;
my $content = get($url);
 
# Tell HTML::TableExtract to pick out the table(s) whose class is 'contract_table':
my $table = HTML::TableExtract->new( attribs => { class => "contract_table" } );
$table->parse($content);
 
## Gimme infos!
foreach my $ts ($table->tables) {
	foreach my $row ($ts->rows) {
		print "", join("\t", @$row), "\n";
	}
}

Pretty much all modern PC memory is also DDR, Double Data Rate. With Single Data Rate RAM, data is only sent when the timing signal is high¹. The clock signal is high for some period of time, then low for another period of time of the same length. One cycle consists of one high period and one low period. Single Data Rate RAM can only transmit at one of these, DDR at both.

DDR is then further subdivided into DDR, DDR2 and DDR3. Though the voltages are different (2.5v, 1.8v, 1.5v respectively), the big difference in practical terms is the socket shape:

While we're here, it's worth noting that the most commonly-used difference between DDR and DDR2 RAM, the notch position, is frightfully difficult to identify without an example of the other type against which to compare. More obvious is the gap between the contacts and the notch on the DDR stick (to the right of the notch in the above pic), which is absent on the DDR2 stick.

There are two ways people refer to DDR RAM, as a DDR-XXX or PC-XXXX. For example, DDR200 is also PC1600.
The 200 in DDR200 is the clock rate of the memory modules (the chips on the memory stick). It is double the clock speed of the system it's plugged into, since it is DDR (and so operates twice per cycle).
The 1600 in the PC1600 is the maximum number of bytes per second that the RAM allows, and is not achievable in the real world.

To calculate one from the other, we do

TransferRate = SystemClockRate x DataRate x NumberOfBytesTransferred / NumberOfBitsPerByte
TransferRate = SystemClockRate x 2 x 64 / 8
TransferRate = SystemClockRate x 16
 

Since we're concerned with Dual Data Rate memory, the data rate is equal to two. It transfers 64 bytes per cycle, and each of those bytes is 8 bits long.
The SystemClockRate is the frequency of the system bus, not of the memory itself - DDR200 operates at a frequency of 200MHz, but requires a system with a clock of 100MHz. In order to find the TransferRate given the MemoryFrequency we need to do

 
TransferRate = SystemClockRate x 16
   but SystemClockRate = MemoryFrequency x 0.5
TransferRate = MemoryFrequency x 0.5 x 16
TransferRate = MemoryFrequency x 8
 

Hence 200 x 8 = 1600 means we'd expect DDR200 to give a theoretical maximum of 1600Bps, and so be PC1600.

The above are all maxima - DDR can operate at lower frequencies than its maximum. DDR266, while expecting a 133MHz system bus, can run satisfactorily in a 100MHz system, but it will only operate as DDR200.

Below are the combinations implemented in the real world:

The above is basically an aggregation and condensation of what is in the following articles. If you want more detail, go there:
http://en.wikipedia.org/wiki/DDR_SDRAM
http://www.hardwaresecrets.com/article/167/1

1. or low. I don't actually know, but It's mostly immaterial. The important bit is that it's an 'or' not an 'and'.

It basically allows you to have a monitor for each PC on your desk, and one keyboard and mouse with which to monitor them. Switching between PCs involves just moving the mouse pointer onto the relevant screen. It uses 'screens' rather than monitors, so you don't need to let it know if you've got a complicated multi-monitor setup on a host (or even if you add or remove monitors from one), and it allows for having screens of different sizes and for, say, the bottom half of one screen to line up with the top half of the next.

It's a server/client model - you have one server box into which you plug the keyboard and mouse. The rest connect over the network to it (in cleartext, don't do this where you don't trust the network).

I have two hosts. My work laptop is running Windows XP and has an external monitor plugged in to it. My testing PC is running Debian testing and is a PC proper. Here's my desk:

jup-linux2 is the left monitor (attached to the PC to its left, running Debian), jup-rmt07 is the laptop on the right, which is also attached to the Sony screen in the middle. Since I take the laptop home with me occasionally, jup-linux2 is configured as a server, jup-rmt07 as the client (less to unplug).

Synergy is in the debian repositories, so it's just an apt-get install synergy. This provides two binaries, /usr/bin/synergyc and /usr/bin/synergys, which are the client and the server respectively.
To install it in Windows, you'll want to grab it from their Sourceforge page

Configuring and starting the server
So, having installed, we can configure! The configuration file can be arbitrarily named, mine's cunningly called ~/.synergy.conf and appears verbatim at the bottom of this. Synergy's really rather configurable, but I've never found much need for more than the basics, so I've an incredibly simple setup.

First, we define some 'screens'. Here we can also configure optons for screens, especially as regards the transference of caps-lock and num-lock statuses. I've no special requests, so I just list the hosts whose screens I want Synergy to manage:

section: screens
	jup-rmt07:
	jup-linux2:
end

Second, we define the links. For each monitor, we state what is at any edge of it. This is used to decide where to put the mouse pointer on leaving the screen, so it needs to be done in both directions - the fact that jup-linux2 is to the left of jup-rmt07 does not imply to synergy that jup-rmt07 is to the right of jup-linux2:

section: links
jup-rmt07:
	left = jup-linux2
jup-linux2:
	right = jup-rmt07
end 

If I have two screens at different heights, I can tell synergy that the top 30% of jup-linux2 lines up with the bottom 40% of jup-rmt07, for example:

jup-linux2
	right(70-100) = jup-linux2(0-40)
jup-rmt07
	left(0-40) = jup-rmt07(70-100)

Again, you always always always need to define the screen in both directions. The file is parsed by synergy to see what to do on leaving that particular screen - when you're in jup-rmt07 and move towards the left of the screen, it's only going to do anything if there's a left defined for that screen, irrespective of how many rights point there.
If my screens are above and below each other, up and down are used. A screen can have as many other screens round it as you like, by assigning percentages of edges to different screens.

Configuring the server under Windows involves a different process to use the same principles. Essentially, you build the same text file as above, but in a clicky gui. It's a little odd, but quite simple.

To start the synergy server, we now run

synergys --config ~/.synergy.conf

Replacing '~/.synergy.conf' with the path to wherever the config file is saved.

Configuring and starting the clients

So, we have a server. Now, clients.
On Windows, synergy is only one executable, so we start that, select the 'Use another computer's shared keyboard and mouse (client)' option, stick the server's hostname or IP in the box, and click 'start'.
If you have a *nix client, the command to connect to a server at jup-rmt07 is synergyc jup-rmt07. synergyc provides a few options for changing the behaviour.

Starting Synergy automatically
Finally, I want them to start automagically on boot/login. For the linux host, this is relatively easy, add the following to your crontab:

@reboot synergys --config ~/.synergy.conf

And it'll be started on boot.
To start it under Windows, click the 'AutoStart' button. This will let you configure it to start it on login or, if you have the requisite permissions, start on boot.