Arguably, the 'distant' bit would be so overwhelming that it would cancel out the 'swift'...
With the exception of cases involving factions in the same gravity well frying one another's satellites, which would indeed be nice and fast, any sort of conflict(barring technology that brutally violates the presently suspected laws of physics) would likely be a decades-to-generations affair. Within the solar system, most objects of interest are a few light-minutes away from one another, so even combatants using lasers or similar would be deprived of any 'instant hit' weapons. Between solar systems, you would be talking anywhere from 4ish to tens or thousands of years. Anything based on matter(whether projectiles or invasion ships) would of course be slower, probably far slower(although, probably extremely hard to detect for the vast majority of their journey).
What would be very interesting, and give any cryogenically frozen and revived Cold-War game theorists their stab at relevance, would be the implications for diplomacy: Because of the distances involved, conversation of any sort could take decades and would be precisely as fast as the fastest available weapons. There would be the oh, so, very, delightful potential for all sorts of situations where both parties would be left to twiddle their thumbs for years, not knowing whether a friendly greeting or a planet-annihilating x-ray pulse is heading their way, with no way to communicate further(and, even if there were, a beam of light or a kinetic-kill projectile travelling at a modest fraction of the speed of light couldn't be called back once launched).
At modest distances, it'd be lots of probabilistic number crunching trying to put the projectile where you expect the enemy to be(or at least force the enemy to burn mass deviating from their inertial/gravitational trajectory). At longer distances, it would be long periods of adrenalized tedium, sweating bullets and deciding whether to do unto others lest they do unto you without any way of knowing what others are or aren't doing unto you until it is too late...
A driverless vehicle may not injure a human being or, through inaction, allow a human being to come to harm, unless in Reno and with the intent of observing said human's demise.
Nothing can really save your performance numbers once you have to hit the platters, so the question would be not 'does it suck more when it can't work purely in RAM?' but 'How good are the mechanisms available for minimizing(ideally automatically, but at least without too much black magic on the application programmers' parts) the frequency with which your setup ends up needing something that isn't in RAM and being bottlenecked by having to fetch it from disk?'...
The cool thing about having a moral goal is that the harder you push it, the more moral you become... If anything, you even get to blame your opponents for the suffering that you inflict(after all, if it weren't for ruthless narcolumbians and potheads, granny could have her pain pills, never you mind that I'm the one who took them away...)
If the DEA were pursuing a pragmatic objective(or a pragmatic objective that isn't pragmatic exclusively because it's an excellent makework project for cops) they'd have hit the cost/benefit rocks bloody ages ago. Luckily for them, they aren't.
If the product is being sold in the US, at least, there may be quite specific reasons why it is 'homeopathic' and why it is sold as such.
Under the Federal Food, Drug, and Cosmetic Act, which established the FDA and its regulatory authority, Homeopathic drugs are a distinct regulatory class. Further(presumably because so much homeopathy is conducted with concentrations indistinguishable from water) the regulations are significantly looser than for conventional drugs. You have to follow some basic accuracy in labelling stuff, and meet strength and purity standards(though per "Section 211.165 (Testing and release for distribution): In the Federal Register of April 1, 1983 (48 FR 14003), the Agency proposed to amend 21 CFR 211.165 to exempt homeopathic drug products from the requirement for laboratory determination of identity and strength of each active ingredient prior to release for distribution.Pending a final rule on this exemption, this testing requirement will not be enforced for homeopathic drug products." you don't actually have to verify the strength and purity before sale).
For this reason, if you want to sell something that is listed in the Homeopathic Pharmacopeia of the United States and its supplements(there are lots of things listed in here...), at a concentration that can be expressed in one of the traditional homeopathic dilution levels(nX, nD, nC, nM, etc.) you can more or less knock yourself out with only the slightest of scrutiny.
In many cases, this does result in the classic overpriced distilled water scenario. It doesn't take many 1:100 or 1:1000 dilutions before even an analytical chemist with an unlimited budget would despair of determining what you were originally diluting(in the case of things like homeopathic plutonium, this is good.) However, "1X", a fairly stiff 10%, is also a perfectly legitimate homeopathic dilution, albeit not one that true homeopathy enthusiasts would tend to view as potent.
The most notorious case of this being Bad is probably 'Zicam', where intranasal administration of 10% zinc gluconate turned out to occassionally destroy the unlucky user's sense of smell. Oops.
In this case, stripped of the 'homeopathic' wording, the spray looks like a fairly plausible, and likely safe, mixture of dilute capsaicin and Eucalyptol in an isotonic carrier. Sensible enough. Whether the function of the 'homeopathic' label is regulatory exclusively or also for marketing purposes is harder to say; but it may be some of both.
This one is conveniently not-paywalled. Research on how exactly to kill the bastards(at least in environments such as whiny humans where expedients like "fire", "brutal doses of ozone", and similar reliable methods are disallowed) is ongoing; but it is apparently the case that a bacterial biofilm exhibits something approaching multicellular cooperation in surviving antibiotics. You can certainly cull the weak and the surface layer; but some combination of near-dormant sleeper cells and novel multi-cellular resistance mechanisms makes eradicating them very difficult indeed.
Assuming the labeling is following conventions for homeopathic dilution notation, I'm not surprised that that stuff would clear your sinuses good and hard, and not because of my boundless confidence in homeopathy...
A '3x' dilution is three successive 1:10 dilutions of the substance indicated in some neutral solvent. "Capsicum 3x" would be.1% capsaicin. Not exactly riot-cop stuff; but it'll definitely give you a bit of a kick. The unspecificed amount of Eucalyptol will likely get the sinuses cleared out as well...
There is, of course, nothing wrong with using plant-derived compounds that cure what ails you(that and sharp objects were, after all, basically the whole of medicine until the chemists really started to gear up in the late 19th and 20th century...); but the marketing as 'homeopathic' of drugs with concentrations well in the conventionally active range always annoys me.
I'm assuming that, in addition to the general spirit of gung-ho surveillance zeal, they are operating under the wishful assumption that this will give them the capability to act more competently in the case of something like the Mumbai attacks in 2008, which were coordinated in large party by cellphone...
"Moreover Mountain Lion adds a powerful new line of defense against future threats where a malware app is prevented from running even if it is deliberately downloaded to a computer"
While having a mechanism for the OS to check and display the cryptographic signature and signing party on an executable before executing it, the notion that this is 'new' seems to stretch credulity. Most Linux distros have been signing packages since shortly after they stopped supporting vacuum tube based systems, and Windows users have been getting little boxes describing(or freaking out about the lack of) 'Authenticode' signatures on drivers, activex controls, and executables for years now...
There are, undeniably, times when Apple introduces novel things, or non-novel-but-polished-to-an-unprecedented-sheen things; but this would not seem to be one of them...
It arguably goes further than that: Depending on the nature of your practice, you might have patients who are dependent on herd immunity(immunocompromized, vaccine component allergy, etc, etc.) Would a doctor be responsible in keeping people who are voluntary infection risks around the rest of their patients?
If it were merely a matter of not taking good advice, I'd be a trifle ambivalent, certainly legal; but seems a bit tasteless. However, the infection risk makes it more like firing a medical assistant who won't wash their hands: it isn't just their health they are risking...
I would be interested to see the reaction. It is, undeniably, the case that robust access control could be used to fuck with advertisers and 'social' stuff and various 'analytics' spying. However, if presented as an architecture/security proposal, it would basically be a request for a Mandatory Access Control/Role Based Access Control implementation, which sounds a great deal more benign...
With the exception of the 'filter' notion, for programmatically sanitizing certain data for certain application contexts(which is hardly new in the sense that virtually all of modern computing is piles of abstraction layers; but is a little odd in that it would mostly be about culling data based on human relevance), most of what you would want for a 'don't-trust-the-apps' implementation of Android would end up looking very similar to a Mandatory Access Control system, with a dash of Role Based Access Control. Presented in those general terms, it sounds about as much unlike a den of scurrilous hackers and enemies of profit as one might imagine.
I strongly suspect that there could be (quite legitimate) objections on resource use grounds, having an instance of every information provider, for every application, filters chewing away in the background, having to move to an SELinux kernel, iptables crunching a set of firewall rules for every application's tun device, etc, etc. certainly wouldn't do the RAM requirements and batterly life any favors... A usable user interface might well prove difficult or impossible to implement on the phone, and not easy even as a full desktop Android Policy Editor widget(hands up, everyone who enjoys SELinux configuration!), which would be another objection
However, at least in an ideal world, most phones would only realistically have to run a fairly lightweight set of controls, built for the user by somebody who knows how to do that, in order to reap most of the benefit. The more intensive capabilities(yeah, your phone's microsd card probably isn't going to be happy if every app's communication with the internet has its own tcpdump instance and a transparent http proxy with some rewrite rules dumping all communications to mass storage...) could be used in emulators for hunting rogue applications.
The proposal would also have the, presumably attractive to both Google and handset vendors(and cheating spouses! Now have all 'extracurricular' messages programmatically shunted into a private namespace, invisible from the standard system utilities!), advantages of being able to support all sorts of dual and multi use device scenarios without going full hypervisor and paying a tithe to VMware on every handset.
Wow, that was rather more vitriolic than I expected...
Ironically, a slightly more 'neutrally presented' permission and filter based per-app provider namespace security scheme could actually be something of a killer app for Android, as well as a valuable tool for the privacy enthusiasts and database-jammers of the world:
Consider the (vastly common, in my experience) 'dual use device' scenario where a single phone is used for both work and personal business(either a business phone that hasn't been given the lockdown treatment, or a personal phone that somebody has set up activesync on, usually). You want convenient stuff like syncing of the company directory to the phone's contacts to Just Work, so that your worker drones can email and call their cubemates efficiently; but you Do Not Want some idiot installing the SocialTwitFriendst.ir app and having it hoover up your entire directory, along with the sucker's gmail contacts, and sending it to some dodgy startup. Solution? All contacts imported from the company directory get a specific filter flag such that only apps blessed by IT can even tell they are there when they query the 'global' contacts list. Boom. The user can still install apps that demand 'Contacts' access, so IT doesn't have to break their phone; but only blessed apps are allowed to have their provider interface namespaces attached as children to the ones provided by corporate sync. Similar behavior could do things like force certain apps to communicate only through a VPN link, without breaking open internet for the browser, or any number of other scenarios.
With some detailed thought about the architecture(this would, admittedly, have the potential to turn into a hellish spaghetti nightmare if you didn't have a clever designer on board) you could do some really neat role based permissions stuff, allowing multiple security contexts to more or less seamlessly exist on the same device, without leakage, or the rather clunky solution of multiple virtualized Android instances... In addition to the almost-certain-to-piss-off marketers privacy wonk scenarios(which these features would also enable), I can imagine some setups that would make IT types very happy indeed...
Out of curiosity, why was the notion shot down for Cyanogenmod? Was it a resource constraint problem of some sort? The(almost definitely hairy) issue of how to do a permissions UI for such a system, or is there actually support for the scum among the movers in the CM community?
Apparently, in the twisted logic of TSA-land, if the gate-rape extends to a full handjob, and you ejaculate on the TSA goon, you have apparently committed the sexual assault.
One wonders if Lightsquared thought that they had a good chance of pulling this off, either through technological optimism or confidence in their legal team(For whatever reason "Rural broadband!!!" appears to be the FCC's root password) or if this was some sort of long-odds/high-rewards gamble by the hedge fund chap...
On the one hand, being able to convert a swath of satellite-to-ground spectrum into ground-ground spectrum would be crazy valuable, and likely result in some very nice returns. On the other, trying to go up against the now-firmly-entrenched users of GPS(ie. almost everybody) is a risky move indeed.
Did they miscalculate the odds, or were they happy to take very bad odds for the possibility of extremely high returns?
For better or worse, it is generally the case that Legacy Systems Win.
Outside of some limited consumer markets, or the occasional dramatic(and generally traumatic) forklift upgrade of some gigantic institutional system(usually still leaves a screen-scraper connected to the old system that everybody politely doesn't talk about hidden somewhere...), the clout of Stuff That Already Works is enormous compared to that of Stuff that Might Be Cool.
If it were merely a matter of forcing Garmin into a class action and giving all their past customers a shiny nickel to spend on new Garmin products, it might have worked. GPS, though, is firmly embedded in all sorts of slow-turnover, expensive, capital equipment and infrastructure. No way is it getting displaced in the near term...
Always remember to give the officer doing the pat-down your best sex-offender-smirk and remark that you "always stand at attention for a man in uniform"...
The situation is not actually winnable in any useful way; but if the rentacop goes home feeling as though their soul is soiled, you've done your part.
I, for one, am bursting with patriotic confidence! These 'passenger advocates'(likely toiling tirelessly out of a dank basement office hidden behind a filing cabinet and marked 'beware of the leopard') will almost certainly reform the TSA's abusive practices just as 'Internal affairs' units have revolutionized the professionalism of our police forces! Victory! Progress!
What android really needs(and probably won't get, for actively self-interested reasons; but so it goes...) is the ability to lie.
Right now, you can at least see what outrageous demands an application is making; but it's a take-it-or-leave-it thing. You cannot, for instance, specify that an application that wants your contacts list for no reason useful to you installed such that any attempt to access the contacts list returns a false one, rather than the actual system-wide contacts.
It'd likely add some resource overhead; but you could theoretically have a per-app 'virtual' set of android.* interfaces: some could transparently map to the real ones, others could be defined by a filter against the real ones(for network access, a specific set of firewall rules, or android.location interface that is based on the genuine android.location data; but with resolution reduced or a fictitious offset introduced, for instance), and some could be based on pure fictions unrelated to the real interface.
The ability to lie would allow you to push back against the creeping trend to just demand all kinds of permissions without obvious reason; but still provide well-formed inputs where applications expect them, so that things will still work(alternative uses, such as polluting the databases of the various 'social' scum who treat hoovering up contacts as a business model, are left as an exercise to the reader); but the device owner's wishes will be preserved.
I'm sure you could get it to pass a fire resistance test if you were willing to add enough flame retardants.
A pity that the most promising candidates are a collection of somewhat sinister organohalogens and organophosphates, research on which generally hasn't led to smiles among the world's toxicologists...
PLA is reasonably stable under everyday conditions(as some would-be composters have discovered to their chagrin... it can be composted but your technique has to be up to the task) The real killer, for something like computer packaging, is the low glass transition temperature. You can get quite dramatic and swift deformation at under 100 degrees, and enough softening to creep under trivial mechanical stress lower still.
Having a laptop case that will start deforming at temperatures quite plausibly reached by forced-air-cooling exhaust would be a bit of a reliability liability...
Slashdot Mirror
Arguably, the 'distant' bit would be so overwhelming that it would cancel out the 'swift'...
With the exception of cases involving factions in the same gravity well frying one another's satellites, which would indeed be nice and fast, any sort of conflict(barring technology that brutally violates the presently suspected laws of physics) would likely be a decades-to-generations affair. Within the solar system, most objects of interest are a few light-minutes away from one another, so even combatants using lasers or similar would be deprived of any 'instant hit' weapons. Between solar systems, you would be talking anywhere from 4ish to tens or thousands of years. Anything based on matter(whether projectiles or invasion ships) would of course be slower, probably far slower(although, probably extremely hard to detect for the vast majority of their journey).
What would be very interesting, and give any cryogenically frozen and revived Cold-War game theorists their stab at relevance, would be the implications for diplomacy: Because of the distances involved, conversation of any sort could take decades and would be precisely as fast as the fastest available weapons. There would be the oh, so, very, delightful potential for all sorts of situations where both parties would be left to twiddle their thumbs for years, not knowing whether a friendly greeting or a planet-annihilating x-ray pulse is heading their way, with no way to communicate further(and, even if there were, a beam of light or a kinetic-kill projectile travelling at a modest fraction of the speed of light couldn't be called back once launched).
At modest distances, it'd be lots of probabilistic number crunching trying to put the projectile where you expect the enemy to be(or at least force the enemy to burn mass deviating from their inertial/gravitational trajectory). At longer distances, it would be long periods of adrenalized tedium, sweating bullets and deciding whether to do unto others lest they do unto you without any way of knowing what others are or aren't doing unto you until it is too late...
A driverless vehicle may not injure a human being or, through inaction, allow a human being to come to harm, unless in Reno and with the intent of observing said human's demise.
Tiny monks with tiny paintbrushes, inscribing ones and zeros on individual electrons. No problem.
Nothing can really save your performance numbers once you have to hit the platters, so the question would be not 'does it suck more when it can't work purely in RAM?' but 'How good are the mechanisms available for minimizing(ideally automatically, but at least without too much black magic on the application programmers' parts) the frequency with which your setup ends up needing something that isn't in RAM and being bottlenecked by having to fetch it from disk?'...
The cool thing about having a moral goal is that the harder you push it, the more moral you become... If anything, you even get to blame your opponents for the suffering that you inflict(after all, if it weren't for ruthless narcolumbians and potheads, granny could have her pain pills, never you mind that I'm the one who took them away...)
If the DEA were pursuing a pragmatic objective(or a pragmatic objective that isn't pragmatic exclusively because it's an excellent makework project for cops) they'd have hit the cost/benefit rocks bloody ages ago. Luckily for them, they aren't.
If the product is being sold in the US, at least, there may be quite specific reasons why it is 'homeopathic' and why it is sold as such.
Under the Federal Food, Drug, and Cosmetic Act, which established the FDA and its regulatory authority, Homeopathic drugs are a distinct regulatory class. Further(presumably because so much homeopathy is conducted with concentrations indistinguishable from water) the regulations are significantly looser than for conventional drugs. You have to follow some basic accuracy in labelling stuff, and meet strength and purity standards(though per "Section 211.165 (Testing and release for distribution): In the Federal Register of April 1, 1983 (48 FR 14003), the Agency proposed to amend 21 CFR 211.165 to exempt homeopathic drug products from the requirement for laboratory determination of identity and strength of each active ingredient prior to release for distribution.Pending a final rule on this exemption, this testing requirement will not be enforced for homeopathic drug products." you don't actually have to verify the strength and purity before sale).
For this reason, if you want to sell something that is listed in the Homeopathic Pharmacopeia of the United States and its supplements(there are lots of things listed in here...), at a concentration that can be expressed in one of the traditional homeopathic dilution levels(nX, nD, nC, nM, etc.) you can more or less knock yourself out with only the slightest of scrutiny.
In many cases, this does result in the classic overpriced distilled water scenario. It doesn't take many 1:100 or 1:1000 dilutions before even an analytical chemist with an unlimited budget would despair of determining what you were originally diluting(in the case of things like homeopathic plutonium, this is good.) However, "1X", a fairly stiff 10%, is also a perfectly legitimate homeopathic dilution, albeit not one that true homeopathy enthusiasts would tend to view as potent.
The most notorious case of this being Bad is probably 'Zicam', where intranasal administration of 10% zinc gluconate turned out to occassionally destroy the unlucky user's sense of smell. Oops.
In this case, stripped of the 'homeopathic' wording, the spray looks like a fairly plausible, and likely safe, mixture of dilute capsaicin and Eucalyptol in an isotonic carrier. Sensible enough. Whether the function of the 'homeopathic' label is regulatory exclusively or also for marketing purposes is harder to say; but it may be some of both.
This one is conveniently not-paywalled. Research on how exactly to kill the bastards(at least in environments such as whiny humans where expedients like "fire", "brutal doses of ozone", and similar reliable methods are disallowed) is ongoing; but it is apparently the case that a bacterial biofilm exhibits something approaching multicellular cooperation in surviving antibiotics. You can certainly cull the weak and the surface layer; but some combination of near-dormant sleeper cells and novel multi-cellular resistance mechanisms makes eradicating them very difficult indeed.
Assuming the labeling is following conventions for homeopathic dilution notation, I'm not surprised that that stuff would clear your sinuses good and hard, and not because of my boundless confidence in homeopathy...
.1% capsaicin. Not exactly riot-cop stuff; but it'll definitely give you a bit of a kick. The unspecificed amount of Eucalyptol will likely get the sinuses cleared out as well...
A '3x' dilution is three successive 1:10 dilutions of the substance indicated in some neutral solvent. "Capsicum 3x" would be
There is, of course, nothing wrong with using plant-derived compounds that cure what ails you(that and sharp objects were, after all, basically the whole of medicine until the chemists really started to gear up in the late 19th and 20th century...); but the marketing as 'homeopathic' of drugs with concentrations well in the conventionally active range always annoys me.
I'm assuming that, in addition to the general spirit of gung-ho surveillance zeal, they are operating under the wishful assumption that this will give them the capability to act more competently in the case of something like the Mumbai attacks in 2008, which were coordinated in large party by cellphone...
"Moreover Mountain Lion adds a powerful new line of defense against future threats where a malware app is prevented from running even if it is deliberately downloaded to a computer"
While having a mechanism for the OS to check and display the cryptographic signature and signing party on an executable before executing it, the notion that this is 'new' seems to stretch credulity. Most Linux distros have been signing packages since shortly after they stopped supporting vacuum tube based systems, and Windows users have been getting little boxes describing(or freaking out about the lack of) 'Authenticode' signatures on drivers, activex controls, and executables for years now...
There are, undeniably, times when Apple introduces novel things, or non-novel-but-polished-to-an-unprecedented-sheen things; but this would not seem to be one of them...
It would appear that they are called the "Heartland Institute" and not the "Brainland Institute" for a reason...
It arguably goes further than that: Depending on the nature of your practice, you might have patients who are dependent on herd immunity(immunocompromized, vaccine component allergy, etc, etc.) Would a doctor be responsible in keeping people who are voluntary infection risks around the rest of their patients?
If it were merely a matter of not taking good advice, I'd be a trifle ambivalent, certainly legal; but seems a bit tasteless. However, the infection risk makes it more like firing a medical assistant who won't wash their hands: it isn't just their health they are risking...
I would be interested to see the reaction. It is, undeniably, the case that robust access control could be used to fuck with advertisers and 'social' stuff and various 'analytics' spying. However, if presented as an architecture/security proposal, it would basically be a request for a Mandatory Access Control/Role Based Access Control implementation, which sounds a great deal more benign...
With the exception of the 'filter' notion, for programmatically sanitizing certain data for certain application contexts(which is hardly new in the sense that virtually all of modern computing is piles of abstraction layers; but is a little odd in that it would mostly be about culling data based on human relevance), most of what you would want for a 'don't-trust-the-apps' implementation of Android would end up looking very similar to a Mandatory Access Control system, with a dash of Role Based Access Control. Presented in those general terms, it sounds about as much unlike a den of scurrilous hackers and enemies of profit as one might imagine.
I strongly suspect that there could be (quite legitimate) objections on resource use grounds, having an instance of every information provider, for every application, filters chewing away in the background, having to move to an SELinux kernel, iptables crunching a set of firewall rules for every application's tun device, etc, etc. certainly wouldn't do the RAM requirements and batterly life any favors... A usable user interface might well prove difficult or impossible to implement on the phone, and not easy even as a full desktop Android Policy Editor widget(hands up, everyone who enjoys SELinux configuration!), which would be another objection
However, at least in an ideal world, most phones would only realistically have to run a fairly lightweight set of controls, built for the user by somebody who knows how to do that, in order to reap most of the benefit. The more intensive capabilities(yeah, your phone's microsd card probably isn't going to be happy if every app's communication with the internet has its own tcpdump instance and a transparent http proxy with some rewrite rules dumping all communications to mass storage...) could be used in emulators for hunting rogue applications.
The proposal would also have the, presumably attractive to both Google and handset vendors(and cheating spouses! Now have all 'extracurricular' messages programmatically shunted into a private namespace, invisible from the standard system utilities!), advantages of being able to support all sorts of dual and multi use device scenarios without going full hypervisor and paying a tithe to VMware on every handset.
No, but my attempt at deadpanning it was apparently a trifle too deadpan.
Wow, that was rather more vitriolic than I expected...
Ironically, a slightly more 'neutrally presented' permission and filter based per-app provider namespace security scheme could actually be something of a killer app for Android, as well as a valuable tool for the privacy enthusiasts and database-jammers of the world:
Consider the (vastly common, in my experience) 'dual use device' scenario where a single phone is used for both work and personal business(either a business phone that hasn't been given the lockdown treatment, or a personal phone that somebody has set up activesync on, usually). You want convenient stuff like syncing of the company directory to the phone's contacts to Just Work, so that your worker drones can email and call their cubemates efficiently; but you Do Not Want some idiot installing the SocialTwitFriendst.ir app and having it hoover up your entire directory, along with the sucker's gmail contacts, and sending it to some dodgy startup. Solution? All contacts imported from the company directory get a specific filter flag such that only apps blessed by IT can even tell they are there when they query the 'global' contacts list. Boom. The user can still install apps that demand 'Contacts' access, so IT doesn't have to break their phone; but only blessed apps are allowed to have their provider interface namespaces attached as children to the ones provided by corporate sync. Similar behavior could do things like force certain apps to communicate only through a VPN link, without breaking open internet for the browser, or any number of other scenarios.
With some detailed thought about the architecture(this would, admittedly, have the potential to turn into a hellish spaghetti nightmare if you didn't have a clever designer on board) you could do some really neat role based permissions stuff, allowing multiple security contexts to more or less seamlessly exist on the same device, without leakage, or the rather clunky solution of multiple virtualized Android instances... In addition to the almost-certain-to-piss-off marketers privacy wonk scenarios(which these features would also enable), I can imagine some setups that would make IT types very happy indeed...
Out of curiosity, why was the notion shot down for Cyanogenmod? Was it a resource constraint problem of some sort? The(almost definitely hairy) issue of how to do a permissions UI for such a system, or is there actually support for the scum among the movers in the CM community?
Just be careful not to take it too far...
Apparently, in the twisted logic of TSA-land, if the gate-rape extends to a full handjob, and you ejaculate on the TSA goon, you have apparently committed the sexual assault.
One wonders if Lightsquared thought that they had a good chance of pulling this off, either through technological optimism or confidence in their legal team(For whatever reason "Rural broadband!!!" appears to be the FCC's root password) or if this was some sort of long-odds/high-rewards gamble by the hedge fund chap...
On the one hand, being able to convert a swath of satellite-to-ground spectrum into ground-ground spectrum would be crazy valuable, and likely result in some very nice returns. On the other, trying to go up against the now-firmly-entrenched users of GPS(ie. almost everybody) is a risky move indeed.
Did they miscalculate the odds, or were they happy to take very bad odds for the possibility of extremely high returns?
For better or worse, it is generally the case that Legacy Systems Win.
Outside of some limited consumer markets, or the occasional dramatic(and generally traumatic) forklift upgrade of some gigantic institutional system(usually still leaves a screen-scraper connected to the old system that everybody politely doesn't talk about hidden somewhere...), the clout of Stuff That Already Works is enormous compared to that of Stuff that Might Be Cool.
If it were merely a matter of forcing Garmin into a class action and giving all their past customers a shiny nickel to spend on new Garmin products, it might have worked. GPS, though, is firmly embedded in all sorts of slow-turnover, expensive, capital equipment and infrastructure. No way is it getting displaced in the near term...
Always remember to give the officer doing the pat-down your best sex-offender-smirk and remark that you "always stand at attention for a man in uniform"...
The situation is not actually winnable in any useful way; but if the rentacop goes home feeling as though their soul is soiled, you've done your part.
This 2008 piece has always been hilarious; but I had hoped that it would not prove prophetic...
You nasty cynic...
I, for one, am bursting with patriotic confidence! These 'passenger advocates'(likely toiling tirelessly out of a dank basement office hidden behind a filing cabinet and marked 'beware of the leopard') will almost certainly reform the TSA's abusive practices just as 'Internal affairs' units have revolutionized the professionalism of our police forces! Victory! Progress!
What android really needs(and probably won't get, for actively self-interested reasons; but so it goes...) is the ability to lie.
Right now, you can at least see what outrageous demands an application is making; but it's a take-it-or-leave-it thing. You cannot, for instance, specify that an application that wants your contacts list for no reason useful to you installed such that any attempt to access the contacts list returns a false one, rather than the actual system-wide contacts.
It'd likely add some resource overhead; but you could theoretically have a per-app 'virtual' set of android.* interfaces: some could transparently map to the real ones, others could be defined by a filter against the real ones(for network access, a specific set of firewall rules, or android.location interface that is based on the genuine android.location data; but with resolution reduced or a fictitious offset introduced, for instance), and some could be based on pure fictions unrelated to the real interface.
The ability to lie would allow you to push back against the creeping trend to just demand all kinds of permissions without obvious reason; but still provide well-formed inputs where applications expect them, so that things will still work(alternative uses, such as polluting the databases of the various 'social' scum who treat hoovering up contacts as a business model, are left as an exercise to the reader); but the device owner's wishes will be preserved.
I'm sure you could get it to pass a fire resistance test if you were willing to add enough flame retardants.
A pity that the most promising candidates are a collection of somewhat sinister organohalogens and organophosphates, research on which generally hasn't led to smiles among the world's toxicologists...
PLA is reasonably stable under everyday conditions(as some would-be composters have discovered to their chagrin... it can be composted but your technique has to be up to the task) The real killer, for something like computer packaging, is the low glass transition temperature. You can get quite dramatic and swift deformation at under 100 degrees, and enough softening to creep under trivial mechanical stress lower still.
Having a laptop case that will start deforming at temperatures quite plausibly reached by forced-air-cooling exhaust would be a bit of a reliability liability...