We have used the vtable trick many times in satellite software operations, whenever we had to "quickly patch" this or that function, without having to uplink a whole software update - which as they explain in the talk, is quite an involved process that takes significant time and resources to complete.
Happy to answer or forward any questions about nanosatellites, software in space, etc!
P.S.: it looks there is a bit of a mix-up with the audio of the recorded talks. The default audio track contains a Polish dubbing. Select the "eng-deu-pol 1080p (mp4)" which seems to be the correct one. (And thanks to the A/V team at CCC for your efforts to make this content accessible to everyone <3)
To stay longer you would need less heavier satellites, with more fuel to correct their trajectory. Or fly higher and have more latency.
5 years is just a good compromise.
Notably, many generations of broadcom wireless firmware uses a similar trick. The Chips are made with a ROM containing the firmware, but obviously the firmware has bugs that get shipped, and ROM's can't be changed. Instead, the hardware has a loadable table of 'patches', which allows pointers or code from ROM to be overridden to point to a [much smaller] RAM at runtime.
Effectively, this means you can tell your software team "We have 2 year to develop this chip, however after 6 months you have to have a 1st draft of all the code, and then you can use the last 18 months of the development cycle to patch up to 5% of that code to make a saleable product."
When linux wireless firmware needs loading, this table of patches is what you're loading in.
Interesting subject matter, novel technical problems and solutions, story narrated at speed and with just enough information to fill in typical knowledge gaps, and on top of all of that there's slides and answers ready to go for random questions from the audience.
Wonderful job, PistonMiner!