elfchief's comments

Untrue. There's a newer format for NAV data -- CNAV. It's currently broadcast on the L2 and L5 bands, and does indeed include a larger week number field -- 13 bits to be exact.

This is like saying "there's no point in ECC if it can't correct every error" ... which simply isn't true. It's still far better to know that corruption exists -- so you can know something is invalid and potentially take action -- than to have corruption silently hanging around doing corrupted data things.

Is it just me or is it absolutely insane that zfs and btrfs are the only common filesystems out there that do data checksumming? I don't want or need the extra complexity of either of them in a lot of cases, but I'd sure as hell like to know if my data is corrupt...

Now if only they'd sell me one. :/

Huh, weird. I ordered some CHIP Pros and dev boards in February last year, and got them in ~2 weeks. I haven't ordered from them since, so maybe they went defunct or something. I dunno. That's too bad. :(

Instead of the pi zero, check out the CHIP Pro (https://getchip.com/pages/chippro) ... a little more expensive, but available in quantity and designed to be pick & placed (or hand-soldered!), runs linux, and does most of the things a pi can do (sans video)

What the link doesn't mention, that I can see, is what the first version affected was. Does this bug go back to the inroduction of submodules in git?

The 9/11 firefighters (especially the first responders that went in before the towers fell) were heroes by just about every definition, though. They risked (and in many cases gave) their lives to try to try to save innocent people. They weren't trying to save their own necks, like a pilot would be. If that doesn't count as being a hero, I'm pretty sure nothing does.

The main things that cause loss of GPS 'lock' are the satellite signals being blocked (buildings, terrain, people, etc in the way), and multipath (signals being reflected off buildings, terrain, etc). A munition a few thousand feet above the ground has none of those things.

(There's also 'GPS jamming', which is totally a thing in war, but that's not really 'like our phones', generally.)

As other posts have mentioned, though, GPS is simply one input into weapons systems, not the input into weapons systems.

I don't know for a fact how they manage it, but I bet the feedback is slow enough (those generators are heavy, and it probably takes a few cycles to even accurately measure a change) that they might not have to do much in the way of actively managing that feedback. The system will oscillate a bit (as it did in that video), but there's nothing inherently wrong with that, as long as it's within a certain set of limits.

(And really, the load changes are typically more gradual. Even "everyone just got home from work" is a fairly spread out event, compared to, say, the sudden loss of a few hundred MW of generating capacity...)

One interesting thing about the "load changes the frequency" thing is that if you measure the frequency in enough places, you can actually see how large load changes "ripple" through the system.

For example, there was a big power outage in Florida in 2008 that caused a generator to suddenly go offline, and several orgs had a couple dozen power frequency meters running on the grid at the time, so they were able to make an animation of the east coast power grid "ringing" over the course of about 10 seconds as the load changed rapidly throughout the grid.

The animation for that is here: https://www.youtube.com/watch?v=bdBB4byrZ6U

Now what I would like to know is ... is this perl code on github?

I doubt you can even hit a target directly under you from a satellite in geosynchronous orbit, at least without a fairly significant amount of effort. You can't just fire a rocket "straight down" -- if you just point at the Earth and thrust, you end up in an elongated orbit that misses the earth entirely.

...and since you have to be moving faster to hit geosynchronous orbit, you have to have a lot more ΔV to get back to the earth than if you were in a lower orbit, which means more fuel, which means more weight, which means harder to get into that orbit to start with...

Oh, and since you're still moving when you're doing that ΔV maneuver, you'll end up in a lower (and not-geosynchronous) orbit before you get all the way to the planet, so the payload would probably end up doing a few orbits on its way down anyhow (at which point, why care if you're "over the target")

Yeah, this is really weird to me. They're talking about installing sensors on particular tracks and the like, after saying that it's GPS-based, but... why? Stick a GPS on the engine, load a database of maximum speeds, get instant safety. What'm I missing?

(Yeah, you have to integrate with the engines themselves, but that seems like not a 6-year project, and especially not once it's been designed and tested. It probably also won't account for "stop, there's something else on the tracks", but just speed-checking seems like it would be a massive reduction of risk with very little complexity...)

The PPS is just something you get when the GPS chipset has a lock, though (and sometimes when it doesn't, depending on how you have it configured). Most non-timekeeping GPS chipsets give you a PPS output for free, and 100% of timekeeping GPS chipsets give you one.

Pretty sure about 50ns. Datasheet for the Trimble Thunderbolt E: http://trl.trimble.com/docushare/dsweb/Get/Document-383329/0... ...second page, "PPS accuracy: 15ns (one sigma)" (I picked a larger number than the spec sheet simply so that hopefully nobody would go "oh, that's the ONE SIGMA value, lets argue".)

My Thunderbolt, in a completely temperature-uncontrolled environment with ~20 degree daily swings, generally has a PPS accuracy of ±45ns, in what is pretty crap conditions (first rule of precision timekeeping is "temperature stability")

Having an atomic clock behind your NTP server doesn't really gain you anything unless GPS is lost for an extended period of time. As long as a timeserver has a GPS lock, it's going to be disciplining the atomic clock the same way any other clock is disciplined, so you don't really gain anything. Even a cheapie timekeeping GPS chip can get down into the < 500ns accuracy range (and the Thunderbolt on my desk will get down to < 50ns).

(You can gain a little accuracy if your timeserver itself is running its main clock (the one that drives the CPU and all the busses) off of a precision frequency reference, be it GPSDO or atomic clock, but that's a separate discussion)

Oh, and if you're using NTP and not directly connected to a precision timesource (not over the network), you may as well give up on that level of precision anyhow. For that you need PTP.

I would really like #2 to have the option of sending encrypted files on disk or zip, and y'all providing a client that will decrypt them using my passphrase, locally.

Nothing personal, but I really don't want y'all seeing my data, even if I need to restore.

(context: I've been a Backblaze user for years and love the hell out of you. I've never really thought of how the restore would work with my encrypted data, though. Turns out the story is ... not what I had hoped)

Now, if Yahoo would just open source the yinst/opsdb/rolesdb/igor/etc ecosystem. I miss that elegant tooling so fricking much.

Now, if only all of microtype's features were available in Lua(La)Tex. They're the sole reason I'm still using pdfLaTeX, even though I end up not able to use opentype fonts. :/

Pretty much this. I have a pair of studio monitors set up for music and tuned for music. Game audio and random youtube videos don't sound so great with that setup, so I don't want it to be my default.

Sure, I could change the default every time I fire up Spotify, but that's annoying and I really shouldn't have to do it -- this kind of setup is not that unusual for music lovers, and it's not a difficult feature to add.