1) Finger memory.
2) :w and :q exist as separate commands with numerous other combinations (:wa, :wqa, :wn) so :wq fits more naturally into that family.
3) If you want to use a shortcut for :wq, ZZ requires even fewer keystrokes (shift z z versus shift : x enter).

Between the three of those, :x never really seems preferable.

> Luckily modern computers don't have to handle these dates retrospectively, if some can't even figure out this year is a leap year.

At least some modern software does get those dates right, though:

~$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

You want the search term "co-working"; try https://en.wikipedia.org/wiki/Co-working for a start. You might also try wiki.coworking.info.

Keep encrypted backups elsewhere that you can restore to a new laptop. And yes, GPG doesn't help you with email headers; if you want to mask the source and destination, you need something better than email, and we don't have anything like that sufficiently widespread.

Why would *anyone* involved in something as sensitive as WikiLeaks trust a webmail provider of any kind, or any third-party email storage? Run your own mail server, download your mails immediately, and store all emails locally on an encrypted drive. That won't protect new emails in transit (that's what GPG is for), but it'll protect existing emails. I can understand people using webmail when they don't really care. But in this case, it seems ridiculous.

Of the competitors, only Chrome is open. And while it seems like a fine browser, and I keep it around to check web-page rendering in WebKit, I can't stand it for normal usage for a pile of reasons:

• The upstream packaging tries to install a new sources.list entry and cron-update itself. *Bad* software, don't mess with my package management, no biscuit. Fortunately Chromium doesn't do anything that crazy.
• Chrome desperately wants to pretend that all monitors have 96 DPI, so I have to lie to it and say I want much bigger fonts than I do, just to get something readable. This also means that sites can't use CSS lengths like "8.5in" and get something actually 8.5 inches wide on my screen.
• Chrome ignores all of my system font configuration that says how to render fonts, producing blurry fonts so bad they literally make my eyes water. (It does Mac-style blurry anti-aliasing, whereas the rest of my system does anti-aliasing that produces crisp lines.)
• Chrome downloads and shows ads on the "new tab" page by default.
• Chrome zooms images and text together, with no option to just make text bigger and leave images un-blurry.

A third party *has* mediated, and made it clear that if the two parties don't come up with a solution then the issue will go to trial, and nobody wants that.

Personally, I don't find it at all clear why Google owes a single penny for scanning books and making them searchable, *without* allowing non-public-domain books to be seen in their entirety. They might wish to make some kind of deal to allow more access to non-public-domain books, but that has nothing to do with fair use of existing books, and if snippets and search don't count as fair use then I don't know what does.

The headline makes this story sound more sensational than the reality. MIT doesn't get any control over the company, just a pile of dividend-bearing stock.

You can't have E without M. Magnetism just comes from relativistic effects on electricity. Take a look at http://en.wikipedia.org/wiki/Relativistic_electromagnetism for an example.

Firefox has supported Cache-Control: public since late 2007.

See https://bugzilla.mozilla.org/show_bug.cgi?id=345181 .

WebM is actually a container (a subset of MKV) as well as a spec for a video codec (VP8) and audio codec (Vorbis).

Still not the same thing; that just gives you the overall diff between RH kernel versions or between the RH kernel and upstream. Other Linux distributions provide full split-out patches and/or git trees of every individual patch they've applied to their kernel, to which many individual changes occur between package revisions.

It doesn't matter at all for CentOS. It matters for other Linux distributions that want to collaborate with Red Hat and with upstream. Digging a fix out of the Red Hat kernel becomes a lot harder with only a monolithic patch. And without fine-grained patches, any kind of conflict between the megapatch and other kernel patches becomes incredibly difficult to troubleshoot.

You can obviously find out the overall difference, but now Red Hat no longer provides either a git tree or split-out patches for each change, which makes it harder to figure out what individual changes they've made to the kernel.