For those looking for it, I think this is referencing the "Zorah" sample, from https://developer.nvidia.com/rtx-kit ... though at this exact moment, the download link on that page seems broken. Failures all the way down, I guess.

The only actual "evidence" that was provided was a link to a falcon sandbox run, something which actually requires human analysis to draw conclusions about -- and anyone who has ever used it knows how many false positives it finds.

A better proclamation might be "cheap network adapter comes with an auto-running executable which needs further analysis".

But I'm stuck -- I exclusively use 'tagged' email addresses when giving anyone my email address, so every incoming message is addressed to "myusername-sometag@domain"... and gmail, of course, uses a + instead of a - for doing that kind of tagging. So if I tried to migrate hosts, literally none of my incoming email would arrive anymore.

Sucks that a decision I made before gmail even existed now restrains me so much. :/

At least, that was generally the case until recently. There is actually a way to almost completely remove the effects of both the ionosphere and troposphere: Those things affect signals differently if you have multiple signals at different frequencies. And, as it happens, GPS does actually have multiple frequencies (L1 and L2, and now L5 as well), and for a fairly long time there have been receivers that could listen to signals from the same satellite but different frequencies, and based on the delay difference between those signals, know exactly what the atmosphere was doing at that exact moment, and dial out the influence of the atmosphere almost completely. You can start getting pretty durned precise once that's not a factor.

The problem is that multi-frequency receivers used to be expensive. Like "started at $10k for the cheap stuff" expensive, even within the last decade. Only in the last few years have inexpensive (under $100) chips become available for doing multi-frequency GNSS. And those can get down into the "under 1 meter in realtime" range trivially, and better than that for a fixed-location station. Phones are getting these now, so things should start getting more accurate, though not that much more accurate.

Multipath is also a big problem in "the urban jungle", but chips are getting better at discriminating, and unless you're just utterly surrounded by skyscrapers, usually isn't too big a deal.

Orbital calculations are also another cause of loss of precision -- the orbits are calculated pretty precisely, but for various reasons the ephemeris data sent down from the satellites doesn't actually represent exact orbital data, but represent data that's "good enough" over the couple of hours the ephemeris data is valid. This can be worked around with patience -- there are ground stations around the world with exactly surveyed locations, which monitor the satellites and calculate the exact orbital paths the satellites actually took, and publish that data (though it takes several weeks to get the "final" data). A typical surveying technique is to record several hours of data from an antenna at a survey location, and then when the precision orbit data is published, post-process that recorded data to remove both orbital and ionospheric effects. This can get you down into the sub-cm range, with enough care.

And then there's also a range of other factors, like solid earth tides, which cause the land masses of the earth to rise and fall by up to a meter(!!!) over time, and when you're trying to figure out exactly where a given point in space is on this big rock ball, that matters!

But, yeah, pretty much it's atmosphere, unaddressed multipath, and orbit precision that makes the difference, and the above is how those are usually dealt with.

The see below part: There are timing receivers that will do a long "survey" to figure out their exact location (or as close to it as they can), and once they have that they can use a single satellite to determine the current time, since they already have most of the needed equations "solved" when the receiver already knows its own (static) location. This is sometimes preferable, depending on one's application, because it makes for less jumpiness in the time solution as new satellites go into and out of view (since the changing geometry of the constellation will make for slightly different solutions every time it changes)

What surprised -me- was that all three boosters were brand new, rather than, say, expending a booster that's already flown half a dozen times or such.

Profits are the only yardstick by which anything in the US is measured. Everything else is secondary.

The real problem for computing is when UTC is converted to unix epoch time, which is defined as an offset from the past, and by definition has exactly 86400 seconds in a day, every day, so some provision has to be made for those extra (or missing) seconds. And -that- is where the problem happens. But it's not UTC that's mucking around with the definition of time, it's the standard representation of time that's used in modern computing that causes the problems.

That being said, UTC is still probably to blame for most of the problems, because it effectively requires knowledge of more than just a timestamp to understand when something actually happened. And that extra knowledge (the map of when leap seconds have happened before) changes often and irregularly. Epoch time could totally be redefined to include leap seconds, and that would solve lots of problems, but there's no practical way to distribute that updated leap seconds table to every system that would possibly need it...

(and was only a problem because they didn't handle critical variables correctly, by having mirrors of the values that could be compared to protect against various types of corruption)

Which... I'm not sure why the OBS team would do this. Streamlabs has been acting in bad faith for years. They've done very little work that's applicable to OBS at all, unless OBS wants to rewrite their front end using Chromium. What good does this do the OBS project? Streamlabs gets to look "good", and OBS gets... absolutely nothing?

I know a bunch of people that prefer manual transmissions. And every single one of them also prefers loud music while they're driving.