I recently had a less wild but similarly baffling experience on an embedded-but-not-small device. Address 0 was actually a valid address. We were getting a HardFault because a device driver was dereferencing a pointer to an invalid but not-null address. Working backwards, I found that it was getting that invalid address not from 0x0 but rather from 0xC… because the pointer was stored in the third field of a struct and our pointer to that struct was null.
foo->bar->baz->zap
Foo = 0, &bar = 0xC, baz = invalid address, *baz to get zap is what blew up.
In my own experience with “modern-ish C++” (the platform I work with only supports up to C++17 for now), once we started using smart pointers, like unique_ptr and shared_ptr, iterator invalidation has been the primary source of memory safety errors. You have to be so careful any time you have a reference into a container.
In a lot of cases the solution is already sitting there for you in <algorithms> though. One of the more common places we’ve encountered this problem is when someone has a simple task like “delete items from this vector that match some predicate” and then just write a for-loop that does that but doesn’t handle the fact that the iterators can go bad when you modify the vector. The algorithms library has functions in it to handle that, but without a good mental checklist of what’s all in there people will generally just do the simple (and unfortunately wrong) thing.
To give you a bit of insight, around the same timeframe (late October/early November) I directly observed two high-accuracy RTK GPS receivers reporting high accuracy (2cm), full 3D DGPS lock with carrier phase, and positions wandering within about a 5m circle horizontally. The altitude was staying pretty consistent (within about 1m, which was outside of the reported accuracy but not bad) until there was a sudden 60m altitude shift. This was all while they were sitting static on the ground, verified both by the crew and the accelerometer, gyro, and RADAR data.
There wasn’t a software fix per se, but we were able to quickly add a check to verify that the Kalman Filter’s position variance estimate was on the same order of magnitude as the accuracy level that the receivers were reporting and put a big red warning up. This wasn’t a flight-critical system, but it is the first time we’d ever seen that behaviour from those receivers and we’ve used them for 5 years.
I don’t know what airbus uses I only looked into the schematics of commercial avionics like Garmin.
I doubted though IMU drift and calibration introduce more error than they can provide in useful signal, old school pressure sensors + gps adjusted manually or automatically for regional pressure settings (pilots get these numbers through radio when they enter a new pressure area) is accurate enough (~1m). I’ll let a real avionics engineer correct me here, I’d be curious if that signal is worth the hassle + I can imagine such tiny SMD sensors ARE the biggest victims of radiation hallucination.
i would expect a huge shift like that to violate the gaussian assumption of the kalman filter? (which i guess is what you're checking, sort of?). regardless i would expect the kalman filter to smooth the shift over some substantial time at least?
In our case I don’t believe it was solar bitflips but rather wildly changing ionospheric conditions. I was primarily pointing out how you can have a software-only fix for problems like this.
Without going too far into the weeds, the fact that the receivers in question were reporting high accuracy under uncertainty is definitely a software bug in the receivers from my perspective. There was a different receiver with a completely different chipset in it on-site too that was experiencing similar issues but was reporting low accuracy. Without going into too much detail, I’ve got pretty good reasons to believe it wasn’t spoofing.
> moving my legs using her upper body, it felt quite intimate and I admired her for being so professional
This highlights something that I've been chewing on a lot lately. I'm not sure what you specifically meant by the word "intimate" when you said that, but I do think it's really interesting to distinguish between "intimate" and "sexual", even though they often coincide.
As an example, years ago I was staying with some out-of-town friends after a break-up and they wanted to introduce me to a couple of lovely single women they knew. I hadn't really been taking great care of myself in the fallout of the breakup, so I went and shaved and got cleaned up. While doing my hair, I realized that my eyebrows were pretty unruly and somewhat sheepishly asked my friend's wife if she'd be comfortable taking some tweezers to them and helping me get them cleaned up. It wasn't, even a little bit, a sexual moment but it ended up being incredibly and unexpectedly intimate. We were both pretty surprised by it and ended up getting closer (as friends) afterwards.
What a nice story! Cleaning up eyebrows shows nicely the discrepancy between intimacy (feeling love and care) and erotica (feeling lust?).
The hair grooming in the article probably felt similar.
Thinking about the physio therapy, her upper body felt very warm and soft but it was probably a rather standard technique for firmly moving the joints and ligaments in legs and hips.
What it made most intimate was not just the softness of her body but also the care she took for the movements, knowing that it would help.
So my limbic system went into oxytocin producing mode, which the aware mind easily picks up with warm thoughts. I think that's where the bridge between intimacy and sexual thoughts can happen, but there my thinking was not firmly going into that direction, it just felt warm and comfortable, even a bit emotional.
In your case the feelings apperently came from both directions, it was not a professional/client context after all.
> What it made most intimate was not just the softness of her body but also the care she took for the movements, knowing that it would help.
100% that was a big part of it too for me. It was the care and attention that was going into it, plus the element of trust that goes into giving someone consent to inflict sharp but short-lived pain.
I’d actually be really curious on the physiotherapy side of it whether there is actually a combination of intimacy and professionalism happening on the other side of it. I’ve done physio with people who did not give me warm and fuzzies at all, and with people who, like for you, left me with that nice oxytocin sense of satisfaction. I wonder if the people who left me with that feeling are good at what they do because they have some added degree of empathy or mirror neurons or whatever that makes them feel good when they treat their patients softly and intentionally.
Indeed i think it is a win win between caregiver and patient, which has little to do with financials. One of the feats of the limbic system is promoting emotional resonance which can happen in both directions and does not to have to imply romance.
I mean... you're completely right and some of the stuff is as ridiculous as you're suggesting (e.g. the furniture). However... what we're agreeing on is that the fungus is absorbing alpha/beta particles and gamma rays that are coming off the radioactive material, which in theory should mean that it would act as a radiation shield. Whether it's a more effective radiation shield than other options is the big question, and for space travel in particular the question I'd want to know is how effective is a given mass of this fungus relative to other options (e.g. water).
With respect to the frequency changing as the signal's downsampled, I'm pretty sure the author isn't correctly keeping track of the fact that by having fewer samples they're effectively changing the sample rate. It looks like the FFT every time is using 2048 bins, which is somewhat unexpected. They're not documenting how they're taking a 2048-point FFT with fewer than 2048 samples. Otherwise, fantastic article!
> Talking about “thousands of tonnes” of nuclear waste is comically misleading when you realise how tiny the volume is.
Yeah, it’s really easy to forget how dense these materials are. A jug of milk (4L/1gal) weighs 4kg/8.8lb. Milk has about the same density as water, 1g/cm^3. Uranium has a density around 19g/cm^3, making that same gallon jug weigh 76kg/167lb. A metric ton of uranium (1000kg) is about 13 gallons.
This is exactly what happens when you invest billions and hire the best industry specialists for decades. M-series processors did not magically appear out of nowhere. Apple perfected them for years in iPhones, but people didn't have the ability to compare since Apple doesn't share their processors with anyone.
I had heard about this but didn’t fully appreciate it until a few years ago in a context completely unrelated to computer monitors. We had a system made up of a few circuit board that had a handful of high-power motor drivers and motors, some somewhat sensitive analog sensors, and a microcontroller orchestrating the whole circus. Having a mixture of high-power motors and sensitive analog electronics is always a recipe for exciting bugs. We had mostly tamed the noise, though, and were debugging a firmware crash.
Everything would be working, sometimes for hours, but once in a while the MCU would HardFault. The exact instruction where it would fault was pretty consistent but not perfectly. We started adding more and more instrumentation. We had logic analyzers and at least two oscilloscopes hooked up to the system at one point. Sometimes it would crash a bunch in rapid succession. When it did, the team that was primarily responsible for it would call me over hoping that it would happen again.
Eventually, late at night, we were sitting around scratching our heads trying to figure it out. I was frustrated. “OK I’m going to go have a smoke. Back in a few.” I stand up and the scope connected to the power rail, right then, shows a spike up to about 10V (on a 3V3 rail). I sit back down and try to figure out what caused it. Can’t figure out what could have possibly triggered it. “Fuck, ok, I’m going to go try to have that smoke again…” stand up. Blip. Crash. Sure enough, it was that specific wheeled chair that caused it. The two other chairs there didn’t, only that one. Ultimately it was a ground loop between two of the boards, but we would have never found it without that chair giving us a way to reproduce the problem.
I recently had a less wild but similarly baffling experience on an embedded-but-not-small device. Address 0 was actually a valid address. We were getting a HardFault because a device driver was dereferencing a pointer to an invalid but not-null address. Working backwards, I found that it was getting that invalid address not from 0x0 but rather from 0xC… because the pointer was stored in the third field of a struct and our pointer to that struct was null.
Foo = 0, &bar = 0xC, baz = invalid address, *baz to get zap is what blew up.reply