This started as a solo side project: a real-time satellite tracker (satradar.com) that shows every active spacecraft orbiting Earth — Starlink trains rising over your horizon, the ISS passing overhead, the GPS constellation in MEO, weather satellites watching hurricanes, geosynchronous comms parked at 35,786 km — I managed to get it updating at up to 120 FPS in Chrome and Safari on my MacBook Pro, though it will do 60 FPS on an iPhone too. I filter out debris and rocket bodies so what you're seeing is the live, working fleet, not dead fragments.
The trick to keeping it fast: the entire SGP4/SDP4 orbital propagator runs inside a WebGL2 fragment shader. Two-Line Element sets (TLEs) go in as a texture, a render-to-texture pass spits Earth-Centered Inertial (ECI) positions out the other side, and the vertex shader reads them back the same frame. Kepler iteration, SDP4 lunar/solar perturbations, the J2/J3/J4 terms — all of it lives in one big GLSL function. The CPU does nothing per-frame.
The same orbit math runs natively on iPhone, iPad, Mac screensaver, Apple TV, and Vision Pro via a Metal port. Six surfaces, one source of truth for every render constant: a single satellite-config.json that both the Swift and the JS pull from at boot. Web throws on first paint if the JSON is missing a key — the two sides drifted silently too many times before I gave up and made it a hard error.
GLSL and Metal can disagree in subtle ways (atan2 near the poles, fp32 mantissa, ANGLE vs Apple's shader compiler, animation timers vs frozen sim clocks), so every push to main PNG-diffs all GPU backends against frozen-time baselines in R2, with GPT-5.4 as a tiebreaker on anything below the pixel threshold. Public dashboard: https://satradar.com/visual-tests.html
The Mac screensaver is free and walks you through everything that was in orbit from October 1957 (Sputnik, alone up there) to modern day — six decades of orbital history, sped up, watching the sky go from one object to more than ten thousand.
A couple of things to play with if you want to jump straight in: the URL accepts ?follow=<NORAD-ID> so you can deep-link to a specific satellite — the ISS, Astranis Arcturus (Astranis's first MicroGEO — a small, dedicated GEO comsat with a reprogrammable software-defined radio), or NuView Alpha (a brand-new commercial LIDAR satellite). It also takes ?date=YYYY-MM-DD, ?speed=<time-warp>, and ?altitude=<Earth-radii> for richer shareable views.
Would love feedback — features you'd want, satellites or constellations I'm not handling well, edge cases in the shader you can break. The iPhone and iPad app is live on the App Store (https://apps.apple.com/app/id6760600849), and the Mac screensaver is a free download. The Apple TV and Vision Pro builds are close behind — if you want into either beta, reply here or ping me and I'll add you.
I feel like I’m missing a step here. So his tatoos showed and someone who happened to know about this guy happened to notice? Does he have a particularly distinctive tattoo?
I’m not rejecting the claims in the article, but they sure are pretty surprising. Two ideas that seem far fetched but more likely to me:
1. Some intelligence agency running voice recognition on YouTube videos.
2. Parallel construction, where he was actually caught via another source (like a tip) and they decided to say they detected via YouTube to obscure the true source.
This is specifically about the GM build which is necessary for final builds, validation, and submission. Often developers have at least a week to do final checks and submissions with this build.
Yeah I'm not sure what the discrepancy is. This afternoon I'm going to dig a bit more into my records.
In my data right now I see a few examples of an $80 purchase match to $56 in proceeds (70%) matched to $56 of a refund.
I can't say I think the 30% fee is appropriate anymore, but this particular case being made about refunds does not appear to be accurate for me at least.
Agree with the app store being better than anything that preceded it. That said, it's not 2008 anymore and Apple should adapt.
What happens in reality is developers either capitulate and / or sneakily separately contact their users and get them to pay through another payment processor.
I make an app called Nikola that's seen data from a few thousand Teslas. The short answer is there are some identifiers, but they're basically impossible for outsiders to track. Tesla is making modifications all the time.
From what I've seen in forums and user groups, etc, owners tend to just break things down by major feature. AP1 / AP2 / AP3, or I have X type of wheel, or I don't have the retractible roof, but there are obviously so many other changes that aren't easy to detect
This would seem totally reasonable to me. It'll take more time, but I can also dig in and see the extent of the battery heater use.
My guess is it's often cold enough for the battery to need to warm up to be efficient, but not cold enough to make it worth it to turn on the battery heater. (Your point still holds in that case)
A piece of data I happen to remember, far fewer than 10% of supercharges have the battery heater on for any period of time at all.
Alrighty here's the first graph. Note that this is average speed, so any trips with an average speed near the right by definition have some parts of the trip faster than the average, so the actual drop at 80 mph isn't quite as severe as it looks.
seems like an apt comparison. Something I forgot to mention here is that the temperature also plays a huge role. I've recently started collecting more temp data, but don't have a big enough sample size to say anything definitive beyond "driving in cold weather does reduce range". This is completely expected.
As a bit of anecdata here: Parking inside vs. outside seems to have a big affect. A slightly chilly garage vs. a cold soak outdoors understandably are quite different.
Another fun fact on practical drain vs. EPA drain:
While I love sentry mode and think it's a great feature, it keeps the electronics awake. In some cases this can cause double digit per day mileage drain. Tesla has clearly been working on this though, as the numbers have improved.
I make an app (called Nikola, not the truck company) for Tesla owners that has seen over 5 MM miles driven on it. I did some quick queries to validate actual range vs. EPA range for those curious.
My general takeaway is to see the EPA range as a useful, albeit unrealistic, indicator. Essentially nobody gets the EPA range, either because they choose not to go the speed limit, they accelerate harder than the EPA test factored in, or the vehicles drain some juice while parked.
The data: For the hundreds of Nikola trips with an average speed of 60 mph, the actual MPGe was about 102. Once you get up to a 75 MPH average trip speed, the MPGe drops to 94. And by 80 MPH the MPGe drops to 77. (avg over all Tesla types)
As a bit of "anecdata", I've driven trips where I hit my range on the nose, just to show I could, but the driving is less fun and I was going slower than traffic. I don't drive that way anymore.
What's most striking to me as someone who has heard over and over again about how air resistance is a X^2 property, is the extent to which short (and presumably slow) trips punch above their weight in terms of range consumed per mile. From what I can tell, the actual cost here is the fixed cost of booting up some systems and electronics, and the variable costs of running them over fewer miles can make the MPGe drop. Starting and continuing to run the AC adds up!
The trick to keeping it fast: the entire SGP4/SDP4 orbital propagator runs inside a WebGL2 fragment shader. Two-Line Element sets (TLEs) go in as a texture, a render-to-texture pass spits Earth-Centered Inertial (ECI) positions out the other side, and the vertex shader reads them back the same frame. Kepler iteration, SDP4 lunar/solar perturbations, the J2/J3/J4 terms — all of it lives in one big GLSL function. The CPU does nothing per-frame.
The same orbit math runs natively on iPhone, iPad, Mac screensaver, Apple TV, and Vision Pro via a Metal port. Six surfaces, one source of truth for every render constant: a single satellite-config.json that both the Swift and the JS pull from at boot. Web throws on first paint if the JSON is missing a key — the two sides drifted silently too many times before I gave up and made it a hard error.
GLSL and Metal can disagree in subtle ways (atan2 near the poles, fp32 mantissa, ANGLE vs Apple's shader compiler, animation timers vs frozen sim clocks), so every push to main PNG-diffs all GPU backends against frozen-time baselines in R2, with GPT-5.4 as a tiebreaker on anything below the pixel threshold. Public dashboard: https://satradar.com/visual-tests.html
The Mac screensaver is free and walks you through everything that was in orbit from October 1957 (Sputnik, alone up there) to modern day — six decades of orbital history, sped up, watching the sky go from one object to more than ten thousand.
A couple of things to play with if you want to jump straight in: the URL accepts ?follow=<NORAD-ID> so you can deep-link to a specific satellite — the ISS, Astranis Arcturus (Astranis's first MicroGEO — a small, dedicated GEO comsat with a reprogrammable software-defined radio), or NuView Alpha (a brand-new commercial LIDAR satellite). It also takes ?date=YYYY-MM-DD, ?speed=<time-warp>, and ?altitude=<Earth-radii> for richer shareable views.
Would love feedback — features you'd want, satellites or constellations I'm not handling well, edge cases in the shader you can break. The iPhone and iPad app is live on the App Store (https://apps.apple.com/app/id6760600849), and the Mac screensaver is a free download. The Apple TV and Vision Pro builds are close behind — if you want into either beta, reply here or ping me and I'll add you.