If I were to write this I think I'd go down this route:

1. Micro kernel with just file,net,graphics support

2. Fetch data via sockets (can be http, but not restricted to)

3. Parse the data for layout info and data values

4. build a frame buffer in memory, and place data (images/text) accordingly

5. write frame to display

6. sleep

7. goto #2

Any ready to roll *nix distro is WAY too heavyweight for the above, so a custom OS or even mini-distro is definitely the way to go.

What benefit do you gain from doing all the trimming work?

I would imagine better performance and a lower boot time. NOOBS boots far faster than Raspbian and still has full networking.

You also get less artefacts if the system is designed for this purpose. You are less likely to see cursors, modal dialogue boxes, crash dumps/notifications, window chrome/frame or other unwanted UI elements. Admittedly, this is more a problem with Windows (for example, BSODs and Windows 10 upgrade pestering). I regularly notice public display screens where something is broken in this way.

Perhaps the latest browsers don't support RISC OS though, which could be an issue for very modern sites. It looks like this idea is for a frame buffer approach so you could render the page in the cloud and just push the resulting image. It would be sensible to have a local cache anyway in case the network dies.

We were coding picture slideshows in Amiga and PC days using such approach.

The one presented in this article is an good example of bloat in modern software.

A full GNU/Linux OS + browser for reading images and copying them into the framebuffer!

Noobs uses buildroot not RISC OS ( https://github.com/raspberrypi/noobs ). Buildroot has Raspberry Pi configs upstream so it shouldn't be too hard to use it to build an image with a simple browser, Chromium in kiosk mode is probably a good bet.

Really?! A browser just for displaying images, wasting MB measured in three digits size doing for what can be done in a few KB?!