After the introductory message I initially saw lots of id: /lib/i386-linux-gnu/libpthread.so.0: unsupported version 0 of Verdef record id: error while load

After the introductory message I initially saw lots of id: /lib/i386-linux-gnu/libpthread.so.0: unsupported version 0 of Verdef record id: error while loading shared libraries: /lib/i386-linux-gnu/libpthread.so.0: unsupported version 0 of Verneed record bash: [: : integer expression expected which would repeat no matter what command I try to run: user@:~$ ls -l ls: /lib/i386-linux-gnu/libpthread.so.0: unsupported version 0 of Verdef record ls: error while loading shared libraries: /lib/i386-linux-gnu/libpthread.so.0: unsupported version 0 of Verneed record Very curious. Turned out my hitting F5 (because things appeared to have frozen - I assumed resource downloads had hung, I have flaky internet) corrupted the local ext2 filesystem in a way the runtime didn't detect and catch upon reload. That's actually kind of interesting because HTTPS nowadays almost always means authenticated encryption, ie a guarantee that application data has absolutely explicitly not been modified. Thus, correct data was downloaded, but somehow corrupted on its way into IndexedDB, due to my hitting F5. I'm very curious as to why that's happening, but I could only blindly speculate as to why. Considering the bigger picture of the many block requests shown in the devtools, it would seem the ext2 block layer just transmits remote requests for small spans of "exactly what's needed right now", with no buffering or preemptive readahead. Given this runtime's nature as a likely-embedded component running specific bespoke applications (I get the impression this entire product exists solely or largely to run a retargeted version of the Linux Flash player) it is likely possible to optimize this quite effectively. In fact, because of the A (then) B (then) ... (then) N serially blocking nature of the problem space, it could actually be quite straightforward to implement a fairly effective solution: if the block layer were modified to understand "here are the bytes you asked for... please also cache this random unrelated list of chunks to cache as well", the web server could then be modified to aggregate s=...&e=... requests, find correlations between ranges, and then preemptively send data estimated to be relevant for correlations over a certain threshold. If you further modified the client to also implement a tagging system in the cache denoting "directly requested" or "preemptively sent by server (when requesting s=...&e=...)", when application code goes to request a given arbitrary block from disk, if that block turns out to have been preemptively cached and the preemption did indeed save a roundtrip, the runtime could send a pingback to the server to strengthen the relationship between the original request and the followup. (Given that this logic would be running on the server, and this approach provides a reward/feedback signal function, I'm almost tempted to wonder if a small neural network could be interesting to play with here, but it might be overkill.) In any case, I'm 119ms away from the disk CDN... which might help explain my motivation to do the above. My ADSL2+ is hit and miss; today it's doing 6Mbps, give or take (especially for small high-latency transfers which take time to ramp up). The devtools is saying a full reload (clear IndexedDB, hard reload) takes 33.75s. During that time it's entirely hung. Some sort of early-boot progress-bar (an extention of the logic that puts the introductory text on screen?) would probably be a good idea. Maybe extend the runtime with a "userspace reached" opcode (or some sort of equivalent magic noop) called at the very bottom of /etc/bashrc, which hides the progress bar. Lastly, a bit of an awkward problem that is Kind Of Interesting™ but doesn't have any straightforward next steps: while attempting to identify how long a cold start takes here I got into a bit of a fight trying to delete the IndexedDB with the site open. Naturally that didn't go down so well, with the app recovering and auto-recreating the DB. Somewhere in there between closing the tab and trying to reload everything, I realized the browser process had started using 100% CPU, and my laptop was at 94°C. Interestingly, everything was still entirely responsive (indeed the only reason I'm submitting this was because the form autosaver still worked; this was slightly too many butterflies at once to reason about and I completely forgot to save my post text), so I quit Chrome via the menu and... it didn't fully exit (I had to hit ^C twice (I run Chrome from a terminal) to make it fully quit). All the threads shut down but the root browser process was still yelling at my CPU. gdb decided it was stuck in futex_wait_cancelable(). Yay. Apparently the IndexedDB has a few handle leaks in it or something :/.