On the plus side, unless WWIII is breaking out(in which case the personnel getting burned out is likely to be a trickier problem; but also one you'd encounter regardless of spare parts), you can probably swap out crew more easily than you can parts(especially the larger ones, or the more sensitive ones that you can't just put in checked baggage); unless the ship is in the midst of active hostility, in which case the crew would be pretty dumb to sabotage equipment that increases their odds of making it home alive.

With humans, you have some uncertainty(accidents, unusual medical issues, the occasional psych freakout or disciplinary problem); but the approximate rate at which you need to rotate people to keep them from burning out is comparatively predictable. With spare parts, there are some you know you'll need; but an impractically bulky number of ones you might need; but can't say for sure about. Much easier to ferry out a fresh batch of crew every X months than it is to guess, sufficiently far in advance, what parts to put on the next supply boat.

It's true that 3d printing isn't going to solve all your problems; but some are likely to prove hairier than others:

Microchips are a pretty nasty case. Between long development cycles and the demand for mil/aero rated and otherwise hardened versions, military gear is quite likely to be riddled with already-obsolete parts by the time it is formally declared 'finished', much less when the Block N variant is still in use 30 years later. Unfortunately, fully accurate emulation of even relatively feeble digital ICs can be fairly tricky(just look at how much effort it takes to get a 100% binary compatible emulation of the NES' less-than-heroic 1.8MHz 6502; never mind newer stuff or analog/mixed signal); and even painfully obsolete IC fab processes are orders of magnitude smaller than alternate fabrication technologies are good for.

Boards and wiring harnesses are also less likely to be amenable to 'just press print and away you go'; but unless you've destroyed the schematics and for some reason can't tell your multimeter minions to trace it out; such relatively large assemblies should be easier to reverse engineer if necessary and rebuild as well or better with modern parts.

Parts, depending on their size, may or may not be amenable to direct 3d printing: if you go with the really fancy processes, smallish parts with comparatively obnoxious-to-machine properties might actually be easier to print than to produce by the original methods. In other cases, you might not 3d print the parts directly; but you could use 3d printing to greatly speed up the re-creation of tooling necessary to fabricate parts(sintered copper, say, is not terribly useful as an aerospace material; but if you need some tooling in stainless steel or another material that's a pain in the ass to machine precisely, being able to sinter copper to your preference, and then do sinker EDM could save you a great deal of time.)

I suspect that some older designs, unless we consider them worth a fully reverse-engineering, are now too ill-documented to be revived; but given that any current design(and probably some moderately old ones) do have CAD representations produced during design and construction, suitably robust printing technology, in combination with some other techniques, we aren't going to just nanofab them all in one piece), does hold promise.

Except for ICs, not sure what is to be done about those. Given economies of scale in the IC market; it might actually be easiest just to adopt the brute-force-and-ignorance approach and order 100x or even 1000x as many as you need, when constructing a system approved for service, just in case it ends up lasting a long time. Yeah, it will look wasteful, and some of the time it will be a waste; but economies of scale will soften the blow a bit; and you'll be saved having to source second or third hand ICs scavenged out of e-waste by the Chinese and fraudulently re-marked as new old stock; which is probably a good thing for system reliability.

This seems downright unamerican! If a branch of the armed forces develops the ability to do something internally, how can it be contracted out? Perhaps congress will oblige us with a variant on the farm bill; and ensure 'price stability' by paying the former producers of now 3d-printed parts to not produce them.

Surely a game involving real-world locations, submitted by players, is so obviously vulnerable to metagaming attacks that it's almost hard to consider them metagaming at all, rather than part of the game?

I think that 'organic engagement within a rich ecosystem' is something that you usually have to visit a tropical medicine specialist to get cleared up; horrid parasitic infections, that sort of thing.

I understand all that. I used Qt myself, but just for simple GUIs. I was just wondering what his real world numbers were. I was not challenging him for his choice. I know the micro-benchmarks between native and VM code. I was curious of how things fared in his larger apps. I normally do JVM for long-running server code, but C++11 and onwards is increasingly attractive, although JVM is still a bit simpler to work with, on the whole. I am exclusively interested in his (or anyone else's) real world experiences on the performance differences between JVM HPC code (server VM config) and C++ server code that uses Qt as the main library.

I don't disagree with anything, but I am just curious: what kind of improvements did you get with C++/Qt stack over say, Java or Scala? (I am assuming you evaluated alternatives) Say, over 2x improvement in performance? Much lower memory utilization?

I can't imagine that the DoD would be happy with DHS clowns guarding something that they actually cared about. Though, if the alternative is G4S, maybe they'd take it. I'd certainly want to be rid of whoever thought that training with doctored MILES gear was adequate.

The 'feature' occurred on Windows Phone first, not sure exactly what version. I assume that it made a great pitch to prospective carriers, since they all love offloading customers onto anything that isn't their data network as often as possible, and typing passwords into your phone is a pain, so automating it likely increases network offload considerably.

Just as they say, in the context of backups, that 'if it isn't automated it won't happen'; there is likely to be a considerable difference in the rate of unintended leakage between a 'yeah, I guess I did tell Bob the password, he could pass it on' and 'the password spreads through your entire social group like a bad chain email'.

This sort of 'friend/acquaintance' attack attack is also exactly where slightly-too-automatic automation makes it really easy to bypass what limited good sense about security humans do have.

If, say, Alice and Bob have just had a messy breakup; it would be fairly obvious to any mutual friend of the two that sharing one's wifi password with the other, or a known friend/agent of the other, is something that they wouldn't like. They might do it anyway; because people are assholes like that sometimes; but it would be deliberate. Social-engineering somebody in that situation into telling you the password might be vaguely tricky. Social-engineering them into making you enough of a contact/friend/whatever on the services that this 'wifi sense' system uses to receive the password should be absolutely trivial; quite possibly already done.

I suspect that it isn't for nothing that this 'feature' first appeared on Windows Phone; carriers adore the idea of getting the filthy customers off the cell data networks they pay for and onto wifi as often as they can, and don't much care about a bit of collateral damage inflicted by dumb implementations.

What I would like to see explained in more detail is the claim that 'wifi sense doesn't reveal your plaintext password' during the sharing process.

My understanding was that(except WPA2 with RADIUS and a suitably chosen EAP) there isn't any provision for authenticating to a password protected AP without knowing the password. The AP itself might be able to destroy the password after it has been set, saving only a hash, as is good practice to keep more important sets of usernames and passwords from being compromised; but the client requesting authentication needs the password. The non 'enterprise' cases were designed to be easy to use, not particularly clever; and MS has limited room to get creative without causing nasty breakage on large numbers of variously dysfunctional legacy APs.

With a proper full WPA2 setup, or with one of the 'no authentication at the AP; but captive portal and/or VPN is the only way to access anything interesting' arrangements, you have more options; but how can you 'share' authentication to a WPA-PSK or WEP network without also sharing the key? Did they actually come up with something really clever, or does the UI just not show you the password, thus 'hiding' it?

Surely this is the logical place to insert "In the public sector, they cut corners to waste money!" and then talk about military contracting for a while.

Did you bother to even skim the article? It was essentially entirely focused on human and organizational risk factors, the sort of thing that anthropologists do actually study, in US nuclear facilities and preferred methods of securing them.

If the concern is "will the roof resist a hardware-store-improv mortar attack?", sure you don't want an anthropologist on the job. If the concern is "so, will the guards notice, give a damn, and do something about it; or will I just have to walk past a token force optimized for cheating its way to passing grades during perfunctory audits at lowest possible cost?", that's an anthropological question. And the answer appears to tend toward the latter.

Surely the proposal will be scuttled when the realize that driving the gambling operations out of the province will sharply reduce the number of them that give due prominence to French language text; and acknowledge the right of the people to lose money without brutalizing exposure to anglicisms.

Technically the gun 'works'; but the vendor is too half-assed to actually provide drivers for the gun until some later revision, for which we will presumably pay more.

Optimists prefer to focus on the fact that, in order to preserve the oh-so-sexy-low-radar-signature design, the system only holds 200 rounds, so nobody expects much of it even when the pilot is able to use it.