[dividuum]

And if you have seen the intermission screens and wondered how these work: They run my software info-beamer (https://info-beamer.com/hosted) on a Pi3 in each Hall. Basically those intermission information screens are written in Lua. My info-beamer software uses both hardware accelerated video decoding as well as OpenGL(ES) to make things run smoothly. I'll release the complete Lua source code early next year. If you want to see how these worked last year, take a look at https://github.com/info-beamer/package-32c3-screens

[throwaway161220]

> Our operating system detects even the tiniest corruption to files and will automatically restore them from our service. The system is completely self-healing.

Can you share details here?

[dividuum]

Sure. The base system is quite minimal an runs from a squashfs read only image. Total size is ~40mb. The squashfs file is stored on the first partition (FAT formatted) which is not mounted rw during normal operation (only while updating the system which happens rarely). The second partition is the data partition. It stores images, videos, the Lua code and other files that are required to actually show content on the screen. This partition is mounted rw.

info-beamer hosted always stores those files using content based addressing. So every file that enters the system gets hashed and is then addressed by that hash both on the website itself as well as on the devices. On the website this might look like this: https://cdn.infobeamer.com/dynimg/blob/image-c40ba24410fb9ca..., on the device they end up on /space/cache/<hash>. This is great for all kind of reasons: Cache invalidation and offline verification. For the website, all files can be cached indefinitely as the url changes once the content changes. On the device each file required for a visualization must only be downloaded once, as it's trivial to see if the same file was already downloaded earlier by just comparing filenames. So fonts that might be shared by visualizations are only downloaded once. Also the device can trivially verify that all files are still correct by hashing all cached files and comparing the result with the filename. If it matches, the file is correct. If it doesn't, something is wrong and a new sync is started to repair the problem.

Works pretty well. Does that help?