elfchief

That's the thing -- I do want to use the UI and I don't want to have to hand-edit XML. I just want the UI to not use the single worst dialog box in all of windows.

I am baffled at why Backblaze clings so tightly to the existing dialog box.

I've only ever had one problem with Backblaze, in my ... 7 or 8? ... years as a customer.

The problem: The UI for excluding directories is horrific. It uses the Windows "Browse for Folder" *SHBrowseForFolder) dialog, which requires you click down through each and every level of your directory structure to get to the directory you want to exclude. You can't cut and paste, it doesn't start from the directory you added your last exclusion in, it's just lots and lots and lots and lots of clicking.

This doesn't seem like it would be hard to fix, so I'm guessing they don't consider it broken?

If the Backblaze folks are still reading: Could you please, pretty please, with sugar on top, for the love of god, fix your fucking exclusions interface? Please?

Not the OP, but it'd see it as multiple SVs. Basically you figure out what the range would be from the SVs to whatever location you want the things to think they're at, and put out all the signals to make that happen. Spoofing a single SV is pretty useless, you have to spoof at least enough of them to give you a position solution.

There's a bunch of maintenance stuff that happens regularly that's on that list... FCSTDV (stationkeepng burns), FCSTMX (scheduled maintenance, like switching to a different atomic clock or the like), that sort of thing.

There's a lot of recent UNUNOREF on the agi.com link in this thread's grandparent, which is basically "it broke and came back before we could send out a note". If you look closely at that list, though, you'll see that almost all of the recent events are a single satellite -- PRN18. I have no idea what's wrong with it (and AFAIK there's no way for the public to get the details), but it's been going unhealthy for ~2 minutes at a time for months now.

(I'm guessing they keep it live because either don't have another satellite positioned so they can put it into that slot easily, or because they don't consider whatever is wrong with it to be a huge problem.)

This ended up not being a problem with the GPS system at all -- it was actually a certain brand of receivers not dealing correctly with leap seconds[1] -- or, specifically, that it's been a while since the last leap second, which caused one of the GPS parameters (basically 'how long since/until a leap second' to roll over, which is not normally a problem, but thanks to a receiver bug, it was, on these specific receivers. This was covered in some detail on the LEAPSECS mailing list.[2]

[1] https://www.flyingmag.com/collins-receivers-struck-by-failur...

[2] https://pairlist6.pair.net/pipermail/leapsecs/2019-June/0071...

Nominally, yes, but the positioning error (according to the spec) is expected to be up to 425m after 14 days, growing worse over time until it hits a positioning error of ~10km at 180 days.

(later generation satellites have an 'autonav' mode that presumably makes this less severe (by using SV-to-SV ranging and such so they're not completely blind to changes), but Galileo may not have that capability or there might not be enough SVs to use that capability yet)

They do (that's literally how GPS/GNSS works), but they drift, for various reasons. One of the parameters that GNSS networks broadcast is a clock correction (how far off each individual satellite's clock is, how fast it's changing, and how fast how fast it's changing is changing), and those parameters come from the ground stations.

It seems like a little drift shouldn't make that much difference, but keep in mind that the speed of light in a vacuum (or air) is about 1 foot per nanosecond, so for every nanosecond one of those clocks has drifted, that's a foot of positional accuracy you no longer have...

The week number is (somewhat) used for navigation, but the way it is used is not affected in any way by the rollover, and there's not really a way (even taking into account bugs) that not knowing what the current GPS epoch is could affect navigation. This is purely a matter of an issue with the time that's output for human consumption, the GPS functionality itself doesn't care in the least.

If you want this straight from the spec, grab a copy of IS-GPS-200J (it's free, just google it), look at section 3.3.1.1, which talks about the carrier frequencies of the various signals. From that:

"The carrier frequencies for the L1 and L2 signals shall be coherently derived from a common frequency source within the SV. The nominal frequency of this source -- as it appears to an observer on the ground -- is 10.23 MHz. The SV carrier frequency and clock rates -- as they would appear to an observer located in the SV -- are offset to compensate for relativistic effects. The clock rates are offset by (delta f)/f = -4.4647E-10, equivalent to a change in the P-code chipping rate of 10.23 MHz offset by (delta)f = -4.5674E-3 Hz. This is equal to 10.2299999954326 MHz. The nominal carrier frequencies (f0) shall be 1575.42 MHz, and 1227.6 MHz for L1 and L2, respectively."

In this context, "SV" is "Space Vehicle", a.k.a. a GPS satellite.

You also have to make a relativistic adjustment in the user segment (aka "your GPS"). You can see an example of doing this correction in open-source software GPS receivers, for example https://github.com/jks-prv/Beagle_SDR_GPS/blob/de895035e93ba... . This adjustment is documented in the above spec, in section 20.3.3.3.3.1 (which you'll see is almost verbatim copied into the the code linked above)

Sure, gps geek and time-nut here.

The rollover problem is a hard one to fix, because there's no reasonable way for a GPS (at least one using LNAV (legacy) signals -- pretty much all of them, though I don't know what modern passenger jets use) to know which GPS "epoch" they're in. If you don't know what epoch you're in, you don't know what the date is.

Some GPSs solve this by recording the week number of their firmware build, and if the signals they get indicate the week number is less than that, they assume they're in the next epoch and update accordingly. Still means you run out of time, but you get a full ~19 years of life first (and then fail at some random GPS week). Some use fuses to record when an epoch has passed. Some use out of band information. Some store the current epoch in flash or battery-backed RAM. Some just never address the problem.

Thing is, though -- the only effect this has, is that it makes the GPS return the wrong date. That's it. The week rollover has no effect on navigation unless there's some significant bugs in the unit, or something external to the GPS relies on the date being output and doesn't deal well with the date suddenly going back in time. That's it.

I'd be kinda shocked if airplanes were just jam-syncing the clocks of their nav computers to the output of a GPS, and then had those nav systems be dependent on that time. But then again, I work in the tech industry, and I've seen the kinda code that goes into most products, so maybe I wouldn't be that shocked.

(I also can't imagine that GPS units used in aircraft aren't directly tested for their behavior during the week rollover. It's a well known and understood problem, and even if some random GPS manufacturer drops the ball, stuff that goes into aircraft has to go through certification for a reason...)

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.