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.
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.
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.
Back in the days when browsers were starting to embed images, were gif and jpeg royalty free? Or did we just live in a simpler time before patent trolls.
GIF required royalties to write, but not to read. Hence the existence of libungif: "a specially modified version of giflib which is free of the Unisys LZW patent. It can read all GIFs, but only write uncompressed GIFs."
The linked story talks about the reasons for the protest in Cairo (namely, wanting the current president of 29 years out, and wanting the 29-year "state of emergency" and corresponding suspension of rights to stop). The summary here just talks about the actions taken against the protesters, and the blocking of Twitter.
RapidShare hosts content themselves, and takes down content when requested to. Atari sued them because they didn't want to keep sending takedown notices, and would prefer that RapidShare do their job for them, like YouTube currently does for copyright holders ("here, tell us what files you don't like look like, and we'll handle it automatically"). The courts sensibly said that RapidShare doesn't have to offer any more help to Atari than they already do.
PirateBay doesn't host content themselves, infringing or otherwise, which means they very sensibly don't respond to takedown notices. That then confuses and annoys both copyright holders and courts, who can't quite figure out that PirateBay has done nothing wrong, because naturally they *must* be doing something wrong if they're not responding to takedown notices.
I'm aware of that; just taking the opportunity to point out that C++ files on UNIX systems can use extensions other than those you mentioned, and in particular that the one bit of C++ in the Linux kernel repository uses the.cc extension.
Actually, you are only just now taking that opportunity. I appreciate the correction and additional information. In fact, that is exactly why I said I wanted to challenge the assertion, rather than saying there definitely isn't any.
Fair enough; I should know better than to post command executions or code snippets as comments without further explanation of their significance. Thanks for calling me on it.:)
I'm aware of that; just taking the opportunity to point out that C++ files on UNIX systems can use extensions other than those you mentioned, and in particular that the one bit of C++ in the Linux kernel repository uses the.cc extension. You also didn't cover the.C extension, though that one doesn't see much use due to incompatibility with case-insensitive systems.
There's no such thing as an "entrance node" in Tor; the first hop is encrypted, and at most the first node you contact can say "the system talking to me uses Tor". While that may cause you some problems in environments that prohibit use of Tor entirely, Tor doesn't have that as a security goal; Tor just ensures that nobody can figure out both endpoints, and it does that quite well as long as no one entity can control a significant fraction of the nodes on the paths you use.
As for trust, you generally have to trust *someone* in a system, but you want to reduce the number of trusted entities to the minimum. For instance, when talking to example.org, you ideally only want to trust example.org to provide the content you expect; you shouldn't also have to trust "org" and the root to not take over the site.
That doesn't mean you want naming by consensus, either; that could have the "everyone on the Internet is lying to you" problem you described.
DNS (perhaps with DNSSEC) might even remain a reasonable protocol to use on individual domains, such as to allow "example.org" to provide "www.example.org" and "planet.example.org". However, having a central "org" registry with control over "example.org" puts control in the wrong place, and allows abuse.
Doesn't really help; browsers have bookmarks already. That doesn't solve the problem of helping users get to a site from some well-known name. And IP addresses aren't as stable as names.
There's no reason for DNS resolution to go through any centralised server. Use a distributed hash table to publish and retrieve records and sign them. Of course you'd still need a central authority to issue and sign certificates.
That decentralizes the boring bit of the problem. You still have to trust the central authority to not abuse their power, and that doesn't work.
Using public keys as addresses would be pretty sweet, but how do you route traffic through a network with randomly distributed addresses? Ad-hoc routing can work on small scales, but there'd be serious issues making a global network like that.
That's actually an easier problem, known as "location-independent identifiers". Most ad-hoc routing protocols tend to flood-fill the network, either when calculating routes or when routing packets. However, ad-hoc routing protocols do exist that avoid flooding, and those protocols can scale.
Virtual Ring Routing can handle Internet-scale networks by treating them like small-world networks, using the same mechanism distributed hash tables use: treat the addresses as a ring, and use a combination of your physical neighbors and your "virtual" neighbors on the ring to cross long distances. A later paper on VRR showed that it scaled quite well with the size of the network, both in the expected length of the routing path and the expected number of routing table entries needed on each node.
We got a team of students to develop an implementation of VRR for Linux, and Microsoft Research has an implementation for Windows.
So yes, we can solve the routing problem easily enough. We just need some way to handle naming that the general public will put up with.
1) Finger memory. :w and :q exist as separate commands with numerous other combinations (:wa, :wqa, :wn) so :wq fits more naturally into that family. :wq, ZZ requires even fewer keystrokes (shift z z versus shift : x enter).
2)
3) If you want to use a shortcut for
Between the three of those, :x never really seems preferable.
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.
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.
GIF required royalties to write, but not to read. Hence the existence of libungif: "a specially modified version of giflib which is free of the Unisys LZW patent. It can read all GIFs, but only write uncompressed GIFs."
Depends on the game in question.
The linked story talks about the reasons for the protest in Cairo (namely, wanting the current president of 29 years out, and wanting the 29-year "state of emergency" and corresponding suspension of rights to stop). The summary here just talks about the actions taken against the protesters, and the blocking of Twitter.
RapidShare hosts content themselves, and takes down content when requested to. Atari sued them because they didn't want to keep sending takedown notices, and would prefer that RapidShare do their job for them, like YouTube currently does for copyright holders ("here, tell us what files you don't like look like, and we'll handle it automatically"). The courts sensibly said that RapidShare doesn't have to offer any more help to Atari than they already do.
PirateBay doesn't host content themselves, infringing or otherwise, which means they very sensibly don't respond to takedown notices. That then confuses and annoys both copyright holders and courts, who can't quite figure out that PirateBay has done nothing wrong, because naturally they *must* be doing something wrong if they're not responding to takedown notices.
Fair enough; I should know better than to post command executions or code snippets as comments without further explanation of their significance. Thanks for calling me on it. :)
I'm aware of that; just taking the opportunity to point out that C++ files on UNIX systems can use extensions other than those you mentioned, and in particular that the one bit of C++ in the Linux kernel repository uses the .cc extension. You also didn't cover the .C extension, though that one doesn't see much use due to incompatibility with case-insensitive systems.
~/src/linux-2.6$ find -name '*.cc'
./scripts/kconfig/qconf.cc
You've attempted to apply rational logic to biases, but biases don't subscribe to logic; they represent bugs in rationality.
There's no such thing as an "entrance node" in Tor; the first hop is encrypted, and at most the first node you contact can say "the system talking to me uses Tor". While that may cause you some problems in environments that prohibit use of Tor entirely, Tor doesn't have that as a security goal; Tor just ensures that nobody can figure out both endpoints, and it does that quite well as long as no one entity can control a significant fraction of the nodes on the paths you use.
As for trust, you generally have to trust *someone* in a system, but you want to reduce the number of trusted entities to the minimum. For instance, when talking to example.org, you ideally only want to trust example.org to provide the content you expect; you shouldn't also have to trust "org" and the root to not take over the site.
That doesn't mean you want naming by consensus, either; that could have the "everyone on the Internet is lying to you" problem you described.
DNS (perhaps with DNSSEC) might even remain a reasonable protocol to use on individual domains, such as to allow "example.org" to provide "www.example.org" and "planet.example.org". However, having a central "org" registry with control over "example.org" puts control in the wrong place, and allows abuse.
Doesn't really help; browsers have bookmarks already. That doesn't solve the problem of helping users get to a site from some well-known name. And IP addresses aren't as stable as names.
That decentralizes the boring bit of the problem. You still have to trust the central authority to not abuse their power, and that doesn't work.
That's actually an easier problem, known as "location-independent identifiers". Most ad-hoc routing protocols tend to flood-fill the network, either when calculating routes or when routing packets. However, ad-hoc routing protocols do exist that avoid flooding, and those protocols can scale.
Virtual Ring Routing can handle Internet-scale networks by treating them like small-world networks, using the same mechanism distributed hash tables use: treat the addresses as a ring, and use a combination of your physical neighbors and your "virtual" neighbors on the ring to cross long distances. A later paper on VRR showed that it scaled quite well with the size of the network, both in the expected length of the routing path and the expected number of routing table entries needed on each node.
We got a team of students to develop an implementation of VRR for Linux, and Microsoft Research has an implementation for Windows.
So yes, we can solve the routing problem easily enough. We just need some way to handle naming that the general public will put up with.