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.

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.

Because a drone can autonomously delivery a brick of C4 to within a meter of where you want it to go on your first try. And you can be miles away while it does that. "Miles away" is also handy if you're using it to deliver an aerosoled nerve agent or some bio-nasty substance over, say, a presidential press conference in the Rose Garden, or a speech on the steps of the Capital.