I would love to see the original, full resolution video. Could you upload it somewhere, or perhaps put it up on BitTorrent?

Also, what data sets did you use in the preparation of this movie? I would be interested to see the orbit specifications for all of these asteroids.

Based on the description in the OP, this sounds like just a high temperature solid oxide fuel cell. There's nothing particularly revolutionary about that. It still emits carbon dioxide, and it still requires fuel. Presumably you would feed it with some kind of "carbon neutral" biofuel.

So my question is: why the hype? How is the "Bloom Box" any better than installing a traditional generator powered with biogas? From a practical perspective they seem to do roughly the same thing: take in fuel and spit out electricity and carbon dioxide.

True, the built-in Linux documentation is often lacking. But in spite of that, it's much, much better than the built-in help files for Windows or Mac.

No matter which OS I use, Google is always my first stop for technical help. The difference between them is that with Linux, I usually find a helpful site almost immediately (usually on the Ubuntu Forums). With Windows, the best help I can find is usually some obscure, confusing entry at the Microsoft Support website. Ick.

This isn't new: these terms are exactly the same as Verizon's current plans for Blackberry service. $30/month for the smartphone "data plan", plus an extra $30/month for tethering. And yes, they've always called it "unlimited", but it's always been capped at 5GB. I've been paying these rates for some time. It's annoying, but it's been going on for ages.

It's amusing to me that people are only getting outraged about this now because Verizon is selling a popular new phone that everyone wants to buy.

The problem is not crossing a border with a book you already own. The problem, for Amazon, is having the rights to sell a book in a different country. Plus higher wireless costs. Plus VAT. All in all, I'm surprised the price is bump is as small as 40%.

The OP summary is quite a troll. PC Pro hasn't "discovered" anything: all of this information was easy to find on the International Kindle website the day it was announced.

This may not be the source of your trouble, but in my experience 80% of conversion layout problems are due to fonts. If you run Linux or Mac, chances are that you're using fonts that are similar to, but different from, Windows fonts. The result? When the document is opened on a different OS, the necessary font substitutions cause spacing shifts and flow problems.

The solution I've found is to use only Times New Roman and Arial in a document where layout is important, because I know I can depend on every Windows user having those two fonts. Non-Windows users can get them as well -- for example, in Ubuntu you can install the msttcorefonts package to get the basic Windows fonts. Sure, if you can use PDF, go for it. But when you have to send a doc file, TNR/Arial is the way to go.

Sure, if you're really paranoid, get an NDA and expect to annoy and alienate plenty of clever people.

I used to feel the same way you do, but I quickly learned one key rule. If someone is technically proficient enough to give you the advice you want, they already have a hundred great ideas of their own that they are more interested in. They may agree that your idea is good, but clever people are nearly always more interested in their own projects.

And if a clever person is SO impressed by your idea that they're willing to put their own projects on hold, they will almost certainly want to work WITH you on it, not steal it from you. Which is pretty much what you're looking for, right? So don't worry about it.

These are not equivalent. "Native" support means that you could put a .pdf file directly on the Kindle (via USB), and the Kindle would be able to open it. What the Kindle actually does is, you can email a .pdf document to something@kindle.com, and Amazon's software will attempt to reflow and convert the .pdf document into .azw format. The Kindle does NOT support .pdf natively.

This is incorrect in several ways. First, the non-DRMed .azw format is almost exactly the same as the non-DRMed .mobi format. It simply has a different extension. The encryption used for DRM may be different, but the Kindle is certainly capable of opening DRMed .mobi files natively. You can bet that Amazon is paying a licensing fee to Mobipocket.

Now, here's how mobipocket DRM works. Your device (Kindle, Bookeen, etc.) has a unique ID number. When you buy an ebook from a site (ie. Fictionwise), you input this ID which is then incorporated into the encryption of the file. Thus, that device will be able to open that file. Any file can be viewed by up to 6 different devices. For most devices, the ID is known to the user. With the Kindle and Amazon, all of the above is handled automatically, so the user does not NEED to know the ID when buying from Amazon.

The script in question, kindlepid.py, simply reads the ID number of the Kindle in question and prints it out for the user. It's worth noting that the official Mobipocket Desktop software version 6.0 could also do this, at least for the Kindle v1.

Now, using the ID, it is possible to buy encrypted .mobi ebooks from other vendors (ie. Fictionwise) with the Kindle added as an "approved" device. The Kindle can read these files, but won't unless a "read-approval" bit is flipped in the file. This can be done by a second script, kindlefix.py.

What's curious and kind of ridiculous about this situation is that if either of these scripts is circumventing DRM, it would be the second script, kindlefix. However, the DMCA takedown notice apparently targeted the FIRST script, kindlepid, which only prints information that you could already get using official Mobipocket software. That's why Amazon's whole approach in this case seems ridiculous at best.

In any case, I think that from Mobileread's point of view this was probably the best response.

Gwyddion is a very nice open-source tool for processing, analysis, and export of AFM/SPM data sets. I find that it has many more useful and advanced features than the crappy program that came with our lab's AFM. It can also open (but not save) almost every data format used by most AFM/SPM manufacturers. (You save in the native Gwyddion format, or export to png, jpeg, tiff, etc.)

A few quibbles: the UI is not very consistent, with some buttons having no menu counterparts and vice-versa. Also, it does not support batch processing, which is my most wished-for feature. Still, it is easily the best AFM/SPM analysis program I have ever used.