I'm assuming that the eventual plan will involve some sort of distillation or RO process: 55,000 tons of water is not something you would want to have to safely entomb somewhere; but the actual volume of long-term nasties must be fairly small(worst case, it could not be greater than the volume of the fuel on site, and any materials that it has been in long term contact with for a sufficient time to render them radioactive, and it doesn't appear to be worst case).
While not terribly cheap, the technology for separating dissolved compounds from water(to fairly extreme degrees of purity, in the case of water for lab/analytic use) is very much off-the-shelf. Similarly, gross screening of a volume of treated water for radioactives should be doable with a Geiger counter, and fine screening should be within the realm of any decently equipped testing laboratory.
It isn't going to be cheap, and the end result will be a small pile of serious unpleasantness and a rather larger one of equipment that isn't worth decontaminating; but it doesn't seem like a fundamentally hard problem.
I suspect that you would run into two major problems:
1. That volume of water is massive and lifting mass out of our gravity well is damn pricy. You could probably give it a funeral sarcophagus shielded with several centimeters of gold for corrosion-resistant radiation absorption for the same money.
2. Heavy launch is not an entirely safe procedure. From time to time, something breaks and the cargo ends up burning up in the atmosphere. If the cargo is deliciously radioactive, that would be an issue. (and, if it isn't, a teakettle is a much cheaper way of dispersing it into the atmosphere...)
Given that the military has successfully gotten away with "stop loss"-ing a fair number of its people, sometimes repeatedly, I get the sense that they enjoy somewhat looser restrictions than do civilian contract-makers. How loose, I don't know.
I'm certainly not up on US military case law, and won't pretend to be; but my suspicion(based on the number of historical situations where an army finds itself cut off/out of supply/attached to a tottering government/etc/etc.) would be that the rules(which tend to be made pragmatically to suit those making them) would be that logistical disruptions believed to be temporary would not be considered sufficient grounds to dissolve the obligations of the troops. In practice, of course, if the situation is bad enough, nobody can enforce the rules, so everybody just says 'the hell with it' and leaves; but that isn't supposed to happen.
It would be very interesting to see what would happen to somebody who did just leave, and then litigated the matter; but I suspect that as long as the existing logistical services, and some sort of IOUs, continue to be distributed, leaving will be Frowned Upon.
This is Symbian we are talking about. Not interesting enough to stir nerd rage; but not dead enough to stir nerd nostalgia. Try back in a decade, maybe, and there might be a tiny group of hardcore Symbian retrophone enthusiasts, like the Amiga guys, pulling impressive but irrelevant stunts to keep their favorite OS running on available hardware....
In this case, it's kind of hard to see Symbian's brief flirtation with openness as a major loss; but it has always interested me that the OpenBSD guys, whose work lacks the legal terms in favor of remaining open that the GPLed Linux team has, are nevertheless some of the most consistent supporters of fully-open systems outside of the core FSF people.
It's Nokia's code, and they can do what they want; but it is rather hard to see this as anything other than the spasmodic flailing of a dying platform, rather reminiscent of the bipolar behavior Sun was exhibiting shortly before their demise(only more serious, since the odds of Symbian related techologies being installed by the end user on a phone sold as non-Symbian are basically zero, while absolute fuckloads of non-Sun servers and desktops end up running JVMs...)
"but a 3rd party build of Android is pretty much the only one where this would ever see the light of day"
I don't think for a second that our Google overlords would touch this idea with a ten foot pole(unless they adopted some variant of the data URI namespacing to add features that corporate customers wanted, to compete with the full hardware-virtualization stuff that Vmware is proposing, and only for that purpose).
Android, though, is the only current candidate where a reasonable percentage of mass-market hardware is within the realm of practical 3rd-party OS builds. A fair number of phone models are well understood enough to replace more or less everything above the bootloader, and enough of the Android sauce is OSS that modifications to it can reasonably be made. Were this to occur, it would be a 3rd party thing only, Google would have no incentive to either hamper its own advertising efforts or scare developers away.
Just for the sake of clarity, having thought about it a bit more(post in haste, repent at leisure...), what I'm proposing would, basically, be a sort of "data chroot".
There would be the host android system, with one or more optional "data chroot" containers underneath. For the convenience of the host system, each would simply be a 'subdomain' of the primary URIs; but(as with a chroot for filesystems) programs within the chroot would see the data URIs exposed to it as originating from the root URI.
All "data chroot"s would have the full set of standard data URIs(along with any provided by applications installed within them); but those standard data URIs would be derived from the real data URIs by a set of filters specific to that "chroot". Some would be passed straight through, if the applications inside are trusted with it, some would be programmatically modified(as in the accuracy-reduction of location data) and some would ignore the root URI entirely and fabricate a fake one with no relation to the real one(as with a false set of contacts).
When an application is installed, and asks for access to a specific set of permissions, you could either grant them, or grant them within the context of a "chroot" in order to control the application's access to real data.
Conceivably, other sorts of system resources that are amenable to a 'filter' model could also be thus controlled(a given "chroot" might have an IPtables config associated with it, for example, that would impose additional restrictions on any application within the "chroot" that is given network access.)
Obviously, the configuration of such things would be pretty hairy for an average user; but it would hardly be inconcievable to have installable 'filter bundles' that could be snapped in to the system, and then used to spawn new "chroot" instances easily. As with firefox extensions or greasemonkey scripts, some would be fairly generic(say, one that simply spawns an empty set of data providers, with no other restrictions, that would allow you to easily create a 'home' and a 'work' container with distinct contacts and such), others would be fairly tightly tailored to specific use cases(an obfuscation container for some particularly grabby app, say).
Arguably, their management team should be given a life-sentence of manually deleting penis-pill spam using the 'Incredimail' client on a virus-riddled WinME box with inadequate RAM and AOL dialup.
The rest of the company can be sold for scrap, and their mailing lists tossed into the nearest smelter.
Only the mobile phone carriers should be allowed to collect large, but unknown, piles of personal information silently and without oversight! It is an outrage that others would dare to step onto the rightful domain of these oh-so-helpful surveillance buddies.
On a more serious note: What I would really like to see in Android(and other mobile operating systems; but a 3rd party build of Android is pretty much the only one where this would ever see the light of day on any hardware that isn't a laptop-size dev board...) is a supplement to the existing system of granular access-request application permissions:
Spoofing.
At present, you can see what permissions an application demands(perhaps not at quite the level of granularity that would be ideal; but the concept is good, and refinements aren't fundamentally challenging); but you have no way of pushing back against an application that seems a bit uppity, other than refusing it. What would be ideal would be a way of setting up multiple instances of the various Android content providers. One set of instances would be the 'real' one, populated with actual system data(address book, location, etc, etc.) Other instances would be various flavors of 'fake', either generated by applying an overlay filter to the real ones(ie. I might want to give an application that uses location data access to 'location data, but truncated to ~city level accuracy', which would be a content provider generated by a simple mathematical operation against the genuine content provider for location data), or auto-generated to look plausible; but be completely unrelated to the truth(ie. an 'address book' consisting of a simple dump of 47 name/number pairs from a phone book). This would allow you to push back against applications that demand more than they need to know; by allowing you to fulfil their architectural 'requirements'; but choose for yourself which are actually necessary for what you want to do(if you want a navigation app to work, you do need to give it your real location. If you just want dining recommendations, you may only feel the need to give it city-level accuracy, and feel no need whatsoever to give over your real address book for 'social dining integration'...)
Such a system would have additional benefits: it would make tasks like separating work/personal(or personal/er... 'extracurricular' if that is your style) architecturally clean and much lighter-weight than virtualization. You could have multiple true address books, say, one accurately reporting your personal contacts, and one accurately reporting your work contacts, and you could point twitfrienddroidfeed at the first and seriouscorporatemail at the second.
It would certainly be political suicide, unless carefully phrased(you can do a lot of crazy stuff to the troops in the name of supporting them, if your spin-fu is good); but, arguably, not paying the civilians might actually present more of a practical problem.
The more heavily active-duty a soldier is, the greater the degree, and likelihood, that some or all of his basic logistical necessities(food, housing, some degree of medical care) will be being taken care of by Uncle Sam. They might not like not being paid; but they won't be starving in the street(and, because it's the military, just leaving qualifies as desertion...)
Civilian employees, by contrast, with a few possible exceptions in isolated bases or research facilities or the like, are generally only seeing wages+benefits, and are responsible for turning those into food, housing, etc. on the local market. You won't have to go too far down the pay grade before you start running into civilian employees who are not too many weeks away from being unable to make minor little payments like 'rent' and 'groceries'. Quitting wouldn't necessarily be a good career move; but it isn't something their employer can do anything about, and they won't have much of a choice about at least moonlighting elsewhere, if not quitting entirely and job-hunting, if they can't keep food on the table.
Nintendo has a platform that would, arguably, be the most amenable to the efforts of indie and small-time dev outfits: Cheap hardware, fairly wide install base(including unconventional customers), an imperfect; but highly interesting, control model, and spec limitations that keep competition from the zOMG 1080P!!! AAA Shooter 2011 100million+ blockbuster titles to a comparative minimum...
On the other hand, Nintendo are control freaks, with among the strongest 1st-party skew of any of the consoles, and what seems to be a cultural/structural distaste for dealing with small-time developers. Frankly, this seems like an unfortunate thing for them(and for their hypothetical customers). Given all the crazy stuff that wiimote hackers have managed on the PC, and the huge success of 'casual' games, it would seem to me that Nintendo could make a killing(albeit a nickel and a dime at a time) just by providing a good-enough console that makes connecting to a TV to play casual games easy, and also has a stable of really out-there indie stuff that takes advantage of its unique input devices. Given that they have, by all reports, been selling Wiis at a profit from day one, their cost-reduced rev.N models could end up being damn cheap, very quiet, broadly accessible.
It is ironic that Microsoft, who is much better suited to conventional '1st and blessed BFF 3rd party AAA titles with giant budgets' model of console development, is a fair way ahead of Nintendo in terms of support for the little guys(like Apple's iDevice ecosystem, it ain't free as in freedom, or as in beer; but it is fairly cheap and fairly broadly accessible).
I'm not sure that Nintendo has any real hope of turning around an institutional/cultural mindset(as well as doing the nontrivial legwork on things like dev tools and online distribution mechanisms) in time; but it does seem like a missed opportunity...
Clearly, a TV is anything that we believe that we have licenced you to display our precious, precious 'premium content' on. We would be happy to adjust the number of TVs, for a price.
I assume that they crawled the web, looking for https:/// addresses and then scraped the information from those, since a given host attempting an SSL session will present the details of its cert and who signed it.
For their big-map-o'-CAs, it looks like the information you would need would be within available browsers, which by necessity come with a list of CAs that they trust, possibly with a bit of legwork to see if there are subordinate CAs involved...
"For the technical research community, our source code as well as a MySQL database dump (August 2010 MySQL dump), the raw data (August 2010 raw data), and the August 2010 CSV database dump are available. You can also use the Observatory in an Amazon EC2 instance we created."
Obviously, the notion that CAs are fundamentally broken, dubiously competent, and somewhat parasitic is bad for business and therefore can be rejected out of hand.
Therefore, I propose the following: All browsers shall be required to stop trusting those inexpensive standard SSL certs, as well as certs issued by budget CAs. 'Extended Validation' certs will now be baseline, with prices remaining unchanged, and two new levels of verification will be added:
'Extended Validation: Pinky Swear!'(indicated by a green background with two interlocking pinky fingers) will have the same standards as 'EV'; but with the additional promise that we had the work experience kid, or a script, whichever is cheaper, check that the certificate request wasn't made from a hotmail account.
'Double-Secret Extended Validation'(icon TBA, pending negotiations with film rightsholders) is so secure that we can't even tell you the process by which we verify applications; but it is super secure.
Frankly, I've dealt with a fair number of cellphone interfaces where being able to write a quick wrapper script that takes a contact name, greps through the contact file, and dumps the AT commands directly to/dev/ttyS0 would have been a fucking miracle compared to the provided system...
Just as computer scientists prefer to start lists at 0, we have a substantial crop of citizens who prefer to start constitutional amendments at 2.
The surprise, in that case, is that they found somebody who thinks that Matthew 5:9 refers to SWAT teams in armored vehicles(and who manages to state, with a straight face, that a vehicle equipped to fire.50 BMG is even remotely compatible with public safety in one of South Carolina's more heavily populated counties... I'm pretty sure that each round comes straight from the factory with an "I don't brake for drywall, or cinderblock, or entire wood-frame houses" bumper sticker.)
I suspect that slightly more would be required for good results; but I do have to wonder how this new toy is different from the optical gaze-tracking technologies that have been around for at least a couple of decades now...
The US would have to pick an enemy who can afford robots in the first place. Bombing backward civilisations is so much more fun, though.
Radically low-tech enemies are actually a huge mess to deal with. There is sort of a bell-shaped-curve if you consider the opponent's level of technological power to be the X axis, and the ease of dealing with them to be the Y:
On the extreme right of the curve, you have technologically superior enemies. You can't win, you can only hope to make a nuisance of yourself and hope that their tolerance for casualties is several orders of magnitude lower than yours. On the extreme left of the curve, you have radically technologically inferior enemies. They can still inflict casualties, because booby traps and small arms absolutely saturate the world market, and will kill your fancy superior forces just fine; but they tend to have relatively few good targets. No big command and control structures or vital infrastructure facilities or seats of government that you can just raise a flag over and expect the existing governmental apparatus to fall into line behind(because there often isn't one, or it is a fragmented mess eve when you aren't there).
The best ones are right in the middle: Developed enough to have centralized infrastructure, governmental and other organizational systems that can be decapitated and then reused, and wealthy enough that they've been trying to build up conventional armored forces and aircraft and the like, rather than irregular guerrillas. Poor enough, on the other hand, that all their armor and aircraft are substantially inferior to yours, and their regular troops are questionably trained conscripts with a very limited interest in getting slaughtered. Compared to the prospect of driving around in circles, eating IEDs, while looking for something worth capturing, blowing your way through a force of hopelessly inferior eastern-bloc rustboxes on your way to the capital is downright idyllic...
My point was that BT HID peripherals are cheap. Way, way, cheaper than the full-featured PDA-with-volume-control ones(which are justifiably expensive, given their spec). The BOM to implement IR output is also quite small(as is the one for input)
My surprise is that, as best I can tell, there isn't a class of remotes that puts these facts together, along with the low cost of microcontrollers with just a few extra GPIO pins. You can get BT HID peripherals for cheap, which will generate pretty much all the keycodes and mouse events that a computer could need; but are in desk-friendly form factors and don't have IR. You can get IR remotes for cheap, which will control home theatre type gear, and have a form factor suitable for couch use; but tend to be either clunky(with 3rd party IR receivers and some configuration) or useless for PCs. What you can't seem to get are BT HID peripherals, in couch-friendly sizes, with just a couple extra GPIO lines driving an IR unit, and a simple code programming interface over the BT HID connection. No fancy screen, no 800MHz ARM core, no WiFi, no App support, just a boring bluetooth peripheral that can also generate IR control output.
It is always a bit surprising how expensive and/or limited remotes have continued to be. The hardware for implementing IRDA (at least when purchased in USB dongle form) costs peanuts(and, while ordinary remote control IR is somewhat different in operation, it has fairly similar part count and less demanding data rates, plus much higher volume, so it could hardly cost more) on the PC side, BT HID peripherals start fairly cheap as well, and have fairly standard support in most OSes for all normal keycodes, some extended multimedia ones, as well as mouse position and button state information. Ample.
The only real complication would be dealing with the assorted wacky IR codes used by random consumer electronics. Even there, though, an IR receiver for 'learning' or a small abuse of the HID spec for allowing a utility program to download premade device control sets would be neither difficult nor expensive.
And yet, we still have just a few classes of remote: the 'free in the box, impossible to obtain a replacement' device specific ones, the dollar-store 'universal' ones(universality may vary), the MCE-yes-the-computer-is-MCE-enabled-out-of-the-box-but-it-still-comes-with-this-ghastly-USB-dongle ones(all of which seem to have hit every branch while falling out of the ugly tree), or the extremely expensive basically-an-entire-PDA fully programmable universal ones.
Where exactly one wants to draw the line between "tool" and "robot" is arguably somewhat arbitrary; but there are definite matters of degree and substantial complexities.
For instance, a simple mine is actually 'autonomous'. It has very limited capabilities; but it exercises those entirely without human intervention, based on sensor data. In both land and naval use, the Chinese were putzing around with recognizable antecedents of those not long after they acquired gunpowder, and various European tinkerers not too long after. Does the use of mines count as "robotic warfare"? Some of the more sophisticated modern examples are just as autonomous and have greater capabilities: a CAPTOR mine has enough onboard computing power to distinguish between ships and submarines by sound, and launch its (homing) torpedo at the latter. All fully autonomous, and circa 1979...
On the other hand, a lot of modern combat "robots" are basically very high performance RC vehicles, albeit often with some sophisticated software handling translation of abstract operator commands into robot actions(with Predators, say, you don't 'fly' them the way you fly an RC aircraft for most of their flight time, they handle a lot of the low-level detail to allow operators to focus on waypoints and target acquisition. With the more sophisticated robotic bomb-defusers and their ilk, their fairly complex manipulators handle all the fiddly little servos internally, in order to achieve manipulator commands provided by the operator).
That's the definitionally tricky bit: there are extremely simple devices that are fully autonomous within the limited scope of their capabilities. There are also extremely sophisticated devices, with almost eerily organic levels of feedback-driven 'housekeeping' going on in order to allow the operator to give the device fairly high level commands; but which are specifically designed to do nothing of importance without the OK from a human.
Then you have the ones that can be used either way: Phalanx CIWS can do fully automatic target engagement(because puny meat-objects simply don't have the reflexes for the job) or can be kept under human supervision(because nothing says "expensive accident" like a trigger-happy Gatling-gun robot operating in the vicinity of friendly aircraft...)
As best I can tell, it seems like autonomy is less of a pure design challenge, and more a question of the practical and PR constraints that you have to abide by in terms of target discrimination... Humans are OK at that, which certainly places them above all but reasonably sophisticated automated systems; but they are hardly perfect. How much of the unwillingness to cut the robots loose is due to their inferiority to humans at this task, and how much is due to human distaste for the idea of automated hunter-killer robots is not entirely clear.(Nor is it entirely clear that they aren't being used: The CIA, for instance, loves drone strikes, and doesn't exactly issue press releases about the operator/drone ratio they are using...)
Afghanistan seems like kind of a low bar for the "elevators to combat robots" metric, since it has been a mixture of tribal infighting and superpower proxy wars at least since the British showed up(and had a lousy time... and then the Russians showed up, and had a lousy time... and the Americans showed up...); but it is, nevertheless, something of a dramatic shift.
What I'm not looking forward to is what will happen when(if ever) the demand for military combat robots slackens a bit and the producers thereof start seriously targeting the home market. Through a combination of military contractors trying to avoid being vulnerable to having only a single customer and direct transfers of military hardware from the DoD(you may throw an SSL warning if your browser doesn't trust DoD certs) military hardware generally has a way of coming home. Even random sheriffs are burnishing their toys collection(it's a wayback machine link because, for reasons that are completely inexplicable, the broader response to the 'The Peacemaker' was perhaps less favorable than anticipated...) I know, from observing one of their training exercises, that the supply of m16s maintained by the police force in the unbelievably boring and low crime bedroom community where I work is much higher than I would have expected.
This suggests that it is only a matter of time before we can expect to see surplussed predators and such 'protecting and serving' here at home.
There are the economic advantages that syncrotic mentions(depending on where you are in the market, having to toss the motherboard rather than the CPU may or may not benefit you); but my understanding is that LGAs can achieve higher pin density than PGAs.
AMD actually uses them as well, in their 'Socket F' and later server sockets; but continues to use PGAs for desktop(Socket AM2 is contemporary with Socket F) and any laptops using something larger than the Fusion designs, which are BGAs.
Slashdot Mirror
I'm assuming that the eventual plan will involve some sort of distillation or RO process: 55,000 tons of water is not something you would want to have to safely entomb somewhere; but the actual volume of long-term nasties must be fairly small(worst case, it could not be greater than the volume of the fuel on site, and any materials that it has been in long term contact with for a sufficient time to render them radioactive, and it doesn't appear to be worst case).
While not terribly cheap, the technology for separating dissolved compounds from water(to fairly extreme degrees of purity, in the case of water for lab/analytic use) is very much off-the-shelf. Similarly, gross screening of a volume of treated water for radioactives should be doable with a Geiger counter, and fine screening should be within the realm of any decently equipped testing laboratory.
It isn't going to be cheap, and the end result will be a small pile of serious unpleasantness and a rather larger one of equipment that isn't worth decontaminating; but it doesn't seem like a fundamentally hard problem.
I suspect that you would run into two major problems:
1. That volume of water is massive and lifting mass out of our gravity well is damn pricy. You could probably give it a funeral sarcophagus shielded with several centimeters of gold for corrosion-resistant radiation absorption for the same money.
2. Heavy launch is not an entirely safe procedure. From time to time, something breaks and the cargo ends up burning up in the atmosphere. If the cargo is deliciously radioactive, that would be an issue. (and, if it isn't, a teakettle is a much cheaper way of dispersing it into the atmosphere...)
Given that the military has successfully gotten away with "stop loss"-ing a fair number of its people, sometimes repeatedly, I get the sense that they enjoy somewhat looser restrictions than do civilian contract-makers. How loose, I don't know.
I'm certainly not up on US military case law, and won't pretend to be; but my suspicion(based on the number of historical situations where an army finds itself cut off/out of supply/attached to a tottering government/etc/etc.) would be that the rules(which tend to be made pragmatically to suit those making them) would be that logistical disruptions believed to be temporary would not be considered sufficient grounds to dissolve the obligations of the troops. In practice, of course, if the situation is bad enough, nobody can enforce the rules, so everybody just says 'the hell with it' and leaves; but that isn't supposed to happen.
It would be very interesting to see what would happen to somebody who did just leave, and then litigated the matter; but I suspect that as long as the existing logistical services, and some sort of IOUs, continue to be distributed, leaving will be Frowned Upon.
This is Symbian we are talking about. Not interesting enough to stir nerd rage; but not dead enough to stir nerd nostalgia. Try back in a decade, maybe, and there might be a tiny group of hardcore Symbian retrophone enthusiasts, like the Amiga guys, pulling impressive but irrelevant stunts to keep their favorite OS running on available hardware....
Damn. Beat me to it. OpenVOX.
In this case, it's kind of hard to see Symbian's brief flirtation with openness as a major loss; but it has always interested me that the OpenBSD guys, whose work lacks the legal terms in favor of remaining open that the GPLed Linux team has, are nevertheless some of the most consistent supporters of fully-open systems outside of the core FSF people.
It's Nokia's code, and they can do what they want; but it is rather hard to see this as anything other than the spasmodic flailing of a dying platform, rather reminiscent of the bipolar behavior Sun was exhibiting shortly before their demise(only more serious, since the odds of Symbian related techologies being installed by the end user on a phone sold as non-Symbian are basically zero, while absolute fuckloads of non-Sun servers and desktops end up running JVMs...)
"but a 3rd party build of Android is pretty much the only one where this would ever see the light of day"
I don't think for a second that our Google overlords would touch this idea with a ten foot pole(unless they adopted some variant of the data URI namespacing to add features that corporate customers wanted, to compete with the full hardware-virtualization stuff that Vmware is proposing, and only for that purpose).
Android, though, is the only current candidate where a reasonable percentage of mass-market hardware is within the realm of practical 3rd-party OS builds. A fair number of phone models are well understood enough to replace more or less everything above the bootloader, and enough of the Android sauce is OSS that modifications to it can reasonably be made. Were this to occur, it would be a 3rd party thing only, Google would have no incentive to either hamper its own advertising efforts or scare developers away.
Just for the sake of clarity, having thought about it a bit more(post in haste, repent at leisure...), what I'm proposing would, basically, be a sort of "data chroot".
There would be the host android system, with one or more optional "data chroot" containers underneath. For the convenience of the host system, each would simply be a 'subdomain' of the primary URIs; but(as with a chroot for filesystems) programs within the chroot would see the data URIs exposed to it as originating from the root URI.
All "data chroot"s would have the full set of standard data URIs(along with any provided by applications installed within them); but those standard data URIs would be derived from the real data URIs by a set of filters specific to that "chroot". Some would be passed straight through, if the applications inside are trusted with it, some would be programmatically modified(as in the accuracy-reduction of location data) and some would ignore the root URI entirely and fabricate a fake one with no relation to the real one(as with a false set of contacts).
When an application is installed, and asks for access to a specific set of permissions, you could either grant them, or grant them within the context of a "chroot" in order to control the application's access to real data.
Conceivably, other sorts of system resources that are amenable to a 'filter' model could also be thus controlled(a given "chroot" might have an IPtables config associated with it, for example, that would impose additional restrictions on any application within the "chroot" that is given network access.)
Obviously, the configuration of such things would be pretty hairy for an average user; but it would hardly be inconcievable to have installable 'filter bundles' that could be snapped in to the system, and then used to spawn new "chroot" instances easily. As with firefox extensions or greasemonkey scripts, some would be fairly generic(say, one that simply spawns an empty set of data providers, with no other restrictions, that would allow you to easily create a 'home' and a 'work' container with distinct contacts and such), others would be fairly tightly tailored to specific use cases(an obfuscation container for some particularly grabby app, say).
Arguably, their management team should be given a life-sentence of manually deleting penis-pill spam using the 'Incredimail' client on a virus-riddled WinME box with inadequate RAM and AOL dialup.
The rest of the company can be sold for scrap, and their mailing lists tossed into the nearest smelter.
Only the mobile phone carriers should be allowed to collect large, but unknown, piles of personal information silently and without oversight! It is an outrage that others would dare to step onto the rightful domain of these oh-so-helpful surveillance buddies.
On a more serious note: What I would really like to see in Android(and other mobile operating systems; but a 3rd party build of Android is pretty much the only one where this would ever see the light of day on any hardware that isn't a laptop-size dev board...) is a supplement to the existing system of granular access-request application permissions:
Spoofing.
At present, you can see what permissions an application demands(perhaps not at quite the level of granularity that would be ideal; but the concept is good, and refinements aren't fundamentally challenging); but you have no way of pushing back against an application that seems a bit uppity, other than refusing it. What would be ideal would be a way of setting up multiple instances of the various Android content providers. One set of instances would be the 'real' one, populated with actual system data(address book, location, etc, etc.) Other instances would be various flavors of 'fake', either generated by applying an overlay filter to the real ones(ie. I might want to give an application that uses location data access to 'location data, but truncated to ~city level accuracy', which would be a content provider generated by a simple mathematical operation against the genuine content provider for location data), or auto-generated to look plausible; but be completely unrelated to the truth(ie. an 'address book' consisting of a simple dump of 47 name/number pairs from a phone book). This would allow you to push back against applications that demand more than they need to know; by allowing you to fulfil their architectural 'requirements'; but choose for yourself which are actually necessary for what you want to do(if you want a navigation app to work, you do need to give it your real location. If you just want dining recommendations, you may only feel the need to give it city-level accuracy, and feel no need whatsoever to give over your real address book for 'social dining integration'...)
Such a system would have additional benefits: it would make tasks like separating work/personal(or personal/er... 'extracurricular' if that is your style) architecturally clean and much lighter-weight than virtualization. You could have multiple true address books, say, one accurately reporting your personal contacts, and one accurately reporting your work contacts, and you could point twitfrienddroidfeed at the first and seriouscorporatemail at the second.
It would certainly be political suicide, unless carefully phrased(you can do a lot of crazy stuff to the troops in the name of supporting them, if your spin-fu is good); but, arguably, not paying the civilians might actually present more of a practical problem.
The more heavily active-duty a soldier is, the greater the degree, and likelihood, that some or all of his basic logistical necessities(food, housing, some degree of medical care) will be being taken care of by Uncle Sam. They might not like not being paid; but they won't be starving in the street(and, because it's the military, just leaving qualifies as desertion...)
Civilian employees, by contrast, with a few possible exceptions in isolated bases or research facilities or the like, are generally only seeing wages+benefits, and are responsible for turning those into food, housing, etc. on the local market. You won't have to go too far down the pay grade before you start running into civilian employees who are not too many weeks away from being unable to make minor little payments like 'rent' and 'groceries'. Quitting wouldn't necessarily be a good career move; but it isn't something their employer can do anything about, and they won't have much of a choice about at least moonlighting elsewhere, if not quitting entirely and job-hunting, if they can't keep food on the table.
It's ironic, really:
Nintendo has a platform that would, arguably, be the most amenable to the efforts of indie and small-time dev outfits: Cheap hardware, fairly wide install base(including unconventional customers), an imperfect; but highly interesting, control model, and spec limitations that keep competition from the zOMG 1080P!!! AAA Shooter 2011 100million+ blockbuster titles to a comparative minimum...
On the other hand, Nintendo are control freaks, with among the strongest 1st-party skew of any of the consoles, and what seems to be a cultural/structural distaste for dealing with small-time developers. Frankly, this seems like an unfortunate thing for them(and for their hypothetical customers). Given all the crazy stuff that wiimote hackers have managed on the PC, and the huge success of 'casual' games, it would seem to me that Nintendo could make a killing(albeit a nickel and a dime at a time) just by providing a good-enough console that makes connecting to a TV to play casual games easy, and also has a stable of really out-there indie stuff that takes advantage of its unique input devices. Given that they have, by all reports, been selling Wiis at a profit from day one, their cost-reduced rev.N models could end up being damn cheap, very quiet, broadly accessible.
It is ironic that Microsoft, who is much better suited to conventional '1st and blessed BFF 3rd party AAA titles with giant budgets' model of console development, is a fair way ahead of Nintendo in terms of support for the little guys(like Apple's iDevice ecosystem, it ain't free as in freedom, or as in beer; but it is fairly cheap and fairly broadly accessible).
I'm not sure that Nintendo has any real hope of turning around an institutional/cultural mindset(as well as doing the nontrivial legwork on things like dev tools and online distribution mechanisms) in time; but it does seem like a missed opportunity...
Clearly, a TV is anything that we believe that we have licenced you to display our precious, precious 'premium content' on. We would be happy to adjust the number of TVs, for a price.
I assume that they crawled the web, looking for https:/// addresses and then scraped the information from those, since a given host attempting an SSL session will present the details of its cert and who signed it.
For their big-map-o'-CAs, it looks like the information you would need would be within available browsers, which by necessity come with a list of CAs that they trust, possibly with a bit of legwork to see if there are subordinate CAs involved...
"For the technical research community, our source code as well as a MySQL database dump (August 2010 MySQL dump), the raw data (August 2010 raw data), and the August 2010 CSV database dump are available. You can also use the Observatory in an Amazon EC2 instance we created."
From the main page...
Obviously, the notion that CAs are fundamentally broken, dubiously competent, and somewhat parasitic is bad for business and therefore can be rejected out of hand.
Therefore, I propose the following: All browsers shall be required to stop trusting those inexpensive standard SSL certs, as well as certs issued by budget CAs. 'Extended Validation' certs will now be baseline, with prices remaining unchanged, and two new levels of verification will be added:
'Extended Validation: Pinky Swear!'(indicated by a green background with two interlocking pinky fingers) will have the same standards as 'EV'; but with the additional promise that we had the work experience kid, or a script, whichever is cheaper, check that the certificate request wasn't made from a hotmail account.
'Double-Secret Extended Validation'(icon TBA, pending negotiations with film rightsholders) is so secure that we can't even tell you the process by which we verify applications; but it is super secure.
This should solve all CA related trust issues.
Frankly, I've dealt with a fair number of cellphone interfaces where being able to write a quick wrapper script that takes a contact name, greps through the contact file, and dumps the AT commands directly to /dev/ttyS0 would have been a fucking miracle compared to the provided system...
Just as computer scientists prefer to start lists at 0, we have a substantial crop of citizens who prefer to start constitutional amendments at 2.
.50 BMG is even remotely compatible with public safety in one of South Carolina's more heavily populated counties... I'm pretty sure that each round comes straight from the factory with an "I don't brake for drywall, or cinderblock, or entire wood-frame houses" bumper sticker.)
The surprise, in that case, is that they found somebody who thinks that Matthew 5:9 refers to SWAT teams in armored vehicles(and who manages to state, with a straight face, that a vehicle equipped to fire
I suspect that slightly more would be required for good results; but I do have to wonder how this new toy is different from the optical gaze-tracking technologies that have been around for at least a couple of decades now...
The US would have to pick an enemy who can afford robots in the first place. Bombing backward civilisations is so much more fun, though.
Radically low-tech enemies are actually a huge mess to deal with. There is sort of a bell-shaped-curve if you consider the opponent's level of technological power to be the X axis, and the ease of dealing with them to be the Y:
On the extreme right of the curve, you have technologically superior enemies. You can't win, you can only hope to make a nuisance of yourself and hope that their tolerance for casualties is several orders of magnitude lower than yours. On the extreme left of the curve, you have radically technologically inferior enemies. They can still inflict casualties, because booby traps and small arms absolutely saturate the world market, and will kill your fancy superior forces just fine; but they tend to have relatively few good targets. No big command and control structures or vital infrastructure facilities or seats of government that you can just raise a flag over and expect the existing governmental apparatus to fall into line behind(because there often isn't one, or it is a fragmented mess eve when you aren't there).
The best ones are right in the middle: Developed enough to have centralized infrastructure, governmental and other organizational systems that can be decapitated and then reused, and wealthy enough that they've been trying to build up conventional armored forces and aircraft and the like, rather than irregular guerrillas. Poor enough, on the other hand, that all their armor and aircraft are substantially inferior to yours, and their regular troops are questionably trained conscripts with a very limited interest in getting slaughtered. Compared to the prospect of driving around in circles, eating IEDs, while looking for something worth capturing, blowing your way through a force of hopelessly inferior eastern-bloc rustboxes on your way to the capital is downright idyllic...
Almost exactly the contrary, in fact.
My point was that BT HID peripherals are cheap. Way, way, cheaper than the full-featured PDA-with-volume-control ones(which are justifiably expensive, given their spec). The BOM to implement IR output is also quite small(as is the one for input)
My surprise is that, as best I can tell, there isn't a class of remotes that puts these facts together, along with the low cost of microcontrollers with just a few extra GPIO pins. You can get BT HID peripherals for cheap, which will generate pretty much all the keycodes and mouse events that a computer could need; but are in desk-friendly form factors and don't have IR. You can get IR remotes for cheap, which will control home theatre type gear, and have a form factor suitable for couch use; but tend to be either clunky(with 3rd party IR receivers and some configuration) or useless for PCs. What you can't seem to get are BT HID peripherals, in couch-friendly sizes, with just a couple extra GPIO lines driving an IR unit, and a simple code programming interface over the BT HID connection. No fancy screen, no 800MHz ARM core, no WiFi, no App support, just a boring bluetooth peripheral that can also generate IR control output.
It is always a bit surprising how expensive and/or limited remotes have continued to be. The hardware for implementing IRDA (at least when purchased in USB dongle form) costs peanuts(and, while ordinary remote control IR is somewhat different in operation, it has fairly similar part count and less demanding data rates, plus much higher volume, so it could hardly cost more) on the PC side, BT HID peripherals start fairly cheap as well, and have fairly standard support in most OSes for all normal keycodes, some extended multimedia ones, as well as mouse position and button state information. Ample.
The only real complication would be dealing with the assorted wacky IR codes used by random consumer electronics. Even there, though, an IR receiver for 'learning' or a small abuse of the HID spec for allowing a utility program to download premade device control sets would be neither difficult nor expensive.
And yet, we still have just a few classes of remote: the 'free in the box, impossible to obtain a replacement' device specific ones, the dollar-store 'universal' ones(universality may vary), the MCE-yes-the-computer-is-MCE-enabled-out-of-the-box-but-it-still-comes-with-this-ghastly-USB-dongle ones(all of which seem to have hit every branch while falling out of the ugly tree), or the extremely expensive basically-an-entire-PDA fully programmable universal ones.
Where exactly one wants to draw the line between "tool" and "robot" is arguably somewhat arbitrary; but there are definite matters of degree and substantial complexities.
For instance, a simple mine is actually 'autonomous'. It has very limited capabilities; but it exercises those entirely without human intervention, based on sensor data. In both land and naval use, the Chinese were putzing around with recognizable antecedents of those not long after they acquired gunpowder, and various European tinkerers not too long after. Does the use of mines count as "robotic warfare"? Some of the more sophisticated modern examples are just as autonomous and have greater capabilities: a CAPTOR mine has enough onboard computing power to distinguish between ships and submarines by sound, and launch its (homing) torpedo at the latter. All fully autonomous, and circa 1979...
On the other hand, a lot of modern combat "robots" are basically very high performance RC vehicles, albeit often with some sophisticated software handling translation of abstract operator commands into robot actions(with Predators, say, you don't 'fly' them the way you fly an RC aircraft for most of their flight time, they handle a lot of the low-level detail to allow operators to focus on waypoints and target acquisition. With the more sophisticated robotic bomb-defusers and their ilk, their fairly complex manipulators handle all the fiddly little servos internally, in order to achieve manipulator commands provided by the operator).
That's the definitionally tricky bit: there are extremely simple devices that are fully autonomous within the limited scope of their capabilities. There are also extremely sophisticated devices, with almost eerily organic levels of feedback-driven 'housekeeping' going on in order to allow the operator to give the device fairly high level commands; but which are specifically designed to do nothing of importance without the OK from a human.
Then you have the ones that can be used either way: Phalanx CIWS can do fully automatic target engagement(because puny meat-objects simply don't have the reflexes for the job) or can be kept under human supervision(because nothing says "expensive accident" like a trigger-happy Gatling-gun robot operating in the vicinity of friendly aircraft...)
As best I can tell, it seems like autonomy is less of a pure design challenge, and more a question of the practical and PR constraints that you have to abide by in terms of target discrimination... Humans are OK at that, which certainly places them above all but reasonably sophisticated automated systems; but they are hardly perfect. How much of the unwillingness to cut the robots loose is due to their inferiority to humans at this task, and how much is due to human distaste for the idea of automated hunter-killer robots is not entirely clear.(Nor is it entirely clear that they aren't being used: The CIA, for instance, loves drone strikes, and doesn't exactly issue press releases about the operator/drone ratio they are using...)
Afghanistan seems like kind of a low bar for the "elevators to combat robots" metric, since it has been a mixture of tribal infighting and superpower proxy wars at least since the British showed up(and had a lousy time... and then the Russians showed up, and had a lousy time... and the Americans showed up...); but it is, nevertheless, something of a dramatic shift.
What I'm not looking forward to is what will happen when(if ever) the demand for military combat robots slackens a bit and the producers thereof start seriously targeting the home market. Through a combination of military contractors trying to avoid being vulnerable to having only a single customer and direct transfers of military hardware from the DoD(you may throw an SSL warning if your browser doesn't trust DoD certs) military hardware generally has a way of coming home. Even random sheriffs are burnishing their toys collection(it's a wayback machine link because, for reasons that are completely inexplicable, the broader response to the 'The Peacemaker' was perhaps less favorable than anticipated...) I know, from observing one of their training exercises, that the supply of m16s maintained by the police force in the unbelievably boring and low crime bedroom community where I work is much higher than I would have expected.
This suggests that it is only a matter of time before we can expect to see surplussed predators and such 'protecting and serving' here at home.
There are the economic advantages that syncrotic mentions(depending on where you are in the market, having to toss the motherboard rather than the CPU may or may not benefit you); but my understanding is that LGAs can achieve higher pin density than PGAs.
AMD actually uses them as well, in their 'Socket F' and later server sockets; but continues to use PGAs for desktop(Socket AM2 is contemporary with Socket F) and any laptops using something larger than the Fusion designs, which are BGAs.