Live data from Hacker News

Why systemd is a problem for embedded Linux

kevinboone.me

201–210 of 308 posts

Re: Why systemd is a problem for embedded Linux

#201
It is unfortunate that after all this time the basic reasons why systemd was introduced and has been so successful are pervasively misunderstood.

> The majority of Linux users are uninterested in the pros and cons of systemd. A small number are violently opposed to it, and a small number are violently opposed to those who are opposed to it.

Starting out by framing systemd in terms of opposition deliberately steers attention away from the issues that drive its adoption. The tone is moderate, but this is not good faith argumentation.

> I think there’s little argument that the main target for systemd is a general-purpose computer, with a modern, integrated graphical desktop

That is one of the targets. The main target is servers that run the web of services typically required to back up modern applications. What if an application depends on a resource server which itself depends on a remote filesystem being mounted and an event service running. Theoretically that can work with System V init, but how tricky is that to put in place and make robust? Administrators for systems vending complex interdependent services are the main target and always have been.

> Unfortunately, what makes systemd good for general-purpose desktop applications

Get it wrong and then run with it. Failing to understand what is driving adoption of systemd leads to arguments about it that don't really go anywhere.

> The more fundamental problem is that the people who most like systemd are distribution managers. Sure, there are administrators who like it, and defend it vigorously; but most end users and administrators don’t really care.

Not distribution managers, but system administrators. They are the ones with the complex needs that systemd serves. As such they advocate for it and because of the lack of working alternatives distribution managers switch to it in order to please the largest number of clients. Thinking of systemd in terms of desktop systems and distribution managers means misunderstanding why it is there in the first place.

Re: Why systemd is a problem for embedded Linux

#202
post #10

Earlier quoted context omitted.

Turns out, many people use systemd after what, 15? years of doomsday predictions :-)

Turns out many people don't care to change their distribution defaults.

Exactly, because I don't care about the plumbing in my house unless it's really bad. Systemd is opinionated and quirky but it does the job just fine for 99.999% of people and it provides a standardized approach to things just by virtue of how it works, and there is a lot of value in that.

Re: Why systemd is a problem for embedded Linux

#203
post #81

Earlier quoted context omitted.

Thats a weird question, every embedded system that is a consumer product will end up with limited RAM simply because less RAM is a $1 saved on the BOM. For most systems, RAM is a choice, and for many of them someone will ask at the end "how much can we get away with". (Your WiFi router probably has 256 or 512 MB of RAM)

I argue that the extra $2.50 (or whatever) to expand to 4GB is worth being able to use a stock Debian + systemd.

$2.50??

Re: Why systemd is a problem for embedded Linux

#204
post #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.

https://www.gentoo.org/support/news-items/2021-08-24-eudev-r...

https://github.com/eudev-project/eudev

https://github.com/elogind/elogind

Re: Why systemd is a problem for embedded Linux

#205
post #200

Earlier quoted context omitted.

My TP-Link MR3020 from around 2015 only has 4^H 16 MB of ram (4 MB flash) and thus cannot even run OpenWRT anymore.

I’ve still got two MR3040. TP-Link hasn’t released any update for them in years. You can run an older version of OpenWrt on them, but there’s no real point. These things don’t even support 5GHz WiFi.

Device with very nice design. I still keep it as decorative even when its a brick.

Re: Why systemd is a problem for embedded Linux

#206
TBH, my biggest gripe is that systemd doesn't play nice with musl or ulibc, I would like to not have to ship a cron, a supervisor, a xinetd equivelant, and a binary just to react to inotify/dnotify events. Though openrc how has a supervisor.

Re: Why systemd is a problem for embedded Linux

#207
post #80

Earlier quoted context omitted.

Okay, I'll bite. What kind of problems do you have with the part of systemd that replicates sysvinit /every other day/?

My most common issues with systemd are related to those long timeouts when something at boot/shutdown is not working as intended, and unexplained/unexplainable changes to the order of boot of some components. For the former I have given up playing whackamole with all the timeouts you need to reconfigure, for the latter I didn't even try because I know that there's something peculiar about my setup that will never wor…

> My most common issues with systemd are related to those long timeouts when something at boot/shutdown is not working as intended

That’s an issue with a daemon, not systemd. Anyone who used NFS saw that routinely on SysV init during the era when Red Hat distributions shut down networking before ensuring that the network mounts were unmounted.

Re: Why systemd is a problem for embedded Linux

#208
post #158

Earlier quoted context omitted.

> There would have been a time when people would have said that 32MB is a crazy high amount of memory Those days are long gone though, for better or worse. We live in the 2020s now and ram is plenty. The small computers we all carry in our pockets (phones) usually have between 4 and 16g GB ram.

That's entirely the point. In the days of user devices with 32MB of RAM, embedded devices were expected to make do with 32KB. Now we have desktops with 32GB and the embedded devices have to make do with 32MB. But you don't get to use GB of RAM now just because embedded devices might have that in some years time, and unless something is done to address it, the increase in hardware over time doesn't get you within the…

I recently looked up 2x48GB RAM kits and they are around 300€ and more for the overclockable ones. That is 3€ per GB and this is in the more expensive segment in the market since anyone who isn't overclocking their RAM is fine using four slots.

Re: Why systemd is a problem for embedded Linux

#209
post #84

Earlier quoted context omitted.

A little bit. The tldr; is that there are a lot of periodic activities including log rotation, automatic updates, time syncing, waking up to check if such things were currently needed, .... Those are generally nice (aside from automatic updates, which are sometimes good but I think usually more harmful than whatever they're fixing), but systemd doesn't know anything about what my userspace demands on the hardware are…

> For anything quasi-realtime, I can certainly hunt down and squash everything systemd is running at the wrong time, but in practice it's much easier to install something else, ensure no processes are running other than the ones I care about, and move those concerns to userspace. Should these issues be fixed by CPU/IO schedulers? Are there any systemd realtime tasks involved?

Now that the realtime patch is in mainline Linux, that approach might make more sense going forward. I don't think systemd has any meaningful realtime tasks by default. My current job has a different set of performance constraints (only need low latency something like 99% of the time, so systemd and noisy cloud neighbors and whatnot are fine), so I probably won't be looking at that part of the stack in any depth any time soon.

Re: Why systemd is a problem for embedded Linux

#210

Earlier quoted context omitted.

> The gap between “over 1GB of RAM” and 8MB RSS contains the vast majority of embedded Linux devices The gap between 16MB RAM and 64MB RAM doesn't exist, though. Literally doesn't, the components have the same cost down to a cent in the BOM. And if you can have 64MB, then there's systemd's own true memory use (around 3-4MB) is completely immaterial.

except thanks to availability crisis hitting the industry for the past decade you have to go with the 4mb sometimes just look at wifi routers. in the usa and China they are all sold with 64 or 128mb ram. south America and Europe they are all 16 or 32 for no clear reason.

> south America and Europe they are all 16 or 32 for no clear reason

I don't know where you're getting your data from but it's clearly wrong or outdated. These are the most often sold routers in Czechia on Alza (the largest online retailer) under $100:

- TP-Link Archer AX53 (256MB)

- TP-Link Archer AX23 (128MB)

- TP-Link Archer C6 V3.2 (128MB)

- TP-Link Archer AX55 Pro (512MB?)

...

- Mercusys MR80X (256MB)

- ASUS RT-AX52 (256MB)

https://www.alza.cz/EN/best-sellers-best-wifi-routers/188430...

Post reply on HN