It’s at times like this I’m happy to pay taxes.

Now, to get back to the subject at hand, in the same article, the author touched on the CO2 emissions of air travel. I couldn’t quite believe what I read so I researched it some more. The CO2 emissions of one passenger on a passenger jet is roughly equivalent to the emissions should the passenger instead travel by car (roughly). However, due to the effect known as “radiative forcing”, the actual impact of emissions from a plane is higher due to the altitude at which it flies. I won’t go into detail about this because frankly, I don’t understand it. However, the Intergovernmental Panel on Climate Change, who recently was awarded the Nobel Prize, uses a multiplier of 2.7. In other words, if traveling by plane gives you a gas mileage of 20 MPG, the effective MPG is 2.7 times less than that.

Calculating the CO2 emissions of air travel is a pain, but thankfully, there’s an online calculator at Atmosfair.de.

A common tourist destination for Swedes is Phuket in Thailand (for some odd reason). It’s roughly 9000 kilometers away if traveling from the south of Sweden. I fed in the departure and arrival airports (Copenhagen-Bangkok-Phuket) and here’s the result.

6.7 tonnes of CO2! As the graph illustrates, one return-flight to Thailand for a Swede is the equivalent of driving your average car 12,000 km per year for 3 years. This completely blew me away. Instead of placing too much weight on the CO2 emissions on your next car, maybe you should consider vacationing a little closer to home next time.

Followers of this cult are extremely sceptical about any information that originates from the US government, the mass media or the corporate world. However, they have no problem whatsoever believing everything that comes out of the mouth of people like Alex Jones, David Ray Griffin and Dylan Avery. A little neutrality please.

As usual when it comes to conspiracy theories, my question is this. What is the likelihood that every single person involved in such a massive operation would keep their mouth shut about it for all these years? In a National Geographic documentary on the subject (I believe it was called Science and Conspiracy), they did a non-scientific but still illustrative count of the number of people that would need to be involved in the supposed 9/11 conspiracy. I believed they stopped counting at around 5000 people. I’m sure the actual number would have to be a lot larger though. This is just not the way conspiracies work. Conspiracies are conducted by a few people behind closed doors under secrecy, not involving thousands and maybe tens of thousands of people. If you open your mind and think about this for a few minutes, you quickly realize that it’s just not possible.

I end this short blurb with a quote from Benjamin Franklin:

- Three may keep a secret, if two of them are dead.

1. Click a link to a Word document in their Gmail (or somewhere else on the web).
2. When asked if they want to open of save the document, they select open.
3. They work on the document for a couple of hours and then hit save.
4. They log out.

The issue with this is that when you pick the open option in the open/save dialogue, the document gets downloaded into your “Temporary Internet Files” and then opened from there. It works, but Temporary Internet Files is a highly volatile place to store documents, in particular when Internet Explorer is set up to clear the folder when you log out (to keep roaming profile size to a minimum). In other words, the changes the student worked on are gone.

I don’t know how to solve this. I’m looking for a solution that does either of the following:

1. Defaults to save and disables the open option for particular file types in Internet Explorer.
2. Forces users to “save as” when the document has been “opened” through a browser.

Anyone?

Some time ago, we noticed that virtually all of the many hundreds of machines on campus, regardless of hardware configuration, were intermittently crashing. We were never able to reproduce the problem, but it was happening at a rate of maybe one or two machines a day. We started out by trying all the standard fixes such as updating drivers and BIOS as well as completely reinstalling some of the machines. Nothing seemed to help. The machines blue-screened and reported various different error codes (7e, 50, 0a etc). We were stumped.

At this point, I was getting pretty frustrated at not being able to solve the problem. In a desperate attempt at finding out what was causing this, I installed WinDbg (part of the Windows Debugging Tools) and loaded up a couple of minidumps from a handful of machines. Using the analyze command, you can get WinDbg to parse the memory dump and output what it thinks might be the culprit behind the crash. I was hoping that the different memory dumps would point to some kind of common driver or executable, but some of them blamed fastfat.sys, others pointed a finger at ntkrpamp.exe and some put the blame on “memory_corruption”. I was getting nowhere and I needed help.

I searched around for a good discussion forum to ask for help and ended up in the troubleshooting section of the Sysinternals forums. More or less immediately, I got a response from someone called Scott. He directed me to enable full memory dumps on a couple of machines as well as enabling Driver Verified on any non-Microsoft drivers. At this time, I had never even heard of the tool called Driver Verified, but apparently, it’s been included in Windows since Windows 2000. Here’s what Wikipedia has to say about it:

Driver Verifier is a tool included in Microsoft Windows that replaces the default operating system subroutines with ones that are specifically developed to catch device driver bugs. [1] Once enabled, it monitors and stresses drivers to detect illegal function calls or actions that may be causing system corruption. It acts within the kernel mode and can target specific device drivers for continual checking or make driver verifier functionality multithreaded, so that several device drivers can be monitored at the same time. [1] It can simulate certain conditions such as low memory, I/O verification, pool tracking, IRQL checking, deadlock detection, DMA checks, IRP logging etc.

So I enabled it and after a couple of days I had a number of full memory dumps created while Driver Verified was running. I loaded them up in WinDbg, but I was none the wiser. I needed more help so I took the liberty of sending Scott a private message asking him if he would be willing to take a quick look at the dumps for me. Scott replied that he actually enjoyed groveling trough memory dumps and that he in fact taught a week long crash dump analysis lab! Talk about finding the right man for the job. So I sent the dumps to Scott who got back to me shortly thereafter with a theory.

At the time of the crash, it appeared that a ZIP file was being flushed out to a removable FAT drive, but the in-memory structures for the file had been torn down already, causing the crash. Scott was able to track the memory address of the prematurely torn down structure to an “SRTSP structure”. SRTSP.sys is a Symantec Antivirus filter driver. It seemed to make sense. Symantec does indeed check files before they are saved to removable drives. Scott also informed me that the driver in question was about a year old and that we could try upgrading it to the latest version. We did and after about two weeks, we have yet to experience one single crash.

The moral of the story I guess is that I should have known better than to use an almost 1 year old version of the Symantec Endpoint Protection client, but the cool thing about the story is Scott. I was stuck and asked for help in an online discussion forum. To my rescue came a complete stranger that not only put time and effort into helping me, but also turned out to be extremely competent at what he did. Amazing!

Thank you very much Scott!

So, without further ado, I present to you Affirmative!

When I started the project, I figured CRC32 calculations were a perfect fit for Grand Central Dispatch. I toyed with the idea of using GCD, but it turns out that doing CRC32 calculations is I/O bound, not CPU bound. That is, the bottleneck is the hard drive, not the CPU. Spawning multiple threads to calculate the CRC32 checksum using GCD actually worsened performance as all the threads were waiting on the hard drive instead of crunching numbers. With this information in hand, I decided to stay away from GCD for this project and do a relatively common two-thread application instead.

Stay tuned for more apps. I actually have a pretty good idea of what I’m gonna do next.

I will of course have to keep one or two regular drives for storage, but OSX and all my apps are going on the SSD.

This is just one of many great documentaries available for viewing at pbs.org.

Now all that remains is a great idea for an application. I’m all ears!