A mixture of both. The AMT system includes a dedicated ARC cpu, which runs its own OS and functions independently of the host to a large degree; but also can see into, and sometimes make use of, some of the hardware visible to the host system(details depend on version). For communication, for instance, the AMT system has access to the wired NIC below the OS's view(wireless NICs are more complex, I think AMT can do a direct connection to a trusted AP if configured to do so; but can't do VPN without piggybacking on the host OS), and it also has enough hooks into the various peripherals that it can do remote KVM in hardware, by emulating HID devices and snooping the framebuffer, mount an .iso as though it were a connected SATA device, and access some storage and memory locations that are also accessible to the host OS or programs, in order to gather data on system health, software versions, etc.

I'm not exactly sure how the BIOS/UEFI flash and the flash that stores the AMT firmware are related to one another. On computers with AMT, a 'bios update' will often flash both; but I don't know if that's because they are just different areas of the same SPI flash chip, or whether it's just a convenience bundling of two nearly unrelated updaters.

They all tend to be fairly miserable(though thermal issues are often more a product of the desire to have more space for ugly branding and fewer vents, which can be fixed with a bit of applied violence); but I do have to give the hardware credit for often being rather amazing for the price. The firmware is shit more or less across the board; but it is astounding how much actual computer they can cram into a $20 router.

Any remote management tool would be a 'backdoor', except that it is put in place by the owner for their convenience and with their consent.

AMT is a particularly powerful, and somewhat opaque, management tool. Anyone who suspects the possibility that(deliberately, or by mistake) those very, very, useful capabilities might be available to others under some circumstances would naturally be suspicious of it.

And, for the FSF and those who share their concerns, the fact that it is a wholly proprietary(and tricky to remove or replace) blob embedded in the brainstem of their computer is not something that would make them happy.

That may differ between laptops and desktops, or between AMT versions. On the desktops I've seen the AMT stuff is active if the PC is plugged in, regardless of its power state. Some of the capabilities of the AMT system cannot be used if the host PC is off; but the system itself runs on a separate processor and only turns off if the PSU is unpowered. Laptops may need to be more conservative, for the sake of retaining battery life while inactive.

Speaking of Dell, failure, and lawyers, back during the 'capacitor plague' era the law firm that Dell retained to fight capacitor-plague related lawsuits was itself stuck with capacitor-plagued Dells. I can only imagine that their IT people saw the humor in the situation. True story.

If your machinist is good enough you can probably fit a V12 in a wristwatch. It's just that all those cylinders will be very, very, tiny and the actual power generated will be rather unimpressive.

If you wanted the same effect in a laptop, you could probably add a GTX980 (250watt TDP) to this laptop as long as it was clocked at maybe 50MHz, rather than the usual 1100.

average user wont be able to, but many hobbiest users will.

once the code is done and an example circuit is created, its just copy and paste. hell, I'd do a sample just for grins. I find the whole idea WRONG to put limits in the code like this, so I'd be happy to write some sample code that will remap gps data on a serial line. but seriously, its not at all hard.

The trouble is that the entire i5-5200u, CPU and GPU, is also 15 watt part. Unless Dell is somehow just throwing away usable space inside that case, I suspect that fan noise, battery life, or both are going to hurt if you double the demands of the core silicon.

I don't know exactly how much you save if you wholly disable the GPU portion of the intel part, probably a little less than half, so even in that case you are talking about a pretty substantial bump in thermal load.

I don't deny that the integrated graphics are feeble, merely note that you are unlikely to get anything exciting into hardware that size. Even if we assume 100% efficient disabling of the integrated GPU, and savings of ~50%, a discrete GPU arrangement would involve a 50% TDP increase. If the integrated graphics can't be cleanly disabled, it might creep closer to doubling. I doubt that that would be a pleasant machine to work with.

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.

gps modules almost always use low speed serial (ttl) comms.

it would be trivial (50 lines of C code, maybe much much less) to have a cpu (even attiny) in the middle between the gps module and the rest of the brain. when the x,y values come back and its inside a 'nfz' it could easily be remapped (in simple ascii) to NOT be in nfz. perhaps if you are near a nfz, it would go into auto-offset mode and add a fixed x,y value so that it thinks its miles away. then you compensate for it at the ground level when you program its course.

would not be hard at all.

waste of time to try to disallow x,y values for things like this. anyone here who spent a few weeks on even a simple arduino could do this remapping in an afternoon.