Investors want a return on their money. Built into growth expectations are things like capital depreciation and inflation. A dollar loses about 2% of its buying power every year so $1,000 sitting in a mayonnaise jar under your bed is only worth $980 next year and $960 the next year. If you give that mayonnaise jar to a business (investing) with no profit planned they would hand you back $1,000 in five years that only had about $900 worth of buying power. To simply pay you back what you invested them the business needs to grow at least 2% per year. In order to give more money back to investors as a reward for them investing the business needs to grow somewhere north of 2% every year. Even an entirely private company needs to grow somewhere above the inflation rate just to be able to give their employees cost of living pay increases, ignoring entirely giving them actual raises to keep them from leaving the company. If someone's paycheck stays stagnant for five years they have about 10% less buying power than when they started working.

No the difference is accountability. The people performing sit-ins were willing to be held accountable for their actions. They could have opted not to give their names if confronted but they put a face and a body to their protest. They actually had a confrontation with their opposition. Participating in a DDoS is not putting a body or face to the protest nor is it actually confronting the opposition. It's little better than throwing rocks through store front windows and running away. Julian Assange putting himself on the line for Wikileaks actions or someone hosting a Wikileaks mirror is protesting. DDoSing websites is throwing rocks and breaking windows.

The people performing sit-ins were not attempting to be anonymous and running away as soon as they were challenged. They were willing to act in public and be arrested for what they believed in. Participating in a DDoS is not remotely similar no matter what delusions of grandeur they might have. It's troubling that these people are equating DDoSing a website with activism or protest.

The TOW is fired from a helicopter or possible a IFV. While the structure the missile hits is obviously going to suffer damage as long as the helicopter of IFV isn't right next to another building when it fires the damage is going to be largely limited to the target. The AT-4 has to be fired by somebody in the middle of the urban environment, the back blast of the AT-4 is significant.

The standard AT-4 model has a roughly 300ft 90 backblast cone. Anyone inside this cone could be seriously hurt by debris from the baseplate debris and the force of the blast itself. Firing an AT-4 from a confined space (inside a building) can do significant damage to that building and people inside it. Here's a video of an AT-4 being fired. Watch the shock wave around the guy as the weapon fires and then imagine that inside a building. You'd do almost as much damage to yourself as to the poor bastard you shot the thing at. Here's another video not only explaining the problem but describing the CS (confined space) variant of the AT-4 meant to solve this problem.

I think Google is interested in the meta tag approach because it's a dead simple thing to add to a CMS. RDF and it's microdata cousins are much harder to shoehorn into existing CMSes and require a lot more effort on the part of the copy writer to add to an entry.

BEVs are commuter cars, you don't drive cross-country in them but to work and back every day. Most people don't drive more than 75 miles a day even including side trips for errands. For most people having a car that can drive 200 miles on a tank of gas is overkill for their actual driving needs. For everything a BEV commuter can't handle there's rental cars or a second family vehicle. The car transportation system would be on the whole more efficient if we bought cars closer to our actual needs and shared (rentals etc) cars whose utility was used only rarely.

There's a lot more to it than that. Shooting in 3D limits the number of in-camera effects that are available and requires the director to make hard choices about focus and focal points. Once principal production is complete (with those limitations) all of the post-production needs to take the 3D projection into account. Having to project in 3D is going to affect every edit, effect, and color grading. It's a lot of extra work to shoot in 3D and then actually project in 2D.

With current telescopes what's the distance limit that we can use astrometry with any hope of accuracy (how many parsecs out can this technique be used)? In a similar vein are you using a single viewing session with one (or a single set) of telescopes or are you making multiple observations at different points in the year to create a virtual optical array? Does this increase the astrometric measurements in a meaningful way?

Microsoft's J++ was not fully compatible with the Java spec at the time and introduced it's own class libraries in the standard Java namespaces IIRC. They claimed their JVM was compatible with Sun's Java even though it really wasn't. If you targeted J++ your app wouldn't run in any other Java environments. Apple's Java implementation is a full implementation of the J2SE spec and all the Cocoa bridging stuff was properly labeled as extenstions. If you write a J2SE app on Apple's JVM it will run on any other J2SE JVM.

The JPEG standard is not perfect. There's several more efficient and effective image codecs available now that were impractical in 1992. However it's relative simplicity and age mean it is trivial to handle on contemporary machines and is available everywhere. Just about any graphical web browser you can find supports JPEG images. While WebP might offer best case space savings over JPEGs of equivalent size the idea that it's somehow appropriate for mass consumption is absurd. The justification of JPEGs slowing down load times for web pages is ludicrous, JavaScript doing a half-assed job of loading resources and unoptimized server access causes far more problems than additional kilobyte in an image. It's yet another half-baked Google project released because there's not enough parental supervision going on.

WebP does not offer any compelling reason except a promise of space/bandwidth savings over JPEG. It doesn't currently support multiple color spaces, color correction, an alpha channel, or animation. It's promise of space savings at various quality levels is ridiculous because like they did with VP8/WebM Google is only focusing on PSNR measurements. PSNR makes for nice graphs but is not an effective measurement of how images actually look to people. An image that scores well in a PSNR test might look like shit when you actually compare it to the source image. Most JPEG encoders are tuned for psychovisual performance, not to score well in PSNR tests. Testing WebP vs JPEG with VQM tests would be far more appropriate but I suspect WebM would do far worse than with PSNR (since that's what VP8 is tuned for).

Without a VQM test it's really not appropriate to say that at a given size WebP has better visual quality than JPEG. Even if this turned out to be the case it's missing a lot of other important features that JPEG either has or a truly viable replacement for JPEG should have. WebP only supports a single color space and color profile so if your source images look like shit in that space or with that profile you're out of luck. JPEG can declare an image's color profile or provide its own ICC. It doesn't support lossless encoding or an alpha channel (right now) so it won't be appropriate to replace PNGs and GIFs which are often less optimized for the web than JPEG. It also doesn't support animation which for good or ill is still an important use of GIF files.

Yet another image format to not get widely accepted on the web doesn't do anyone any good. Why not help support JPEG-2000 or JPEG-XR? Help PNG out with a F/OSS compatible LZMA library. No camera manufacturers will support it because they can't just write a few Exif tags and attach an ICC profile and have a usable image. Converting your personal library means you get not only a lossy-to-lossy conversion but lose the ability to do lossless editing (rotation etc). Because WebP has more complicated encoding than JPEG it's going to require more CPU power to decode, your iPhone an Droid will get worse battery life browsing WebP content than JPEG content. The reduced file size (assuming WebP lives up to its promises) isn't going to make up for the vastly more complicated decoding. So hooray, Google managed to reuse their VP8 encoder for still images while simultaneously not solving any actual problems with images on the web.