The Protocol contains a loophole large enough to drive a truck through, never mind some photons:
"Article 3
Blinding as an incidental or collateral effect of the legitimate military employment of laser systems, including laser systems used against optical equipment, is not covered by the prohibition of this Protocol."
As long as the blinding is a side effect (mitigated by "all feasible precautions to avoid the incidence of permanent blindness to unenhanced vision") of a non-blinding purpose(setting things on fire, destroying machine vision/optical sensor gear, 'dazzling', and basically anything else you might feel like using a laser for, it's all legal. That is not exactly fertile ground for any sort of serious arms control, even if lasers weren't comparatively cheap and trivial to build, especially at the modest powers that will really boil your eyeballs but aren't subject to the engineering challenges of aspirational air-defense and antimissile systems.
It gives me no pleasure to say so; blinding is a pretty ugly thing to do; but the Protocol as written is about as effective as forbidding murder; but making it legal to put a bullet through any hat you see, regardless of whether it contains a head or not.
It's also an overcomplicated solution. OBD can get pretty nasty if you want access to esoteric stuff or manufacturer proprietary crap; but a basic, bluetooth-capable, OBD dongle that'll report the rough outlines of how a vehicle is being used is quite cheap indeed and not especially complex. I wouldn't necessarily want to try dead-reconing with nothing but that output; but answering "Am I driving right now?" is considerably less demanding.
It's not really polite to say so that bluntly; but the difference is that measles deaths are basically optional(1st world anti-vaxxers) or just another bad thing that happens to poor people in poor and unpleasant places. By contrast, Ebola is currently just another bad thing that happens to poor people in poor and unpleasant places; but we've got basically nothing available to do about it if it spreads beyond the usual outbreak sites(yes, unlike the usual outbreak sites, we have limited supplies of high grade medical isolation gear and some interesting experimental drugs; but nobody has enough of the cool tech to deal with an outbreak of nontrivial size, especially if they want their medical and logistical systems to continue handling routine functions and care at the same time).
There are loads of places far less poor and squalid than Liberia and the other oubreak sites; but without any good options on the table it wouldn't take long to run through your supply of isolation wards and fancy positive-pressure protective suits even in the most upmarket first world locations with well regarded research hospitals and such, were the population to be affected.
Was she asleep for, oh, the past quarter century? We've put together a neat little system (really an untidy patchwork of them) such that you can't touch something Turing-complete, drive on a substantial percentage of reasonably major roads, or do just about anything involving commerce without it dropping into the gigantic database somewhere and she's freaking out about somebody's little model airplane with a gopro?
It is the case that there are quite a few values of 'somebody' where worrying might be a good idea; but as a relatively petty footnote to the Orwellian world we've already put into operation. Pretending otherwise is clueless at best and actively dishonest at worst.
I can understand the interest in the existence of Eucalyptus itself (it's a more or less interface compatible implementation of a bunch of Amazon's heavily used 'cloud' services that you can run stuff on in house or at a non-Amazon 3rd party). Amazon's pricing is crazy aggressive; but sometimes you need to do things in house, want to do things in house, or want to go mixed-strategy(in-house/Amazon for overflow, spread across more than one 3rd party provider, etc, etc.) and in general it's not a good feeling to have a stack of important stuff dependent on a single vendor.
What I find much harder to understand is what HP gains from this, or what I, the hypothetical customer, as supposed to be willing to pay HP to put its name on here.
Is this just more HP flailing, or is there an angle I'm missing? Are there lots of potential customers who won't touch Amazon (perhaps because they have to keep stuff internal); but won't touch Eucalyptus without some giant company selling them a support agreement? If so, since Amazon is off the table, why would they care about Amazon API compatibility? Who is the target here, and why aren't they either DIYing it, paying Amazon's incredibly aggressive prices for the real thing, or using an architecturally different cloud/VM arrangement?
Even if it were perfect, almost no ChromeOS devices have touchscreens and almost all Android devices do (especially if you count on the ones Google even slightly endorses, not the media-player-mystery-HDMI-dongle stuff). For applications that are basically hobbled by the touchscreen, a keyboard and mouse will be an improvement. For those that are enhanced by, or actively dependent on, it, that will be a bit of a mess no matter how perfect the runtime is.
Unless those proportions change fairly markedly, it probably makes sense for them to start with some popular, mouse and keyboard friendly, applications that don't lean on native ARM blobs much or at all.
Don't forget the Khmer Rouge or the Rwandan Akazu: they had less to work with; but killing north of 20% of your country's population really shows a commitment to atrocity.
Sorry, my phrasing was ambiguous: the rPi I/O is 'broken out' in the sense of 'breakout board', it's substantially accessible on reasonably friendly headers that you can connect to without tiny elven soldering fingers or oddball connectors; unlike the (otherwise cheap and quite tempting) 'buy an android mini-stick-thing/used phone with 3rd party firmware support' option, which gets you power, sometimes a screen, and a few peripherals for crazy cheap; but where you'll be lucky to find a handful of undocumented test points, much less any headers.
The chip the rPi is based on really isn't quite right for the job(but feel the price...) so eth isn't so hot; but I've never had any serious issues, assuming an acceptance of the speed limits.
I am genuinely baffled at how the embargo is supposed to support US policy interests(either idealistic, cynical, or both); but alleged damages that high do seem to suggest that the "It's pointless, they'll just trade with the EU and BRIC and things" theory is limited at best. I honestly would have expected a smaller effect myself. I just can't fathom why anyone thinks it's a worthwhile plan.
In all honesty, it's really a testament to Excel's relatively favorable balance of power and ease of use, even non-techies can do some reasonably heavy lifting and more sophisticated users can do some fairly impressive rapid prototyping.
Unfortunately, these sorts of horrors always seem to be the result. What I don't know is how much of the disaster is caused by Excel just not scaling well(which, at least in theory, is something that could be improved) and how much is caused by the fact that non-programmers may be scared away from programming by the stuff that Excel is good at hiding; but still get bitten by the stuff they don't even know is there(which, in fairness to them, is the same stuff that usually bites actual programmers, though less often if they are good ones).
$1.1 billion over 55 years is $20 billion/year, in a country with a GDP of ~$70 billion, so that arguably puts the embargo into the category of 'surprisingly effective; if not exactly at achieving any of the US' alleged objectives'.
When it comes to 'terrorizing and vile violations of human rights', though, that barely registers. Did this guy sleep through the entire 20th century?
I had the displeasure of observing(thankfully, not of being called in to clean up after) some very, very, heavy Excel users who were eventually forced to capitulate and move to something less insane because it was becoming a matter of pure chance whether a multi-day simulation run would cause Excel to exhaust its memory space and fall over(this was maybe a decade before 64 bit x86, much less broad support for it, was a thing, so just throwing money at the problem wasn't an option).
That would be interesting to know. Helium is remarkably low-density by the standards of inert gasses(~.18grams/Liter vs. ~.9 for Neon and 1.25 for the ignoble-but-pretty-well-behaved Nitrogen), so it may actually be substantially different from any of the other options.
It isn't 100% clear: All 'Silvermont' SKUs appear to be 64 bit capable, and this board has a Silvermont-based Atom on it(two of them actually); but Intel's Edison Native Applications Guide definitely appears to be walking you through setting up a build environment for 32 bit x86.
Whether that means that Intel actually lasered support for 64 bit execution off when they were designing this chip(which isn't like most of the other Silvermont devices, which have a GPU and more PC-style I/O, so clearly some cutting was done), or whether it means that they decided to default to 32 bits for everything because the device only has 1GB of RAM soldered on and no support for more, is not clear from anything I've been able to find.
TFS is simply incorrect; but may have been confused by Intel's "Galileo" board, which is based on Quark (at 400MHz). Curiously, 'Galileo' is much more Arduino-esque (a bit more raw punch, weaker hard-real-time bitbang); but also has a full PCIe lane(brought out on a miniPCIe connector) and 100Mb ethernet(optional PoE in Gen2); but no RF.
The much more PC-like, or at least BB Black/rPi-like Edison has a substantially punchier CPU; but no PCIe, wired ethernet, and includes wifi and BT.
I'm not sure if we are misjudging intel through the lens of existing products, or if Intel can't quite decide what niche to hit; but I find this mix a trifle confusing personally...
The teeny little one has the high powered CPU (relatively speaking); but not the high speed expansion bus or wired networking and PoE options. The relatively big one has high speed expansion (but severely limited GPIO, making compatibility with MCU projects that depend on bitbanging rather tepid); but the weak CPU and limited RAM.
I'm interested, and it's always worth keeping an eye on Intel; but I'm a bit confused about what they are aiming at here.
I'm definitely open to suggestions if you have any cool ones to point me to; but I've had some fairly unpleasant experiences with a lot of the theoretically-capable-and-crazy-cheap 'android stick' type sticks and boards. The rPi is indeed quite feeble; but what I/O it has is actually mostly broken out, and (while not exactly FSF-level 'open') is crazy open by the standards of something broadcom based, and enjoys a very strong community of people who can answer questions about any obscure points.
The beaglebone black is a bit more expensive and supply-challenged; but has nicer networking, a bit more punch, ans the SPUs.
Do you know of some things that exploit the various unbelievably cheap smartphone parts; but don't require a working knowledge of chinese datasheets, or have absolutely all signals but HDMI exposed in lilliputan test points? I imagine that there are some; but the couple of times I've dived in without too much research I've ended up with something that...mostly...runs the included Android-build-of-mystery; but is otherwise effectively unusable.
(There are, of course, some nice options over in router-land, in terms of price and network connectivity, sometimes enough GPIO for light work; but those aren't going to be doing much video anytime soon.)
Intel has the Product Brief up. Unless they specifically decided to hide the fact (which would seem unlikely), video appears to be absent.
Wireless connectivity looks pretty nice (wifi and bluetooth out of the box, though BTLE is mysteriously 'in Q4-14', which makes one wonder if perhaps the driver situation has a few grim little stories that we should know about...) and the inclusion of both 2x Atom cores at 500MHz and 1x Quark core at 100MHz is potentially interesting, depending on how easily and elegantly the Atom and Quark 'sides' of the device can talk to one another and either share control of, or at least transfer control of, the various I/O lines.
Not going to shove the rPi out of the way for video-pushing applications, and I suspect that PWM and bitbang-heavy applications may still be underimpressed by Intel compared to the classic microcontroller options; but it could certainly be a contender for a lot of the 'arduino-connected-to-the-network' applications which don't lean too hard on squeezing every last drop out of bare-metal-MCU work; but which could really use a bit more punch on the networking and storage/logging side.
Certainly nothing obvious comes to mind, in terms of features.
The only class of complaint that would be nice to see addressed (not exclusive to the heart, also covers skeletal muscle, bone density, tissue healing, and assorted metabolic processes) is that most of the parameters are still tuned for a relatively high-exertion, high-risk, environment with a strong risk of at least occasional malnutrition. As your basic first-world 'press buttons at work, hired because he knows what buttons to press' type, I can afford plenty of calories and adequate supportive care if injured. Since that's the case, storing spare energy on my waistline is largely unappreciated, maintaining muscles at relatively feeble standby states, rather than defaulting to growing them for when I do have use for them, and prioritizing speedy; but scar-prone, healing over slower but more elegant regeneration are all kind of annoying.
In the same boat; but more of an issue for women, is calcium handling: bioavailable calcium is cheap as dirt these days; but we still suffer skeletal embrittlement over time.
I can't think of any big, dramatic, neat features, just a variety of optimizations that were adaptive under a somewhat different environment than the one I now live in that would be nice to bump a bit.
It is potentially useful data; but the trouble is that detecting 'NSA-like' activity is just plain hard.
A large-scale exploit attempt (while it is something that an intelligence agency might try, under certain circumstances) is really what you'd expect from someone with purely commercial interests: Find a nice bug, try to hit a lot of targets as fast as possible and cash out before the guys playing defense (or your competitors) catch on to the new toy and either the targets start to harden or your competitors start cleaning them out before you can get them.
An intelligence agency, on the other hand, has less use for large numbers of low-value compromises; but likely has a much shorter list of very high value targets that would receive attacks targeted with considerable care and precision and tailored to be minimally intrusive(if the purpose is observation) or maximally damaging(if it's a Stuxnet-style sabotage operation). Such uses would be unlikely to show up in a broad survey of mostly-low-value targets; particularly if the survey requires any cooperation on the part of the site operator, which is more likely in the case of random commercial outfits who depend on security vendors, less likely in the case of paranoid high profile targets.
I'd hate to have one sneak up on me, leaving me mentally incapacitated before I knew what hit me; but I'd say that "enjoy the bodily condition of my early 20s until cognitive indicators start to look worrisome, put affairs in order, administer euthanasia procedure co-developed by veterinary experience and recreational pharmacology enthusiasts" is a strategy that would easily exceed virtually all historical quality-of-life outcomes...
That statement sounds like gutless PR posturing: Obviously you want to learn as much as you can from a failure, especially an unexpected one; and make appropriate modifications based on what you find; but there's a reason why people say mean things about sample sizes of 1. It's entirely possible that you won't be able to nail down exactly why things went wrong in a single unit. Given the continued supply of patients who Will Die, Period, without replacement organs that aren't available, it hardly seems worthwhile to stop just because you lack a perfect determination (so long as you do, of course, make whatever improvements/modifications your imperfect determination suggests are needed).
You aren't going to make progress without experiments, some risky; but you have a population of (adult, of-sound-mind) patients who will definitely die without intervention. You don't want to act in reckless disregard for human life; but when you've got people who will definitely die and the possibility of producing improved treatments, excessive avoidance of uncertainty is disregard for human life. It's a pity that the PR flacks didn't have the guts to say that.
Certainly. If you lack an important organ, even a pretty lousy reproduction looks like a great idea (see also, kidney dialysis, diabetes treatment, etc); but we have a rather long way to go before any transhumanist puffery about 'advantages' becomes justified. Even reaching approximate parity with a normally functioning organ is a pretty heroic challenge. If you don't have one of those, your standards are lower; but you aren't getting an upgrade.
Slashdot Mirror
The Protocol contains a loophole large enough to drive a truck through, never mind some photons:
"Article 3 Blinding as an incidental or collateral effect of the legitimate military employment of laser systems, including laser systems used against optical equipment, is not covered by the prohibition of this Protocol."
As long as the blinding is a side effect (mitigated by "all feasible precautions to avoid the incidence of permanent blindness to unenhanced vision") of a non-blinding purpose(setting things on fire, destroying machine vision/optical sensor gear, 'dazzling', and basically anything else you might feel like using a laser for, it's all legal. That is not exactly fertile ground for any sort of serious arms control, even if lasers weren't comparatively cheap and trivial to build, especially at the modest powers that will really boil your eyeballs but aren't subject to the engineering challenges of aspirational air-defense and antimissile systems.
It gives me no pleasure to say so; blinding is a pretty ugly thing to do; but the Protocol as written is about as effective as forbidding murder; but making it legal to put a bullet through any hat you see, regardless of whether it contains a head or not.
It's also an overcomplicated solution. OBD can get pretty nasty if you want access to esoteric stuff or manufacturer proprietary crap; but a basic, bluetooth-capable, OBD dongle that'll report the rough outlines of how a vehicle is being used is quite cheap indeed and not especially complex. I wouldn't necessarily want to try dead-reconing with nothing but that output; but answering "Am I driving right now?" is considerably less demanding.
It's not really polite to say so that bluntly; but the difference is that measles deaths are basically optional(1st world anti-vaxxers) or just another bad thing that happens to poor people in poor and unpleasant places. By contrast, Ebola is currently just another bad thing that happens to poor people in poor and unpleasant places; but we've got basically nothing available to do about it if it spreads beyond the usual outbreak sites(yes, unlike the usual outbreak sites, we have limited supplies of high grade medical isolation gear and some interesting experimental drugs; but nobody has enough of the cool tech to deal with an outbreak of nontrivial size, especially if they want their medical and logistical systems to continue handling routine functions and care at the same time).
There are loads of places far less poor and squalid than Liberia and the other oubreak sites; but without any good options on the table it wouldn't take long to run through your supply of isolation wards and fancy positive-pressure protective suits even in the most upmarket first world locations with well regarded research hospitals and such, were the population to be affected.
Was she asleep for, oh, the past quarter century? We've put together a neat little system (really an untidy patchwork of them) such that you can't touch something Turing-complete, drive on a substantial percentage of reasonably major roads, or do just about anything involving commerce without it dropping into the gigantic database somewhere and she's freaking out about somebody's little model airplane with a gopro?
It is the case that there are quite a few values of 'somebody' where worrying might be a good idea; but as a relatively petty footnote to the Orwellian world we've already put into operation. Pretending otherwise is clueless at best and actively dishonest at worst.
I can understand the interest in the existence of Eucalyptus itself (it's a more or less interface compatible implementation of a bunch of Amazon's heavily used 'cloud' services that you can run stuff on in house or at a non-Amazon 3rd party). Amazon's pricing is crazy aggressive; but sometimes you need to do things in house, want to do things in house, or want to go mixed-strategy(in-house/Amazon for overflow, spread across more than one 3rd party provider, etc, etc.) and in general it's not a good feeling to have a stack of important stuff dependent on a single vendor.
What I find much harder to understand is what HP gains from this, or what I, the hypothetical customer, as supposed to be willing to pay HP to put its name on here.
Is this just more HP flailing, or is there an angle I'm missing? Are there lots of potential customers who won't touch Amazon (perhaps because they have to keep stuff internal); but won't touch Eucalyptus without some giant company selling them a support agreement? If so, since Amazon is off the table, why would they care about Amazon API compatibility? Who is the target here, and why aren't they either DIYing it, paying Amazon's incredibly aggressive prices for the real thing, or using an architecturally different cloud/VM arrangement?
Unfortunately, while we have the Foreign Corrupt Practices Act, we could really use some work on domestic corrupt practices...
Even if it were perfect, almost no ChromeOS devices have touchscreens and almost all Android devices do (especially if you count on the ones Google even slightly endorses, not the media-player-mystery-HDMI-dongle stuff). For applications that are basically hobbled by the touchscreen, a keyboard and mouse will be an improvement. For those that are enhanced by, or actively dependent on, it, that will be a bit of a mess no matter how perfect the runtime is.
Unless those proportions change fairly markedly, it probably makes sense for them to start with some popular, mouse and keyboard friendly, applications that don't lean on native ARM blobs much or at all.
Don't forget the Khmer Rouge or the Rwandan Akazu: they had less to work with; but killing north of 20% of your country's population really shows a commitment to atrocity.
Sorry, my phrasing was ambiguous: the rPi I/O is 'broken out' in the sense of 'breakout board', it's substantially accessible on reasonably friendly headers that you can connect to without tiny elven soldering fingers or oddball connectors; unlike the (otherwise cheap and quite tempting) 'buy an android mini-stick-thing/used phone with 3rd party firmware support' option, which gets you power, sometimes a screen, and a few peripherals for crazy cheap; but where you'll be lucky to find a handful of undocumented test points, much less any headers.
The chip the rPi is based on really isn't quite right for the job(but feel the price...) so eth isn't so hot; but I've never had any serious issues, assuming an acceptance of the speed limits.
I am genuinely baffled at how the embargo is supposed to support US policy interests(either idealistic, cynical, or both); but alleged damages that high do seem to suggest that the "It's pointless, they'll just trade with the EU and BRIC and things" theory is limited at best. I honestly would have expected a smaller effect myself. I just can't fathom why anyone thinks it's a worthwhile plan.
In all honesty, it's really a testament to Excel's relatively favorable balance of power and ease of use, even non-techies can do some reasonably heavy lifting and more sophisticated users can do some fairly impressive rapid prototyping.
Unfortunately, these sorts of horrors always seem to be the result. What I don't know is how much of the disaster is caused by Excel just not scaling well(which, at least in theory, is something that could be improved) and how much is caused by the fact that non-programmers may be scared away from programming by the stuff that Excel is good at hiding; but still get bitten by the stuff they don't even know is there(which, in fairness to them, is the same stuff that usually bites actual programmers, though less often if they are good ones).
$1.1 billion over 55 years is $20 billion/year, in a country with a GDP of ~$70 billion, so that arguably puts the embargo into the category of 'surprisingly effective; if not exactly at achieving any of the US' alleged objectives'.
When it comes to 'terrorizing and vile violations of human rights', though, that barely registers. Did this guy sleep through the entire 20th century?
I had the displeasure of observing(thankfully, not of being called in to clean up after) some very, very, heavy Excel users who were eventually forced to capitulate and move to something less insane because it was becoming a matter of pure chance whether a multi-day simulation run would cause Excel to exhaust its memory space and fall over(this was maybe a decade before 64 bit x86, much less broad support for it, was a thing, so just throwing money at the problem wasn't an option).
You just buy a WD-authorized helium cartridge... Make sure that it hasn't dried out, and that the activation chip hasn't expired.
That would be interesting to know. Helium is remarkably low-density by the standards of inert gasses(~.18grams/Liter vs. ~.9 for Neon and 1.25 for the ignoble-but-pretty-well-behaved Nitrogen), so it may actually be substantially different from any of the other options.
$6,000? AMD's 64-bit-ARM Opteron A1100 reference board is half as much and (while obviously not very 'embedded') is a rather bigger piece of gear...
It isn't 100% clear: All 'Silvermont' SKUs appear to be 64 bit capable, and this board has a Silvermont-based Atom on it(two of them actually); but Intel's Edison Native Applications Guide definitely appears to be walking you through setting up a build environment for 32 bit x86.
Whether that means that Intel actually lasered support for 64 bit execution off when they were designing this chip(which isn't like most of the other Silvermont devices, which have a GPU and more PC-style I/O, so clearly some cutting was done), or whether it means that they decided to default to 32 bits for everything because the device only has 1GB of RAM soldered on and no support for more, is not clear from anything I've been able to find.
TFS is simply incorrect; but may have been confused by Intel's "Galileo" board, which is based on Quark (at 400MHz). Curiously, 'Galileo' is much more Arduino-esque (a bit more raw punch, weaker hard-real-time bitbang); but also has a full PCIe lane(brought out on a miniPCIe connector) and 100Mb ethernet(optional PoE in Gen2); but no RF.
The much more PC-like, or at least BB Black/rPi-like Edison has a substantially punchier CPU; but no PCIe, wired ethernet, and includes wifi and BT.
I'm not sure if we are misjudging intel through the lens of existing products, or if Intel can't quite decide what niche to hit; but I find this mix a trifle confusing personally...
The teeny little one has the high powered CPU (relatively speaking); but not the high speed expansion bus or wired networking and PoE options. The relatively big one has high speed expansion (but severely limited GPIO, making compatibility with MCU projects that depend on bitbanging rather tepid); but the weak CPU and limited RAM.
I'm interested, and it's always worth keeping an eye on Intel; but I'm a bit confused about what they are aiming at here.
I'm definitely open to suggestions if you have any cool ones to point me to; but I've had some fairly unpleasant experiences with a lot of the theoretically-capable-and-crazy-cheap 'android stick' type sticks and boards. The rPi is indeed quite feeble; but what I/O it has is actually mostly broken out, and (while not exactly FSF-level 'open') is crazy open by the standards of something broadcom based, and enjoys a very strong community of people who can answer questions about any obscure points.
The beaglebone black is a bit more expensive and supply-challenged; but has nicer networking, a bit more punch, ans the SPUs.
Do you know of some things that exploit the various unbelievably cheap smartphone parts; but don't require a working knowledge of chinese datasheets, or have absolutely all signals but HDMI exposed in lilliputan test points? I imagine that there are some; but the couple of times I've dived in without too much research I've ended up with something that...mostly...runs the included Android-build-of-mystery; but is otherwise effectively unusable.
(There are, of course, some nice options over in router-land, in terms of price and network connectivity, sometimes enough GPIO for light work; but those aren't going to be doing much video anytime soon.)
Intel has the Product Brief up. Unless they specifically decided to hide the fact (which would seem unlikely), video appears to be absent.
Wireless connectivity looks pretty nice (wifi and bluetooth out of the box, though BTLE is mysteriously 'in Q4-14', which makes one wonder if perhaps the driver situation has a few grim little stories that we should know about...) and the inclusion of both 2x Atom cores at 500MHz and 1x Quark core at 100MHz is potentially interesting, depending on how easily and elegantly the Atom and Quark 'sides' of the device can talk to one another and either share control of, or at least transfer control of, the various I/O lines.
Not going to shove the rPi out of the way for video-pushing applications, and I suspect that PWM and bitbang-heavy applications may still be underimpressed by Intel compared to the classic microcontroller options; but it could certainly be a contender for a lot of the 'arduino-connected-to-the-network' applications which don't lean too hard on squeezing every last drop out of bare-metal-MCU work; but which could really use a bit more punch on the networking and storage/logging side.
Certainly nothing obvious comes to mind, in terms of features.
The only class of complaint that would be nice to see addressed (not exclusive to the heart, also covers skeletal muscle, bone density, tissue healing, and assorted metabolic processes) is that most of the parameters are still tuned for a relatively high-exertion, high-risk, environment with a strong risk of at least occasional malnutrition. As your basic first-world 'press buttons at work, hired because he knows what buttons to press' type, I can afford plenty of calories and adequate supportive care if injured. Since that's the case, storing spare energy on my waistline is largely unappreciated, maintaining muscles at relatively feeble standby states, rather than defaulting to growing them for when I do have use for them, and prioritizing speedy; but scar-prone, healing over slower but more elegant regeneration are all kind of annoying.
In the same boat; but more of an issue for women, is calcium handling: bioavailable calcium is cheap as dirt these days; but we still suffer skeletal embrittlement over time.
I can't think of any big, dramatic, neat features, just a variety of optimizations that were adaptive under a somewhat different environment than the one I now live in that would be nice to bump a bit.
It is potentially useful data; but the trouble is that detecting 'NSA-like' activity is just plain hard.
A large-scale exploit attempt (while it is something that an intelligence agency might try, under certain circumstances) is really what you'd expect from someone with purely commercial interests: Find a nice bug, try to hit a lot of targets as fast as possible and cash out before the guys playing defense (or your competitors) catch on to the new toy and either the targets start to harden or your competitors start cleaning them out before you can get them.
An intelligence agency, on the other hand, has less use for large numbers of low-value compromises; but likely has a much shorter list of very high value targets that would receive attacks targeted with considerable care and precision and tailored to be minimally intrusive(if the purpose is observation) or maximally damaging(if it's a Stuxnet-style sabotage operation). Such uses would be unlikely to show up in a broad survey of mostly-low-value targets; particularly if the survey requires any cooperation on the part of the site operator, which is more likely in the case of random commercial outfits who depend on security vendors, less likely in the case of paranoid high profile targets.
I'd hate to have one sneak up on me, leaving me mentally incapacitated before I knew what hit me; but I'd say that "enjoy the bodily condition of my early 20s until cognitive indicators start to look worrisome, put affairs in order, administer euthanasia procedure co-developed by veterinary experience and recreational pharmacology enthusiasts" is a strategy that would easily exceed virtually all historical quality-of-life outcomes...
That statement sounds like gutless PR posturing: Obviously you want to learn as much as you can from a failure, especially an unexpected one; and make appropriate modifications based on what you find; but there's a reason why people say mean things about sample sizes of 1. It's entirely possible that you won't be able to nail down exactly why things went wrong in a single unit. Given the continued supply of patients who Will Die, Period, without replacement organs that aren't available, it hardly seems worthwhile to stop just because you lack a perfect determination (so long as you do, of course, make whatever improvements/modifications your imperfect determination suggests are needed).
You aren't going to make progress without experiments, some risky; but you have a population of (adult, of-sound-mind) patients who will definitely die without intervention. You don't want to act in reckless disregard for human life; but when you've got people who will definitely die and the possibility of producing improved treatments, excessive avoidance of uncertainty is disregard for human life. It's a pity that the PR flacks didn't have the guts to say that.
Certainly. If you lack an important organ, even a pretty lousy reproduction looks like a great idea (see also, kidney dialysis, diabetes treatment, etc); but we have a rather long way to go before any transhumanist puffery about 'advantages' becomes justified. Even reaching approximate parity with a normally functioning organ is a pretty heroic challenge. If you don't have one of those, your standards are lower; but you aren't getting an upgrade.