# Dell Warranty Info

I hate navigating the Dell website. It's inconsistent and messy and noisy, and all I generally want is a single date (when the warranty expires or expired on a given box). So I wrote this. It scrapes the Dell website, and returns the warranty info for the service tag it's been passed.
I've CGI'd it here.

#! /usr/bin/perl use strict;use warnings; die "<span class="katex math inline">0\n\tGet warranty info from dell.\nUsage\n</span>0 [SERVICE TAG]\n" if !<span class="katex math inline">ARGV[0]; my</span>service_tag = <span class="katex math inline">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</span>url_base = "http://support.euro.dell.com/support/topics/topic.aspx/emea/shared/support/my_systems_info/en/details";my <span class="katex math inline">url_params = "?c=uk&cs=ukbsdt1&l=en&s=gen";my</span>url = <span class="katex math inline">url_base.</span>url_params."&servicetag=".<span class="katex math inline">service_tag;my</span>content = get(<span class="katex math inline">url); # Tell HTML::TableExtract to pick out the table(s) whose class is 'contract_table':my</span>table = HTML::TableExtract->new( attribs => { class => "contract_table" } );<span class="katex math inline">table->parse(</span>content); ## Gimme infos!foreach my <span class="katex math inline">ts (</span>table->tables) {	foreach my <span class="katex math inline">row (</span>ts->rows) {		print "", join("\t", @\$row), "\n";	}}

# DDR RAM identification and naming conventions

All (modern) PC memory is SDRAM (Synchronous Dynamic RAM). DRAM, the predecessor, responded to requests as soon as it could after the control voltages changed, SDRAM replies according to a clock cycle (which synchronises it with the system bus).

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 high1. 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 / NumberOfBitsPerByteTransferRate = SystemClockRate x 2 x 64 / 8TransferRate = 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.5TransferRate = MemoryFrequency x 0.5 x 16TransferRate = 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:

 DDR200 PC1600 DDR266 PC2100 DDR333 PC2700 DDR400 PC3200 DDR2-400 PC2-3200 DDR2-533 PC2-4200 DDR2-667 PC2-5300 DDR2-800 PC2-6400 DDR2-1066 PC2-8500 DDR3-800 PC3-6400 DDR3-1066 PC3-8500 DDR3-1333 PC3-6400 DDR3-1600 PC3-12800

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'. []

# Using Synergy to share a keyboard and mouse across PCs

Synergy is a really neat way of using multiple computers at the same time, like a more convenient KVM switch (you do need to be physically close to all of them).

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.