elfchief's comments

The linked article is awful -- it not only doesn't contain a link to the demo (just to "nvidia.com"), but it doesn't even say what the name of the demo is... plus there's a couple of different places where the article just randomly links to some random person's soundcloud...

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.

It's worth noting that there's basically zero proper evidence that there is any malware included with this device -- it runs an exe when inserted, but that exe appears, at a glance, to be a driver installer. Definitely not the right way to do things, but there's a difference between "incompetent" and "malicious".

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

I really wish I could move my personal email over to gmail -- I've run my own local email server for 30 years, and tbh I just don't really care to do that anymore.

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. :/

To expand on this for @causi: The largest thing is the earth's atmosphere, because changes in the ionosphere (and a lesser degree, the troposphere) cause the signals to get refracted differently from moment to moment. Part of the data coming from the constellation includes general ionospheric correction data (and WAAS can provide data that covers smaller (but still kinda large) areas, which allows the receiver to adjust for those refractions to some degree, but there's only so much it can do -- conditions change quickly, and in areas smaller than the correction data can accommodate, so there's still variance that can't be completely removed -- it's not a lot, but at one foot per nanosecond of delay, it can still make a significant difference.

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.

</ramble>

There's pretty much never a reason (...normally, but see below) you'd use a separate satellite for the time -- you do need four satellites to solve for X/Y/Z/time, but you solve them together. Basically, there's only one combination of satellite positions and (pseudo)ranges that will produce a solution, and one of the outputs of that solution is the time (the inputs are just time offsets between the various signals, based on the receiver's non-precision local clock).

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)

At one point (I don't know if it's still the case) for certain launches the US government laid claim to "100% of the thrust available from a booster" or somesuch, basically not leaving anything left over for landings. I'm not sure it was ever documented why they had this requirement.

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.

I'm impressed at just how hard it is to see what catppuccin actually looks like in VSCode without installing it first. The catppuccin github has no screenshots, and the catppuccin-for-vscode github/site has exactly one screenshot, which is split into diagonal "bands" for the four different versions of the scheme, and only one of those bands has a significant amount of code.

I think the answer to literally every question that starts with "Why does the US..." is going to always be: profits

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

I suspect having a color coding material/technique that can apply to random bits of random plane parts, that won't get rubbed off / broken off / obscured by dirt/grease/grime/etc, consistently throughout the plane, is probably harder than it appears at first glance.

Neat, if so! Where do you see that, though?

I wonder if it's doing L1/L2, or L1/L5...

Actually, UTC -is- continuous. Even with leap seconds. At no point does UTC go backwards, at no point does a second happen twice, and at no point does a second change in length -- your 'extra' second happens as 23:59:60; when there's a negative leap second, the last second of the day is 23:59:58. UTC is not expressed or defined as an offset from some time in the past.

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

Hasn't happened, but it may actually happen in the next half-decade or so. If not, it's almost guaranteed to happen ~25 years from now.

One thing that I found amusing/interesting/horrifying back when I read about this originally is that you can measure the computer reboot time in feet. IIRC, in the problem vehicles, the reboot time was something like 150 feet @ 60mph.

They also followed almost none of the guidelines in the MISRA C standard, which is a standard developed by the automotive industry specifically for helping to ensure that code running on car computers is up to at least some standard.

IIRC, they did identify a bit that if it were flipped in a certain way at a certain time, would lead to the struck throttle condition, and were able to successfully replicate the stuck throttle condition by 'manually' flipping that bit. So they never reproduced the problem in the field, but they could force a condition that would cause it -- and for a one-in-a-million thing like a cosmic ray bit flip, that seems like a reasonable methodology.

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

One thing I don't see mentioned -- why is the write load so high? Can anyone from Roblox say? (I have a specific reason for asking.)

Related, does anyone know if there are any good tools for learning things about a graph (not necessarily a graphviz graph, but that'd be fine!)? Things like... take a graph from me and identify all the "islands" that don't connect to each other? Or to find the shortest 'path' from point A to point B in a graph?

I really hope Streamlabs paid a ton of money for this "cooperation", but from the wording, I doubt they did (since otherwise they'd be listed as a sponsor, etc, etc).

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?

Or just... wrong.

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