Though thinking further, how would an operating system recover from a permanent error without this behaviour? All future fsyncs would return errors as it continued to fail to sync to a broken disk. So, probably a pragmatic decision.

It's hard to avoid concluding that the fsync() behaviour here is just broken. I can't think of a justification for returning success from the second fsync while having pages which haven't been synced.

Storage wars - is that something like Cache in the Attic?

Verdict: Leftfield - Original is still the best music to watch www.youtube.com/watch?v=SILV...

One surprise has been how nice the Rust ecosystem for programming this has been - I'm using github.com/rp-rs which was just the first thing that came up. I expected a lot of device support to be skeletal at best, but everything I wanted was there, and pretty easy to put together.

And I do mean easily. Here's my code github.com/rboulton/pla... - it's a few bits of Rust thrown together with zero thought for efficiency or cleanliness, but it's sitting here analysing the sound of my typing and flashing pretty lights at something like 50FPS, without breaking any kind of a sweat.

I first played with this kind of thing in the late 90s. At that time, I needed the full resources of a desktop PC to perform this kind of analysis. The fact that a roughly £1 microcontroller can do it easily is something I find quite incredible.

Rather than just software, I've been playing with simple hardware - a string of ws2812 leds, a shop.pimoroni.com/products/pla... and a cheap electret microphone. Total cost around £30. General idea - record an audio signal, perform an FFT to get the frequencies, massage them into something pretty.