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

31–40 of 308 posts

Re: Why systemd is a problem for embedded Linux

#31

Post by lambda »

fsckboy wrote: post #14
oblio wrote: post #10

Earlier quoted context omitted.

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

i don't notice anything good systemd does for me, just where it interferes, and that's a constant annoyance, a few days a week.

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. They don't all have to invent their own daemonization support and logging; you just log to the journal.

And that's just core systemd. Things like systemd-resolved give me proper support for split-DNS when using VPNs. systemd-networkd gives me consistent, powerful configurable networking setup that works across distros.

Is it perfect? No, I do still have some complaints with it. But it's a hell of a lot better than what it's replacing. I wouldn't ever go back to sysvinit or upstart, and many other parts of systemd are compelling alternatives to the things they replace, like systemd-networkd over ifupdown.

Re: Why systemd is a problem for embedded Linux

#32

Post by johnea »

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. There is systemd-firstboot, etc, but this is not as convenient as just being able to set config options on the mounted (non-booted) embeddded media.

I've never liked it, I still don't like it, and I think the number of people in this camp is understated by the article.

However, I am still running it. As other posts have mentioned, switching distributions is a major hasstle, especially if you've built tools using the distro's architecture. For me, this is archlinux.

Although, I am in the process of testing and migrating to void linux. Which is systemd free, and hosts ARM and x86 binary package repositories.

Re: Why systemd is a problem for embedded Linux

#33

Post by detaro »

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…

> how many embedded systems in 2024 are really RAM-limited?

A lot. Plenty embedded Linux stuff still ships with 256 MB or 512 MB RAM, and the wishlist for features in the software running on top is always getting longer than initially planned...

But of course the average has moved up, and it's not unusual to see systemd in embedded systems either (while I don't have a number at hand, the 250MB number seems off to me). The space is big, and different constraints and rules at different points in there.

Re: Why systemd is a problem for embedded Linux

#35

Post by amelius »

cyberax wrote: 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…

This should be the top comment.

Re: Why systemd is a problem for embedded Linux

#36

Post by fsckboy »

lambda wrote: post #31
fsckboy wrote: post #14

Earlier quoted context omitted.

i don't notice anything good systemd does for me, just where it interferes, and that's a constant annoyance, a few days a week.

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 is an adversary

Re: Why systemd is a problem for embedded Linux

#38

Post by [deleted] »

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…

[deleted]

Re: Why systemd is a problem for embedded Linux

#39

Post by cbmuser »

Brian_K_White wrote: post #28
oblio wrote: post #10

Earlier quoted context omitted.

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

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 scam. If you think your nutrition is better off if you stick to nature, you’ve missed a large part of human history where people starved to death by the thousands every year because they exclusively relied on “organic food”.

systemd runs on billions of systems worldwide and everyone who ever professionally maintained enterprise servers understand what a bad approach the crude hack that SysVInit with its collection of shell scripts was.

Re: Why systemd is a problem for embedded Linux

#40

Post by hansvm »

Not really embedded, but one of the easier classes of wins I've had over the years is moving prod servers to a non-systemd Gentoo. Random (rare) 200ms latency spikes and whatnot just disappear, and the system jitter drops down to the tens of microseconds range, significantly improving the qualitative performance of basically every piece of software I care about.
Post reply on HN