The questions stands; how would it PXE?
All of them now have a very specific model industrial MicroSD card in them, and none have lost or corrupted data, or refused to boot, since those cards were added. They had SanDisk ultra cards before that, and they had to be reinstalled all the time.
I picked the card because it's an aMLC* model (cheap overall, $15 for 4GB, $25-28 for 8GB), which significantly improves write endurance even compared to MLC cards, and because the controller is designed to handle sudden power loss, which is where a lot of these Pi+SD problems come from; consumer MicroSD cards are generally designed for use in devices that have batteries and rarely if ever lose power suddenly, so the controller can take risks for optimization that it wouldn't otherwise want to take.
They're also rated down to 0C, which I can say is definitely true as I have some operating close to that right now.
This is the card: https://www.digikey.com/product-detail/en/atp-electronics-in...
4GB isn't huge in a world where 32/64GB cards are common for a similar price, but a full headless OS installation doesn't even take half of that, and there's no real use for more space most of the time.
* with aMLC mode, it's still MLC flash (so cheaper than SLC), but each cell only stores a single bit rather than 2 (MLC) or 3 (TLC), so there are only 2 voltage states it needs to be able to measure, rather than 4 (MLC) or 8 (TLC). That means you lose some storage capacity (half vs MLC), but the tolerances for the voltage measured in each cell is significantly relaxed, so it remains usable long past the point where a plain MLC mode card would not be able to accurately program and measure the voltages that represent the 2-bit values of 00, 01, 10, or 11 anymore.
Plus, it costs $3 each, is stamp-sized and has Wifi.
The ESP32s were routinely dropping from WiFi (some being crashes, some just disassociating and never connecting again). ESP-IDF has had quite a few WiFi fixes, but it's difficult to guarantee that your own code isn't directly causing the problem (which you get for free running in userland on Linux), and dealing with it was becoming a huge time sink.
Most of the Pi Zero W boards I have were $5 at Microcenter, the MicroSD adds to the cost a little but they're extremely reliable as a result, and my own code is no longer running in the same address space with the scheduler and WiFi driver under extremely tight memory constraints :)
the ESPs are most definitely better for higher volume solutions
EDIT : now that you mention it - micropython is pretty cool -- and I haven't used it - need to try that on the ESP :)
If you then adjust your systemd journal to not write very often you have eliminated most of your SD writes.
The remote sensor systems I run lose power from time to time during the year, sometimes once a day. I’d say each time there used to be something like a 0.1% to 1% chance of corruption. Since I’ve moved to /run and a slower journal I haven’t lost an SD card[1]. Thus far it seems I have at least an order of magnitude improvement.
[1] Well, I had a wind turbine tower collapse in an inaccessible location. The raspberry pi is in a lake now, but it can’t have gone far so I don’t call it “lost”. I’ll dive and recover it in the spring. That camera/sensor has spent a couple months underwater before. In fact, I’ve had three systems end up underwater for months and all the SD cards have been fine when recovered.
> If you then adjust your systemd journal to not write very often you have eliminated most of your SD writes.
The trouble is that the OS isn't the only one writing to flash in the card, the MicroSD card controller is erasing and writing to it at random times as well even if the filesystem is read-only, with no coordination between it and the OS.
As a result you can easily end up in situations where the card decided to run some housekeeping to manage the flash just milliseconds before a power cycle or a power loss, and seemingly all consumer MicroSD cards are not up to the task of keeping the data intact at the same time.