For long term maintenance of a low oxygen environment they are probably using a Nitrogen generator of some flavor. If you want the job done fast, the ready availability of liquid nitrogen is very handy: let one liter of that boil off and you get almost 700 of pure nitrogen. Just carry it down and dump it.
My cynical suspicion is that have a datacenter in an underground oxygen-purged bunker is something you cost-justify under 'disaster recovery' or similar; but actually do because of a vague, gnawing, ill-defined dissatisfaction with the fact that your life is basically as safe as it is tedious. The same sort of thing as why really boring federal agencies build huge SCIFs and random suburbanites lovingly shop for tacticool accessories to cram onto their AR-15.
That aside, I assume that they got it for peanuts compared to the original build cost, since abandoned bunkers aren't terribly high-value real estate(and potentially turn into blighted little holes if you don't keep them locked and have a cop watch the entrance moderately closely), and a cold war bunker is probably nice and sturdy, trivial to provide physical security for, and not too much more inconvenient than a situation where equipment has to be taken upstairs by cargo elevator. The oxygen purge seems harder to justify except for the cool factor, though.
Do staff go down with O2 tanks for maintenance, cleaning, server work, etc?
Easy problem. They just hired some Perl divers to do admin. Those guys can hold their breath for an impressive amount of time and are comfortable with CLI use, natural fit.
I wonder what constraints were placed on the problem that made "displace the oxygen in this sealed bunker" a two-year problem? Maybe it's a quote taken out of context and refers to how long the entire environmental control setup took?
I suspect that in a computer of that size you wouldn't want anything other than integrated graphics. Sure, AMD or NVIDIA could provide a part low clocked enough, or cut down enough, to fit within the size and thermal constraints; but once they've done that they probably won't be much better than the already-integrated graphics.
Unless you have enough room for a proper GPU, low end discrete GPUs are increasingly somewhat pointless, since they always add complexity and cost; but don't necessarily outperform integrated ones by all that much.
You'd probably need to use a different formulation than for cotton or cellulose based bills; but I suspect so.
Based on a look at paints sold for use on plastics and vinyl(like this one), the strategy appears to be to use a suitably nasty solvent as a carrier for the pigment and have the solvent infiltrate the polymer's structure, carrying the pigment with it. In a case where you need not worry about damaging the polymer(unlike commercial plastic paints, where the solvent can't be so aggressive that it messes up the underlying material permanently), like tagging stolen bills, you could presumably be particularly aggressive in your formulation.
I don't know the chemistry of the polymer and the protective coatings in common use; but you can usually find a solvent that will do the trick, especially if you don't mind a bit of damage to the material being worked with.
I'm not saying that SNMP is the correct mechanism for IoT, just that the state of discovery and interaction between IoT 'things' is so dismal(except where specially handcrafted by the vendor) that SNMP's MIBs look positively advanced by comparison.
Crazy-cheap silicon makes connecting things to networks relatively simple; but it doesn't solve the much more difficult problem of making those things interact in a useful way without either intricate top-down command and control or a ghastly nightmare of emergent oddities and security problems. At present, there appears to be very, very, little headway in making the 'things' that are supposed to be internetworking aware of one another, much less usefully so, with people either rolling their own totally isolated little thing or attempting to be the gatekeeper for all device interaction. It does not inspire confidence.
The trick is that security measures have costs, in time, money, user convenience, etc. and it is considered 'crazy'(in the weak sense of 'not sensible', not the psych-ward sense) to voluntarily impose costs on yourself that are out of proportion to the costs of the expected threat.
There's always something you could be doing more securely; but only sometimes is it worth it.
I'd be curious to know (I'm definitely underinformed, so this is an honest question) whether that tactic has lost some effectiveness over time. The classic monitoring-RF-to-read-CRTs stuff depended on getting an adequately clean copy of the distinctly analog output of the CRT. Now, all signals are fundamentally analog signals; but digital signals are analog signals designed to make guessing the correct value really easy(since there are only two possibilities, rather than an arbitrary number of them); and now more than ever it's a safe guess that sensitive data will be heading over a number of RF-emitting digital busses, from the keyboard to the computer, within the computer, and likely to the monitor as well.
Does the broadband noise still drown out the desired signal sufficiently to prevent reconstruction, or does our increased emphasis on high-speed digital busses (often designed to operate with some amount of error correction in the event of cheap lousy hardware being cheap and lousy) make it more tractable to either unambiguously pick the correct interpretation of a noisy input, or make a number of guesses and use known features of the bus to help eliminate the incorrect ones?
We also have a (general, not universal) willingness to let the market squabble it out for an extended period of time, rather than give a good hard shove in the direction of some implementation. This tendency may be abetted by the fact that early adoption creates incumbents who have a vested interest in stalling as long as possible to milk their legacy investments and first-mover advantage, as in our wonderful market for ISPs.
With the payment card industry, you have a lot of people(all clambering to grab as much of the cut for themselves as they can, and shove as much of the risk onto others as they can) with competing agendas and a desire to have their pet proprietary system gain a foothold so they can extract tolls with it(eg. the incidents where some retailers with functioning NFC POS systems were deliberately disabling them because Apple Pay was a competitor to their 'CurrenC' system, and the ongoing spat between Google and the carrier-backed payment scheme formerly known as ISIS before that became a toxic brand). Nobody actually believes that "USA IS #1!!! Mag stripes RULE!"; but between everyone wanting to control the customer data and processing fees and banks, merchants, and payment processors fighting over risk allocation, it's a bit of a clusterfuck.
Compare to say, the DoD's CAC rollout: CACs still aren't what you'd call a joy to configure(especially on OSX, or in Citrix environments, or other oddball use cases); but the DoD decided that it wanted everyone using smartcards for cryptographic authentication, said that that was how it was going to be, and it was so (relatively) quickly and smoothly.
Opinions vary on how often we dodge a bullet, or get the benefit of something new and innovative, thanks to there being no mandate in place vs. how often we suffer pointless bullshit for an agonizingly long period of time(eg. the less-than-totally-compatible US cellular market); but the fact that we tend not to mandate an end to such fights all that often, or all that quickly, is simply a fact. Even when we do mandate something, it's often a de-facto 'national' mandate created because California, or another large state, demands something and it's cheaper to sell California-spec everywhere than it is to have two SKUs.
Depending on how motivated the thieves are, it may be more cost effective to have some shock-sensitive dye capsules embedded. Since they'd only be breached in the event of an attack(or really serious damage to the ATM from other sources) they could last the life of the machine and be entirely passive. If you were feeling particularly motivated, it would cost only a modest amount extra to get an ink with a unique tagging agent, per ATM, so that marked bills could be traced directly back to a specific attack.
If a lot of ATMs are being blown up, or attackers are unconcerned by dyed bills(maybe because of literal laundering, maybe there are people who don't care?), then active defensive measures are more likely to save enough hardware to be worth the cost. If not, a passive capsule or capsules fragile enough to break during an explosion are simple, low-maintenance, and a fair deterrent.
Pretty much all embedded devices smart enough to support TCP/IP, as well. I'm pretty sure that my router is currently the most 'IoT' device in my house, though also the least conceptually novel.
There are some honestly interesting, tricky, and (at least partially) novel problems in 'IoT'. Making devices that are networked, can talk to each other, and actually do something useful with that ability is a real challenge. Even more so if you want compatibility between multiple vendors, support for use cases the vendor didn't more or less build for you(ideally without requiring that the user be a software engineer), or some semblance of assurance that there aren't a zillion security and privacy issues, innumerable covert channels, and other disasters.
My apathy is mostly derived from the fact that most 'IoT' doesn't actually seem to be doing much of that. Plenty of stuff that lets you use the internet as a very long serial cable to connect to its config interface(which is fine, the internet is a great way, if secured, of very, very, cheaply connecting from arbitrary distance; but brutally non-novel), some walled-garden 'ecosystems' that support very limited interaction of devices between two vendors who have explicitly agreed to cooperate and updated their products to make that possible; but otherwise it's mostly the same old IP-capable firmwares that devices expensive enough to have the capability have used for at least something like two decades. Useful; but not terribly new, and often implemented so badly as to be a liability.
It's honestly a trifle disheartening. While arguably in need of some serious maintenance(especially the 'security' of the earlier versions), SNMP is arguably closer to an 'IoT' design(pretty much just add the ability for devices to advertise their MIBs to other devices on the network, rather than having the admin hunt them down and load them, and you are closer to being ready than most actual products are). That isn't really a flattering thing.
SNMP is quite useful; but it is a bit crufty and conceptually ancient. The fact that everyone's shiny, new, 'IoT' things, with their markedly-more-capable-and-way-cheaper embedded hardware typically can't advertise their capabilities and manipulate one another in some vaguely sane way at the same level as some seriously old hardware is not terribly impressive.
Even if the actual implementation is some XML-soup-and-'cloud'-bullshit horror, conceptual parity or superiority would be nice to see.
I suspect that the mania will be tempered by the fact that it will be fairly easy to classify all sorts of projects, that you were already doing, as "IoT" if you wish to seem super cutting edge and so on without actually making any changes.
There's a vague sort of notion about what "IoT" is supposed to be, cobbled together from some mixture of analogies to SCADA and industrial control systems and science fiction; but it is broad and ill formed enough that all sorts of things that can connect to a network in some way, and any and all software associated with them, can be covered without stretching the truth too hard.
Plus, until the various squabbling factions decide how to actually make the 'things' interact usefully with each other(the current preference seems to be 'appoint either Google or Apple as Feudal Oligarch', with 'don't even bother, everything you buy will have its own terrible app!' as the runner up), the 'internet' bit is really just being used as a convenient remote access to the control panel(and for monetizing users, of course), which is much less hairy and challenging than actual interactions among things in some conveniently configurable and/or emergent-without-being-pathological way.
Any guesses about how many existing 'embedded system that connects to the internet in some fashion' projects were dubbed 'internet of things' in order to bring this new buzzphrase to prominence?
Yeah, yeah, I know, at some point the scale and pervasiveness of embedded connectivity may reach a point where it is different in kind, not just degree, from past use; but I submit that we aren't there yet by a nontrivial margin. For the moment, "IOT" seems to mean 'has a terrible smartphone app' or 'last model, you connected to the serial port to configure the system; when we revised the hardware it turned out that adding ethernet would be cheap and lots of customers wanted it, so we added it.'
I agree that an update to 802.11 would be nice, unauthenticated management frames are a potentially nasty issue; but the rest of the argument is nuts.
All sorts of crimes can be committed by means of a speech act(indeed, many crimes are hard to commit without some means of communicating, fraud, extortion, ransoming hostages, etc.); but that doesn't give them constitutional protection, any more than the argument that your god demands blood sacrifice would provide protection against murder charges.
This is classic Locke stuff: a restriction aimed at restraining speech is illegitimate and illegal; but that does not imply that the mere use of speech to commit a given act necessarily covers that act under the protections given to speech. Same with religions. Restrictions targeted at a given exercise of religion are unacceptable; but this does not protect someone who breaks a law established for suitable unrelated reasons.
There's also the (only partially related) matter that 'radio interference' need not always imply "really loud white noise or other stochastic garbage at the appropriate frequency". That's often the easiest way, and for relatively primitive radio systems that have very few features to exploit it may be the best one; but if RF emissions specifically tailored to cause a radio system to fail aren't 'radio interference', what exactly is? Higher level attacks offer substantial advantages in power requirements, precision targeting, resistance to noise-mitigation mechanisms, and so on; but just because they aren't pure noise doesn't make them not interference.
That seems like a fairly slim bit of legal weasel-wording given that nowhere is "your airspace" in the slices of spectrum that wifi uses. I would certainly agree that 'containment' should only be performed in 'your airspace'; but there is no such space.
In private buildings that don't offer guest services or otherwise accommodate outsiders, you can certainly disconnect anything you don't approve of from the wired LAN, and ask anyone operating a hotspot to leave or be removed for trespassing; but the notion that you enjoy preferential rights to that spectrum by virtue of owning the building is simply unsupported.
Next you'll be telling me you can create operating systems in less than 15GB!
Indeed they can. Unfortunately they decided to let the people responsible for ACPI actually follow through on that, and then decided that it would make a good bootloader.
What I find most baffling about the whole affair is how something that one would ordinarily think of as a fairly overtly malicious exploit, spoofing the appropriate management frames to break a network you don't have authenticated access to the configuration interface for, became a 'respectable' tool for 'management', even included out of the box in fancy commercial products from vendors with risk averse legal teams and so on.
This seems like the place where somebody who has been dealing with enterprise wireless gear long enough to have observed the change might be found. Did this 'feature' cross over from what was initially a proof of concept by a security researcher? Was it recognized as a possibility before the standards had even been hammered out and was available from day one? Do we know what vendor adopted it first? Were there any who specifically didn't offer it for legal, rather than technical, reasons?
At this point, it is certainly the case that at least some wireless management consoles adopt a very...possessive...tone, detecting 'rogue' APs, despite those APs being no more or less legitimate than any others, in terms of spectrum use, and offering 'containment' or various similarly clinical euphemisms for dealing with them. How, historically, did it come to be that this nasty DoS trick went all legitimate, even as generalized hacker hysteria can get you a stiff dose of CFAA charges for almost anything that involves a CLI and confuses the DA?
I'd love to have my hands on all the versions of various vendors' wireless management and administration packages, to see how this feature evolved over time. I can certainly see its appeal; but I find it hard to believe that nobody had serious doubts about its legality from time to time.
Less likely. The FCC is pretty clearly within their powers in saying that you aren't allowed to intentionally interfere with other people's Part 15 devices by using your own to generate disruptive RF.
There is no obvious coverage for forbidding the sale of devices having a Part 15 radio component; but lacking a software configuration for providing network access to other devices with that device. They might be able to shove it into the conditions of a spectrum auction, and make it binding on the buyer; but it's more of an FTC problem.
Does anyone know why they wouldn't sidestep the infeasibility of particularly long cable runs by having the elevator climb the walls of the shaft directly, rather than being raised and lowered on a cable? I imagine that a cable and counterweight arrangement is more energy efficient for shorter runs; but if that isn't an option wouldn't a cog railway style mechanism, with 'track' on one or more walls of the elevator shaft, result in a system where the weight that has to be moved doesn't change at all with the height of the building? There would be some additional weight per unit height from the track structure; but that would be static and connected to the building's frame rather than being forced to support its own weight.
Too energy intensive? Wears too quickly? Safety breaks infeasible leading to risk of sickening plummet to doom?
That's an OK rant, I'd give it a C+, or maybe a nice solid B, because of the pernicious influence of the 'self esteem' movement and grade inflation; but you need to remember 'elasticity'. It's a fairly important property of both supply and demand.
It is undoubtedly true that many political policies(across the spectrum, or whatever the geometry of your preferred political metaphor is) are incoherent, largely because many individuals' own desires are internally inconsistent and, even where they aren't, they usually have to do some amount of compromising with competing goals in order to actually get something passed into law.
However, elasticity of supply and demand are major factors in considering the policies you mention:
'Sin taxes', on booze, cigs, hookers, etc. are designed to exploit elasticity in two ways: because kids tend to be fairly poor, since their labor force participation and share of capital gains are both low, they usually have very high elasticity of demand; their demand for a good will generally drop sharply, sometimes to zero, with even relatively modest price increases. Here, the 'sin tax' is basically a flavor of Pigouvian taxation, aimed at discouraging voters' children from doing things they don't want them doing. Among adult consumers(especially addicts, what great customers!), demand for sin goods tends to be inelastic, which makes taxing those goods a pragmatic revenue source, since the low elasticity of demand reduces deadweight losses from taxation and means that you won't reduce the number of sales you get to take a cut of by too much in taking your cut. So (while you aren't supposed to say it this cynically in public) 'sin taxes' are actually a pretty sweet deal: they are an easy sell, by tax standards; because they promise to curtail activity that voters dislike(thanks to the high elasticity side of the sin market); but they are also far better at revenue generation than standard Pigouvian taxation, thanks to the low elasticity side of the sin market, who will keep right on buying. It actually works pretty well.
In the case of minimum wage (aside from pure moralizing of the 'living standards below X are unacceptable per se' flavor), the assumption being made(exactly how accurately it is being made is arguable) is that what demand remains for low-skilled workers is actually fairly inelastic(which is less crazy than it might sound, since so much has already been offshored or automated, with the remaining demand mostly coming from people who need warm bodies on site in the US, or idiomatic native English proficiency, or the like); but that the bargaining power of low-skilled workers is approximately fuck-all, since the demand has plummeted from historical highs, and organized labor is nearly dead. If such assumptions are accurate(the second is definitely true, I don't really want to get into an argument about the first, merely to note that it is the assumption being made by those in favor of minimum wage increases), then it should actually be possible to increase the minimum wage without markedly reducing demand for minimum wage workers, since the employers who could make do with fewer(either through robots or China) have mostly already done so. Whether or not it is accurate, it is the operating assumption.
As for 'wage and price controls', I'm not certain what you are referring to. Nixon tried them, back in '71, as a counterinflationary strategy(outcome: unsuccessful) and more far-reaching measures were taking during the world wars; but the various regulations(local, state, national) that are wage or price controls of some flavor are rarely talked about in aggregate like that; and are a giant hodgepodge of various things.
Few companies have ever done that(probably not zero, I'm sure at least a few charities have been structured such that they count as 'companies' in legal terms); but any company with a PR budget has wished to appear (at least in part) to be doing that. Given the number and size of the world's PR budgets, I can only assume that a great many companies have wished to appear to do that.
I don't know how much Uber HQ values good PR, though given their zillion-odd entanglements in markets where they are dubiously legal, they probably should consider it; but if they do value it, the case to be made is pretty obvious:
Whatever Team Econ has to say about the wonders of equilibrium pricing and the joyous intersection of the supply and demand curves, it's pretty obvious that 'surge pricing' is not people's favorite aspect of Uber, especially during events that are seen as exceptional in some way(they scored some very acidic headlines during the Sydney hostage incident, as I recall). Even among people who reject economic moralizing, the existence of options markets is a convincing demonstration that people assign value to predictable prices.
On the other hand, it's also fairly evident that Uber's service will be less popular if it is seen as unreliable and more popular if people think of it as always delivering a ride on request.
If Uber wants to improve their image, they have the option of doing so by absorbing some or all of the conflict between these two aspects of their service in situations that would be likely to generate unpleasant attention otherwise. They don't have an obligation to do so(even if they did drop the facade of not being a taxi operation, taxi regulations largely focus on price not on obligating operators to operate at all times); but it is a fairly obvious way to buy more favorable opinion, which is something that profit-oriented companies routinely think is worth doing.
Assuming that the obsolete compute modules are of standard size/pinout (or, more likely, that compute chassis are only produced for phones that ship in sufficiently massive volume to assure a supply of board-donors), this scheme would work; but I have to imagine that a phone SoC would make a pretty dreadful compute node: Aside from being a bit feeble, there would be no reason for the interconnect to be anything but abysmal. For efficiency's sake, SoCs tightly integrate all the parts that need to chat at high speed with one another(along with whatever else fits, just to save board space), and only such interfaces as are absolutely necessary are brought out of the package, much less broken out on the board in some sort of civilized connector. In terms of dedicated interfaces you'll have some dubiously appropriate wireless stuff, a USB slave or host/slave interface, and a few GPIOs. The only options with really serious bandwidth or low latency would probably involve creative(and not necessarily possible, depending on the situation) abuse of camera and screen interfaces.
For all those nice, tractable, problems that behave well on loosely coupled nodes, each individually quite feeble, I guess it'll work; but that certainly doesn't include most of the really obnoxious computational crunching problems.
Slashdot Mirror
For long term maintenance of a low oxygen environment they are probably using a Nitrogen generator of some flavor. If you want the job done fast, the ready availability of liquid nitrogen is very handy: let one liter of that boil off and you get almost 700 of pure nitrogen. Just carry it down and dump it.
My cynical suspicion is that have a datacenter in an underground oxygen-purged bunker is something you cost-justify under 'disaster recovery' or similar; but actually do because of a vague, gnawing, ill-defined dissatisfaction with the fact that your life is basically as safe as it is tedious. The same sort of thing as why really boring federal agencies build huge SCIFs and random suburbanites lovingly shop for tacticool accessories to cram onto their AR-15.
That aside, I assume that they got it for peanuts compared to the original build cost, since abandoned bunkers aren't terribly high-value real estate(and potentially turn into blighted little holes if you don't keep them locked and have a cop watch the entrance moderately closely), and a cold war bunker is probably nice and sturdy, trivial to provide physical security for, and not too much more inconvenient than a situation where equipment has to be taken upstairs by cargo elevator. The oxygen purge seems harder to justify except for the cool factor, though.
Do staff go down with O2 tanks for maintenance, cleaning, server work, etc?
Easy problem. They just hired some Perl divers to do admin. Those guys can hold their breath for an impressive amount of time and are comfortable with CLI use, natural fit.
I wonder what constraints were placed on the problem that made "displace the oxygen in this sealed bunker" a two-year problem? Maybe it's a quote taken out of context and refers to how long the entire environmental control setup took?
I suspect that in a computer of that size you wouldn't want anything other than integrated graphics. Sure, AMD or NVIDIA could provide a part low clocked enough, or cut down enough, to fit within the size and thermal constraints; but once they've done that they probably won't be much better than the already-integrated graphics.
Unless you have enough room for a proper GPU, low end discrete GPUs are increasingly somewhat pointless, since they always add complexity and cost; but don't necessarily outperform integrated ones by all that much.
You'd probably need to use a different formulation than for cotton or cellulose based bills; but I suspect so.
Based on a look at paints sold for use on plastics and vinyl(like this one), the strategy appears to be to use a suitably nasty solvent as a carrier for the pigment and have the solvent infiltrate the polymer's structure, carrying the pigment with it. In a case where you need not worry about damaging the polymer(unlike commercial plastic paints, where the solvent can't be so aggressive that it messes up the underlying material permanently), like tagging stolen bills, you could presumably be particularly aggressive in your formulation.
I don't know the chemistry of the polymer and the protective coatings in common use; but you can usually find a solvent that will do the trick, especially if you don't mind a bit of damage to the material being worked with.
I'm not saying that SNMP is the correct mechanism for IoT, just that the state of discovery and interaction between IoT 'things' is so dismal(except where specially handcrafted by the vendor) that SNMP's MIBs look positively advanced by comparison.
Crazy-cheap silicon makes connecting things to networks relatively simple; but it doesn't solve the much more difficult problem of making those things interact in a useful way without either intricate top-down command and control or a ghastly nightmare of emergent oddities and security problems. At present, there appears to be very, very, little headway in making the 'things' that are supposed to be internetworking aware of one another, much less usefully so, with people either rolling their own totally isolated little thing or attempting to be the gatekeeper for all device interaction. It does not inspire confidence.
The trick is that security measures have costs, in time, money, user convenience, etc. and it is considered 'crazy'(in the weak sense of 'not sensible', not the psych-ward sense) to voluntarily impose costs on yourself that are out of proportion to the costs of the expected threat.
There's always something you could be doing more securely; but only sometimes is it worth it.
Speaking of AM radios and software on the victim computer: this classic.
Unfortunately only works on CRTs; but it's a heartwarmingly neat trick.
I'd be curious to know (I'm definitely underinformed, so this is an honest question) whether that tactic has lost some effectiveness over time. The classic monitoring-RF-to-read-CRTs stuff depended on getting an adequately clean copy of the distinctly analog output of the CRT. Now, all signals are fundamentally analog signals; but digital signals are analog signals designed to make guessing the correct value really easy(since there are only two possibilities, rather than an arbitrary number of them); and now more than ever it's a safe guess that sensitive data will be heading over a number of RF-emitting digital busses, from the keyboard to the computer, within the computer, and likely to the monitor as well.
Does the broadband noise still drown out the desired signal sufficiently to prevent reconstruction, or does our increased emphasis on high-speed digital busses (often designed to operate with some amount of error correction in the event of cheap lousy hardware being cheap and lousy) make it more tractable to either unambiguously pick the correct interpretation of a noisy input, or make a number of guesses and use known features of the bus to help eliminate the incorrect ones?
Doesn't FreeBSD run on toasters and have SNMP support? I was pretty sure that it did.
We also have a (general, not universal) willingness to let the market squabble it out for an extended period of time, rather than give a good hard shove in the direction of some implementation. This tendency may be abetted by the fact that early adoption creates incumbents who have a vested interest in stalling as long as possible to milk their legacy investments and first-mover advantage, as in our wonderful market for ISPs.
With the payment card industry, you have a lot of people(all clambering to grab as much of the cut for themselves as they can, and shove as much of the risk onto others as they can) with competing agendas and a desire to have their pet proprietary system gain a foothold so they can extract tolls with it(eg. the incidents where some retailers with functioning NFC POS systems were deliberately disabling them because Apple Pay was a competitor to their 'CurrenC' system, and the ongoing spat between Google and the carrier-backed payment scheme formerly known as ISIS before that became a toxic brand). Nobody actually believes that "USA IS #1!!! Mag stripes RULE!"; but between everyone wanting to control the customer data and processing fees and banks, merchants, and payment processors fighting over risk allocation, it's a bit of a clusterfuck.
Compare to say, the DoD's CAC rollout: CACs still aren't what you'd call a joy to configure(especially on OSX, or in Citrix environments, or other oddball use cases); but the DoD decided that it wanted everyone using smartcards for cryptographic authentication, said that that was how it was going to be, and it was so (relatively) quickly and smoothly.
Opinions vary on how often we dodge a bullet, or get the benefit of something new and innovative, thanks to there being no mandate in place vs. how often we suffer pointless bullshit for an agonizingly long period of time(eg. the less-than-totally-compatible US cellular market); but the fact that we tend not to mandate an end to such fights all that often, or all that quickly, is simply a fact. Even when we do mandate something, it's often a de-facto 'national' mandate created because California, or another large state, demands something and it's cheaper to sell California-spec everywhere than it is to have two SKUs.
Depending on how motivated the thieves are, it may be more cost effective to have some shock-sensitive dye capsules embedded. Since they'd only be breached in the event of an attack(or really serious damage to the ATM from other sources) they could last the life of the machine and be entirely passive. If you were feeling particularly motivated, it would cost only a modest amount extra to get an ink with a unique tagging agent, per ATM, so that marked bills could be traced directly back to a specific attack.
If a lot of ATMs are being blown up, or attackers are unconcerned by dyed bills(maybe because of literal laundering, maybe there are people who don't care?), then active defensive measures are more likely to save enough hardware to be worth the cost. If not, a passive capsule or capsules fragile enough to break during an explosion are simple, low-maintenance, and a fair deterrent.
Pretty much all embedded devices smart enough to support TCP/IP, as well. I'm pretty sure that my router is currently the most 'IoT' device in my house, though also the least conceptually novel.
There are some honestly interesting, tricky, and (at least partially) novel problems in 'IoT'. Making devices that are networked, can talk to each other, and actually do something useful with that ability is a real challenge. Even more so if you want compatibility between multiple vendors, support for use cases the vendor didn't more or less build for you(ideally without requiring that the user be a software engineer), or some semblance of assurance that there aren't a zillion security and privacy issues, innumerable covert channels, and other disasters.
My apathy is mostly derived from the fact that most 'IoT' doesn't actually seem to be doing much of that. Plenty of stuff that lets you use the internet as a very long serial cable to connect to its config interface(which is fine, the internet is a great way, if secured, of very, very, cheaply connecting from arbitrary distance; but brutally non-novel), some walled-garden 'ecosystems' that support very limited interaction of devices between two vendors who have explicitly agreed to cooperate and updated their products to make that possible; but otherwise it's mostly the same old IP-capable firmwares that devices expensive enough to have the capability have used for at least something like two decades. Useful; but not terribly new, and often implemented so badly as to be a liability.
It's honestly a trifle disheartening. While arguably in need of some serious maintenance(especially the 'security' of the earlier versions), SNMP is arguably closer to an 'IoT' design(pretty much just add the ability for devices to advertise their MIBs to other devices on the network, rather than having the admin hunt them down and load them, and you are closer to being ready than most actual products are). That isn't really a flattering thing.
SNMP is quite useful; but it is a bit crufty and conceptually ancient. The fact that everyone's shiny, new, 'IoT' things, with their markedly-more-capable-and-way-cheaper embedded hardware typically can't advertise their capabilities and manipulate one another in some vaguely sane way at the same level as some seriously old hardware is not terribly impressive.
Even if the actual implementation is some XML-soup-and-'cloud'-bullshit horror, conceptual parity or superiority would be nice to see.
I suspect that the mania will be tempered by the fact that it will be fairly easy to classify all sorts of projects, that you were already doing, as "IoT" if you wish to seem super cutting edge and so on without actually making any changes.
There's a vague sort of notion about what "IoT" is supposed to be, cobbled together from some mixture of analogies to SCADA and industrial control systems and science fiction; but it is broad and ill formed enough that all sorts of things that can connect to a network in some way, and any and all software associated with them, can be covered without stretching the truth too hard.
Plus, until the various squabbling factions decide how to actually make the 'things' interact usefully with each other(the current preference seems to be 'appoint either Google or Apple as Feudal Oligarch', with 'don't even bother, everything you buy will have its own terrible app!' as the runner up), the 'internet' bit is really just being used as a convenient remote access to the control panel(and for monetizing users, of course), which is much less hairy and challenging than actual interactions among things in some conveniently configurable and/or emergent-without-being-pathological way.
Any guesses about how many existing 'embedded system that connects to the internet in some fashion' projects were dubbed 'internet of things' in order to bring this new buzzphrase to prominence?
Yeah, yeah, I know, at some point the scale and pervasiveness of embedded connectivity may reach a point where it is different in kind, not just degree, from past use; but I submit that we aren't there yet by a nontrivial margin. For the moment, "IOT" seems to mean 'has a terrible smartphone app' or 'last model, you connected to the serial port to configure the system; when we revised the hardware it turned out that adding ethernet would be cheap and lots of customers wanted it, so we added it.'
I agree that an update to 802.11 would be nice, unauthenticated management frames are a potentially nasty issue; but the rest of the argument is nuts.
All sorts of crimes can be committed by means of a speech act(indeed, many crimes are hard to commit without some means of communicating, fraud, extortion, ransoming hostages, etc.); but that doesn't give them constitutional protection, any more than the argument that your god demands blood sacrifice would provide protection against murder charges.
This is classic Locke stuff: a restriction aimed at restraining speech is illegitimate and illegal; but that does not imply that the mere use of speech to commit a given act necessarily covers that act under the protections given to speech. Same with religions. Restrictions targeted at a given exercise of religion are unacceptable; but this does not protect someone who breaks a law established for suitable unrelated reasons.
There's also the (only partially related) matter that 'radio interference' need not always imply "really loud white noise or other stochastic garbage at the appropriate frequency". That's often the easiest way, and for relatively primitive radio systems that have very few features to exploit it may be the best one; but if RF emissions specifically tailored to cause a radio system to fail aren't 'radio interference', what exactly is? Higher level attacks offer substantial advantages in power requirements, precision targeting, resistance to noise-mitigation mechanisms, and so on; but just because they aren't pure noise doesn't make them not interference.
That seems like a fairly slim bit of legal weasel-wording given that nowhere is "your airspace" in the slices of spectrum that wifi uses. I would certainly agree that 'containment' should only be performed in 'your airspace'; but there is no such space.
In private buildings that don't offer guest services or otherwise accommodate outsiders, you can certainly disconnect anything you don't approve of from the wired LAN, and ask anyone operating a hotspot to leave or be removed for trespassing; but the notion that you enjoy preferential rights to that spectrum by virtue of owning the building is simply unsupported.
Next you'll be telling me you can create operating systems in less than 15GB!
Indeed they can. Unfortunately they decided to let the people responsible for ACPI actually follow through on that, and then decided that it would make a good bootloader.
What I find most baffling about the whole affair is how something that one would ordinarily think of as a fairly overtly malicious exploit, spoofing the appropriate management frames to break a network you don't have authenticated access to the configuration interface for, became a 'respectable' tool for 'management', even included out of the box in fancy commercial products from vendors with risk averse legal teams and so on.
This seems like the place where somebody who has been dealing with enterprise wireless gear long enough to have observed the change might be found. Did this 'feature' cross over from what was initially a proof of concept by a security researcher? Was it recognized as a possibility before the standards had even been hammered out and was available from day one? Do we know what vendor adopted it first? Were there any who specifically didn't offer it for legal, rather than technical, reasons?
At this point, it is certainly the case that at least some wireless management consoles adopt a very...possessive...tone, detecting 'rogue' APs, despite those APs being no more or less legitimate than any others, in terms of spectrum use, and offering 'containment' or various similarly clinical euphemisms for dealing with them. How, historically, did it come to be that this nasty DoS trick went all legitimate, even as generalized hacker hysteria can get you a stiff dose of CFAA charges for almost anything that involves a CLI and confuses the DA?
I'd love to have my hands on all the versions of various vendors' wireless management and administration packages, to see how this feature evolved over time. I can certainly see its appeal; but I find it hard to believe that nobody had serious doubts about its legality from time to time.
Less likely. The FCC is pretty clearly within their powers in saying that you aren't allowed to intentionally interfere with other people's Part 15 devices by using your own to generate disruptive RF.
There is no obvious coverage for forbidding the sale of devices having a Part 15 radio component; but lacking a software configuration for providing network access to other devices with that device. They might be able to shove it into the conditions of a spectrum auction, and make it binding on the buyer; but it's more of an FTC problem.
Does anyone know why they wouldn't sidestep the infeasibility of particularly long cable runs by having the elevator climb the walls of the shaft directly, rather than being raised and lowered on a cable? I imagine that a cable and counterweight arrangement is more energy efficient for shorter runs; but if that isn't an option wouldn't a cog railway style mechanism, with 'track' on one or more walls of the elevator shaft, result in a system where the weight that has to be moved doesn't change at all with the height of the building? There would be some additional weight per unit height from the track structure; but that would be static and connected to the building's frame rather than being forced to support its own weight.
Too energy intensive? Wears too quickly? Safety breaks infeasible leading to risk of sickening plummet to doom?
That's an OK rant, I'd give it a C+, or maybe a nice solid B, because of the pernicious influence of the 'self esteem' movement and grade inflation; but you need to remember 'elasticity'. It's a fairly important property of both supply and demand.
It is undoubtedly true that many political policies(across the spectrum, or whatever the geometry of your preferred political metaphor is) are incoherent, largely because many individuals' own desires are internally inconsistent and, even where they aren't, they usually have to do some amount of compromising with competing goals in order to actually get something passed into law.
However, elasticity of supply and demand are major factors in considering the policies you mention:
'Sin taxes', on booze, cigs, hookers, etc. are designed to exploit elasticity in two ways: because kids tend to be fairly poor, since their labor force participation and share of capital gains are both low, they usually have very high elasticity of demand; their demand for a good will generally drop sharply, sometimes to zero, with even relatively modest price increases. Here, the 'sin tax' is basically a flavor of Pigouvian taxation, aimed at discouraging voters' children from doing things they don't want them doing. Among adult consumers(especially addicts, what great customers!), demand for sin goods tends to be inelastic, which makes taxing those goods a pragmatic revenue source, since the low elasticity of demand reduces deadweight losses from taxation and means that you won't reduce the number of sales you get to take a cut of by too much in taking your cut. So (while you aren't supposed to say it this cynically in public) 'sin taxes' are actually a pretty sweet deal: they are an easy sell, by tax standards; because they promise to curtail activity that voters dislike(thanks to the high elasticity side of the sin market); but they are also far better at revenue generation than standard Pigouvian taxation, thanks to the low elasticity side of the sin market, who will keep right on buying. It actually works pretty well.
In the case of minimum wage (aside from pure moralizing of the 'living standards below X are unacceptable per se' flavor), the assumption being made(exactly how accurately it is being made is arguable) is that what demand remains for low-skilled workers is actually fairly inelastic(which is less crazy than it might sound, since so much has already been offshored or automated, with the remaining demand mostly coming from people who need warm bodies on site in the US, or idiomatic native English proficiency, or the like); but that the bargaining power of low-skilled workers is approximately fuck-all, since the demand has plummeted from historical highs, and organized labor is nearly dead. If such assumptions are accurate(the second is definitely true, I don't really want to get into an argument about the first, merely to note that it is the assumption being made by those in favor of minimum wage increases), then it should actually be possible to increase the minimum wage without markedly reducing demand for minimum wage workers, since the employers who could make do with fewer(either through robots or China) have mostly already done so. Whether or not it is accurate, it is the operating assumption.
As for 'wage and price controls', I'm not certain what you are referring to. Nixon tried them, back in '71, as a counterinflationary strategy(outcome: unsuccessful) and more far-reaching measures were taking during the world wars; but the various regulations(local, state, national) that are wage or price controls of some flavor are rarely talked about in aggregate like that; and are a giant hodgepodge of various things.
Few companies have ever done that(probably not zero, I'm sure at least a few charities have been structured such that they count as 'companies' in legal terms); but any company with a PR budget has wished to appear (at least in part) to be doing that. Given the number and size of the world's PR budgets, I can only assume that a great many companies have wished to appear to do that.
I don't know how much Uber HQ values good PR, though given their zillion-odd entanglements in markets where they are dubiously legal, they probably should consider it; but if they do value it, the case to be made is pretty obvious:
Whatever Team Econ has to say about the wonders of equilibrium pricing and the joyous intersection of the supply and demand curves, it's pretty obvious that 'surge pricing' is not people's favorite aspect of Uber, especially during events that are seen as exceptional in some way(they scored some very acidic headlines during the Sydney hostage incident, as I recall). Even among people who reject economic moralizing, the existence of options markets is a convincing demonstration that people assign value to predictable prices.
On the other hand, it's also fairly evident that Uber's service will be less popular if it is seen as unreliable and more popular if people think of it as always delivering a ride on request.
If Uber wants to improve their image, they have the option of doing so by absorbing some or all of the conflict between these two aspects of their service in situations that would be likely to generate unpleasant attention otherwise. They don't have an obligation to do so(even if they did drop the facade of not being a taxi operation, taxi regulations largely focus on price not on obligating operators to operate at all times); but it is a fairly obvious way to buy more favorable opinion, which is something that profit-oriented companies routinely think is worth doing.
Assuming that the obsolete compute modules are of standard size/pinout (or, more likely, that compute chassis are only produced for phones that ship in sufficiently massive volume to assure a supply of board-donors), this scheme would work; but I have to imagine that a phone SoC would make a pretty dreadful compute node: Aside from being a bit feeble, there would be no reason for the interconnect to be anything but abysmal. For efficiency's sake, SoCs tightly integrate all the parts that need to chat at high speed with one another(along with whatever else fits, just to save board space), and only such interfaces as are absolutely necessary are brought out of the package, much less broken out on the board in some sort of civilized connector. In terms of dedicated interfaces you'll have some dubiously appropriate wireless stuff, a USB slave or host/slave interface, and a few GPIOs. The only options with really serious bandwidth or low latency would probably involve creative(and not necessarily possible, depending on the situation) abuse of camera and screen interfaces.
For all those nice, tractable, problems that behave well on loosely coupled nodes, each individually quite feeble, I guess it'll work; but that certainly doesn't include most of the really obnoxious computational crunching problems.