Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd is a problem for embedded Linux

kevinboone.me

Post reply on HN
Print view View original

121–130 of 308 posts

Re: Why systemd is a problem for embedded Linux

#121

Post by simoncion »

throwaway2037 wrote: post #117
simoncion wrote: post #97

Earlier quoted context omitted.

The systemd maintainers are pretty particular about things that aren't a "supported use case", so even if you bother to do the work, you stand a solid chance of having your work be wasted. In my professional experience, "unsupported use case" effectively means "I don't want to work on that". [0] Also, at $DAYJOB, we run into mysterious systemd failures and misbehaviors at least once a year (usually for things that sh…

> we run into mysterious systemd failures and misbehaviors at least once a year Can you share an example?

> Can you share an example?

The most detail my NDA permits me to get into is that our most recent failure was that the systemd cron replacement gets in a state where it refuses to ever schedule a scheduled task and that the systemd folks were like "aw, shucks" about it.

Re: Why systemd is a problem for embedded Linux

#122

Post by nubinetwork »

foul wrote: 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...

Re: Why systemd is a problem for embedded Linux

#123

Post by pwg »

thnkman wrote: post #109
0xbadcafebee wrote: post #95

Systemd, Wayland, DBus, and other modern Linux "solutions" are all problematic for the same reason: they are complex monoliths that are extremely difficult to replace, in part or in whole. Systems often won't work without them, because the entire ecosystem has grown dependent on them. You literally can't run a modern desktop without a bunch of "shims" whose sole purpose is to fake being systemd. The best designs, sad…

Where have you heard that Slackware will be using systemd next release? I have been using slackware for years, and this is news to me.

There's nothing named "systemd" in the FILE_LIST [1] for Slack64-current (which is what eventually becomes "the next release" at the appropriate time.

So it would seem the GP has been taken in by some rumor somewhere.

[1] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-cur...

Re: Why systemd is a problem for embedded Linux

#124

Post by TheCycoONE »

0xbadcafebee wrote: post #95

Systemd, Wayland, DBus, and other modern Linux "solutions" are all problematic for the same reason: they are complex monoliths that are extremely difficult to replace, in part or in whole. Systems often won't work without them, because the entire ecosystem has grown dependent on them. You literally can't run a modern desktop without a bunch of "shims" whose sole purpose is to fake being systemd. The best designs, sad…

Wayland seems like an odd entry in that list. It's mostly a strugle for people because it's not the monolith X was and now we have dozens or hundreds of different applications from different vendors to cover a subset of the functionality that was built in. In that sense X was the complex monolith that is extremely difficult to replace.

Also unlike the complaints about systemd in the article, Wayland is well suited to embedded. Automotive Grade Linux was an early adopter. It's desktop usage that has taken longer.

Re: Why systemd is a problem for embedded Linux

#125

Post by kelnos »

jcalvinowens wrote: post #116
Aurornis wrote: post #111

Earlier quoted context omitted.

You have been living in a strange world if you’ve been getting away with 1GB in the average consumer IoT device for the past 5 years. That’s not typical at all. I’ve done a lot of work with production runs in the millions. There is no way we’d put that much RAM on a device unless it was absolutely, undeniably required for core functionality.

I've asked in the past, and been told that a even a 2x-3x difference in the amount of RAM made such a negligible difference in cost it was decided to go with the larger amount. I frankly have a hard time understanding how that can be true... but I can't really imagine why they wouldn't be honest with me about it.

> I've asked in the past, and been told that a even a 2x-3x difference in the amount of RAM made such a negligible difference in cost it was decided to go with the larger amount

That doesn't pass the sniff test. Look at retail RAM prices. Certainly the magnitude of the price is quite different than buying individual RAM chips at quantity, but the costs do scale up as RAM size goes up. Hell, look at RAM chip prices: you are definitely going to increase the price by more than a negligible amount if you 2x or 3x the amount of RAM in your design.

Also consider the Raspberry Pi, since the article mentions it quite a bit: RAM size on the Pi is the sole driver of the different price points for each Pi generation.

Re: Why systemd is a problem for embedded Linux

#126

Post by skydhash »

somerandomqaguy wrote: post #114
0xbadcafebee wrote: post #93

Earlier quoted context omitted.

> every embedded Linux device I've been paid to work on in the past five years had over 1GB of RAM That is almost by definition not an embedded device. There's a reason we have vfork().

Huh? Been a while since I was in the digital signage space but a lot of the equipment runs of the shelf RK3288 plugged into commercial displays. 2GB of RAM was pretty common. IIRC's though LG's WebOS TV's have minimum 2GB of RAM in the digital signage space directly built into the units themselves. I believe Samsung Tizen based units has similar RAM. My router has 1GB of RAM in it. But even my cheapest routers have 1…

A decade ago, I had to settle for 512MB of ram for my Windows XP desktop.

Re: Why systemd is a problem for embedded Linux

#127

Post by jcalvinowens »

Aurornis wrote: post #110
jcalvinowens wrote: post #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 Linu…

> 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 The gap between “over 1GB of RAM” and 8MB RSS contains the vast majority of embedded Linux devices. I, too, enjoy when the RAM budget is over 1GB. The majority of cost constrained products don’t allow that, though…

> The gap between “over 1GB of RAM” and 8MB RSS contains the vast majority of embedded Linux devices.

Of all currently existing Linux devices running around the world right this moment? Maybe.

But of new devices? Absolutely not, and that's what I'm talking about.

> The majority of cost constrained products don’t allow that, though.

They increasingly do allow for it, is the point I'm trying to make.

And when they don't: there are far better non-Linux open source options now than there used to be, which are by design better suited to running in constrained environments than a full blown Linux userland ever can be.

> It increases boot times (mentioned in the article) which is a pretty big deal on certain consumer products that aren’t always powered on. The article makes some good points that you’ve waved away because you’ve been working on a different category of devices.

I've absolutely worked on that category of devices, I almost never run Linux on them because there's usually an easier and better way. Especially where half a second of boot time is important.

Re: Why systemd is a problem for embedded Linux

#128

Post by silverliver »

dcsommer wrote: post #77
transpute wrote: post #16

OpenEmbedded/Yocto, Devuan and Gentoo provide multiple init systems. systemd CVEs: https://ubuntu.com/security/cves?package=systemd&limit=100 Rust PoC: https://github.com/KillingSpark/rustysd > Rustysd is a service manager that tries to replicate systemd behaviour for a subset of the configuration possibilities. It focuses on the core functionality of a service manager, not requiring to be PID1 (aka init process).. c…

How many systemd CVEs are memory or thread safety related?

What do memory and thread safety have to do with the project's stated goals? I for one would love to avoid systemd's arbitrary requirements while retaining compatibility with upstream (e.g. PID must be 1).

Re: Why systemd is a problem for embedded Linux

#129

Post by phendrenad2 »

stefan_ wrote: post #81
phendrenad2 wrote: post #23

Wait so systemd is a problem for embedded Linux because... it uses 250MB of RAM? So it's only really a problem for systems where using a mainstream distro probably wouldn't even be a consideration anyway (yocto seems to be popular, as mentioned above). I'm not seeing a strong argument here. At the risk of inviting a parade of "actually, one time at band camp I saved the day with a first-gen raspberry pi zero", how ma…

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.

Re: Why systemd is a problem for embedded Linux

#130

Post by phendrenad2 »

redleader55 wrote: post #103
phendrenad2 wrote: post #23

Wait so systemd is a problem for embedded Linux because... it uses 250MB of RAM? So it's only really a problem for systems where using a mainstream distro probably wouldn't even be a consideration anyway (yocto seems to be popular, as mentioned above). I'm not seeing a strong argument here. At the risk of inviting a parade of "actually, one time at band camp I saved the day with a first-gen raspberry pi zero", how ma…

(Almost) All the routers that people have in their homes - the ones running OpenWRT - have between 64-256 MB RAM, and no swap. Raspberry Pis are not "embedded", they are cheap, low power consumer devices.

Actually, modern routers typically have 512MB RAM. And RPis absolutely are embedded, not only are they often used for one-off embedded installations due to the 2-day lead time from Amazon, but also the compute module is very popular in industrial control.
Post reply on HN