I think a lot of the hostility comes from seeing GNOME developers take an actively hostile attitude to non-GNOME projects using components like GTK+ that we used to think of as vital infrastructure everybody used.

This is beside the point, unless Valves wants to indemnify users of the code they released (hint: they won't).

Do real-time video processing server-side? Seriously?

It's not like Satoshi is controlling the system from the shadows or something - Bitcoin is open-source. You don't need to trust its creators.

The Mozilla Suite (codenamed "SeaMonkey") was discontinued. A new project, outside of (but not on bad terms with) the Mozilla Foundation, was started to continue development under the name "SeaMonkey" (now as a brand, not just as a codename). As far as I know, they use recent upstream versions of Gecko and thus automatically support HTML5 and so on.

This is only confusing to people who followed Mozilla development closely enough to have seen "SeaMonkey" used to refer to the Suite. I'd guess that it was somewhat inspired by the origins of the Mozilla project - "Mozilla" was the old codename for Netscape Navigator.

I don't think you know how one gets mod points.

It seems to work for them, though. How many countries have had nearly 200 years of peace?

The nice thing about Wayland is that, because all the real work is being done by things like evdev, KMS and widget toolkit the actual display server is *much* simpler than Xorg. Weston is only a reference implementation of a Wayland compositor, and it's expected that desktop environments will implement their own that work the way they want them to (for example, work is underway to let KWin function as a Wayland compositor).

So it's not even a question of having to do some hackish modification of upstream to get their own way - they could have just implemented Wayland in Unity's WM, like other major DEs have done. The concerns about running on Android drivers are weird - the Wayland protocol doesn't care how you actually do your compositing and display the finished screen (there is already a modified version of Weston for the Raspberry Pi, which uses the device's video scaling hardware to do the actual composition work), so a seperate client protocol (as opposed to rendering backend) makes no sense.

So, if, in fact, the Iranians aren’t going to compromise, it would be best if somebody else started the war [...] We are in the game of using covert means against the Iranians. We could get nastier at that.

(Apologies if the linked video is edited and does not include the quote - I'm on mobile right now and haven't watched that copy. Search for Patrick Clawson to find the rest.)

We're "truthers" if we don't think Saddam attacked the towers? Nobody outside of the United States believed that.

But they aren't using the other compiler properly - their results effectively rely on the lie that they can do SIMD and ARM can not. And even without the actual dishonesty, it's a synthetic benchmark selected specially to show off their compiler/processor's strong points.

Flash drives seem to be characterized by very high failure rates. Changing the drive? Unclear this is a user operation. All real drives -- the ones you use for your data -- would have to be external bricks.

Hard drives are also prone to high failure rates. If your "real data" lives only on a single magnetic disk (in a portable device, FFS) you're already asking to lose it.

What about retroreflectors? Presumably, it would require only a miniscule fraction of a missile-killing laser beam to screw up the tracking optics.

And the gunsmiths of the Khyber Pass have been making real, metal firearms on a completely amateur basis since before CNC mills existed. Not single-shot proofs-of-concept either, working copies of Lee Enfields and the like. No high-tech of any sort required.

Ammo was already relatively easy to make.