I know that The Emirates Telecommunications Corporation is one. The same guys who tried to send an eavesdropping trojan horse(labeled as a system update) to 100,000 or so blackberry users...
https://www.eff.org/observatory has more details on the ~650 different entities who will be silently trusted by your standard IE or FF install.
SSL has, potentially, been seriously compromised in that some fairly dodgey entities are trusted issuers from the perspective of the vast majority of consumer browsers, etc.
Mathematically, no big deal; but in practice, potentially an issue.
Now, firesheep is ooh scary because it makes it visible and obvious that complete strangers can jack-yo'-myspace in the coffee shop.
This works because an open WLAN is the equivalent of an old unswitched ethernet network, with every wi-fi reciever in radio range plugged in. It can be mitigated, however, if you are VPN connected to a secure network, because your traffic will be nothing but inscrutable VPN noise, even if the site in question is sloppy.
However, here is the part where the paranoia starts to tickle... Y'know who always has access to any traffic that isn't encrypted between you and your remote host? Your ISP. Y'know who(unless you are buying a pretty serious business class line) you've signed a ridiculously one-side contract with, one that allows them to do basically anything at any time, for any reason? Your ISP. Y'know who hates being reduced to a dumb pipe, and looks covetously at the ad money flowing through the various web companies? Your ISP(See Phorm, Nebuad, et al.). Y'know who could be, totally silently, Firesheeping every non-SSL login you make, and observing all the fun consumer data that advertisers will pay for? Your ISP...
Forget the neckbearded script-kiddie in the coffee shop. He is trivial to work around.
True enough. If the serials are sufficiently large and non-obvious, MD5(or SHA1 or whatever, obviously I'm not making a specific algorithmic recommendation), will make them much more opaque at relatively low cost, and without bringing in high-value crypto keys to the system.
If the serials are too obvious, guess-hash-and-check becomes a viable strategy, which would not be true with proper encryption(but with proper encryption, "grab a low-level logistics operator and pull out his fingernails" would be; while with hashing it wouldn't...)
I think you are(more clearly and succinctly), making more or less the point that I was trying to.
Back in the day, Windows CE lived too basically seperate lives(and still does, in a many locations). One was as a bespoke embedded OS, tailored tightly to various kiosks and POS systems and embedded whatnots, with absolutely no expectation of any sort of "apps" or even OS upgrades. Not infrequently, it was literally burned into actual ROM. On the other side, it served as the core of Pocket PC and Windows Mobile, which were expected, and sometimes actually managed, to have 3rd party application ecosystems, occasional upgrades, within the architectural limits of their platforms, and generally offer a windows-like experience in a smaller box.
I could see Android going very much the same way: if you just need to knock out a kiosk, or a feature-phone, or some embedded something or other, android is free, can be wrangled by relatively widely available linux and java guys, and works reasonably well. Your device will be forever stuck at version X, and may have no facility at all for ugrades(unless enthusiasts hack one in); but it will be an Android device.
The bigger question is whether Android will survive as a coherent platform in the second space. Will "android" actually mean something in terms of what applications, functions, and upgrades the end user can expect, or will a bunch of telcos and widget makers just save some money on firmware and middleware?
And you raise money by appealing to your constituents, and you can raise the most money by appealing to the constituents with the deepest pockets, which means governing in favor of the wealthiest, which means plutocracy...
Unless you use some heavily obfuscated system for generating serials(non sequential, starting from oddball offsets, etc.) it would likely be both conceptually trivial and computationally feasible for the enemy to do a guess and check attack:
If your spotter team sees a tank with a hex-encoded MD5 hash on the side, they have basically no way of converting that back to a serial. However, if you suspect that the serials start with 000001 and increment, or something, generating the first 10,000 MD5 hashes, and using OCR or even human labor against hashed serials seen in the field becomes quite simple.
It is functionally impossible to, given a set of captured hashes, reverse them into plaintext serials; but the set of plausible serials(particularly if you've captured a few samples from factories or spying operations or something) isn't all that huge, and most hashing operations are pretty cheap, especially on dedicated hardware, so it would not be difficult to guess a set of serials, hash them, and then check against hashed serials seen in the field.
And this is why they always tell you to leave crypto to the experts, I suppose...
It is quite possible(at least until things started going really badly for them) that the germans were producing tanks in multiple locations, with each factory/complex serializing independently, and then sending to the front with the most optimal combination of high need and low shipping distance.
That way, you don't need any particularly privileged crypto keys floating around(only the plaintext serials, and each one of them only reveals one hashed serial) and a logistics officer in possession of a plaintext serial can trivially generate the hashed serial and verify it against a piece of hardware. People below a certain security level can just be handed the hashed serials for the stuff they are supposed to keep track of, thus preventing large lists of plaintext serials from floating around in questionably secure locations or hands.
As a de-facto standard cheap embedded OS for reasonably high resource devices, it is pretty hard to see Android doing badly. Mostly linux guts, so it runs on plenty of stuff, Google has been pretty aggressive about improving it, freely available(if you don't want Google's blessing and proprietary apps). Runs basically-java, so there are plenty of developers available; but also has the unixy underpinnings such that, if your horrid legacy application supports the architecture, you can run it natively and just interact with it via a thin android UI. Hard to argue too much with that, at least until you get to screen-and-keyboard devices were something a little less touchphone focused might be nice.
How well "android" in the sense of "Google blessed, app-store linked, reasonably up to date and supported by the vendor with upgrades(or left open for 3rd party support), it is less clear. By virtue of being open, the risk of carrier tentacles getting in and ruining things becomes higher, and the competition from more forcefully unified platforms greater.
It may not have been improvised in the field; but chain, grape, and canister shot were all(at least in naval contexts) widely used and available well before the civil war. I'm not terribly familiar with the conflict; but it would be totally unsurprising if some field guns being used in an anti-infantry role were firing assorted unpleasant payloads other than solid round shot.
Of course, even aside from the cannons, your cotemporary 5.56 FMJ (while considerably lighter, higher velocity, and much easier to reload) is pretty much mom's kiss goodnight compared to a.58 or.68 Minié ball.
Also, of course, without antibiotics available, a fair percentage of the more elegant tissue-conserving, never mind reconstructive, surgery was basically just a civilized method of getting Gangrene and dying horribly.
As any chef or butcher going back to the era of flint knives could demonstrate, cutting tissue quite precisely is actually really doable for a skilled tradesman. Haemostasis and infection control, on the other hand, are what kept surgery at the "chop it off and dip what's left in hot tar" stage.
Too dangerous. Antarctic ice is specially evolved to be resistant to the ice mites transmitted by penguins. Were the arctic ice to be infected, we could lose 90% of the arctic ice cover within just a few years due to mite infestation...
I suspect that classic Von Neumman computers, and their crazy-fast-but-not-wildly-different descendants are not a wildly good analogy for the brain. Adult neurogenesis is a well established phenomenon, with some demonstrated links to behavioral change. At the level of crude analogy, the brain exhibits at least FPGA levels of hardware plasticity, quite possibly greater.
On the other hand, as you note, a brain never actually shuts down(with the limited exception of a few cases of people being frozen and surviving). Consciousness ceases about once a day, or under anesthesia, or certain types of trauma; but the brain is "in flight" 24/7/365 from when it starts to grow to when it dies. There may be some amount of important activity that is never hardcoded into cellular structures that are well preserved after death.
However, even in that case, it doesn't mean that studying the structure teaches you nothing. Consider the computer analogy: by design, certain things, like secure-swap crypto keys, are deliberately kept in RAM only, and never flushed to disk. They are lost on shutdown. However, the kernel code that implements the secure swap is visible as a magnetic structural change, and the function of SRAM is clearly visible from studying its circuit diagrams, which can be inferred by imaging it silicon.
A researcher given a computer and forced to study it without turning it on could(with considerable difficulty) read the HDD contents, determine the initialization vector for that architecture, read the BIOS code, etc. and infer that, were the system still running, there would be a crypto key stored in RAM for the secure swap. He wouldn't be able to tell you what the key was before the computer was shut down; but(with some seriously arduous work), his purely physical study could tell you a great deal about what to expect, and what areas to study, if you had a method for imaging the RAM contents of a running computer.
You don't get to know everything about every computer; but a useful composite view can be assembled. Similarly, with the brain, there are probably certain activities about which you just can't say much based on a dead brain; but structural study should be able to shed a great deal of light about where to look in a living brain if you want to see different functions in action. "This structure, based on its neural anatomy, looks like a timing mechanism. Expect to see periodic waveforms on electrodes in a living organism." "This area has strong connections to the retina, it should light up like a christmas tree when visual stimuli are presented.", etc.
Doesn't really matter what causes desertification, the consequences are largely the same. More specifically, we are discussing an article proposing the notion that fair portions of the arctic are going to become more or less temperate. I am granting that the status of "true for the sake of argument". Given that, severe ecological disruption, and probable desertification, of equatorial regions seems fairly likely.
If TFA's projection is wrong, that may not be true at all; but there also isn't much to talk about.
Given the amount of angst and disruption caused by the relatively puny numbers of existing economic migrants, I suspect that things might not be so ducky.
Even in situations where the long-term basically turns out well(ie. the US's comparatively open immigration policy(with various historical exceptions based on whatever flavor of subhuman we are freaking out about today) has basically been reasonably successful; short, sharp upticks in migration, particularly the sort that is more desperate than entrepreneurial, can get really ugly.
China, large swaths of Africa, and central America are already a bit water-stressed. Their (large) populations aren't going to take kindly to the idea of just shriveling up and dying. Under sufficiently severe stress, local governments are either just going to fail, or going to adopt a deliberate "go north, young man" policy to make their excess populations somebody elses problem. At that point, places like the US, southern Europe, Russia, etc. enjoy the delightful choice of either absorbing a giant bolus of "the wretched refuse of your teeming shore", or the militarization and xenophobia of a society willing to just stretch out the concertina wire and start shooting to kill. Fun times.
Extra giggles will, of course, be had all around if doctors in the northern hemisphere have to start reading the Journal of Tropical Medicine as a matter of professional practice, rather than altruism...
While it might be nice for the peoples of the Arctic rim to be able to move from a "shivering a lot and burning penguins for warmth" based economy(yes, I know, penguins are antarctic; but the arctic doesn't have any birds nearly as iconic), the fact that there are many more people, and a lot more land, closer to the equator is going to make that move a major net downer. Particularly since the inhabitants of the new equatorial desert are unlikely to take kindly to any plans that involve them dying quietly in their place, which will imply a certain amount of desperate migration, which never goes very well....
In a sense, that analogy is apt; but in a sense, that would actually be a reasonably sensible start to determining how an apple tastes.
If you want the subjective experience of tasting an apple you just bite one. Problem solved. If you want to know why the apple tastes as it does it isn't clear that a biting them strategy will ever get you closer to that.
At some point, you are going to have to break down and do a sophisticated analysis of the chemistry and structure of the apple. However, the more fine-grained the analysis, the pricier per cubic mm and thus the more likely that you will miss an important spot, or fail entirely to see some aspect of the taste based on the experience of contrast between two or more distinct regions. Therefore, having a bunch of black and white slice photos is hardly the end of your job; but it might actually be pretty useful in planning what parts of the apple to hit in greater detail, and what you need to know about them.
What magical fairyland do you think "willpower" lives in?
Also, just parenthetically, PCs compartmentalize their differences rather aggressively, for cost reasons; but it is actually relatively simple to observe the hardware differences between PCs running different OSes: just look at the arrangement of magnetic domains on the HDD platter surfaces. Hardly easier than just booting the sucker; but 100% physical and hardware based.
It almost certainly is disrupting fine structures or details of network connections that future neurologists might want to study; but I suspect that this is one of those situations where they don't really have a choice.
The brain is extremely complex, and nondestructive imaging methods are either expensive, low-resolution, or both. Good old slice-n-stain, with a dash of modern robotics, is cheap and high resolution.
Since we know so little about how brains actually work, it isn't a bad idea to just build a giant dataset, using an economic and high-resolution technique, and hope that that dataset allows future researchers to pinpoint more closely what they should actually be looking for.
Given that the supply of brains donated to science, while not huge, can be reasonably expected to continue into the indefinite future, starting with destructive; but quick, reverse engineering steps, and then gradually progressing down to finer, more focused ones, seems pretty sensible.
A lot of the brains thus sliced will, it is true, be destroyed as far as the researchers of the future are concerned; but slicing them may be the only way to get the researchers of the future to a position of sufficient knowledge.
Semantic questions, and questions of categorization, can be interesting and(when all goes well) can even clarify your thinking about a topic; but are otherwise rather pointless.
On the one hand, it is trivially obvious that if you aren't running the GNOME desktop environment, you aren't runnning GNOME. On the other hand, if you are running a set of programs, and depending on a set of libraries, essentially identical to that of a GNOME desktop, just window managed by something else, it is much more meaningful to say that you are "running GNOME" or "running a GNOME derivative" than it is to say much else.
Unless you want to actually come up with some set-based definition of what "Running GNOME" means, you won't really be able to conclusively answer the question one way or the other.
While I strongly suspect that Apple had absolutely nothing to do with it(Steve Jobs probably personally kills someone from PR every time "malware" appears in the same sentence as any Apple product, unless it's a sentence about immunity thereto), it does raise the important notion of the security downsides that also exist in walled garden environments.
The security upsides are obvious. Whitelisting is easier than blacklisting. Enumerating goodness vs. badness, users are idiots who will click anything, etc.
However, this is the downside: Since there are always some applications that fall outside of the whitelist(enumerating goodness is easy, enumerating all goodness is hard, and some people don't want goodness, and some goodness is bad for the vendor's bottom line), there will be a demand for ways to run them. This means that there is a population of users who depend on the existence of security flaws in the system, and have an essentially antagonistic relationship with their own, and a lot of other people's, vendor. In open systems, only malware writers and scum are in this position. Everyone else is either a white hat, disinterested, or just a sheep. In closed systems, some white hats and just sheep are actually on the same side as the malware writers and scum, because both depend on exploits to run the code they want.
Any data that are stored on a single device are data you don't care about, full stop. HDDs certainly do have cooler sounding failure modes; but SSDs can and do just stop talking, or, if really maldesigned, start throwing data on the floor instead of politely reporting their inability to write in the future.
We, collectively speaking, long ago decided that storage should be cheap, and anybody who wanted reliability could just buy more and play with redundancy.
The real problem with SSD reliability is not the high end(making solid state circuits that are extremely durable and fail relatively gracefully is certainly nontrivial; but it is basically a solved problem); but the fact that, since they are already painfully expensive compared to HDDs, a lot of the ones actually on the market are, shall we say, the product of certain compromises...
Rock-solid firmware and generous amounts of spare area, along with SLC flash, will give you a very reliable product. MLC flash, minimal spare area, and whatever firmware built without egregious compiler warnings will get you a drive that is priced to move. Hence the horror stories.
Operating or powered-down? With the heads parked and locked, HDDs can be reasonably shock resistant. While actively seeking, not so much.
(Also, just as a general matter of interpreting G numbers, unless you do all your computing in a padded room, you'd be surprised how easy it is to reach very high peak deceleration by doing quite ordinary things. As the deceleration distance approaches zero, the deceleration rate approaches infinity. In practice, even the most tightly packed hardware, dropped onto concrete, will get at least a couple of millimeters to decelerate in; but a meter or two of acceleration at 1G followed by a return to zero velocity within a couple of millimeters can really hurt.)
Slashdot Mirror
I know that The Emirates Telecommunications Corporation is one. The same guys who tried to send an eavesdropping trojan horse(labeled as a system update) to 100,000 or so blackberry users...
https://www.eff.org/observatory has more details on the ~650 different entities who will be silently trusted by your standard IE or FF install.
SSL has, potentially, been seriously compromised in that some fairly dodgey entities are trusted issuers from the perspective of the vast majority of consumer browsers, etc.
Mathematically, no big deal; but in practice, potentially an issue.
Now, firesheep is ooh scary because it makes it visible and obvious that complete strangers can jack-yo'-myspace in the coffee shop.
This works because an open WLAN is the equivalent of an old unswitched ethernet network, with every wi-fi reciever in radio range plugged in. It can be mitigated, however, if you are VPN connected to a secure network, because your traffic will be nothing but inscrutable VPN noise, even if the site in question is sloppy.
However, here is the part where the paranoia starts to tickle... Y'know who always has access to any traffic that isn't encrypted between you and your remote host? Your ISP. Y'know who(unless you are buying a pretty serious business class line) you've signed a ridiculously one-side contract with, one that allows them to do basically anything at any time, for any reason? Your ISP. Y'know who hates being reduced to a dumb pipe, and looks covetously at the ad money flowing through the various web companies? Your ISP(See Phorm, Nebuad, et al.). Y'know who could be, totally silently, Firesheeping every non-SSL login you make, and observing all the fun consumer data that advertisers will pay for? Your ISP...
Forget the neckbearded script-kiddie in the coffee shop. He is trivial to work around.
True enough. If the serials are sufficiently large and non-obvious, MD5(or SHA1 or whatever, obviously I'm not making a specific algorithmic recommendation), will make them much more opaque at relatively low cost, and without bringing in high-value crypto keys to the system.
If the serials are too obvious, guess-hash-and-check becomes a viable strategy, which would not be true with proper encryption(but with proper encryption, "grab a low-level logistics operator and pull out his fingernails" would be; while with hashing it wouldn't...)
I think you are(more clearly and succinctly), making more or less the point that I was trying to.
Back in the day, Windows CE lived too basically seperate lives(and still does, in a many locations). One was as a bespoke embedded OS, tailored tightly to various kiosks and POS systems and embedded whatnots, with absolutely no expectation of any sort of "apps" or even OS upgrades. Not infrequently, it was literally burned into actual ROM. On the other side, it served as the core of Pocket PC and Windows Mobile, which were expected, and sometimes actually managed, to have 3rd party application ecosystems, occasional upgrades, within the architectural limits of their platforms, and generally offer a windows-like experience in a smaller box.
I could see Android going very much the same way: if you just need to knock out a kiosk, or a feature-phone, or some embedded something or other, android is free, can be wrangled by relatively widely available linux and java guys, and works reasonably well. Your device will be forever stuck at version X, and may have no facility at all for ugrades(unless enthusiasts hack one in); but it will be an Android device.
The bigger question is whether Android will survive as a coherent platform in the second space. Will "android" actually mean something in terms of what applications, functions, and upgrades the end user can expect, or will a bunch of telcos and widget makers just save some money on firmware and middleware?
And you raise money by appealing to your constituents, and you can raise the most money by appealing to the constituents with the deepest pockets, which means governing in favor of the wealthiest, which means plutocracy...
Oops, I just thought of a major weakness:
Unless you use some heavily obfuscated system for generating serials(non sequential, starting from oddball offsets, etc.) it would likely be both conceptually trivial and computationally feasible for the enemy to do a guess and check attack:
If your spotter team sees a tank with a hex-encoded MD5 hash on the side, they have basically no way of converting that back to a serial. However, if you suspect that the serials start with 000001 and increment, or something, generating the first 10,000 MD5 hashes, and using OCR or even human labor against hashed serials seen in the field becomes quite simple.
It is functionally impossible to, given a set of captured hashes, reverse them into plaintext serials; but the set of plausible serials(particularly if you've captured a few samples from factories or spying operations or something) isn't all that huge, and most hashing operations are pretty cheap, especially on dedicated hardware, so it would not be difficult to guess a set of serials, hash them, and then check against hashed serials seen in the field.
And this is why they always tell you to leave crypto to the experts, I suppose...
Overt plutocracy is so very vulgar, and might get the proles worked up....
It is interesting to note exactly how little people know about the actual American wealth distribution...
It is quite possible(at least until things started going really badly for them) that the germans were producing tanks in multiple locations, with each factory/complex serializing independently, and then sending to the front with the most optimal combination of high need and low shipping distance.
Probably best to hash them.
That way, you don't need any particularly privileged crypto keys floating around(only the plaintext serials, and each one of them only reveals one hashed serial) and a logistics officer in possession of a plaintext serial can trivially generate the hashed serial and verify it against a piece of hardware. People below a certain security level can just be handed the hashed serials for the stuff they are supposed to keep track of, thus preventing large lists of plaintext serials from floating around in questionably secure locations or hands.
As a de-facto standard cheap embedded OS for reasonably high resource devices, it is pretty hard to see Android doing badly. Mostly linux guts, so it runs on plenty of stuff, Google has been pretty aggressive about improving it, freely available(if you don't want Google's blessing and proprietary apps). Runs basically-java, so there are plenty of developers available; but also has the unixy underpinnings such that, if your horrid legacy application supports the architecture, you can run it natively and just interact with it via a thin android UI. Hard to argue too much with that, at least until you get to screen-and-keyboard devices were something a little less touchphone focused might be nice.
How well "android" in the sense of "Google blessed, app-store linked, reasonably up to date and supported by the vendor with upgrades(or left open for 3rd party support), it is less clear. By virtue of being open, the risk of carrier tentacles getting in and ruining things becomes higher, and the competition from more forcefully unified platforms greater.
It may not have been improvised in the field; but chain, grape, and canister shot were all(at least in naval contexts) widely used and available well before the civil war. I'm not terribly familiar with the conflict; but it would be totally unsurprising if some field guns being used in an anti-infantry role were firing assorted unpleasant payloads other than solid round shot.
.58 or .68 Minié ball.
Of course, even aside from the cannons, your cotemporary 5.56 FMJ (while considerably lighter, higher velocity, and much easier to reload) is pretty much mom's kiss goodnight compared to a
Also, of course, without antibiotics available, a fair percentage of the more elegant tissue-conserving, never mind reconstructive, surgery was basically just a civilized method of getting Gangrene and dying horribly.
As any chef or butcher going back to the era of flint knives could demonstrate, cutting tissue quite precisely is actually really doable for a skilled tradesman. Haemostasis and infection control, on the other hand, are what kept surgery at the "chop it off and dip what's left in hot tar" stage.
Too dangerous. Antarctic ice is specially evolved to be resistant to the ice mites transmitted by penguins. Were the arctic ice to be infected, we could lose 90% of the arctic ice cover within just a few years due to mite infestation...
I suspect that classic Von Neumman computers, and their crazy-fast-but-not-wildly-different descendants are not a wildly good analogy for the brain. Adult neurogenesis is a well established phenomenon, with some demonstrated links to behavioral change. At the level of crude analogy, the brain exhibits at least FPGA levels of hardware plasticity, quite possibly greater.
On the other hand, as you note, a brain never actually shuts down(with the limited exception of a few cases of people being frozen and surviving). Consciousness ceases about once a day, or under anesthesia, or certain types of trauma; but the brain is "in flight" 24/7/365 from when it starts to grow to when it dies. There may be some amount of important activity that is never hardcoded into cellular structures that are well preserved after death.
However, even in that case, it doesn't mean that studying the structure teaches you nothing. Consider the computer analogy: by design, certain things, like secure-swap crypto keys, are deliberately kept in RAM only, and never flushed to disk. They are lost on shutdown. However, the kernel code that implements the secure swap is visible as a magnetic structural change, and the function of SRAM is clearly visible from studying its circuit diagrams, which can be inferred by imaging it silicon.
A researcher given a computer and forced to study it without turning it on could(with considerable difficulty) read the HDD contents, determine the initialization vector for that architecture, read the BIOS code, etc. and infer that, were the system still running, there would be a crypto key stored in RAM for the secure swap. He wouldn't be able to tell you what the key was before the computer was shut down; but(with some seriously arduous work), his purely physical study could tell you a great deal about what to expect, and what areas to study, if you had a method for imaging the RAM contents of a running computer.
You don't get to know everything about every computer; but a useful composite view can be assembled. Similarly, with the brain, there are probably certain activities about which you just can't say much based on a dead brain; but structural study should be able to shed a great deal of light about where to look in a living brain if you want to see different functions in action. "This structure, based on its neural anatomy, looks like a timing mechanism. Expect to see periodic waveforms on electrodes in a living organism." "This area has strong connections to the retina, it should light up like a christmas tree when visual stimuli are presented.", etc.
Doesn't really matter what causes desertification, the consequences are largely the same. More specifically, we are discussing an article proposing the notion that fair portions of the arctic are going to become more or less temperate. I am granting that the status of "true for the sake of argument". Given that, severe ecological disruption, and probable desertification, of equatorial regions seems fairly likely.
If TFA's projection is wrong, that may not be true at all; but there also isn't much to talk about.
Given the amount of angst and disruption caused by the relatively puny numbers of existing economic migrants, I suspect that things might not be so ducky.
Even in situations where the long-term basically turns out well(ie. the US's comparatively open immigration policy(with various historical exceptions based on whatever flavor of subhuman we are freaking out about today) has basically been reasonably successful; short, sharp upticks in migration, particularly the sort that is more desperate than entrepreneurial, can get really ugly.
China, large swaths of Africa, and central America are already a bit water-stressed. Their (large) populations aren't going to take kindly to the idea of just shriveling up and dying. Under sufficiently severe stress, local governments are either just going to fail, or going to adopt a deliberate "go north, young man" policy to make their excess populations somebody elses problem. At that point, places like the US, southern Europe, Russia, etc. enjoy the delightful choice of either absorbing a giant bolus of "the wretched refuse of your teeming shore", or the militarization and xenophobia of a society willing to just stretch out the concertina wire and start shooting to kill. Fun times.
Extra giggles will, of course, be had all around if doctors in the northern hemisphere have to start reading the Journal of Tropical Medicine as a matter of professional practice, rather than altruism...
While it might be nice for the peoples of the Arctic rim to be able to move from a "shivering a lot and burning penguins for warmth" based economy(yes, I know, penguins are antarctic; but the arctic doesn't have any birds nearly as iconic), the fact that there are many more people, and a lot more land, closer to the equator is going to make that move a major net downer. Particularly since the inhabitants of the new equatorial desert are unlikely to take kindly to any plans that involve them dying quietly in their place, which will imply a certain amount of desperate migration, which never goes very well....
In a sense, that analogy is apt; but in a sense, that would actually be a reasonably sensible start to determining how an apple tastes.
If you want the subjective experience of tasting an apple you just bite one. Problem solved. If you want to know why the apple tastes as it does it isn't clear that a biting them strategy will ever get you closer to that.
At some point, you are going to have to break down and do a sophisticated analysis of the chemistry and structure of the apple. However, the more fine-grained the analysis, the pricier per cubic mm and thus the more likely that you will miss an important spot, or fail entirely to see some aspect of the taste based on the experience of contrast between two or more distinct regions. Therefore, having a bunch of black and white slice photos is hardly the end of your job; but it might actually be pretty useful in planning what parts of the apple to hit in greater detail, and what you need to know about them.
What magical fairyland do you think "willpower" lives in?
Also, just parenthetically, PCs compartmentalize their differences rather aggressively, for cost reasons; but it is actually relatively simple to observe the hardware differences between PCs running different OSes: just look at the arrangement of magnetic domains on the HDD platter surfaces. Hardly easier than just booting the sucker; but 100% physical and hardware based.
It almost certainly is disrupting fine structures or details of network connections that future neurologists might want to study; but I suspect that this is one of those situations where they don't really have a choice.
The brain is extremely complex, and nondestructive imaging methods are either expensive, low-resolution, or both. Good old slice-n-stain, with a dash of modern robotics, is cheap and high resolution.
Since we know so little about how brains actually work, it isn't a bad idea to just build a giant dataset, using an economic and high-resolution technique, and hope that that dataset allows future researchers to pinpoint more closely what they should actually be looking for.
Given that the supply of brains donated to science, while not huge, can be reasonably expected to continue into the indefinite future, starting with destructive; but quick, reverse engineering steps, and then gradually progressing down to finer, more focused ones, seems pretty sensible.
A lot of the brains thus sliced will, it is true, be destroyed as far as the researchers of the future are concerned; but slicing them may be the only way to get the researchers of the future to a position of sufficient knowledge.
Semantic questions, and questions of categorization, can be interesting and(when all goes well) can even clarify your thinking about a topic; but are otherwise rather pointless.
On the one hand, it is trivially obvious that if you aren't running the GNOME desktop environment, you aren't runnning GNOME. On the other hand, if you are running a set of programs, and depending on a set of libraries, essentially identical to that of a GNOME desktop, just window managed by something else, it is much more meaningful to say that you are "running GNOME" or "running a GNOME derivative" than it is to say much else.
Unless you want to actually come up with some set-based definition of what "Running GNOME" means, you won't really be able to conclusively answer the question one way or the other.
While I strongly suspect that Apple had absolutely nothing to do with it(Steve Jobs probably personally kills someone from PR every time "malware" appears in the same sentence as any Apple product, unless it's a sentence about immunity thereto), it does raise the important notion of the security downsides that also exist in walled garden environments.
The security upsides are obvious. Whitelisting is easier than blacklisting. Enumerating goodness vs. badness, users are idiots who will click anything, etc.
However, this is the downside: Since there are always some applications that fall outside of the whitelist(enumerating goodness is easy, enumerating all goodness is hard, and some people don't want goodness, and some goodness is bad for the vendor's bottom line), there will be a demand for ways to run them. This means that there is a population of users who depend on the existence of security flaws in the system, and have an essentially antagonistic relationship with their own, and a lot of other people's, vendor. In open systems, only malware writers and scum are in this position. Everyone else is either a white hat, disinterested, or just a sheep. In closed systems, some white hats and just sheep are actually on the same side as the malware writers and scum, because both depend on exploits to run the code they want.
Any data that are stored on a single device are data you don't care about, full stop. HDDs certainly do have cooler sounding failure modes; but SSDs can and do just stop talking, or, if really maldesigned, start throwing data on the floor instead of politely reporting their inability to write in the future.
We, collectively speaking, long ago decided that storage should be cheap, and anybody who wanted reliability could just buy more and play with redundancy.
The real problem with SSD reliability is not the high end(making solid state circuits that are extremely durable and fail relatively gracefully is certainly nontrivial; but it is basically a solved problem); but the fact that, since they are already painfully expensive compared to HDDs, a lot of the ones actually on the market are, shall we say, the product of certain compromises...
Rock-solid firmware and generous amounts of spare area, along with SLC flash, will give you a very reliable product. MLC flash, minimal spare area, and whatever firmware built without egregious compiler warnings will get you a drive that is priced to move. Hence the horror stories.
Operating or powered-down? With the heads parked and locked, HDDs can be reasonably shock resistant. While actively seeking, not so much.
(Also, just as a general matter of interpreting G numbers, unless you do all your computing in a padded room, you'd be surprised how easy it is to reach very high peak deceleration by doing quite ordinary things. As the deceleration distance approaches zero, the deceleration rate approaches infinity. In practice, even the most tightly packed hardware, dropped onto concrete, will get at least a couple of millimeters to decelerate in; but a meter or two of acceleration at 1G followed by a return to zero velocity within a couple of millimeters can really hurt.)