Debian stable (ok, writing this on Debian Trixie which is not stable yet, but nonetheless works w/o trouble in a virtual machine).

I am using Debian for work and on my servers.

Why Debian? Because for my use cases there are no real alternatives at this moment.

• I need stable support for Aarch64 and AMD64, which already rules out nearly every other distribution
• For desktops I use a highly customized Gnome, which takes some work and my workflow depends on a few plugins, which rules out Fedora
• For work I need some 3rd party software repositories which again rule out fast moving distributions and other non mainstream distributions
• By now I think I run Debian and distributions based on Debian for nearly 3 decades, everything I need works stable and good enough at this moment and I accumulated a lot of knowledge about how things work in Debian
• Some of my hardware needs workarounds (not because it is too new), and again I know my way around Debian and how to patch/fix things for my hardware
• It is nice that I can use Debian for my desktops and my servers on all hardware I own, I would not want to have to learn different Linux systems for desktops and servers or have different versions of software (think Fedora vs. RHEL/CentOS/Alma etc.)

Every 6 month I’ll boot Fedoras live cd and play around with the newest Gnome/KDE, but seriously, for at least the last 5 years I never feel like essential improvements are pushed in the newest iterations of Gnome/KDE and I can happily wait the maximum of 2 years until they are released with Debian.

Saying that, I also own a Steam Deck and as an entertainment/media station I totally love what Valve is doing there. I would also be totally happy to run a De-Googled ChromeOS if it would support all the platforms/software etc. I need. For containers I’ll also happily use Alpine Linux, if it is possible, but again, I’ll mostly default to Debian simply because I know my way around.

In the end, an operating system is just a necessary evil to allow me to do what I want to do with a computer. As long as I have a stable OS which I can tweak to my liking/needs automatically and central package management, I am good. (Unless it is your hobby to play around with your operating system ;-)).

Count me in! The old installer hat a great UX for people knowing what they wanted to do… There must be dozens of us, dozens! ;-)

Thank you for the tip, I’ll check it out, if the Pi runs unstable again. Just surprised, it sounds that it happened often to you… Since I upgraded to better sd-cards, I never had sd-card trouble again for nearly a decade now. (And I am constantly running multiple Pis 24/7 as servers)

Thanks. I could neither find a file /var/log/kern.log nor did find /var/log | grep -i mess have a match.

dmesg and journalctl -k, found only entries after reboot, that the shutdown was not clean. Any specific logs where I could find more?

Does on mean that /sys/kernel/mm/lr_gen/enabled returns 0x7?

Just set vm.page-cluster to 0, to disable the page read-ahead (AFAIK the default value was set when swap was still on rotating disks).

Arch wiki has some good options for tuning the VM

Debian does not enable it by default, cat /sys/kernel/mm/lru_gen/enabled will be a 0.

I am running Debian 12 on all of my devices with Debians vanilla kernel! :-) Just enable MGLRU on Debian like it is described in this blogpost.

One further tip for ZRAM: On my device the LZ4 algorithm was noticeable faster than ZSTD (didn’t try ZSTD with the enabled MGLRU, yet) and it was important to disable the RAM page read-ahead on my device.

I don’t know either, but unless one uses zstd (lzo seems more like a thing for this hardware), I would hope that it is totally usable. (Running zstd memory compression on a Raspberry Pi 2, w/o any noticeable speed impact)

Show me some numbers! ;-) … Perhaps I miss something, but basically we have 32bit pointers vs. 64bit pointers, the rest of the data should be the same size. 64bit should be faster for tasks where the CPU is the bottleneck/computations, so IMHO it will be an interesting tradeoff with no clear winner for me.

The most important thing is not the distribution, but to enable ZRAM (or ZSWAP) and use a lightweight desktop. I am not sure how much difference a 32bit vs a 64bit distribution makes, but if possible you could take one for the team and run some trials and report your numbers (RAM usage) back here.

Of course I recommend Debian with a lightweight desktop of your choice, or Alpine.

Thanks, this would indeed solve my problem. Still hoping for a better solution, but if everything else fails I’ll utilize it!

Thanks, that would be a valid approach and my last resort.

As you said, I hope someone knows a more elegant solution, though!

Nice, thanks a lot, especially the dirty_bytes settings are interesting to me, because I experience hangs with too much disk IO :-P.

Cheers!

Could you ELI5 the last five settings? I saw that Chrome OS sets vm.overcommit_memory = 1, it seems to make sense but is missing here.

Thanks a lot! You are right, I saw this already.

I can confirm the findings with my benchmarks: zstd has the best compression, lz4 is the fastest.

To my understand it is swap read-ahead, and the number is a power for the base 2. This means the default reads 2^3 = 8 pages ahead. According to what I read, the default of 3 was set in the age of rotating discs and never adapted for RAM swap devices.

Thank you for your answer and your insights.

In my unscientific tests, sysctl/vm.page-cluster made a measurable difference (15% faster when setting it to 0), and it seems everyone else (PopOS, ChromeOS) tweaks at least this setting with ZRAM. I would assume the engineers at PopOS/ChromeOS also did some benchmarks before using this settings.

Now I really would be interested, if you would measure a difference on your 1gb potato SBCs, because IMHO it should even have a bigger impact for them. (Of course, your workload/use cases might make any difference irrelevant, and of course potato SBCs have other bottlenecks like WiFi/IO, which might make this totally irrelevant.

Good points, but again: I would assume advertisers track/fingerprint you anyway, so we are not speaking about getting anonymized information from Mozilla but IMHO we are speaking about getting one more data point about you, which is easy to de-anonymize in combination with the rest of the information known about you.