I suspect most of the "corruption" RPi users experience is likely bad power (shitty undersized USB power bricks) glitching the CPU and causing the filesystem to corrupt. The SD card is likely doing exactly as it's being told by the host system - write (invalid) data to blocks, which it does.
I have always bought the official power supply, yet of the two Pi 3s that I have connected to my TV at home, the one that runs Kodi/OSMC to serve up movies has never suffered any filesystem corruption, despite it suffering repeated power outages without warning (it's low enough to the ground that the toddler has often pulled the power cable out, and I haven't been able to find a better place to keep it). The other one, bought at the same time from the same source, is meant to be the one the kids use for programming in Snap!, a variant of MIT Scratch that doesn't have the artificial limitations that Scratch has. (Snap! functions — the exclamation mark is part of the name — can take lists as input, whereas Scratch functions can only take numbers or strings, giving it an artificial ceiling; also, Snap! functions can take functions as input and return functions, making higher-order programming possible, while Scratch deliberately does not allow that). However, that Raspberry Pi has suffered two SD card failures in the past year; it's been down more often than it's been up, and I've ended up using either my laptop or my wife's laptop for my kids' programming lessons.
It's actually weird that Raspberry Pis seem so bad at using SD cards.
I've just scrapped a large PBX which had a whopping 8MB SD card in it. Its 486 processor booted Linux off the SD card, it wrote CDRs to the SD card, it served said CDRs up over a web interface off it, it saved its logs to the card, and all the other day-to-day chatter of a running system.
It was installed pretty much 20 years ago. The date sticker on the SD card shows that it was replaced 18 years ago, presumably as part of an upgrade.
I'm going to guess that it was not a normal COTS SD card, and instead designed for continuous writes.
The factors for SD card failures in raspberry pi seem to be mostly SD cards not meant for the purpose and having things like swap, atime or disk logs enabled which leads to unnecessary writes.
Still supposedly a human prompting stuff to happen in any case. Not to mention, I think you'd have to prompt against the model to avoid making URL routes in a 100% frontend application, leading me to believe the "missing" page navigation is intentional.
it's very easy to verge into OLPC type thinking with this, you probably should just give them normal bikes instead of trying to come up with some bespoke DIY-able system
the OLPC was the "send them bikes" disguised as the DIY-able system. They designed what they thought would be the best computer for impoverished children when in reality those children had no real use for a computer
I dunno, saying they don't have a use for a computer seems incorrect to me, even in the poorest parts of the world today, a substantial minority have acquired their own computer that's cheap, small, efficient, has a built in long distance radio, can run arbitrary software, doesn't require reliable electricity (I mean cell phones)
obviously it's a different technological and economic today compared to 2005, but still, "the global poor don't need computers" is questionable just based on the fact that they are spending their own money to get them
if we had a standardized way to deliver packages like we do mail (the heavily regulated mailbox!) this would not be a problem, it's a phenomenal waste of human effort to navigate this uniquely for every location
it's not like a doorman where there's useful social interaction
I have a PO Box (I do not have a mailbox so the city gives me a PO box for free). A kind human gets my packages from the back and hands them to me. It's great and efficient. The only inconvenience is the hours are a little narrow.
Nitpick: binfmt.emulatedSystems is not true cross compilation. It sets up a nixos to enable emulated native compilation. After painful tinkering, i prefer this way too. When i recall correctly, for cross compilation you'd have to use nixpkgs flags.
At some point it's a matter of perspective. If the emulated system is fast, it feels the same as "true" cross compilation. In the end it's a bunch of bits and bytes which produces some other bits and bytes when we poke it. If it goes fast, it's good. If it goes slow, it's painful.
reply