367 karma · joined October 5, 2011
Migrations would be restricted to hosts running specific releases of the hypervisor [1], and AWS's SDN systems would need to handle these changes in very-near-realtime.
[1] wiki.xen.org/wiki/Xen_Version_Compatibility
This tends to be glossed over in discussions of his work, but Aubrey de Grey is specifically interested in reducing the (currently inevitable) human suffering associated with aging. Clinical immortality would be an eventual side-effect of succeeding in that mission.
Every manner of treatable and correctable disease and condition is "part of being a biological organism," but it seems absurd to hold such a standpoint if you're not also in favour of discarding modern medicine in order to die slowly and painfully from cancer.
SSH has a baked-in SOCKS proxy. Example: I SSH into my VPS with the "-D 55555" commandline option, configure my browser to use a SOCKS proxy at localhost:55555, and visit www.netflix.com. That HTTP traffic is tunneled over the SSH connection, and as far as Netflix is concerned, it originates at the US datacenter hosting my VPS.
Docker and Vagrant are convenient for building (and distributing) consistent environments on top of (potentially wildly) different software or hardware platforms. Docker has a ton of other tricks up its sleeve (one example is "layers:" http://docs.docker.io/en/latest/terms/layer/).
Chef/Puppet/Salt/et al. are configuration management tools which enable programmatic definition of infrastructure. The key point is: you define how the system should look, not the specific steps on how to get there. Abstraction layers (management of files/users/packages/services/etc.) provided by the CM tool shield you from a nightmare of permutations, corner cases, and platform-specific options; it'll just enforce a given configuration regardless of local changes.
Having a central source of truth for systems configuration is a gamechanger in itself; your configuration directives or applications can query (or update) your configuration management database, which enables some very cool automation with very little effort. Then there's the community: for any given stack, there's probably a well-documented, well-tested Chef cookbook or Puppet manifest to build it, instantly plugging you into a rich experience base.
Yes, one could script all of this from scratch, but I'm not sure why one would.
I'm not sure that story survives outside a vacuum, but there you have it.
I wish every bank did this as standard practice! Hang up, dial the customer care number on the back of the card, then dial the digits supplied by the support rep.
Better yet, print instructions right on the back of the card: "don't engage any support representative you did not call directly." Training customers to do this (perhaps even through proactive callouts?) would work to significantly reduce this kind of fraud.
Disregarding the fact that most of those items have nothing to do with government surveillance, this particular item has more to do with the fact that attempted (and competent) acts of terrorism are an extremely rare event.
The CIA and FBI failed to stop 9/11 when they failed to exchange relevant information [1]. Lack of actionable data was not the problem then, and I have a hard time believing it's a problem now.
In all seriousness, I'm curious how difficult it would be to jam this network.
A lack of transparency for intelligence operations means their outcomes are difficult to measure, which in turn means the bang-for-the-buck efficacy of those operations is probably not a significant deciding factor in the funding they receive.
[1] http://projects.washingtonpost.com/top-secret-america/
Indeed:
"A change in public policy saw the mass discharge of Riverview Hospital's patients as an effort to integrate them into the community while the province considered the land for development. However, this caused a large influx of mentally ill into the DTES as poor follow-up support failed to reach a majority of these individuals."
http://en.wikipedia.org/wiki/Downtown_Eastside#Mental_Illnes...
Your article [2] mentions mastering issues. In many cases, the master for the vinyl edition of an album differs significantly from that of the CD or digital release; for example, the vinyl edition may feature less compression, preserving dynamic range.
http://www.soundmattersblog.com/vinyl-vs-cd-in-the-loudness-...
Today, I'd recommend working through Linux From Scratch. You'll develop a rich understanding of how a UNIX-like OS fits together, including a fair bit of shell functionality: http://www.linuxfromscratch.org/lfs/
My favourite dead-tree UNIX book would be UNIX Power Tools, 3rd Edition (http://www.amazon.com/Power-Tools-Third-Shelley-Powers/dp/05...). It may be a while before it's a truly valuable resource, but keep it in mind.
Reviewing the history of the mailop list [1] shows how frustrating it can be when a behemoth (AOL, MS, etc.) stops accepting your mail. It's bad enough when you're a sizeable mail operation; as a tiny standalone mailserver, you are not at all a priority, and it's possible you'll lose the ability to communicate with a significant fraction of the Internet's email users (regardless of how complete/correct your configuration) and with little recourse.
Some examples:
http://noglutennoproblem.blogspot.ca/2012/03/wheat-belly-bus...