Black Coffee (Deprecated)

John Ashcroft: Wicked and Demented Man

Attorney General John Ashcroft is not only a wicked and righteous man, but also demented in the uniquely repugnant form radical Christians have mastered. He is perhaps the greatest pox of the entire Bush Administration.

Is this nasty habit going to go away?

So this weekend I'm at a company "retreat," staying at a well-known luxury hotel that probably costs several hundred US dollars per night. So when I came back to the room, I planned to turn on my laptop, check my email and relax. Well I did turn on the pc, but I never made it online because this hotel is a member of the "Biznet Hotspot Network."

Oh fuck you.

If the Best Western will give me free wireless internet in a $49 hotel room, why should I pay another lousy 'hotspot provider' to use it here? The answer is that I won't, I boycotted.

This business of pervasive internet pervasively balkanized by all these penny-ante providers is already very tedious. About the only thing I can think to do is set up an http tunnel on obscure ports that hopefully aren't blocked by these providers. Otherwise, if they think I'm going to pay them 10$ to read my email, they can forget it. Especially especially when Cinemax is showing a straight-to-video John Gotti movie for free....

The Big Sleep and Other Novels

During a two-month vacation between jobs in 1998 I read an Elmore Leonard novel. His books are like Pringles, eat one, you'll eat the whole can. Since then I've read the majority of his corpus, and they're mostly all entertaining. Like Pringles, though, they're all very similar and the last one you eat doesn't have the same great taste of the first. Regardless, in any of them, you can count on hilarious dialogue, a cast of idiosyncratic characters, and a twisty plot.

Recently I've enjoyed another fresh find: Raymond Chandler and Dasheill Hammet detective novels. Very similar in style to each other, they have the same dependable characters, plots, and atmosphere story-after-story. Like Elmore Leonard novels, I'll probably be pretty bored of them by the time I've read them all, but right now we're still in our honeymoon and I'm enjoying the hell out of them.

I mean, how can you not enjoy prose like this (from Raymond Chandler's The Long Good-Bye)

The homicide skipper that year was a Captain Gregorius, a type of copper that is getting rarer but by no means extinct, the kind that solves crimes with the bright light, the soft sap, the kick to the kidneys, the knee to the groin, the fist to the solar plexus, the night stick to the base of the spine. Six months later he was indicted for perjury before a grand jury, booted without a trial, and a later stamped to death by a big stallion on his ranch in Wyoming.

Written in 1953, the story has no political correctness, either, especially when Marlowe is talking to the mexican houseboy, Candy.

I stood up and walked around the table. He moved enough to keep facing towards me. I watched his hand but he evidently wasn't wearing a knife this morning. When I was close enough I slapped a hand across his face.

'I don't get called a son of a whore by the help, greaseball. I've got business here and I come around whenever I feel like it. Watch your lip from now on. You might get pistol-whipped. That pretty face of yours would never look the same again.'

Robert DeNiro should definitely play Marlowe.

MT-Blacklist: Credit when credit is due

I've had sporadic spam attacks but between MT's 2.66 comment-throttling/banner and my original counter-spam techniques, I was doing ok. Today I had a new, troubling attack. Some asshole representing a website for piercings and jewlery was spamming my comments, but was using (spoofing?) different IPs for each attack, so I had no way to effectively stop him.

MT-Blacklist was my only solution. It took perhaps seven minutes to install and it worked perfectly. I know that in earlier articles I resisted using it, but I have to say the system is good. As well, one of my early complaints, that it actually doesn't delete the comment, appears to be incorrect. As far as I can tell from the interface, it does indeed delete the spam and rebuild the blog.

The most amusing thing is that the top of the MT-Blacklist blog is the message:

Latest Change to Master Blacklist: skidman.com [Added: 2004/02/19 09:16:25]

That is the asshole I had problems with today!

Now, if only Google would zap the PageRank of all the sites listed in the Blacklist Clearinghouse....

The Dirty Thirty-One

Truth is stranger in fiction, particularly on the Korean Pensisula.

SILMIDO, South Korea -- In the winter of 1968, at the height of the cold war between the Koreas, 31 North Korean would-be assassins sneaked across the world's most heavily guarded border and reached a wooded area behind the palace of the South Korean president, Park Chung Hee, before they were stopped.

Three months later, in a tit-for-tat effort, the South Korean military recruited 31 men, from prisons and off the streets, for special training on this rocky islet in the Yellow Sea. Their mission was to sneak across the border, make their way to Pyongyang, the North Korean capital, and assassinate the North's leader, Kim Il Sung. But relations between the sides eased suddenly, so the mission was aborted.

In 1971, with no prospect of leaving this island, the recruits revolted, killed their guards in a military compound and managed to reach the mainland. There they hijacked a bus to Seoul, before being stopped by the authorities and blowing themselves up with grenades.

Rumsfeld

I don't like blog articles that are just links to other articles, but you really must check out Rumsfeld Kung Fu.

The Case Against Garmin

Whether good, bad, or indifferent, I'm saddled with a Garmin eTrex Vista GPS. I think Garmin did a lot of things right in the Vista's design. The interface mostly does what I'd expect, and on rare occasion I've even been surprised to find exactly the feature I was looking for in exactly the place I would expect to find it.

That being said, the Vista and MapSource, its ugly cousin, are not without their problems.

The only interface for downloading data is serial.

The use of a serial interface limits the device to quite slow data transfer speeds. Fortunately the interface supports up to 115Kbaud, but that means transfers will never exceed about 11KB/s. To put that in perspective, downloading 24MB of map data will take at least 30 minutes. That's a long time to wait.

The obvious solution is to provide a USB interface. The only downside to this approach is that Garmin may feel compelled to also provide a serial interface so that the GPS can interoperate with other NMEA compliant equipment. I think a good compromise would be to either provide both interfaces, or provide only the USB interface and offer a USB to serial dongle as an accessory.

They do provide a "turn GPS off after transfer" option, so that you can initiate a transfer and then walk away from the system without worrying about the GPS sitting their gobbling batteries long after the transfer is complete. This at least makes the best of a bad situation.

The protocol spoken over the serial interface is ridiculously slow.

When I recently downloaded 24MB of map data to my Vista it took 55 minutes, almost two times longer than should have been required for the 115Kb connection. I suspect that the protocol being used is woefully ineffecient -- perhaps each byte is sent in duplicate as a sort of retarded checksum.

To force the use of a slow serial interface for downloading data is bad enough, but to then not make every effort to use that interface as efficiently as possible is just insulting.

MapSource won't tell me how much data can be downloaded to the GPS.

MapSource provides a selection tool that allows you to select a subset of the CD map data and download it to a Garmin GPS. As you select the map area MapSource displays a running total of how much total memory will be required in the GPS.

When I recently selected a large number of maps, perhaps totaling 36MB of data, and tried to download it to the GPS I got a popup dialog from MapSource telling me that the selected area would not fit into the GPS, and I should select a smaller area and try again. I was given no information as to how much map data would fit in the GPS, simply that 36MB was definitely too much. What am I supposed to do now? Engage in binary search until I discover how much map data I can download? Consult the manual? Give me a break.

I can imagine that MapSource may say to the GPS "I've got 36MB of data for you" only to have the GPS reply "Up yours, that is too much", in which case MapSource truly can't tell me how much map data would fit. Of course, that only shifts the blame from MapSource to the Vista -- Garmin is on the hook regardless. I think it is much more likely that MapSource knows exactly how much space is available for map data (which may be different from the total memory in the unit) and simply neglected to report it as part of the error message.

Uploading maps starts from a clean slate.

When uploading maps to the GPS from MapSource, the very first action taken is to completely erase the map memory in the GPS. In the not uncommon case where the new map area partially overlaps the map area already in the GPS, no attempt is made to avoid needlessly transmitting the overlap area. The map data itself is broken into variable sized tiles, each of which is contained in its own distinct file on the MapSource CD-ROMs. When map data is selected for upload to the GPS, it is these tiles that are selected. There is almost certainly a filesystem, albeit probably rudimentary, which organizes the GPS memory, so it should be very straightforward to keep those map tiles that overlap, and only download the new tiles.

Downloading track data is inexorably slow.

I recently downloaded the track log from my GPS, a total of 7447 points. It required 6 minutes to move this piddling amount of data, in part because Garmin insists on performing the transfer at 9600 baud. The only possible explanation I can find is that the GPS could not continue to operate as a GPS while transferring the track log if it was going any faster than 9600 baud. I think that's a pretty unlikely explanation however, and a pretty poor design if that's the case.

Saving track data is a destructive operation.

The Vista maintains an active track log, and at any time the track log can be saved (and optionally cleared) to memory. Up to 10 tracks can be saved, in addition to the active track log.

However, saving the track log turns out to be a *destructive* operation. I discovered this when I downloaded my saved tracks and saw that the active log was about 2400 points, while the saved track from the previous day was only 700 points. I knew I had covered about the same distance in about the same time on each day, so something funny was definitely going on. I had previously seen very poor track resolution when displaying tracks in MapSource, and I had a sinking feeling I knew what was going on.

I saved the active log and then cleared the active log and downloaded the saved tracks again. Lo and behold, the previously 2400 point active log had become a scant 700 points upon saving the log. Presumably Garmin deletes intermediate points on straight line paths, etc. But whatever the error metric is for deleting points from the track, on more than one occassion it has turned the log of a hike from a smooth and obvious path into a nearly incoherent scribble that skips over switchbacks and other important features. To add insult to injury, the tracks are mangled without any warning whatsoever. It's incredibly annoying that Garmin should see fit to treat my data with such complete disregard. A dialog announcing "Saved logs are resolution reduced from the active log, and the resulting track may be completely useless. Are you sure you would like to save the active log?" is certainly in order.

The only excuse I can think of for this deplorable behavior is memory pressure -- there simply isn't enough memory to be storing voluminous tracklogs while also providing a large map, etc. Perhaps some analysis will give us some more confidence in this hypothesis.

A point on a track will probably require about 16 bytes of storage, between latitude, longitude, elevation and time. Perhaps Garmin has found even more goodies to store, like compass heading, etc. Of course there is a great deal of coherence in this data (latitude and longitude change very slowly, the time of day changes deterministically, etc.) so it could be wonderfully compressed. But let's not make extra work for Garmin, and we're trying to see how they might have a storage problem, so let's give them the benefit of the doubt and say 24 bytes per track point.

A quick experiment can vet this assumption. Downloading a track log which totaled 7447 points required about 6 minutes at 9600 baud. That's enough time to transfer about 345K, which gives us 46 bytes per trackpoint. Hmmmm. About 2x larger than the largest reasonable point size I can think of, but okay. Garmin isn't a big fan of efficient protocols, so maybe the track points aren't that big. In any case, let's use 46 bytes per trackpoing as a certainly pessimistic working figure.

So a 2400 point active log requires 110KB to store. Obviously 15 such logs would require about 1.5MB to store. In a device with 32MB of memory. And a *great* deal of that memory may be available, depending on how much or how little map data has been downloaded to the device. Of course I think there's good reason to believe that Garmin's memory management isn't that sophisticated -- perhaps with good reason. It would be irritating to try to upload map data to the GPS only to be told that track data will have to be deleted to make space.

Regardless, the track data requires ridiculously little space, and doing a poor filtering of the track to try to save space was a horrible idea. Even worse, this track data could be easily compressed, I would guess by a factor of 5, *without deleting track points* to further reduce any memory pressure.

Transfers can't be resumed.

Data transfers to or from the GPS can't be resumed. Either the transfer is performed in its entirety, or it must be restarted from scratch. This wouldn't be such an issue, except for some transfers require an inordinately long time. If my laptop goes into suspend mode during a long transfer, guess what? I can't resume the transfer, I have to start over from scratch.

MapSource + Laptop = Software Crashes

I did the most obvious thing and loaded MapSource on my laptop, allowing me to take the full MapSource data with me, instead of just the small portion which can be held in the GPS at any one time. My laptop doesn't include a serial port, so I bought a USB to Serial converter to allow MapSource to talk to the Vista and vice versa.

The first time I tried this system out in the field I ran into trouble. I started an upload to the Vista, and then started browsing a paper DeLorme atlas of the area while I waited (and waited). I forgot that my laptop was going to suspend after a few minutes of activity to conserve its battery.

What happened when the laptop suspended? The transfer to the GPS was interrupted and thus spoiled, so it would have to be repeated from scratch. When I unsuspended my laptop MapSource immediately crashed hard. I suspect that the USB to Serial dongle may behave a little strangely when the laptop suspends. For example, after resuming MapSource probably assumed that the serial port was still open, etc. However, the dongle may not have provided that interface. In which case MapSource would have encountered an error the next time it tried to use the serial port.

This isn't to say that MapSource is without blame here -- in fact the dongle may be operating exactly as it should. Regardless of how poorly behaved the dongle may be, MapSource should never crash. It should intelligently report the error it encountered, and in all likelihood it can just reopen the serial device and continue operating.

I think this is one of the few cases where I think Garmin has an at least plausible excuse. It's very likely that they've never tested their MapSource with the USB to Serial dongle I'm using. I'd be interested to know if they've tested the software under power suspend/resume, as obviously they should. Perhaps this is one for tech support.

Can't ask for trackback to a waypoint.

My normal mode of operation is to start the track log running at the start of the day and then save the track at the end of the day. During the course of the day I'll often set waypoints as I go, without starting a new track. For example, I'll set a waypoint at a trail head, but just leave the track log running.

Once I've hiked out the trail a fair piece it can be useful to now how far I've gone, so I'll know how much further I have to go to the end, whether I should turn around, etc. Garmin provides a feature that seems like it would do exactly this: you can "backtrack" along a track. The feature tells you how far from the start of the track you are and provides guidance to keep you on the track. Unfortunately this feature only supports backtracking along an entire track. So in my usual mode of operation I can only backtrack to my starting point for the day. It would be much more useful to be able to backtrack to a particular waypoint. In fact, part of the backtrack interface could present a selection dialog: "These waypoints are within 100 meters of your track. Select waypoint to backtrack, or start of track."

"Find nearest (waypoints)" is too literal.

The "Find nearest waypoints" function does exactly that, where Garmin has set some threshold for when a waypoint will be considered near. If the waypoint is too far away it simply won't be in the returned list, no matter how few waypoints are near the current location. What would be the harm in displaying a complete list of waypoints in order of distance from the current location? Just change the menu item to "Browse by distance" instead of "Find nearest" and it would be perfect.

"Find (waypoint) by name" is too clumsy.

The other option for locating a waypoint is to key in the waypoint name, or a prefix thereof, and select it from the list. The downside to this approach is it requires me to click around the virtual keyboard and hit "OK" before I can browse the list of names. This is a tedious process and is made even more annoying when the desired waypoint is near the top of the waypoint list, as any waypoint which stills bears its default numeric name will be. Why not provide "Browse waypoints by name" option to let me browse the list in alphabetical order?

MapSource draws really ugly maps.

MapSource does a terrible job of rendering maps. I'm sure a Tufte analysis of them could provide myriad reasons why they are a poor representation, but I'll stick with the simplest reason: they are incredibly difficult to read. I can't think of any possible reason why. Garmin is not the first company to draw a map, there are literally millions of examples of well-rendered maps that they could have used for direction.

What is so bad about the maps?

For starters, there is almost no control over the amount of detail that is shown. There is a crude slider under the preferences which lets you vary the detail between "Low" and "High" but it's unclear, at least to me, what effect this as you vary the scale of the map (zoom in and out). With the detail turned all the way up there is a dizzying amount of information on the screen at times. Any detailed options for what to show, what not to show, are completely absent. Don't need to see the several thousands navigational buoys in the San Francisco Bay? Tough, Garmin has decided those are important. Don't want a map choking on topographic contours? Tough, Garmin likes those too. Want to see more street names? Tough, Garmin has thrown almost all of those out in order to force you to buy a different, and presumably equally bad, map product from them.

Next up, they draw detail roads (the vast majority of roads) as narrow lines, regardless of scale. This makes the roads surprising hard to see and follow in a field of much stronger lines. For example, the topographic contours (which seem to *always* be displayed) include some very heavy lines periodically.

What else? The text labels, which are mostly used for point features in the topographic version (can't have you getting the street names for free) include no haloing, so often the text is just a jumble of thin text on top of other thin features.

MapSource draws really slowly.

MapSource draws the map very slowly. I mean agonizingly slowly. So slowly that scrolling is practically impossible to use. I think part of the problem is that MapSource doesn't appear to cache any of the map tiles in memory, so each time it redraws the screen it has to fetch all the tiles again from disk. Even worse, the software only officially supports keeping the map data on CD-ROM, making the pain of constantly reading the tiles from disk that much greater.

MapSource only supported to run off CD-ROM.

It is ridiculous in this day and age to not install all 1.5GB of data on the hard disk and eliminate the need for the CD-ROM. Fortunately you can copy the map data to your hard disk if you're willing to edit some registry keys so Garmin can find it there.

Selected area always highlighted in MapSource.

In order to download data to the GPS a map area must be selected. The selected area is drawn with a purple highlight, always. There is no way to turn off this feature, other than deselecting the area. Why? Who knows.

Uploading data from the GPS always starts a new .mps file.

Uploading data from the GPS (waypoints, tracks, routes, etc.) always starts a new .mps file (Garmin's proprietary save format for MapSource). As far as I can tell there is no way to upload the data into an existing .mps file, although I would argue this is the most obvious thing in the world to do. One reasonable interface would be to ask if the data to be uploaded should be included in the currently MPS file, if there is an MPS file open.

Transfer progress meter is subtly broken.

The progress meter for data transfers to/from the GPS includes an estimated time of completion that is slightly askew. When data is being transferred the estimated time till completion (ETC) will steadily increase until the integer representation of the percent complete changes. Clearly they are taking the elapsed time, dividing by the integer percent complete and extrapolating the time remaining.

While there's a ready hypothesis as to why the observed behavior exists, what astounds me is that the behavior was never corrected! We are several generations past x86 microprocessors which lack floating point support, so there is certainly no obvious reason to avoid the use of floating point. I suspect that the mistake was simply never observed, which seems astounding, given how incredibly slow the tranfers are. Of course, there is another, perhaps even more disheartening, possibility: the incorrect behavior was observed and not corrected.

"Find Place" is nearly useless.

The "Find Place" feature can only find cities, despite the fact that many more things also have names. Why not provide a "Find Named Feature" function instead? Of course, this may be part of the "you bought this version of the atlas, so you don't get that data" punishment program.

"Find Place" is broken.

Searching for "Severna Park", a city in Baltimore, returns nothing. Backing up and searching for "Seve" (a prefix) shows a list of many matching cities, which includes "Severna Park". Selecting that city and hitting "Find" results in "Severey, KS" getting selected. I can't imagine what is going wrong here. Perhaps there is an index of some sort that is out of date with respect to the map data? I can't imagine.

Waypoints don't include the time of creation.

Waypoints entered via the "Clikstik" could easily store the time of creation (a GPS always knows the time). This would be immensely useful for correlating waypoints to tracks, to time-stamped photographs, etc. At least the trackpoints all include the time.

Saved tracks don't include the time of creation.

"Raw" tracks includes a timestamp for each trackpoint, which combined with a distance-based search matching algorithm allows you to guess an approximate time for waypoint creation. Of course it is a guess at best -- the map from time to position is one-to-one, but position to time is potentially one-to-many. But at least it's something. HOWEVER, Garmin throws away the time associated with each trackpoint when the track is saved! So not only does the track get horribly massacred when saved, a large portion of the useful information is destroyed!

Duplicate waypoint names are forbidden

If you enter a waypoint with the same name as an existing waypoint the software complains that the name is already in use. Certainly a valid complaint. However, the software neglects to make any suggestion of a waypoint name that *isn't* already in use in order to allow the user to make some rapid progress.

Perhaps the most irritating thing about these problems is they are all so apparent after comparatively little use of the device, and they could be all easily remedied by Garmin.

Home-ripped RSS feeds

During Christmas, when I was holed-up in the Kuala Lumpur Mandarin Oriental, I was thinking about home-ripping RSS feeds to sites I enjoyed.

Oh, and back to scraping web sites to produce RSS feeds. I'm sure there is an Oreilly book out there that would describe the best practices for spidering a site and scraping its contents, but hell, do I really want to write and maintain a perl script every time I want to scrape a new site? No. It's a mess picking through all the piles of badly-formatted and baroque .html source.

What would be much cooler is a GUI-based engine that looks something like a browser, loads up a page and displays its structure, allowing you to annotate it with GUI devices, describing the landmarks on the page, what to scrape and what to ignore. It would then take that information and mechanically produce perl script for scraping the site according to those hints.

Well it turns out I was prescient, but lazy.

Just a few weeks ago I bought the O'Reilly spidering hacks book but haven't done anything with it because I've been busy with another software project. Tonight I was discussing my need to rip a site into a nice summary and 31die said, "make sure you use Template::Extract"

It's not as easy as a GUI scraping utility, but it's getting close. The idea is that the Template:: modules can take HTML output and a loosely specified template, then produce a formal data structure that I can then rend into whatever I want, handsome HTML for printing, or an RSS feed for viewing through my newsreader. The loosely specified part of it is what makes it neat -- it will be much easier to specifiy less-brittle scraping regexps.

Cool... so now I can embark on making an RSS feed for Slashdot and Drudgereport... Pretty slick...

Just in case anyone is considering moving to Seattle.

Greater Seattle excels in livability with a mild climate, affordable housing, a full range of arts, cultural and sporting events, an abundance of shops and restaurants, and easy access to outdoor recreational activities throughout the year.

Seattle's mild winters and cool summers enable year-round outdoor activities. High temperatures in July average about 75 F (24 C), while low temperatures in winter drop below freezing an average of only 15 days per year.

If you temporarily tire of the vaulted ceilings, hardwood floors, and scenic vistas of your own affordable luxury home, you can head outside. Unfortunately, there are only about 2000+ geocaches around Seattle, so once you find all of them using the more than sixty-five major mountain biking trails and hundreds of miles of offroad driving access ensured by the Pacific Northwest 4wd Association, you can do things like racing north during the annual Alcan Rally, departing from Seattle.

Once you've done all the driving you can bear, Seattle is a major international hub of Northwest Airlines, with directs flights to Asia, Pittsburgh, and San Francisco.

And, of course, Seattle is composed of 50.2% women!

Just in case you missed that.... THERE ARE MORE WOMEN THAN MEN IN SEATTLE

IE Rendering Woes

Can someone help me out here? This blog looks fine from my PC, but on my laptop, all the commas are replaced with rubbish. It looks like I'm using a 300 baud acoustic coupler to surf his site. No other sites suffer this problem and both my PC and the laptop are using identical versions of IE.

AdSense

After the stunning response I received as an "Amazon Associate," exactly zero dollars, I decided to try a different tack in the "get free money" game -- Google Adsense. For a bit of a trial, I've added (more like tacked on) some Google ads to the individual archive entries for this blog. When I have more time, perhaps I'll do something more tasteful or effective.

Tim Bray at Ongoing has enjoyed the system so far, and at the very least, it will be interesting to see how all this works, although Google seems to be quite draconian in enforcing a "don't talk about your statistics and revenues" policy.

Old becomes new again: GIS technology 150 years later

Wired is running an interesting article on how city governments are using "mapping technology to infuse efficiency and clarity into what would otherwise be simple civic drudgery. The system, known as the Citywide Geographic Information Systems (GIS) Utility, combines aerial photography, census figures, crime statistics and other information submitted by city agencies and local utilities.

It's funny though, the problems, ideas and solutions are not new.

Yes, that's right, this is nothing new.

Specialized mapping software helped New York plot the addresses of people who had called to complain about having lost their heat during a recent cold snap. That helped determine precisely where the city should set up "heating centers" for New Yorkers to huddle in.

In 1854 brilliant surgeon John Snow drew maps of cholera outbreaks in London to help visualize that certain public wells were infected with Cholera. Shutting off those wells stopped the epidemic.

Sadly, many things don't change, including labor cartels (also known as unions) who continue to resist efficiency and progress.

In a test on Staten Island, New York City officials used the system's knowledge of building sizes at each address to estimate the amount of garbage that certain streets ought to produce. The data helped plot the most efficient routes for trash pickup.

But officials in the technology department said they feared that expanding the mapping function to garbage pickup elsewhere in the city could rankle the sanitation workers' union.

Harry Nespoli, president of the union, said he was unaware of the GIS test, but expressed doubt that trash service could be improved by software.

"We are not computers, you know. We are human beings," he said. "Does a computer get lunch time? Does a computer sprain his ankle? Does a computer die like one of my members did the other day? We have very, very efficient managers on this job. They came up through the ranks. They know the best way to pick up the garbage."

I'm not sure what Nespoli is getting at here.... Things that don't eat, sprain their ankles, or die sound like good things. Especially when they don't go on strike and demand to work less for more pay. But then, if you are a labor cartel, you don't have to make sense.

I'm sorry, but I do find this funny...

Britain's 'biggest selling sunday newspaper' published an article 'Cannibal's House of Horror' this weekend. Drudgereport linked to it, saying "**WARNING GRAPHIC** CANNIBAL'S HOUSE OF HORROR... "

So I looked at it anyway. The collection of email quotes they got from this guy are hilarious.

---

Then came a terrifyingly matter-of-fact exchange about the fate of any human leftovers.

VICTIM: "What will you do with my brain?"

CANNIBAL: "I'll leave it, I don't want to split your skull."

VICTIM: "Better bury it, preferably in a cemetery; nobody notices skulls there. Or maybe pulverise it?"

CANNIBAL: "We have a nice small cemetery here."

VICTIM: "You could use it as an ashtray."

---

One of the first oddballs to respond [to the Cannibal's solicitations] was an Italian called Matteo.

But his tastes were a bit strong even for Meiwes. Without a hint of irony, he told the judges in court: "Matteo wanted me to burn his testicles with a flame thrower.

"And he wanted me to hammer his body down with nails and pins while he was whipped to death. I found that a bit weird."

---

The killer also spoke of another e-mail pal, Andreas, from Regensburg in southern Germany. "He wanted me to pick him up in a cattle truck and slaughter him like a pig," said Meiwes.

"I told him to take the train. I picked him up at the station and we went back to the butchery at my house. He wanted me to wear rubber boots, which he licked. I wrapped him in clingfilm ready for slaughtering but he backed out. So we just fooled around, drank beer and ate pizza."

---

Meiwes said: "He wanted me to pronounce a death sentence upon him like in a court so I got one made up from a document on the internet. He came to the house but he backed out, too. We ended up going to the pictures to watch Ocean's Eleven."