Because of inherent drift, inertial navigation is inherently suited only to fast vehicles that get to where they're going in just a few minutes or hours, e.g., planes and missiles. Cargo ships do not qualify. It is best combined with GPS to "flywheel" through outages (e.g., vehicles in tunnels) and so it can be automatically recalibrated whenever GPS is available.

Besides LORAN-C, there used to be another low frequency radio navigation system even better suited for global shipping: Omega. It operated on even lower frequencies, in the 10-14 kHz (yes, kHz) range, and had worldwide reach unlike LORAN-C which was only regional. It was shut down in 1997.

I certainly wouldn't bet that GPS satellites couldn't be destroyed, but most anti-sat weapons demonstrated so far work only on low altitude orbits. The US systems consist essentially of lobbing a small suborbital missile up in the path of the target satellite. Destroying a GPS satellite in a 20,000 km orbit takes a much bigger launch vehicle and considerably more time, and would be much harder to conceal from US space sensors.

Jamming and spoofing are the much bigger threats.

LORAN-C would probably be rather resistant to EMP. Like just about everything military, the transmitting equipment would be designed to be EMP-resistant, and receiving equipment on vehicles would not be particularly susceptible. It's stuff with long cables that picks up EMP. LORAN-C is certainly much more jam-resistant than GPS. The transmitter power levels are/were enormously higher, some in the megawatt range, to overcome natural background noise and antenna inefficiency. Even the large towers used are only a small fraction of a wavelength (3 km). Also, LORAN-C operates by groundwave propagation (that's why the frequency is so low) so it's not very sensitive to solar activity.

That was probably LORAN-A, with which we used to share the 160m band (1.8-2.0 MHz). LORAN-C operates (or operated) in a dedicated allocation at 100 kHz. LORAN-A was shut down quite a few decades ago.

Actually, the US military has a very simple way of selectively shutting down GPS: they locally jam the L1 frequency. The satellites also transmit on a second frequency, L2, with an encrypted, high precision "P(Y)" code for which the keys are closely controlled. They have receivers that can work with just the P(Y)-code, so it doesn't matter to them if L1 is jammed.

No. I think I understnd how to interpret a commit log. If the commit was from a trusted source, ignore it. You have just narrowed down your search by at least 2 orders of magnitude. If you have a suspected commiter, scrutinize them. Commit logs go a very long way to taking your OMFG How will anyone analyze every change! to a pleasant rejoicing song of: Hey, it turns out we only have to review a very small subset!

There is no old code; only old auditors :-)

I can assure you, when I analyze any hardware/software system I don't in any manner way shape or form categorize anything, or base any decision on the age of, and subsystem.

I doubt I'm the only competent analyst.

Non-sequitur much?

Somebody should invent commit logs!

"But with Linux most contributors, be they individuals or companies, are primarily concerned with their own projects."

Your definition of contributor is skewed. A FOSS contributor may do so in many ways. Clearly a project lead for a major project isn't going to contribute further by analyzing the ecosystem; their plate is full. There are others, also known as contributors, who do this. Other contributors administer project websites or write documentation. There is a whole wide array of types of contributors.

That being said, clearly there are more developers than people doing security audits, and it would be nice to see more contribtors in all the other categories, actually.

That is correct. In the world of the big boys we release updates on a moment by moment basis, thereby avoiding as much as a months delay for no good reason. :-)

In Open Source vernacular, we call that becoming more and more secure :-)

And how, prey tell, do you expect the developers to sign their packages with everybody else's private keys? If they do that the update will fail, because the package manager isn't going to install a package from an Ubuntu repository that isn't signed by Cannonical's private key, for example.

I'm as surprised as you are...

"... for those that were stupid enough to think that something electronic and stored in a common format over a common communications medium was secure.

Stupid enough? I hate to break it to you, but most if not all secure systems work in exactly the way you decry to be "stupid". Maybe you've heard of SSL?