If you want a material example, the raspberry pi's SOC is designed to be mounted in read only mode with industrial on-board flash. It is meant to be used with t

If you want a material example, the raspberry pi's SOC is designed to be mounted in read only mode with industrial on-board flash. It is meant to be used with the broadcom toolkit that includes multiple boot partitions for safe and validated updates. In addition, (afaik) that SDK includes a hardened and stripped down linux kernel with watchdog, chain of trust and binary signature verification - a far cry from the raspberry pi's kinda "open like whatever" standard desktop and server grade distro. A material consequence of this is that raspberry pis (pre 4, at least) that lose power during a SD write have had a common tendency to leave the flash in a really bad state, rendering the device unusable until a reflash happens. The compute model suffers from all of this. I use the compute modules for lighting and other fun such activities, at art and music festivals. I have gotten used to carrying spare SD cards (for non compute) and a laptop with flash snapshots (for CMs). More than once, a breaker has blown and the compute module wouldn't come up after due to a trashed filesystem. I will admit, the CMs are wayyy more robust than the normal ones, due to whatever emmc they're using. I could probably mount the flash as RO also but that tends to cause "weird things" to happen. If I have to flash a CM once in a weekend, that's a small price to play > What's the difference between a prototyping board and a product built using the lessons learned while integrating the prototyping board? The difference is that the lessons learned likely won't cover the large amount of pitfalls you'd encounter in the field, but those pitfalls still exist. TLDR: Raspberry pi doesn't include a hardened sdk and distro intended for robust, embedded applications.