Installed DietPi for the first time this week. I have a RasPi Zero W that I use as a keyserver for other devices to get their LUKS keys off when needed and had Raspbian 11 Lite on it. Did an upgrade to RasPi OS 13 Lite (Trixie based) but it was SO SLOW. SystemD seemed to be doing way too much for a Lite install plus it wouldn’t let me limit the SSH server to a fixed interface without failing due to network not being ready when sshd started.
So I tried DietPi. Wow, really impressed. Good website that didn’t need half the JS on the Internet to function, amazing installer that took the dietpi.txt config and applied everything I want for a one shot setup, and a fast and lightweight OS that responds faster on the Zero W than even Raspbian 11 did.
Thank you to all the devs that have created this really awesome OS. I fully intend to migrate my dual PiHoles to DietPi when I get the time and upgrades are needed.
I started to update our OS comparison page, und hence tested Raspberry Pi OS Lite on RPi Zero W and RPi 5 recently. And I can agree that it worsened significantly since last time (Bookworm-based), when looking at running processes, idle RAM usage, and especially boot time. Part of it is their new network stack, and the switch to cloud-init support (for first run setup), which for some reason remains active and runs again on every boot, resulting in >2 minutes boot time on the RPi Zero W (vs. <30 seconds our end), repeatedly and consistently. I did not test runtime performance though, and of course on RPi 5, the absolute impact isn’t something common users would practically recognize. But <3 seconds vs. >15 seconds boot time there is telling as well, about the different priorities, and evaluation about which base features are commonly really needed, and how to enable them with least overhead. The Raspberry Pi Imager GUI-based pre-configuration is pretty nice, though, I have to admit, if not used to editing plain text config files.
The increasing things systemd does is sadly something we cannot easily dodge either. I did have some discussions with systemd devs in these regards, as some usually invisible new features do cause issues in certain cases, and are IMO at least worth a thought of concern for security reasons as well (like new sockets which enable automatic sshd startup, even if that was explicitly disabled by the admin), and have been made difficult to disable (only via cmdline entry in this particular case). But systemd keeps confirming the old/constant criticism from significant parts of the Linux community, that they do not exactly follow the UNIX philosophy for systemd as a whole (while the individual modules are actually often very good and light).
We are happy and motivated to keep looking into every aspect of the whole OS, dig deep into, and evaluate every feature, see what we can or should disable by default, and what we could implement in a lighter more targeted way .
@MichaIng I really appreciate the core dev responding so well. You have fostered a great community around your work and, despite being very new to this forum, I can see why it is doing well.
I definitely noticed the network and cloud-init impacts when I briefly ran RasPi OS 13 - I definitely did not like the boot times either and the overall responsiveness logging in and using it was a step backwards on my Zero. Maybe not such an issue on faster hardware but definitely an issue for low power, low needs use cases.
I fully understand how hard it is to avoid systemd (I deal with RHEL professionally) and avoid it on my infrastructure at home in general. I do appreciate distributions that either avoid it completely (Slackware mail server) or somehow find a way to make a very good system despite it (Mint desktops, DietPi). I agree that some aspects of systemd do their jobs well, but I just cannot accept the breadth of its components and how, in many cases, it only fits to specific use cases rather than the general freedom that was provided by the implementations it chose to replace.
All of that aside, I really do appreciate the work that goes on creating quality alternatives for use by us mere mortals.
.