“It’s been wild to read endless online complaints from so-called ‘technical’ RPi users for the last 13 years about SD card wear and tear…”

A lot of the SD-card wear issues come from people running “normal PC workflows” on a storage medium that was never designed for that pattern.

Something I’ve seen help many newcomers is simply enabling an overlay filesystem or tmpfs-based writes. It’s basically the middle ground between a full RAM-boot distro (piCore, Alpine diskless, NetBSD) and a standard SD-based Raspberry Pi OS.

You still get the normal ecosystem and docs, but almost no writes hit the card unless you explicitly commit them.

For anyone stuck between “I want something simple” and “I don’t want my SD to die,” overlays are the easiest win.

Tesla rather famously had issues by writing logs to SD storage.

There is (at least) two different groups of people using Raspberry PI. One of them are completely new Linux users who need a ton of help and resources to understand enough so they can achieve what they're trying to do. Raspbian/Raspberry Pi OS, even with their faults, is probably the better option for those people, as the environment and context very much takes first time users into account.

NetBSD and Tiny Core Linux, even with all their benefits, is a harder experience to get into if you haven't already dipped your toes into Linux, and doesn't have the same wide community and boundless online resources.

The point I'm making is not that NetBSD is a solution

The point I'm making is that putting the rootfs on a memory filesystem, e.g., tmpfs, mfs, etc. avoids the problem with SD cards^1

This can be done with a variety of operating systems. IMO, the advantange of the RPi hardware is that it is supported by so many different operating systems

When I want to run additional, larger programs that are not in the rootfs I have embedded into the kernel, I either (a) run them from external storage or (b) copy them to the mfs/tmpfs

It depends on how much RAM I have available

1. There are probably other ways to avoid the problem, too

I suspect the majority of "SD corruption" on RPis is due to bad power supplies or EMI causing the system to misbehave (and write erroneous data to the card) rather than actually exhausting the card's write capacity.

That's been my experience. The Pi 3 was notorious for killing SD cards, for instance. I know one guy who eventually just moved all Pi 3 installations he made over to USB sticks because every Pi 3 he used would just kill SD cards at random but far faster than they should have. Not many write cycles at all, just surged the cards or something.

I actually considered NetBSD for an old 32 bit box yesterday, so I'm somewhat wise to this world. My first experience with ramdisk operating systems was Puppy Linux back in the early 2010s. Ultimately I'm probably going with OpenBSD for that box.

But, NetBSD ISOs are much heavier than TCL ISOs, and so while I'm sure there's a way to get just what I want working in diskless mode, I'm not confident I will have any RAM to run what I actually want to run on top of it.

Hi check this https://smolbsd.org/#about Also standard NetBSD ISO might not be useful do check platform specific images.

Puppy Linux was pretty sweet back then, I used it for a Gecko machine for a few years until I got a vastly more powerful 'flat' netbook that arrived after those. It was a pretty nice gadget, though one had to have small and/or flexible fingers or the keyboard would have been a pain.

https://www.digitalreviews.net/reviews/pc/norhtec-xcore-geck...

I've noticed Puppy is still around but I have no idea whether it can still be comparable to Tiny Core.

What's the size of your "diskless" NetBSD installation, and how fast does it boot?

As compared to TC, the "out of the box" NetBSD images contain many things I wouldn't need, so customizing it has been a recurring thought, but oh well. The documentation and careful modularity is, obviously, a huge bonus of NetBSD in that regard (even an end-user like me could do some interesting modifications of the kernel solely by reading the manual). TC seems much more ad-hoc, but I assume this, too, is intentional, by design.

In 2011, TCL was 10MB

Around that time the NetBSD kernels with embedded rootfs filesystem I was making were around 17MB

Today, TCL is 23MB

The NetBSD kernels with embedded rootfs I'm using today are around 33MB

That size can be reduced of course

I don't monitor the boot process on RPi with serial console, I only connect after tinysshd is running, so I don't pay close attention to boot speed. It's fast enough

TCL appears to be aimed at users that prefer a binary distribution; also it provides GUI by default

I prefer to compile from source and I only use textmode hence NetBSD is more suitable for me than TCL

For someone who does not want to compile anything from source, it is possible to "customise" (replace) the rootfs of a NetBSD install image with another rootfs. It is not documented anywhere that I'm aware of but I have done it many times

I use a very minimal userland. I guarantee few if any HN readers would be satisfied with it. If I need additional programs I either (a) mount an external drive and run the programs from external storage, e.g., via chroot, or (b) copy them from an external drive into mfs or tmpfs

It depends on how much RAM I have

Check this https://smolbsd.org/#about

This appears to be new to me. Very interesting, many thanks for sharing!

I set up a similar system using NixOS, no writes to the disk by default.

Though I don't explicitly load the entire userspace into RAM, since this is a laptop and I don't foresee a need to remove the SSD after boot.

Back in the day I believe I just installed the OS on a USB stick and used the SD card only to boot of that.