The Compute Module 4 series have been able to support eMMC chips, so I don't see why they wouldn't continue with the 5 if/when it shows up
It's a fiddly FPC connector though, which isn't a great contributor to mechanical robustness.
It's not so hobbyist/tinkerer friendly, where you're likely to put a lot of cycles on the connector, bend things back and forth, and end up with an enclosure that does not protect everything as well as one would like. Indeed, you have a sibling comment talking about breaking lots of FPC going to cameras.
Mechanical/connector failure is a small but noticeable share of the SD robustness problems on SBCs. I would expect FPC to be worse.
Also, other connectors for this type have surprisingly low durability. Most M.2 slots are rated for extremely low mating cycles. Amphenonol, who I would considered to be an high quality manufacturer, rates their M.2 slots for '25-60' mating cycles total. Less than 100. Most manufacturers do not even specify the number of mating cycles.
I'm not saying they made a bad choice; they're facing a lot of constraints and have a lot of IO to get out while staying hobbyist friendly.
> Also, other connectors for this type have surprisingly low durability. Most M.2 slots are rated for extremely low mating cycles.
Sure, but I don't -need- as many mating cycles for M.2, as it'd be screwed to the board and done. Whereas if I'm dealing with a Pi stackup and coming in and out of the case, I'm likely to get through the couple dozen cycles I'm allowed with FPC. And if I'm putting it on a vibration-intensive environment like a quadcopter, I need to be pretty dang careful with mechanicals.
> Again, this sounds overblown.
Everything's a tradeoff. Flex is cheap and small and offers versatility. It's also delicate and annoying.
250 MB/s is for PCIe 1.
"One of the most exciting additions to the Raspberry Pi 5 feature set is the single-lane PCI Express 2.0 interface. Intended to support fast peripherals, it is exposed on a 16-pin, 0.5mm pitch FPC connector on the left-hand side of the board.
From early 2024, we will be offering a pair of mechanical adapter boards which convert between this connector and a subset of the M.2 standard, allowing users to attach NVMe SSDs and other M.2-format accessories."
As you keep spamming this here, did you read the HN Guidelines[0]?
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
> did you read the HN Guidelines[0]?
OK…
I did read that they were going to support M.2., and I have gotten around my issues with SD cards in the past using SSD-grade USB drives and NVMe adapters. My comment was about how crap SD cards are, and how this class of SBCs (including the PI 5) often use them as their default storage (as in, not needing an adapter or special firmware to boot). My final statement was my wish for a high speed durable storage standard that was better than SD cards without having to spend more money than the SBC itself on storage, although looking today on Amazon it seems that NVMe drives have gotten way cheaper, no idea of those are quality though.
Those I’ve acquired this way worked well, those I’ve brought off online stores almost always had problems or short lives (or both).
Also, those micro SD cards were always fine after a format/partition and I can still use them in other devices just fine. I've read before that the Pi has a tendency to corrupt micro SD cards through its reader, and IIRC it's related to power issues.
Combined with a portable LCD, it's a low-power dev workstation on a battery. ^_^
One is an NTP server which gets the time from GPS, although that one will probably be retired soon, internet time works fine.
I used to have one inside a MAME cabinet but I upgraded it to a "real" PC because the Pi isn't really powerful enough for modern versions of MAME.
You need a server to host the ISO (via http/ftp/tftp or whatever you prefer) and a DHCP server that will distribute the ISO URI to the client.
Configure the client to boot from the network in the bios and put it in the same LAN as the dhcp server.
That's the gist of it.
99% of the time it's the verbose logging of application servers that is the culprit of sdcard failures.
I had to do this when I was doing some long-running I/O intensive operations and it was basically killing the SD card storage.
One of the things I do is to configure hosts to use the overlayfs (read only fileystem) where appropriate and that helps to reduce wear on the SD cards.
I don't use then where I want a responsive system and use USB/SSD or NVME/SSD instead.