Live data from Hacker News

Why systemd is a problem for embedded Linux

kevinboone.me

41–50 of 308 posts

Re: Why systemd is a problem for embedded Linux

#42
Meh, we are not in 2021 or 2018 anymore.

Eudev and elogind ARE mantained and used in voidlinux and gentoo, and anyways being that embedded it doesn't seem clear to me where would the "hard dependency of a very essential software on some systemd-thingd" happen.

Re: Why systemd is a problem for embedded Linux

#43
post #36
post #31

Earlier quoted context omitted.

The thing is, the good things are the things you don't notice; the things that just work. They didn't used to "just work" like that before systemd. System boot is faster. I can have fewer things started up in the background, and instead have them start up when needed. Restarting services works consistently. Every application doesn't have its own bespoke and half baked management scripts which don't work half the time…

> the good things are the things you don't notice; the things that just work sorry, no, at least in any meaningful sense, because init already just worked for me. and when something didn't, I could find how to fix it in a way that was transparent and I understood and could even modify or make better, without being connected to the internet looking for cargo cult incantations on stack overflow init was a tool; systemd…

Yeah, the two systemd components GP mentioned have given me no end of trouble.

Re: Why systemd is a problem for embedded Linux

#44
post #30

> With care, though, a minimal installation of systemd does run on a low-resource ARM board like the Pi 3. In fact, it will run on a board with 1Gb RAM, perhaps even lower. Come fucking on. I ran systemd on a 32Mb MIPS board (RouterBoard from Mikrotik) just fine. The RES column is incredibly misleading in this case, because systemd is the first app in the system. So it gets charged for loading the entire glibc and th…

systemd itself is also large in storage size(8MB?), which is why openwrt has its own procd replacements, and yocto is not default to systemd either due to this. additionally, systemd does not work well with musl which is very popular in embedded linux.

Re: Why systemd is a problem for embedded Linux

#45
I couldn't disagree more: I've worked with lots of embedded devices running systemd, and it solves many more problems than it introduces. The community is also quite responsive and helpful in my experience.

I won't pretend there aren't occasional weird problems... but there's always a solution, here's a recent example: https://github.com/systemd/systemd/issues/34683

Memory use is irrelevant to me: every embedded Linux device I've been paid to work on in the past five years had over 1GB of RAM. If I'm on a tiny machine where I care about 8MB RSS, I'm not running Linux, I'm running Zypher or FreeRTOS.

Re: Why systemd is a problem for embedded Linux

#46
post #32

The article fails to mention another aspect of systemd that interferes with emmbedded dvelopment: it's utility applications (primarily systemctl, but all the others as well) are intended to be run on the booted system for which the control is being performed. When configuring boot media, like an SD card, for an embedded ssystem that is not the running system where the configuration is occurring, this is an impediment…

Can you be specific about what cannot be configured on mounted embedded media?

systemd follows the drop-in config file model where configuration snippets are placed into directories (like .d/ directories in Debian). It should not be necessary to run utilities from the target system in order to configure it on mounted media.

Drop unit files for services, sockets, filesystem mounts, timers, etc onto the mounted media and they will be detected when the target system boots.

Re: Why systemd is a problem for embedded Linux

#48
post #39

Earlier quoted context omitted.

What do you imagine this proves or disproves? How many people eat McDonalds? Or buy in to countless other things that can be trivially demonstrated to be against their own interests. I don't know about anyone else but I never heard the critiques of systemd to be based on any doomsday predictions. Everyone knew it would function, and that it even serves one use case better than before. The critique was only ever that…

> How many people eat McDonalds? If you’re already starting like this it’s obvious that the following text will be non-scientific non-sense. As a reminder: There is no such thing as “healthy food” and “unhealthy food”, there is just healthy and unhealthy nutrition. Still baffles me that people think it would actually be legal to sell actual unhealthy food, i.e. poisonous food. Also, “organic food” is just a marketing…

And yet, you’ll still find many of us that think systemd is worse, but for different reasons. (I think the food analogy was lost)

Re: Why systemd is a problem for embedded Linux

#49
post #34

The memory comparison isn’t really fair as SysVInit relies on external utilities for starting and stopping processes. At the very least, SysVInit requires a shell for running init scripts which systemd doesn’t need for native service files.

Real embedded developers wouldn’t stand for the overhead of modern stuff like SysVInit.

Re: Why systemd is a problem for embedded Linux

#50

I couldn't disagree more: I've worked with lots of embedded devices running systemd, and it solves many more problems than it introduces. The community is also quite responsive and helpful in my experience. I won't pretend there aren't occasional weird problems... but there's always a solution, here's a recent example: https://github.com/systemd/systemd/issues/34683 Memory use is irrelevant to me: every embedded Linu…

Small typo: Zephyr https://zephyrproject.org/
Post reply on HN