elfchief's comments

I love Backblaze, I really do, but holy hell is the user experience bad if you ever need to actually interact with any part of their software -- client or website. And it's been that way forever, and it's super frustrating that it seems like they've put zero effort into improving any of it.

Though reading some of the "backup got frozen, compare everything by hand" stories from here, I'm starting to wonder if maybe I shouldn't put my data somewhere else. Problem is, I've yet to find another "fire and forget" type of wolution for windows that works anywhere near as well.

I don't suppose you have any idea if there are publicly available motion amplification tools, yet?

I came here to say exactly this. Ligatures make a -huge- difference to me, please offer some example text that makes use of them.

Also, please make it an option to hide the font names so that it is a true blind comparison.

Awesome idea, though!

Git was not intended (AFAIK) to be cryptographically secure. Being unsuitable for crypto != being unsuitable for other uses.

I'd say they should do one of these for police shootings, except the whole system would probably overload and melt down.

Everybody is mentioning Bitwarden as a replacement, but what about Dashlane? I've had my eye on Dashlane for a while, and it seems on-par with lastpass, so I'm confused why it isn't mentioned in this discussion more.

(to be clear: this is a genuine question, not an attempt to stealth-shill for Dashlane)

From the article:

> Why is it 119.88 Herz, not 120 Herz? No idea.

The short version of this is that TVs generally have framerates that are a multiple of 59.94, because NTSC is actually 59.94Hz (rather than 60), for various historical reasons -- basically, for color TV to become a thing, without obsoleting every single B&W TV in existence at the time, they needed to slow the framerate down by 0.06Hz[1]

There's still plenty of TV-targeted panels out there that only do 59.94Hz, and not 60Hz. Some of them are even in computer monitors! I imagine likewise that there are a lot of panels that do 119.88Hz (59.94Hz * 2) and not 120Hz.

And just to be confusing, a number of things (both hardware and software) tell you that you have a 60Hz signal when you actually have a 59.94Hz signal! A really good example is windows -- refresh rate settings in the OS get quite interesting, showing 59.94 in some places, and 60 in other places![2]

[1] https://en.wikipedia.org/wiki/NTSC#Color_encoding

[2] https://support.microsoft.com/en-us/help/2006076/screen-refr...

To be fair, they didn't actually think they'd discovered faster than light travel. They basically went "uhhhh, we double-checked everything and our numbers work out but we're pretty sure this isn't faster than light; here's our paper, can someone please point out wtf we screwed up?

I'm pretty certain that I'm not going to be using any new tab organization feature, if it requires me take explicit action to get the benefit. If I was reasonably capable of organizing my browsing, I wouldn't currently have 468 tabs open to start with...

Now, if only someone could make Wacom drivers that make the Wacom touch functionality interface better with Photoshop and friends, rather than just handing keyboard shortcuts to them. Somehow, that's the best Wacom has managed to do, which makes those features effectively unusable in the very apps those tablets are most commonly used...

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...)