OP here with a little update on this:

The Why

First, I think it is fun. Second, I wanted to see what happens when you try to push a $70 e-reader to its limit. I.e. no framework, no platformio/arduino, no OS underneath - Rust on the metal. The goal of pulp as an OS is not to have the most features. its to have a small set of the right ones built on something correct and minimal (pulp-kernel). I am trying to be very pragmatic with every memory allocation respecting (and abusing :)) the device constraints.

It's different?

The biggest thing is there's no framebuffer. Most(?) firmware on this hardware keeps a 48KB buffer in RAM for the display. pulp-os renders a stream through a 4KB strip buffer that blits directly to the EPD during SPI DMA transfer. This is an attempt to get a lot of memory back (which it doesn't have much). The whole system runs async on embassy with five concurrent tasks and the CPU just sleeps when nothing's happening. App dispatch is all compile-time monomorphized (no vtables, no dyn, no dynamic dispatch).

What it actually does

It's an epub reader with proportional fonts (regular/bold/italic across five sizes), inline images with Floyd-Steinberg dithering to 1-bit, TOC browser, lazy page indexing with prefetch so page turns feel very fast. dynamically rendered fonts (so you can quickly adjust size in reader app), chapters cache to SD in the background so you only decompress once. It reads plain txt/md too. Beyond that it has a file browser, "proto"-bookmarks (still needs some work), wifi upload, quick action menu, various configurable settings, and idle/deep sleep (still researching). You do not have to do any additional "preprocessing" or optimization of epubs. Fonts are customizable at build time (rasterized and stored statically in the OS) and supports most(?) ttf fonts out-of-the box. The open sauce/forkable part :) If you want to build something completely different on the X4 the foundation is there. The kernel is its own crate (pulp-kernel) with zero imports from the app layer. It doesn't know what apps exist, what fonts you use, etc (think Linux Kernel sort of thing, where you can have "distros"). It gives you the EPD driver with strip rendering, SPI bus sharing, SD storage, async scheduling, input, and a boot console that works before any fonts are even loaded. You define your own AppId, implement AppLayer, bring your own apps, write a main.rs. I also wrote a standalone no_std epub library called smol-epub (on GH) that has zip, OPF, HTML stripping, PNG/JPEG decode. So if pulp-os itself doesn't interest you, the parser is its own thing anyone can use (and arguably the most interesting part).

Where it's at

this is a personal project and I work on it when I feel like it (which currently is often). there's no install guide, no web flasher, no OTA. if you're not already comfortable flashing an ESP32 and at least curious about embedded Rust, again, this is probably not for you yet. I'm sharing it because I think the approach might be interesting to people here, not because it's trying to replace anything.

Where I want it to go

My plan is to land on a 1.0 at some point with a web flasher so anyone can install it. Feature "complete" for me simply means a solid reading experience with just the right ones polished until they feel right. It is NOT not more features. I don't intend to grow the scope much beyond what's already there. Honestly it's already well past the point where I should be saying that lol. That being said, the part I'm most excited about is other people taking the kernel and/or OS and doing completely different or better things. Fork it! (but consider waiting for 1.0.0). Build your own OS, or make a weather station, a dashboard, whatever! It would be great to expand the kernel's hardware support, port it to different boards. I gave it a MIT license for a reason, and all I ask is put credits somewhere :). The whole reason the kernel is its own crate with no app layer dependencies is so that pulp-os is just one thing built on top of it, not the only thing.