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.

This. We got 7 billion people - probably closer to 10 before it peaks, and as a minimum I should have one IP address at home, at work and for my cell phone. So 3*10 billion is 30 billion, IPv4 can offer 4 billion. And that's not counting every other odd thing I might want, like remote-controlled alarm/heating/whatever at my cabin or my car, servers of various kind and maybe IoT will become good for something.

Of course they probably could have just done it much, much simpler by making a dotted quad a dotted quint:

1.2.3.4.5

For compatibility each host under 1.2.3.4.x is granted 256 ports IPv4 ports mapped from x*256 to (x+1)*256-1 to a designated "IPv4 compatibility ports" like say the last ports from 65279 to 65535. So 1.2.3.4.1 can either be fully addressed by quint-capable equipment or 1.2.3.4:256-511 that'll be mapped to 1.2.3.4.1:65279-65535. And 1.2.3.4.2 will have 1.2.3.4:512-767 mapped to 1.2.3.4.2:65279-65535 and so on. You could use the same technique to provide a virtual IPv4 interface for legacy software, it thinks it is listening to 1.2.3.4:256 but it's really listening at 1.2.3.4.1:65279 - and any application it tells to connect to 1.2.3.4:256 would work.

That would have led to a gradual 256-times expansion of the address space without any hard switch-offs. But instead they decided to solve everything and now 19 years after the IPv6 standard we're still only barely in motion.

The very page you link to says:

What's ICU?

Not sure exactly how much Qt functionality you'd lose, but it's an optional dependency.

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.

Or maybe it's okay if systemd fucks up all the servers running RHEL 7. After all, nothing important runs on that. So let's check, is Red Hat Inc. tanking and considering backtracking? Hell no, they're growing strong both in revenue and profits in the year that's passed since. So if a $14 billion dollar company can make systemd work for them, it probably can't be that bad. Or if it's bad, well then rip out the bad parts like write a non-binary log because how hard could it be to take the binary messages, printf and log the text in addition to/instead of a blob? Sometimes it sounds like the only two options is to drink the kool-aid or nuke it from orbit.

Not sure if you're stoned or trolling or dropped out of a time vortex from the 90s, but

1) GUI installers have been the norm for desktop oriented distros for years, mostly through live CDs.
2) For most of Linux history there's been zero credible competitors to X
3) Wayland is mainly driven by ex-X developers
4) Wayland will still need drivers to have accelerated graphics

5) Neither application developers nor users usually see X, you write against for example Qt and the toolkit takes care of talking to X. They might hate X, but they hide its quirks pretty well.