The Jackboot of Corporate Democracy

Via John Cole... After the oil rig explosion in the Gulf, Transocean appears to have engaged in a deliberate scheme of isolation, sleep deprivation, and intimidation in order to extort signatures out of the workers. After being pulled out of the sea after the explosion, the workers were held on the ships offshore for 36-40 hours, denied access to phones or radios in order to call loved ones, drug tested, deprived of sleep, and then told to sign on the dotted line "or else". From the Guardian UK:

By Davis's estimate, it took 12-15 minutes to get from the rig to the work boat, but it would take another 36-40 hours before they were to return to shore – even though there were dozens of boats in the area and Coast Guard helicopters airlifting the most severely injured to hospital.

Some of the men were openly furious, while others, like Davis, were just numb. He says they were denied access to the onboard satellite phone or radio to call their families.

When the ship finally did move, it did not head for shore directly, stopping at two more rigs to collect and drop off engineers and coast guard crew before arriving at Port Fourchon, Louisiana.

The company was ready for the men then, with portable toilets lined up at the dock for drug tests. The men were loaded on to buses, given a change of clothing and boxes of sandwiches, and taken to a hotel in Kenner, Louisiana, where finally they were reunited with their families.

Lawyers say the isolation was deliberate and that Transocean was trying to wear the men down so they would sign statements denying that they had been hurt or that they had witnessed the explosion that destroyed the rig.

"These men are told they have to sign these statements or they can't go home," said Buzbee. "I think it's pretty callous, but I'm not surprised by it."

Davis had been awake nonstop for about 50 hours by that point. He signed. Buzbee says most of the men did.

This statement seems to corroborate a story told previously by Christopher Choy, another Deepwater Horizon rig worker:

Choy, a young roustabout on the rig, was handed a form to fill out, asking what he'd seen. "They came on there, and they gathered everybody in the galley on the boat and handed out ... papers and stuff saying, '[These are] statements. You need to sign these. Nobody's getting off here until we get one from everybody.' "

But when Choy read the Coast Guard form, he didn't like what he saw. "At the bottom, it said something about, like, you know, this can be used as evidence in court and all that. I told them, I'm not signing it," Choy says. "Most of the people signed it and filled them out. I just didn't feel comfortable doing it." Choy shared his story at length with NPR and the PBS program NewsHour, in one of the most extensive interviews from a survivor of the April 20 rig blast.

The Coast Guard acknowledges it kept the men on the water in part so its investigators could get statements. But Choy says he thought the man who gave him the form said he was a lawyer with BP, the oil company. BP says it had no investigators or lawyers there.

It would be reasonable that the Coast Guard might want to interview the workers and get statements about the explosion and what was going on. Heck, someone from the government needs to be investigating at even this early point! But this doesn't quite sound like an investigation. This sounds like a corporate ass-covering maneuver with the Coast Guard looking on and providing a convenient excuse for the suits to hold the workers there and browbeat them into silence and indemnity. Then they were all drug tested, with those obvious implications (if you piss dirty, then obviously this was all your fault), and denied the ability to contact their families? Then, before they were allowed to go home, they had to go in front of Transocean lawyers yet again and have signatures demanded of them? Again from NPR:

But before they could go home, there was one more form and one more attempt to get the survivors to give information. At the hotel, there were representatives for Transocean who asked Choy to initial a line that said: I was not injured as a result of the incident or evacuation.

Choy had seen men with open wounds and burning flesh. He knew 11 of his friends were dead. He felt he was among the lucky ones.

Exhausted and just wanting to get home with Monica, he signed.

This is not only obscene, but it is criminal! Anyone involved, the actual lawyers or any other employees at Transocean (or BP or any other involved corporation) should be investigated and charged with Unlawful Restraint at the very least (and perhaps Kidnapping or Criminal Abduction). If the executives of the company knew about it, and surely they did if this level of thing was happening, then they should be charged as well.

Even if it is only Criminal Restraint, the penalties of which are often fairly light (fines and no more than 6 months in jail), it would send a message that this sort of corporate ass-cover is not acceptable.

Heck, with all of the hints of criminality surrounding this tragedy, they should indict the entire corporations (Transocean and BP, from what it seems so far) as criminal enterprises and prosecute them under RICO (which has predicate acts of extortion and blackmail).

Thoughts on Google's Open-Source and Royalty-Free WebM Project

Yesterday at their I/O conference, Google announced that they were open-sourcing the well-regarded VP8 video compression codec as part of a project to create a full-featured MPEG-4 competitor dubbed WebM. From the newly-minted WebM blog:

WebM includes:

  • VP8, a high-quality video codec we are releasing today under a BSD-style, royalty-free license
  • Vorbis, an already open source and broadly implemented audio codec
  • a container format based on a subset of the Matroska media container

The new WebM format enters a divided video compression codec scene. From a content-producer's perspective, one problem with supporting HTML5 Video on the web has been the lack of consistent video format support in the browser market. WebM aims to change that.

Currently, there are a variety of options for video support on your website, including: Flash, SilverLight, QuickTime, HTML5, and even still Real Media. Right now, the most popular choice is, of course, Adobe Flash. This high adoption rate is driven by the ubiquity of Adobe's Flash Plugin (Adobe quotes a 99.1% penetration in "Mature Markets" for Flash Player version 9 or better) and also by end-user acceptance. Most end-users know how to use a Flash video player intuitively, and they don't need to worry about how the video was compressed, or how to make sure the video opens in the right "player" application. It is the format used on YouTube, Hulu, Flickr, Facebook, MySpace, and a vast number of other popular sites.

As of Flash Player version 9.0.115.0, Adobe introduced full support for the MPEG-4 AVC (also known as H.264) compression codec and a new file format, F4V, based on the MPEG-4 Part 12 ISO specification (better known as MP4).

Briefly regarding terminology, the MPEG-4 Part 10 specification is also known by the names "AVC" (for Advanced Video Coding) or "H.264" depending on which specific standards body you are discussing. However, these terms both refer to the same standard, and can be used interchangeably.

The MPEG-4 AVC codec provides much higher quality, especially at low bitrates, than the older choices available for Flash playback (typically the On2 VP6 codec or Sorenson Spark). The MP4-wrapped AVC files are also compatible with most of the more "traditional" computer video player applications like Apple's QuickTime, VLC Player, ZoomPlayer, and Windows Media Player (with widely-available free decoder DirectShow filters). Many set-top DVD players began to support AVC MP4s (in addition to MPEG-4 ASP compressed AVIs), an AVC codec is used to compress the video content on many BluRay discs. And, of course, if you choose your settings carefully, they are compatible with Apple's dominant iPod (and later the iPhone). Choosing Flash to embed video content in your website, and using AVC to compress your videos, seemed like the simple choice.

However, with the recent explosion in the use of mobile devices for Internet access, counting on that monolithic level of Flash support among your users has become much more difficult for content producers. Unless you've been living under a very large rock, you know that Apple won't support Adobe Flash on their iPhone OS based products. However, the truth is that none of the currently-shipping smartphones and other mobile web-connected devices currently support Flash video at all. Adobe has promised a working solution for Android with Google's upcoming "FroYo" Android release, but even that won't offer full support. Adobe admits that Hulu's DRM-protected video won't be supported, and public demonstrations of the new mobile Flash running video haven't gone so well.

So, with all of this in mind, what is the big alternative? To many, it seems likely to be HTML5 and the new video embed tag. Instead of requiring a plugin like Flash, browser makers are just building the video support directly into the browser. HTML5 provides the delivery mechanism, but unfortunately does not resolve the issue of the the video format support.

The problem has been the with the compression and container formats. Supporting MPEG-4 AVC would seem like the simple choice. Much of the more recent Flash video content out there is already in AVC, so it wouldn't require a massive re-encoding project for the content producers. It is very high-quality, even at low bitrates, and it is an open standard approved by an international standards body. Unfortunately, all is not well in H.264-land, as it is also patent "encumbered". Many of the technologies upon which both AVC compression and the MP4 container format are based are patented by a variety of corporations. Apple, Dolby, Hitachi, Fraunhofer-Gesellschaft, Sony, Siemens, and even Columbia University are all licensors in the MPEG LA AVC/H.264 license pool. This same licensing authority maintains license pools for many other popular current, future, and legacy technologies including MPEG-2, ATSC, 1394 (FireWire), and LTE. While the MPEG-LA has committed to "continue not to charge royalties for Internet Video that is free to end users" through the end of their next licensing term on December 31, 2015, they can-and-do charge royalties to companies making hardware and software that works with or decodes AVC-encoded video. They also require licenses for companies that want to resell AVC-compressed video, via title or via a subscription (such as Amazon or Apple). And, they will make no guarantees that these terms won't change in 2016. In fact, they openly admit that one of the goals of their licensing model is "in order to encourage early-stage adopters".

Despite this encumbrance, Apple and Google decided to support the MPEG-4 AVC and MP4 standards, and the current version of both companies' browsers fully support the HTML5 video embed tag using those formats. While a bit late to the game, Microsoft announced that they too would be fully supporting HTML5 and AVC-compressed video in their upcoming IE9 browser. In fact, Google has converted most of YouTube to AVC and launched a HTML5-driven Beta version of their site back in January.

However, the patent licensing scheme was not an acceptable option for Mozilla and Opera. They were both philosophically opposed to the restrictions that this would place on their end-users (and, frankly, they also worried that they could be forced to pay unspecified royalties themselves now and down the road).

Instead, Opera and Mozilla both supported the Ogg Theora codec (with video wrapped in an OGG Video container). Google also released support for the Ogg Theora video in their Chrome browser, but Apple and Microsoft stuck with AVC and MP4 only. This led to a new problem for content producers! You're trying to move away from Flash in order to support mobile devices and your web browser users with one single simple technology, but the market is badly fractured! You have:

  • Apple on one side with their popular mobile platform supporting only MPEG-4 AVC/H.264
  • Microsoft with their sliding-but-still-impressive 60-ish percent market share not supporting anything currently, but promising to support the same as Apple with their next browser.
  • Google straddling the middle with their browser, but using AVC/H.264 on their all-important YouTube property
  • Adobe continuing to support AVC/H.264 with their still-dominant Flash Player
  • And then there is Mozilla (and Opera) on the other side with Ogg Theora. Firefox has the second largest browser usage share, and has generally continued to grow.

So, as a content provider on the web, you end up having to choose to support one or all of these individual different options and create and maintain multiple different encodes for each video asset on your site.

Making things worse is the fact that Ogg Theora is not quality competitive with MPEG-4 AVC at equivalent bitrates. Even xiph.org, the organization responsible for the OGG and Theora projects, does not claim that Theora (with the new Thusnelda technology) "beats x264 in perceived quality, as it certainly does not (yet ;-), only that the gap is closing". A final problem with supporting OGG Theora is that it is also not currently supported by most professional video encoding suites and hardware encoder devices (not to mention handheld decoder devices).

So, it is into this fractured world that Google is introducing their new WebM standard. It certainly has the promise to solve many of these problems in one fell swoop. The video compression in the standard is based on the well-regarded On2 VP8 codec. On2 made the popular VP6 codec supported by earlier versions of Adobe Flash Player, and Google purchased them back in August 2009.

Now, VP8 is not necessarily the complete panacea that Google would have you believe. Jason Garrett-Glaser, one of the primary x264 developers, wrote:

Overall, VP8 appears to be significantly weaker than H.264 compression-wise. The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264. Of course, this is still significantly better than Theora, and in my tests it beats Dirac quite handily as well.

Still, it is a vast improvement over Theora and other competing compression formats, and Google is now making it available with an open-source friendly license. The patent issue, unfortunately, isn't nearly so clear. Garrett-Glaser goes on to say (emphasis his):

VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Though I am not a lawyer, I simply cannot believe that they will be able to get away with this, especially in today’s overly litigious day and age. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents. Until we get some hard evidence that VP8 is safe, I would be extremely cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem.

But if luck is on Google’s side and VP8 does pass through the patent gauntlet unscathed, it will undoubtedly be a major upgrade as compared to Theora.

Still, many of the choices Google made with this new WebM project look, on the surface, to be very good ones. On2 is, at least, a viable competitor to MPEG-4 AVC. The OGG Vorbis audio compression codec they selected is a very well-regarded open-source competitor to AAC. And I, personally, think they couldn't have done better than to have chosen the fantastic open-source and patent-free Matroska (better known as MKV) for the container format. Google announced a huge list of companies and organizations that are signed up to support the new WebM standard including Mozilla, Adobe, Opera, Brightcove, Ooyala, Telestream, Qualcomm, ARM, and AMD.

And, the fact that Google controls both the most heavily trafficked internet video destination on the web today and a fast-growing mobile OS competitor to the iPhone OS both make the future for WebM look bright indeed.

Now, I personally just need the new Telestream Episode 6 to support WebM when it ships (and suspect it will since they're on Google's hit list), and to convince my web developers in helping me to deploy HTML5 support in AVC/H.264 and WebM with fallback to Flash. Exciting news indeed!

My Idea of a Drum is a Button on a Drum Machine

So said Mr. Reznor in a Keyboard magazine article way back when. I woke up on this miserable, rainy morning to a broken monitor on my main workstation downstairs. Thankfully, it should be still under warranty (unlike my Christie projector that broke last month 6 days after the warranty expired). But, you know, things happen. Heck... I could be constantly harassed by own government for the terrible crime of having exposed their rampant hypocrisy and anti-democratic behavior. Or, you know, I could be a Republican operative in PA-12 riding the incredible wave of anti-Obama sentiment to certain victory (or maybe not).

Sometimes the only way to solve it is with some unapologetic poppy-fun-music. These days it comes it comes it comes it comes it comes and goes...

Think less but see it grow.

Also, this.

EDIT: Ask and you shall receive! The Christie Projector came back in from the repair voyage today.

That's a Mighty-Fine TLS Cert You Have Thar

I'm fairly excited that I got the secure server working tonight, making my logins and admin stuff all shiny and secure. We'll figure the rest out later. One thing that was a bit tricky was knowing to add the wfRunHooks( 'BeforeInitialize', array( &$title, &$article, &$output, &$user, $request, $this ) );, but I got it sorted out. Of course, that change is going to get blown away if there are any further point releases that come out before 1.6 comes out of beta. So, I'll have to remember the deal, which was here: http://fs.fsinf.at/wiki/SecurePages.

It is working quite nicely though! I'm pleased!

Gulf Oil Spill the Size of the Entire Maine Coastline

So, I spent a few minutes in Google Earth and Photoshop during my lunch break today. It can be very difficult to imagine the true scale of the catastrophe happening down in the Gulf of Mexico, since generally the maps you see all are out over the open water with few geographic reference points that make sense to mere mortals. I thought it might be helpful to those of us up here in Maine to compare it to our local coastline. I was inspired by this cool tool built by Paul Rademacher, which unfortunately has not yet been updated with the most recent observational data available. So, I took the Gulf of Mexico Oil Spill observation map from Google Earth, which was just updated yesterday (05/17/2010) with new observational data, and layered the oil spill size overtop of the same-scale map of Maine's coastline. Despite following the growth of of the oil slick fairly closely, I really wasn't prepared for what I found.

First, we have the map of the Deepwater Horizon Oil Slick itself:

And here we have the map of the coast of Maine:

Obviously, I rotated the graphic of the oil slick itself to line it up with the Maine coastline, but I didn't scale or transform the image in any other way.

Making matters even worse is the fact that this only really shows an estimate of the size of the surface oil slick (and probably a conservative one at that). With typical "shallow" oil spills, such as those from an oil tanker, most of the oil stays on the surface of the water. The oil glugs out of the containment system on the ship, and pretty quickly settles up to the surface of the sea. Everyone knows that oil floats on top of water! Unfortunately, the spill happening (and continuing) at a depth of 5,000ft changes the rules quite a bit due to currents, pressure, thermal layers in the ocean, and the hundreds of thousands of gallons of dispersants we've dumped into the ocean. As discussed in an article this weekend in the Christian Science Monitor, the "real" spill is actually quite likely below the surface of the water, and growing at an even more catastrophic rate.

The oil that can be seen from the surface is apparently just a fraction of the oil that has spilled into the Gulf of Mexico since April 20, according to an assessment the National Institute for Undersea Science and Technology. Significant amounts of oil are spreading at various levels throughout the water column, says the report, which was posted online a week ago but first published by The New York Times Saturday.

The research, combined with other emerging data, could fundamentally alter researchers’ understanding of the oil spill. It suggests that vastly more oil than previously reported could be spilling from the wellhead and the attached riser pipe that now lies crumpled on the seafloor like a kinked and leaking garden hose.

Moreover, it suggests that serious environmental degradation could take place in the open ocean, creating massive “dead zones” where no creature can live because of the lack of oxygen in the water. The spread of oil at all levels of the Gulf also could become a concern for shore communities in hurricanes, which stir up the water column as they come ashore.

Well, great. That map looked bad enough, but now it appears that even this doesn't fully capture the scale of the disaster. This undersea oil plume was apparently discovered by the National Institute for Undersea Science and Technology (NIUST), which has been maintaining a blog about their work with regular updates (via Jim White at FDL). As reported by the USA Today:

In the first on-site measurements of the oil spreading below the surface, researchers found the plume of crude stretches 15 to 20 miles southwest from the site of the damaged wellhead and is about 5 miles wide, said Vernon Asper, a University of Southern Mississippi marine scientist leading the research.

The plume is compact, much thicker than the lighter remnants reaching the surface and suspended in about 3,000 feet of ocean, he said. A deepwater current is dragging it out to sea. The underwater oil cloud is not connected to the surface slick — now the size of Delaware and Rhode Island combined.

"This [underwater] plume is some of the heavier products of the oil that won't reach the surface," Asper said in a radio-telephone interview from aboard the R/V Pelican, a 116-foot research ship at the site of the spill. "We think this oil is going to stay down there. It doesn't look like it's coming to the surface."

It would seem that oil staying down under the surface might help matters a bit, but really we have no idea what the impacts of this might be. And then, at the surface, BP is dumping tons of surfactants on the oil that has reached the surface, in an effort to break it up and disperse it. As discussed over at FDL, these dispersants have already been shown to reduce the ability of water to absorb atmospheric oxygen. It is quite likely that this will have a tremendous and devastating effect on the oxygen levels underwater, perhaps creating a "dead zone" the likes of which the world has never seen. And, on top of it, we don't really know where this underwater column of oil will end up. The deepwater currents are pulling it out into the ocean, where it will likely get caught up in the complex ocean current system and dragged across the globe.

Driving home the point that we really aren't seeing the full size of the impact via these "size of such-and-such state" surface maps? The first tar balls washed ashore in Key West on Monday.

But don't worry. Transocean Ltd., the Swiss firm that owned and operated the oil rig, had a closed-door meeting on Friday where they announced they would be distributing approximately $1 billion in dividends to shareholders. More of the ongoing corporate strategy of privatizing gains and socializing losses!

Or, others would just call it what it really is: Looting.

Dear Glynor: MC Sound Settings Help

I recently got this email in from a friend over on the J. River Interact Forum:

Like I said, I probably have a dozen questions but I wont overwhelm you with the trivial ones right off. The problem that I feel will be hardest to troubleshoot via email is the replacement Sound card and correct DSP settings(I am just guessing the problem is there) and the reason why this one has priority is simply, I cant listen to my music using MC. This is a computer that is almost 6yrs old and although I generally try to build a new system at least every 4 years, this is a pretty strong box(hardware wise) and software upgrades have kept it acceptably up to date. I recently upgraded it to Win7 and my old XP Turtle Beach Santa Cruz sound card would not work with “7" and I since I am on the verge of building a Core i7(920) box, I just wanted to find something that “would work” until I got the new box built. I bought a Creative Card that is supposed to be compatible with Win7 and, as I said, it seems to work fine outside MC14(i.e. Windows Media Player).

I have tried many different settings in DSP without any success. In fact, so many that I cant even remember what unnecessary changes I might have made and that was one reason I suggested a phone call as an option because I thought it might save some back & forth time troubleshooting, but you may have a simple solution. I tried the Wiki to find solutions but, no help. I would get sidetracked a lot when searching and end up forgetting what I was even looking for...... it would be funny if it werent so frustrating.

I will give you the basics and you can tell me what other info you need or any changes that you think I need to try. Is there a way to send you a log of my settings? Seems like I remember there being a way to do that? My Speakers are Logitech Z-680/ 5.1 and my Sound card is a Creative SB0790 X-Fi Xtreme. Now, what MC is actually doing is ....... when I start playing back an audio file the sound skips almost like an album that is scratched and the song progress bar skips around also. Although I feel the problem is probably somewhere in my DSP settings, that is just my guess. I included captures of output format & volume leveling settings but let me know if you need anything else. Thanks a lot for your help

(Note: I edited this a bit from the source to protect the innocent.) He also included two nice screenshots of his current MC DSP Settings:

I thought it would be the most useful thing to answer here, because then other people might be able to benefit from the advice as well.

Okay.  The problem is probably in your DSP settings, but it is possible (of course) that it could be a driver problem.  Just because it only happens in MC, doesn't necessarily mean that MC isn't just exposing a weakness that isn't exposed by iTunes or Windows Media Player, but might show up with MC or some pro audio app that you don't own or aren't using. Correlation doesn't equal causation.

Still, in this case... I'd agree with you that the DSP is probably to blame.  My best suggestion is this:

Turn all of that crap off. This would be the first thing to try.  Just open up MC's DSP Studio and uncheck ALL of the boxes along the left-hand side.  MC does not need DSP studio to work, these are all optional corrections.  You don't need to turn them on, so turn them ALL off.

Then go into MC's  Tools -> Options -> Audio and reset everything there.  Put:

  • Output mode to Direct Sound
  • Click the Output Mode settings button and set:
    • Device to Primary Sound Driver
    • Channels to Default Channels (recommended).
    • Crank the buffering slider over towards the right-hand side (about where the text says "More Responsive")

Then, test playback and see if it is solved.  If so, then you can go back through and turn things on ONE AT A TIME and test after each and every single change.  If you have trouble remembering what you did (who doesn't with these complex systems) then just get a notepad and make a note each time you tweak a setting.  Just write down something like:

[sourcecode]05/17/2010 - Changed Tools > Options > Audio > Output mode.  Original: Direct Sound.  New: AISO.[/sourcecode]

That's what I do if I'm in there mucking about with settings I don't fully understand!

Without knowing a LOT more than is reasonable about your particular setup and system, I can't really make specific settings suggestions. However, I can give this general advice as well:

If you are dealing with an older computer, say of earlier Pentium 4 vintage or something similar, then you might be simply running into the limits of what your CPU can handle when processing that audio. All of those DSP Settings, like Tempo & Pitch, EQ, Headphones, and Volume Leveling, all suck down CPU cycles while you are playing the files back, and piling things on can be detrimental.

Now, you might say: I was using all of that same stuff on the same computer before you switched to Windows 7! Well, that was before you switched to Windows 7. The sound model on Windows 7 was completely re-written, and was written with modern hardware in mind. That doesn't mean it isn't as good (it is better than the older Windows XP kmixer in many ways), but it does mean it might require more resources to accomplish the same stuff. And the same goes with all of the other new features and twiddly-dinks enabled in Windows 7, all of which are taxing your system more than it would have been sitting idle under Windows XP or earlier systems. That's just called Progress!

So, put everything back to the default, and then go through and manually enable things one at a time, and you'll find where the problem lies.  If this doesn't work (if you set it back to the defaults, and it still skips and sputters), then you know something else is going on that may or may not be DSP/Audio setting related!  It could be a disk access problem, broken or faulty Creative Drivers, or maybe even some other odd setting in MC that is causing issues as well.

That's the best advice I have.  I hope this helps!

Global Cooling? Not So Much...

So... Have you heard the one about "global cooling"? This comes up from time to time, and is almost always parroted by skeptics as definitive proof that global climate change is The Big Lie. People often "prove" this claim by pointing to impressive looking graphs that show a dramatic cooling trend starting after 1998. These claims have been repeatedly debunked, of course. The basic trick in their statistics and graphs has been that 1998 was an anomaly. It was an unbelievably hot year, because of the strongest El Nino effect of the century, and so if you start your graph with 1998 on the left-hand side, it looks like the world has been cooling since then. Well, debunking these claims just got a bit easier. Joe Romm has the latest from the NASA Mean Surface Temperature dataset:

It was the hottest April on record in the NASA dataset. More significantly, following fast on the heels of the hottest March and hottest Jan-Feb-March on record, it’s also the hottest Jan-Feb-March-April on record.

The record temperatures we’re seeing now are especially impressive because we’ve been in “the deepest solar minimum in nearly a century.” It now appears to be over. It’s just hard to stop the march of manmade global warming, well, other than by reducing greenhouse gas emissions, that is.

Most significantly, NASA’s March prediction has come true: “It is nearly certain that a new record 12-month global temperature will be set in 2010.″

So, to get it straight, we set a few records here:

  1. April 2010 was the warmest April in recorded history (incidentally, March 2010 was the hottest March in recorded history as well).
  2. The 4 month period from January - April 2010 was the hottest similar period in recorded history.
  3. The 12-month period from May 2009 - April 2010 was the hottest 12-month period in recorded history (the record we just beat was originally set in 2007).

Oh, and those graphs the deniers always use to "prove" that the Earth has been cooling, and not warming? Krugman took that raw data and made a little graph of his own:

So, good job on the whole cranking the heat thing all around. I'd like to say that we'd love you for it up here in Maine, but I suspect that when those temperature and water levels rise, all those millions of displaced people will probably be heading up this way.

The Trouble With Ambox (and Mbox)

So today I had a little struggle getting the Template:Ambox (and my other custom Templates going on my new Wiki page). I had this same struggle once before, and there's really nothing more frustrating than that. When you know you've been down the road once before, but you really can't remember quite how you got there. So, I thought I'd document it briefly. Now, I'm absolutely no MediaWiki wizard here! I'm just figuring it out as I go, but I have figured out a few things along the way. If I'm wrong in some way, go ahead and throw something in the comments for me.

Read More