TFS' assertion that Honeycomb is "born too early" seems not just ill-supported; but simply followed by irrelevant information occupying the location where supporting details customarily go.
Obviously, Honeycomb is later than Google would want it to be. All software, even stuff that ships as predicted, is later than its creators would want(because who wouldn't want software to be done in zero time?) However, that seems to have no logical connection to how many devices are being displayed with it. As with essentially any OS that isn't tied directly to one specific product, early development likely occurs on dev boards that will never be made into products, or on last-gen stuff that is deemed adequately representative for testing purposes. Eventually, it matures enough to appear in public facing tech demos, and then it ships. In this case, Motorola seems to have been the BFF launch buddy. Other than the trivial sense in which it is "too early" for Honeycomb to have broad distribution(which is true of every software package at some point in its life) how is this relevant?
Clearly, Google is working on catching up to the incumbent(and busy stealing share from the other players, especially no networks that Apple doesn't care to deal with); but, unless there is a cogent argument that Apple will do something in the near future that will be so groundbreaking that Google will just have to run away and abandon their efforts, the notion that they are "too late" seems dubious. Later than they would like, obviously; but (unless public reports are being fudged pretty seriously) moving more than enough Android devices to make their improvement efforts strategically viable, possibly even self-sustaining, for the forseeable future.
My naive expectation was, as it turned out, wrong; but what I had in mind by "the market for good exploits, well crafted viruses, and so forth would be a fairly global one" was the expectation that once an exploitable bug is found, it would first be exploited by "tier 1" attackers, either against specific high value targets or regions with a high GDP/cluefullness ratio. Once in the wild, the value of the exploit would go down over time, both as patches and AV updates filter out, and as assorted tier 2 and below attackers obtain copies of the attack package and produce minor variants with their own payloads to exploit less lucrative, or slower-to-patch markets.
Obviously, most of the highest-quality malware R&D would go into producing attacks either for targeted use against specific high-value entities, or general use in high value regions; but I would have expected that those attacks would either soon be pirated, or(once high value targets and legitimate Windows systems were patched) sold at reduced prices to the bottom feeders, who would then exploit less valuable markets. The really good money is probably in targeted ops, followed by wealthy nations; but I suspect that a decent living can be made, in a country with low cost of living index, if the attack tools you are using are all stolen or heavily discounted...
That is why I was surprised. I would have expected the malware in less lucrative locations to be mostly bargain priced or stolen versions of malware that had already made the rounds elsewhere, rather than something novel enough to frequently escape detection...
The problem with them is that they've become excessively efficient at doing so. Casinos, the other high-profile fool devaluation institutions, at least operate on the comparatively honest principle that you have to go inside and put your money on the table in order to lose it...
Is there any evidence to suggest that Facebook, as a privately held company, isn't already whoring out every bit of their precious "social graph" that someone will pay them enough for? It is definitely the case that public status and next-quarter-driven shareholders can drive a company to evil; but I'm pretty sure that Facebook has already arrived at evil by limo and is currently lounging by the pool and sipping a drink with Zynga...
It isn't really news that AV products rely fairly heavily on canned signatures and that heuristic detection of evil lags behind evil by a fair margin.
What does surprise me, though, about these results, is that they suggest a fairly high level of geographic discrimination in the customization and targeting of malware. My (naive) expectation would have been that, aside from trivial stuff like trying to get the language of your spam/phishing/social engineering emails correct, the market for good exploits, well-crafted viruses, and so forth would be a fairly global one. Also, given that some malware attempts to propagate itself, rather than being delivered by a bugged website or other external mechanism, I would expect a fair amount of "splash" from malware spreading to any vulnerable hosts it can find, not bothering with any sort of geolocation, or from expats who live in country A, but still visit websites from home country B.
I would have expected a much more homogeneous(from the perspective of the mechanics of the exploit mechanism, evasion techniques, and payload) worldwide population of malware.
I don't know the details of how much release occurs underground, due to fracturing operations connecting with aquifers, and how much occurs during the wastewater handling phase. Apparently, a nontrivial percentage of the fluid injected to break up the formation and carry in the proppants comes back up the well with the escaping gas. This stuff is a mixture of water, whatever fracking additives were being used(generally proprietary formulations, contents unspecified; but contact not advised), and whatever soluble minerals happened to be inhabiting the area being drilled. The wastewater is either stored in "evaporation ponds"(sometimes even with plastic liners that aren't leaky!) or sent to local wastewater treatment plants, which are usually geared toward organic material and ill-equipped to handle mining wastes.
The details of what exactly happens underground are a little murky; but the fact that local water quality frequently takes a turn for the worse once the drilling starts is an observable, and observed, pattern...
With Nokia becoming an MS hardware OEM, QT isn't going to be the default, native, library set for any platform with notable share; but I see it cropping up(subtly, you usually have to take a look at the stuff an installer does to notice it) in all sorts of cross-platform commercial software with quite broad distribution. Then you have KDE, which is a fairly heavy QT user, albeit not one with a huge install base.
I'd say that the odds of world domination look slim; but I don't see why QT couldn't continue doing what it did before the Nokia acquisition(even if Nokia has no further interest, they paid good money for Trolltech, so they'd be stupid to destroy them internally, rather than spin them off again and take what they can get...)
One could also look to the ongoing "hydrofracking" saga, or the vast number of leaking mine sites in the American west whose owners disappeared once the extractable minerals were gone, leaving the heavy metal leachates for somebody else to drink. Because extraction industries are always rather ugly(or, at best, are much more expensive to run cleanly), an ability to evade liability for environmental destruction and human casualties is a valuable competitive advantage in the sector.
In terms of sheer political rot caused by this, coal country is probably the worst domestic location; but one can, of course, find much more extreme examples in the assorted despotic oil princedoms and warlord-controlled African mines and other such delightsome places...
If the politics of extraction industries in America's south-eastern coal producing regions are anything to go by, the theoretical damages will be very high indeed; but buying enough of the government to get it off their backs will be quite modestly priced. There will be 10-20 years of litigation, the fines that actually survive the appeals process will be approximately equal to those assessed for downloading a couple of dozen mp3s, and assorted slimy politicians will go on at considerable length about how any fines at all are "job killing", "anti-business", and "play right into OPEC's agenda"...
I accepted BP/Transocean's not-at-all-self-interested assessment of the Sound Science(tm) concerning this minor, but unfortunately unprofitable, incident with the uncritical, childlike, faith that every corporate person deserves. I, for one, am shocked, shocked, that actual scientists might have come to different conclusions.
I suspect that it is a mixture of "collateral damage in the war on spammers" and "convenient mechanism for price discrimination".
Back in the day, the ISPs could use the simple "dialup=cheap gits(unless they inquire about worldwide availability of dial-in numbers, in which case Soak 'em), T1=Soak 'em" heuristic to more or less distinguish between business and home users.
Now that a T1 is pitifully slow by consumer broadband standards(and, depending on location and providers, not much more reliable than a faster and cheaper consumer broadband connection, never mind two or more coming in over different wires for redundancy...) they need something else to keep business users paying more. Crippling common server functions is, conveniently, both a plausible reaction to spambots and a good way of making consumer-priced connections less useful...
Hey, competition is important. You don't think that the LHC guys are going to get off their asses and deliver that planet-devouring black hole that they've been holding out on us about if they don't know that the UCSD antimatter team has a competing PhDed existential threat in the works, do you?
If(and only if) Apple adjusts their strategy as needed, I would say that what they are doing is (while rather nasty) quite pragmatic. They could hardly have had a better position from which to induce the production of iOS-native applications, favorable network effects, and customer lock-in than they have enjoyed since the iPhone release. They would have been foolish to turn that down by spending their time obsessing about whether it could support Flash, and Java(and its cellphone variants), and BREW, and whatnot. They had what a very desirable segment of customers very much desired. That left them in the position to make the rules and tell everyone that they could play along or not at all. By doing so, they made a pile of cash and had a huge library of applications produced for their exclusive platform.
Now should they(through some combination of the continued improvement of Android and decreasing cost of handsets running it or internal Scully-esque stagnation) start heading back to the bad old days of flogging incremental improvements to old products, for high prices, as their competitors advance rapidly, they may have to revise this strategy...
If they do revise it, they should get away largely unscathed(and with a giant pile of cash and legacy application lock-in in the bank). Even after Jobs' public mockery of them, Adobe would probably come running like a whipped puppy if given the chance to offer Flash on iDevices. Doing something along the lines of Blackberry's rumored 'dalvik-alike' android compatibility mechanism would also be entirely possible. As would things like making the device available to more carriers and/or for a lower margin.
If they do not revise it, they could have some long-term issues...
I would be extremely concerned about the accuracy, auditability, and freedom from coercion/tampering of a voting system.
However, I'm not at all sure that nationalism is an effective mechanism for advancing that concern(it might simply be orthogonal, it might actually be negative, by bringing the electoral system under the control of an entity with a strong domestic agenda.., or it might be positive; by bringing the electoral system under domestic scrutiny).
Nationalism, per se, is (I think) irrelevant to the matter. However, completely 'a-national' behavior is often a sign of somebody who is just buying off-the-shelf from whoever hits the best combination of flashy sales demo and low price... That is a Terrible procurement model for electoral systems. However, that applies even if the vendor thus selected happens to be as American as God, the Flag, and Mom's Apple Pie(cough... Diebold, er 'Premier Election Systems' cough...)
Treating procurement of election apparatus as identical to buying office supplies is always a dangerous mistake, and it should always be remembered that fucking it up can, in fact, make the difference between a democracy and a sham. In that sense, there is a "nationalist" component to it. That doesn't mean anything in particular about the geographic origins of the system, though...
Can anybody think of a good "duress code" style mechanism to address this? Being able to, for instance, cast your actual vote at time A and then being able to cast further ballots at later times that are silently discarded? Some way of signalling to the web form that the ballot you are "casting" should be discarded?
Unfortunately, I can't think of anything that you couldn't also use quite efficiently for the various voter discouragement/vote misdirection tricks that are commonly deployed to suppress polling regions demographically known to favor the opposing cause...
I've had very mixed results with USB-PS/2 adapters and model Ms, unfortunately. My '93 vintage "Manufactured for IBM by Lexmark" works perfectly with the cheapest adapter the ebay-mongers of the pacific rim could dredge up.
The '92 "IBM" model, on the other hand, won't even illuminate any of its indicator LEDs on the same adapter. Apparently, the capacitive keyswitches, especially on the earlier models, use substantially more power on the +5v than many adapters deliver.
Unfortunately, getting one of the high-power adapters is a total crapshoot. I've seen some that claim(per lsusb) to draw only 50ma. Others assert the need full 500ma available. Some fall in between. There appears to be no correlation between price and power demand or power delivered to the downstream PS/2 device. The packaging, of course, doesn't mention such details at all. Even better, in the fine tradition of cheap USB devices, some of them are lying to the host system(see also, non-powered hubs that always report themselves to the host as being powered...) The lying ones lead to delightful situations where how well the system works depends on exactly how tolerant the motherboard or USB chipset designers were. Many desktop boards, and some laptops, have bowed to the inevitable, and cheerfully deliver 500ma or more if called upon, regardless of the lies told by the device. The ones that stick strictly to spec, on the other hand, you can get to pop up alarming warnings just by plugging some of the ghastlier liars in...
For pure *tube cases, it is true that Flash is essentially entirely unnecessary. As you say, it just does decode on an mp4 or flv video pulled from a URL, and provides a few basic play control widgets(and typically ads...).
On quite a few sites, the URL for the video file is clearly visible in the page source. You can even rewrite the page on the client side for HTML5 video with some basic greasemonkey or equivalent. Annoyingly, enough sites do a little bit of obfuscation/screwing around with referrer URLs and cookies/embedding certain parts of the URL in the.swf player/etc. that creating a fully general-purpose HTML5-ifier would require either per-site hand tuning or a more invasive approach(traffic sniffing the HTTP GET request usually works...)
The more complex(but still quite easy for the video provider to build app support for without changing much) case is mp4 video over RTMP or RTMFP... I suppose, if you had access to all the fun HTML5 web sockets and high speed JS and so forth, you might be able to port rtmpdump to javascript and have it reconstruct the mp4 file in local storage and play back from there; but that would be more a stunt than a practical application. However, since the provider controls the permissiveness of their RTMP/RTMFP server, they can presumably get an app working with it...
Either of these cases could easily enough be addressed in an adroid application as well(even a third-party one, if the provider isn't using RTMPE or constantly tweaking their web code in order to break those...); but the marketshare numbers are such that quite a few web properties do have an iDevice app and don't have an Android one.
The genuinely hard case is the one where the full capabilities of Flash are put to use. The classic vector graphics/bitmaps/actionscript stuff. This is rarely what people mean by "flash video" anymore(though it was, back in the day); but still covers essentially all Flash games, some 'webapp' interfaces, and that "AIR" stuff that Adobe is always desperately hoping people will care about. On the client side, you basically have no option but to run Flash if you want to use this stuff(the 3rd party implementations of the flash environment sometimes work; but you are still running flash). On the provider side, re-tooling such flash-based assets takes some, potentially a great deal, of effort. Only viable if the marketshare numbers are compelling.
How many(if any), native applications are you using that are iDevice-specific implementations of a web property or game that is otherwise flash based? If nonzero, how many of those also have an Android equivalent?
That is why Apple can spit on flash, while Google is getting cozy with Adobe... Apple knows that, for the present at any rate, they have the install base sufficient to drive people to develop platform specific applications for them. Android has fewer platform-specifics, which makes Adobe's ability to(imperfectly) make available the vast legacy base of Flash stuff all at once attractive...
In the long term, Flash is almost certainly fucked. Apple and Microsoft both have competing native environments and development tools in which they are strongly invested, and which are defaults on their platforms. Google is less overtly hostile; but their native environment also isn't flash based, and their web products are pretty aggressive about advancing native HTML/JS and using those where possible. Adobe has the advantage of well-entrenched design tools; but their flash runtime has no platform of its own, and the world isn't quite as friendly as it used to be... Short and mid term, though, there is a huge body of legacy and current stuff that they can offer to platforms with weaker native application bases.
I think that, in large part(aside from specific niche/legacy stuff that is simply "flash or nothing", which is comparatively rare but very important to certain buyers) Flash is more of an issue for runners-up.
Because Apple has a fairly impressive chunk of the desirable customers demographic and a strong no-flash position on their iDevices, many outfits who were previously content to use flash have had to adjust. However, many of them have just churned out an iDevice-specific app that wraps their web content, rather than re-tool their web presence. For non-Apple devices, this isn't all that helpful. It is quite likely that many of them will eventually do the same for Android; but, in the meantime, there is a problem. Adobe, while dubiously competent, is the party capable of providing a general-purpose solution to viewing flash-dependent web properties.
I can only assume that neither Adobe nor Motorola are happy about this. Motorola needs all the advantages they can get in competing against the incumbent tablet device, and the longer Flash on mobile devices remains a joke, the more Flash users will come up with alternatives that will reduce Flash's value to embedded device developers and likely trickle back to the PC side sooner or later(and I'm pretty sure that there isn't an IT department on earth who wouldn't love to stop supporting the Flash plugin...).
DRM is, in fact, evil(even if you don't think that its objectives are.)
DRM is, inevitably, simply cannot be done any other way, a class of methods and mechanisms whereby my computer is placed under a 3rd party's partial control in order to make it obey their interests, rather than mine. Even if I happen to agree with the particular rule being thus enforced(which is hardly assured, most DRM users go beyond the rights copyright law allows), it is the change in the ultimate controller of the system that is the inevitable and unacceptable consequence...
The fact that any system sufficiently robust to allow for effective DRM also allows for effective censorship is just icing on the cake...
Slashdot Mirror
TFS' assertion that Honeycomb is "born too early" seems not just ill-supported; but simply followed by irrelevant information occupying the location where supporting details customarily go.
Obviously, Honeycomb is later than Google would want it to be. All software, even stuff that ships as predicted, is later than its creators would want(because who wouldn't want software to be done in zero time?) However, that seems to have no logical connection to how many devices are being displayed with it. As with essentially any OS that isn't tied directly to one specific product, early development likely occurs on dev boards that will never be made into products, or on last-gen stuff that is deemed adequately representative for testing purposes. Eventually, it matures enough to appear in public facing tech demos, and then it ships. In this case, Motorola seems to have been the BFF launch buddy. Other than the trivial sense in which it is "too early" for Honeycomb to have broad distribution(which is true of every software package at some point in its life) how is this relevant?
Clearly, Google is working on catching up to the incumbent(and busy stealing share from the other players, especially no networks that Apple doesn't care to deal with); but, unless there is a cogent argument that Apple will do something in the near future that will be so groundbreaking that Google will just have to run away and abandon their efforts, the notion that they are "too late" seems dubious. Later than they would like, obviously; but (unless public reports are being fudged pretty seriously) moving more than enough Android devices to make their improvement efforts strategically viable, possibly even self-sustaining, for the forseeable future.
My naive expectation was, as it turned out, wrong; but what I had in mind by "the market for good exploits, well crafted viruses, and so forth would be a fairly global one" was the expectation that once an exploitable bug is found, it would first be exploited by "tier 1" attackers, either against specific high value targets or regions with a high GDP/cluefullness ratio. Once in the wild, the value of the exploit would go down over time, both as patches and AV updates filter out, and as assorted tier 2 and below attackers obtain copies of the attack package and produce minor variants with their own payloads to exploit less lucrative, or slower-to-patch markets.
Obviously, most of the highest-quality malware R&D would go into producing attacks either for targeted use against specific high-value entities, or general use in high value regions; but I would have expected that those attacks would either soon be pirated, or(once high value targets and legitimate Windows systems were patched) sold at reduced prices to the bottom feeders, who would then exploit less valuable markets. The really good money is probably in targeted ops, followed by wealthy nations; but I suspect that a decent living can be made, in a country with low cost of living index, if the attack tools you are using are all stolen or heavily discounted...
That is why I was surprised. I would have expected the malware in less lucrative locations to be mostly bargain priced or stolen versions of malware that had already made the rounds elsewhere, rather than something novel enough to frequently escape detection...
The problem with them is that they've become excessively efficient at doing so. Casinos, the other high-profile fool devaluation institutions, at least operate on the comparatively honest principle that you have to go inside and put your money on the table in order to lose it...
Is there any evidence to suggest that Facebook, as a privately held company, isn't already whoring out every bit of their precious "social graph" that someone will pay them enough for? It is definitely the case that public status and next-quarter-driven shareholders can drive a company to evil; but I'm pretty sure that Facebook has already arrived at evil by limo and is currently lounging by the pool and sipping a drink with Zynga...
It isn't really news that AV products rely fairly heavily on canned signatures and that heuristic detection of evil lags behind evil by a fair margin.
What does surprise me, though, about these results, is that they suggest a fairly high level of geographic discrimination in the customization and targeting of malware. My (naive) expectation would have been that, aside from trivial stuff like trying to get the language of your spam/phishing/social engineering emails correct, the market for good exploits, well-crafted viruses, and so forth would be a fairly global one. Also, given that some malware attempts to propagate itself, rather than being delivered by a bugged website or other external mechanism, I would expect a fair amount of "splash" from malware spreading to any vulnerable hosts it can find, not bothering with any sort of geolocation, or from expats who live in country A, but still visit websites from home country B.
I would have expected a much more homogeneous(from the perspective of the mechanics of the exploit mechanism, evasion techniques, and payload) worldwide population of malware.
I don't know the details of how much release occurs underground, due to fracturing operations connecting with aquifers, and how much occurs during the wastewater handling phase. Apparently, a nontrivial percentage of the fluid injected to break up the formation and carry in the proppants comes back up the well with the escaping gas. This stuff is a mixture of water, whatever fracking additives were being used(generally proprietary formulations, contents unspecified; but contact not advised), and whatever soluble minerals happened to be inhabiting the area being drilled. The wastewater is either stored in "evaporation ponds"(sometimes even with plastic liners that aren't leaky!) or sent to local wastewater treatment plants, which are usually geared toward organic material and ill-equipped to handle mining wastes.
The details of what exactly happens underground are a little murky; but the fact that local water quality frequently takes a turn for the worse once the drilling starts is an observable, and observed, pattern...
With Nokia becoming an MS hardware OEM, QT isn't going to be the default, native, library set for any platform with notable share; but I see it cropping up(subtly, you usually have to take a look at the stuff an installer does to notice it) in all sorts of cross-platform commercial software with quite broad distribution. Then you have KDE, which is a fairly heavy QT user, albeit not one with a huge install base.
I'd say that the odds of world domination look slim; but I don't see why QT couldn't continue doing what it did before the Nokia acquisition(even if Nokia has no further interest, they paid good money for Trolltech, so they'd be stupid to destroy them internally, rather than spin them off again and take what they can get...)
This lovely fellow was also on my mind. Or this rather sordid story...
One could also look to the ongoing "hydrofracking" saga, or the vast number of leaking mine sites in the American west whose owners disappeared once the extractable minerals were gone, leaving the heavy metal leachates for somebody else to drink. Because extraction industries are always rather ugly(or, at best, are much more expensive to run cleanly), an ability to evade liability for environmental destruction and human casualties is a valuable competitive advantage in the sector.
In terms of sheer political rot caused by this, coal country is probably the worst domestic location; but one can, of course, find much more extreme examples in the assorted despotic oil princedoms and warlord-controlled African mines and other such delightsome places...
If the politics of extraction industries in America's south-eastern coal producing regions are anything to go by, the theoretical damages will be very high indeed; but buying enough of the government to get it off their backs will be quite modestly priced. There will be 10-20 years of litigation, the fines that actually survive the appeals process will be approximately equal to those assessed for downloading a couple of dozen mp3s, and assorted slimy politicians will go on at considerable length about how any fines at all are "job killing", "anti-business", and "play right into OPEC's agenda"...
I accepted BP/Transocean's not-at-all-self-interested assessment of the Sound Science(tm) concerning this minor, but unfortunately unprofitable, incident with the uncritical, childlike, faith that every corporate person deserves. I, for one, am shocked, shocked, that actual scientists might have come to different conclusions.
I suspect that it is a mixture of "collateral damage in the war on spammers" and "convenient mechanism for price discrimination".
Back in the day, the ISPs could use the simple "dialup=cheap gits(unless they inquire about worldwide availability of dial-in numbers, in which case Soak 'em), T1=Soak 'em" heuristic to more or less distinguish between business and home users.
Now that a T1 is pitifully slow by consumer broadband standards(and, depending on location and providers, not much more reliable than a faster and cheaper consumer broadband connection, never mind two or more coming in over different wires for redundancy...) they need something else to keep business users paying more. Crippling common server functions is, conveniently, both a plausible reaction to spambots and a good way of making consumer-priced connections less useful...
Hey, competition is important. You don't think that the LHC guys are going to get off their asses and deliver that planet-devouring black hole that they've been holding out on us about if they don't know that the UCSD antimatter team has a competing PhDed existential threat in the works, do you?
If it weren't so damn expensive, it'd probably give those crazy kids over in high-density rocket fuels something to chew on, as well...
Hence the "for the present at any rate"...
If(and only if) Apple adjusts their strategy as needed, I would say that what they are doing is (while rather nasty) quite pragmatic. They could hardly have had a better position from which to induce the production of iOS-native applications, favorable network effects, and customer lock-in than they have enjoyed since the iPhone release. They would have been foolish to turn that down by spending their time obsessing about whether it could support Flash, and Java(and its cellphone variants), and BREW, and whatnot. They had what a very desirable segment of customers very much desired. That left them in the position to make the rules and tell everyone that they could play along or not at all. By doing so, they made a pile of cash and had a huge library of applications produced for their exclusive platform.
Now should they(through some combination of the continued improvement of Android and decreasing cost of handsets running it or internal Scully-esque stagnation) start heading back to the bad old days of flogging incremental improvements to old products, for high prices, as their competitors advance rapidly, they may have to revise this strategy...
If they do revise it, they should get away largely unscathed(and with a giant pile of cash and legacy application lock-in in the bank). Even after Jobs' public mockery of them, Adobe would probably come running like a whipped puppy if given the chance to offer Flash on iDevices. Doing something along the lines of Blackberry's rumored 'dalvik-alike' android compatibility mechanism would also be entirely possible. As would things like making the device available to more carriers and/or for a lower margin.
If they do not revise it, they could have some long-term issues...
I would be extremely concerned about the accuracy, auditability, and freedom from coercion/tampering of a voting system.
However, I'm not at all sure that nationalism is an effective mechanism for advancing that concern(it might simply be orthogonal, it might actually be negative, by bringing the electoral system under the control of an entity with a strong domestic agenda.., or it might be positive; by bringing the electoral system under domestic scrutiny).
Nationalism, per se, is (I think) irrelevant to the matter. However, completely 'a-national' behavior is often a sign of somebody who is just buying off-the-shelf from whoever hits the best combination of flashy sales demo and low price... That is a Terrible procurement model for electoral systems. However, that applies even if the vendor thus selected happens to be as American as God, the Flag, and Mom's Apple Pie(cough... Diebold, er 'Premier Election Systems' cough...)
Treating procurement of election apparatus as identical to buying office supplies is always a dangerous mistake, and it should always be remembered that fucking it up can, in fact, make the difference between a democracy and a sham. In that sense, there is a "nationalist" component to it. That doesn't mean anything in particular about the geographic origins of the system, though...
Very strong turnout in favor of "H3r5bal V14gR/\". I hear he really stands up for the voting man, if you know what I mean...
Can anybody think of a good "duress code" style mechanism to address this? Being able to, for instance, cast your actual vote at time A and then being able to cast further ballots at later times that are silently discarded? Some way of signalling to the web form that the ballot you are "casting" should be discarded?
Unfortunately, I can't think of anything that you couldn't also use quite efficiently for the various voter discouragement/vote misdirection tricks that are commonly deployed to suppress polling regions demographically known to favor the opposing cause...
I've had very mixed results with USB-PS/2 adapters and model Ms, unfortunately. My '93 vintage "Manufactured for IBM by Lexmark" works perfectly with the cheapest adapter the ebay-mongers of the pacific rim could dredge up.
The '92 "IBM" model, on the other hand, won't even illuminate any of its indicator LEDs on the same adapter. Apparently, the capacitive keyswitches, especially on the earlier models, use substantially more power on the +5v than many adapters deliver.
Unfortunately, getting one of the high-power adapters is a total crapshoot. I've seen some that claim(per lsusb) to draw only 50ma. Others assert the need full 500ma available. Some fall in between. There appears to be no correlation between price and power demand or power delivered to the downstream PS/2 device. The packaging, of course, doesn't mention such details at all. Even better, in the fine tradition of cheap USB devices, some of them are lying to the host system(see also, non-powered hubs that always report themselves to the host as being powered...) The lying ones lead to delightful situations where how well the system works depends on exactly how tolerant the motherboard or USB chipset designers were. Many desktop boards, and some laptops, have bowed to the inevitable, and cheerfully deliver 500ma or more if called upon, regardless of the lies told by the device. The ones that stick strictly to spec, on the other hand, you can get to pop up alarming warnings just by plugging some of the ghastlier liars in...
For pure *tube cases, it is true that Flash is essentially entirely unnecessary. As you say, it just does decode on an mp4 or flv video pulled from a URL, and provides a few basic play control widgets(and typically ads...).
.swf player/etc. that creating a fully general-purpose HTML5-ifier would require either per-site hand tuning or a more invasive approach(traffic sniffing the HTTP GET request usually works...)
On quite a few sites, the URL for the video file is clearly visible in the page source. You can even rewrite the page on the client side for HTML5 video with some basic greasemonkey or equivalent. Annoyingly, enough sites do a little bit of obfuscation/screwing around with referrer URLs and cookies/embedding certain parts of the URL in the
The more complex(but still quite easy for the video provider to build app support for without changing much) case is mp4 video over RTMP or RTMFP... I suppose, if you had access to all the fun HTML5 web sockets and high speed JS and so forth, you might be able to port rtmpdump to javascript and have it reconstruct the mp4 file in local storage and play back from there; but that would be more a stunt than a practical application. However, since the provider controls the permissiveness of their RTMP/RTMFP server, they can presumably get an app working with it...
Either of these cases could easily enough be addressed in an adroid application as well(even a third-party one, if the provider isn't using RTMPE or constantly tweaking their web code in order to break those...); but the marketshare numbers are such that quite a few web properties do have an iDevice app and don't have an Android one.
The genuinely hard case is the one where the full capabilities of Flash are put to use. The classic vector graphics/bitmaps/actionscript stuff. This is rarely what people mean by "flash video" anymore(though it was, back in the day); but still covers essentially all Flash games, some 'webapp' interfaces, and that "AIR" stuff that Adobe is always desperately hoping people will care about. On the client side, you basically have no option but to run Flash if you want to use this stuff(the 3rd party implementations of the flash environment sometimes work; but you are still running flash). On the provider side, re-tooling such flash-based assets takes some, potentially a great deal, of effort. Only viable if the marketshare numbers are compelling.
Playing The Legend of Zelda sent me down the path to a depraved life of home invasion and malicious destruction of pottery...
How many(if any), native applications are you using that are iDevice-specific implementations of a web property or game that is otherwise flash based? If nonzero, how many of those also have an Android equivalent?
That is why Apple can spit on flash, while Google is getting cozy with Adobe... Apple knows that, for the present at any rate, they have the install base sufficient to drive people to develop platform specific applications for them. Android has fewer platform-specifics, which makes Adobe's ability to(imperfectly) make available the vast legacy base of Flash stuff all at once attractive...
In the long term, Flash is almost certainly fucked. Apple and Microsoft both have competing native environments and development tools in which they are strongly invested, and which are defaults on their platforms. Google is less overtly hostile; but their native environment also isn't flash based, and their web products are pretty aggressive about advancing native HTML/JS and using those where possible. Adobe has the advantage of well-entrenched design tools; but their flash runtime has no platform of its own, and the world isn't quite as friendly as it used to be... Short and mid term, though, there is a huge body of legacy and current stuff that they can offer to platforms with weaker native application bases.
I think that, in large part(aside from specific niche/legacy stuff that is simply "flash or nothing", which is comparatively rare but very important to certain buyers) Flash is more of an issue for runners-up.
Because Apple has a fairly impressive chunk of the desirable customers demographic and a strong no-flash position on their iDevices, many outfits who were previously content to use flash have had to adjust. However, many of them have just churned out an iDevice-specific app that wraps their web content, rather than re-tool their web presence. For non-Apple devices, this isn't all that helpful. It is quite likely that many of them will eventually do the same for Android; but, in the meantime, there is a problem. Adobe, while dubiously competent, is the party capable of providing a general-purpose solution to viewing flash-dependent web properties.
I can only assume that neither Adobe nor Motorola are happy about this. Motorola needs all the advantages they can get in competing against the incumbent tablet device, and the longer Flash on mobile devices remains a joke, the more Flash users will come up with alternatives that will reduce Flash's value to embedded device developers and likely trickle back to the PC side sooner or later(and I'm pretty sure that there isn't an IT department on earth who wouldn't love to stop supporting the Flash plugin...).
Who's using PS/2 Mouse/keyboard connectors?
Model M for life, yo.
Yup. Never mind Our Cellular Overlords...
DRM is, in fact, evil(even if you don't think that its objectives are.)
DRM is, inevitably, simply cannot be done any other way, a class of methods and mechanisms whereby my computer is placed under a 3rd party's partial control in order to make it obey their interests, rather than mine. Even if I happen to agree with the particular rule being thus enforced(which is hardly assured, most DRM users go beyond the rights copyright law allows), it is the change in the ultimate controller of the system that is the inevitable and unacceptable consequence...
The fact that any system sufficiently robust to allow for effective DRM also allows for effective censorship is just icing on the cake...