“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.

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.

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.

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 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.

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.

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.

I recently put Alpine with i3 on a Raspberry Pi 4 Model B and I'm super impressed with how snappy it is. I find it much better even than Raspberry Pi OS Lite.

I can vouch for it, I had an RPi that was translating a serial port to TCP/IP in a difficult to access location, and it stayed doing its duty for years, Alpine is very solid.

Important to mention: Alpine can run from RAM like TinyCore

on a pi?

You can run nodejs fine on a pi with "Raspberry Pi OS Lite". In the configs, look for "Overlay File System" and enable it on the boot partition and main partition. The pi will boot from the sd card and run entirely in ram.

Be sure to run something to clear your logs occasionally or reboot once in a while or you'll run out of RAM. Still, get a quality sd card and power supply. You can get years out of a setup like this.

To my understanding TCL expects the RAM-only / diskless case unless you put in a lot of extra work not to do that. In your situation the only thing you would have to really be worried about is whether 4 GB of RAM or whatever you have is enough to fit TCL and the files for your node server and the actual programs you are trying to run with all that. It doesn't get pretty once you exceed your available RAM, be forewarned - but that's true of all programs in a sense.

Yep. PiOS Desktop (for x86) was a superb very-lightweight distro.

I carefully put a fairly minimal Xfce setup on it instead of LXDE and RAM usage doubled. It's impressively hand crafted and pruned.

Sadly, though, it hasn't been updated since Debian 11.

Ive experimented with several small distros for this when doing cross platform development.

In my experience, by the time you’re compiling and running code and installing dev dependencies on the remote machine, the size of the base OS isn’t a concern. I gained nothing from using smaller distros but lost a lot of time dealing with little issues and incompatibilities.

This won’t win me any hacker points, but now if I need a remote graphical Linux VM I go straight for the latest Ubuntu and call it day. Then I can get to work on my code and not chasing my tail with all of the little quirks that appear from using less popular distros.

The small distros have their place for specific use cases, especially automation, testing, or other things that need to scale. For one-offs where you’re already going to be installing a lot of other things and doing resource intensive work, it’s a safer bet to go with a popular full-size distro so you can focus on what matters.

Isn’t this what GitHub remote envs are (or whatever they call it)?

Never really got what it’s for.

moonlight / sunshine might work if you can't run it locally.

It'd be best with hardwired network though.

I used to use it during the netbook era, was great for that.

No I tried to use it but it didn't click with me. I had it on cd but I'd normally reach for something else.

I like using old hardware, and Tiny Core was my daily driver for 5+ years on a Thinkpad T42 (died recently) and Dell Mini 9 (still working). I tried other distros on those machines, but eventually always came back to TC. RAM-booting makes the system fast and quiet on that 15+ years old iron, and I loved how easy it was to hand-tailor the OS - e.g. the packages loaded during boot are simply listed in a single flat file (onboot.lst).

I used both the FLTK desktop (including my all-time favorite web browser, Dillo, which was fine for most sites up to about 2018 or so) and the text-only mode. TC repos are not bad at all, but building your own TC/squashfs packages will probably become second nature over time.

I can also confirm that a handful of lenghty, long-form radio programs (a somewhat "landmark" show) for my Tiny Country's public broadcasting are produced -- and, in some cases, even recorded -- on either a Dell Mini 9 or a Thinkpad T42 and Tiny Core Linux, using the (now obsolete?) Non DAW or Reaper via Wine. It was always fun to think about this: here I am, producing/recording audio for Public Broadcasting on a 13+ year old T42 or a 10 year old Dell Mini netbook bought for 20€ and 5€ (!) respectively, whereas other folks accomplish the exact same thing with a 2000€ MacBook Pro.

It's a nice distro for weirdos and fringe "because I can" people, I guess. Well thought out. Not very far from "a Linux that fits inside a single person's head". Full respect to the devs for their quiet consistency - no "revolutionary" updates or paradigm shifts, just keeping the system working, year after year. (FLTK in 2025? Why not? It does have its charm!) This looks to be quite similar to the maintenance philosophy of the BSDs. And, next to TC, even NetBSD feels "bloated" :) -- even though it would obviously be nice to have BSD Handbook level documentation for TC; then again, the scope/goal of the two projects is maybe too different, so no big deal. The Corebook [1] is still a good overview of the system -- no idea how up-to-date it is, though.

All in all, an interesting distro that may "grow on you".

1: http://www.tinycorelinux.net/book.html

I use one of them to make an old EEE laptop a dedicated Pico-8 machine for my kids. [https://www.lexaloffle.com/pico-8.php]

In college I used a Slax (version 6 IIRC) SD card for schoolwork. I did my work across various junk laptops, a gaming PC, and lab computers, so it gave me consistency across all of those.

Booting a dedicated, tiny OS with no distractions helped me focus. Plus since the home directory was a FAT32 partition, I could access all my files on any machine without having to boot. A feature I used a lot when printing assignments at the library.

All sorts. Having a full bootable OS on a CD or USB was always cool. When I left the military and was a security I used to use them to boot computers in the buildings I worked in so I could browse the internet.

Before encryption by default, get files from windows for family when they messed up their computers. Or change the passwords.

Before browser profiles and containers I used them in VMs for different things like banning, shopping, etc.

Down to your imagination really.

Not too mention just to play around with them too.

They can be nice for running low footprint VMs (e.g. in LXD / Incus) where you don't want to use a container. Alpine in particular is popular for this. The downside is there are sometimes compatibility issues where packages expect certain dependencies that Alpine doesn't provide.

I used DSL for the control of a homebrew 8' x 4' CNC plasmacutter.

I had a 386 PC with 4MB of RAM when I was a kid, and it ran Windows 3.1 with a GUI, but that also had a VGA display at 640x480, and only 16-bit color (4 bits per pixel). So 153,600 bytes for the frame buffer.

The Amiga 500 had high res graphics (or high color graphics … but not on the same scanline), multitasking, 15 bit sound (with a lot of work - the hardware had 4 channels of 8 bit DACs but a 6-bit volume, so …)

In 1985, and with 512K of RAM. It was very usable for work.

It's so much fun working with systems with more pixels than ram though. Manually interleaving interrupts. What joy.

More like 6.2+ MB, or at least I'd sure hope that a FHD resolution is paired with at least a 24 bit (8 bpc) SDR color. And then there's the triple buffered vsync at play, so it's really more like 18.6+ MB.

Those old computers were 640x480 or so. Maybe smaller.

Do you really need the framebuffer in RAM? Wouldn't that be entirely in the GPU RAM?

You do not really need a framebuffer to drive a GUI, though. That's very much a PC thing.

That's only RISC OS 2 though. RISC OS 3 was 2MB, and even 3.7 didn't have everything in ROM as Acorn had introduced the !Boot directory for softloading a large amount of 'stuff' at boot time.

> The Acorn Archimedes had the whole OS on a 512KB ROM.

True. And it's still around. It's FOSS now, runs natively on a Raspberry Pi 1-400 and Zero, and has Wifi, IPv6, and a Webkit browser.

https://www.riscosopen.org/content/

https://www.riscosdev.com/direct/

If that is a lot less of things not needed for the specific use case, that is still a big plus.

They had a free distro for a while, it's was pretty exciting being real time and with a microkernel and such. As a CS student it was neat to see where the world of computing might have went if different decisions had been made in the past.

Here’s a blast of classic internet: http://toastytech.com/guis/qnxdemo.html

No ssl, probably so you can access that site on the browser

64 bit generally adds about 20% to the size of the executables and programs as t to last on x86, so it's not that big of a change.

Switch to an ILP32 ABI and you get a lot of that space back

There’s an installation option to run apps off disk. It’s called “The Mount Mode of Operation: TCE/Install”.

To think that the entire distro would fit in a reasonable LLC (last level cache)..

640x480 with 16 colours was standard in offices in the late 80s.

If you were someone special, you got 1024x768.

Somebody has build it: https://membarrier.wordpress.com/2017/04/12/qnx-7-desktop/

Licensing, and QNX missed a consumer launch window by around 17 years.

Some businesses stick with markets they know, as non-retail customer revenue is less volatile. If you enter the consumer markets, there are always 30k irrational competitors (likely with 1000X the capital) that will go bankrupt trying to undercut the market.

It is a decision all CEO must make eventually. Best of luck =3

"The Rules for Rulers: How All Leaders Stay in Power"

https://www.youtube.com/watch?v=rStL7niR7gs

As someone who used QNX back then, they didn't target end-users but embedded and real-time users.

They were expensive too. You had to pay for each device driver you used.

because it's not free and their aim was at developers and the embedded space. How many people have even heard of QNX?

Me too! And the GUI was only a 40KB distribution and was waaaaaay better than Windows 3.0!

> yeah but what can you do with free QNX?

« QNX DEMO disk

Extending possibilities and adding undocumented features »

http://qnx.puslapiai.lt/qnxdemo/qnx_demo_disk.htm

Same situation but I'm using NetBSD instead. I'm betting it'll still be supporting 32-bit x86 long after the linux kernel drops it.