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

91–100 of 308 posts

Re: Why systemd is a problem for embedded Linux

#91

Post by cozzyd »

TacticalCoder wrote: post #88
cozzyd wrote: post #56

I run systemd-based Debian just fine on 512 MB RAM BeagleBoneBlack SBCs with 4GB emmcs. Now emacs, that's a problem due to the large install size.

> Now emacs, that's a problem due to the large install size. I was running Emacs on a 486 with something like 16 MB of RAM. Don't remember the HDD size. The Emacs executable I built from source is about 28 MB. Honestly I don't know what else is needed besides that executable that'd be really big. Is it really that problematic that it wouldn't work with 512 MB of RAM and 4 GB of storage?

I think the problem is the Debian packaging, which has hundreds of MB of elisp or something.

https://packages.debian.org/sid/emacs-common

(yes, it does fit, but it takes up way more space than I'd like...)

Re: Why systemd is a problem for embedded Linux

#92

Post by simoncion »

AdieuToLogic wrote: post #66
cbmuser wrote: post #39

Earlier quoted context omitted.

> 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…

Ignoring the food portion of the above: > 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. This is your opinion and not one held by all. It also ignores the various BSD system initialization scripts, which are explicitly not "SysVInit" related, and have…

It also ignores the diverse (if small) set of Linux init systems... 'openrc' being the one I'm most familiar with, as a Gentoo Linux user.

I'm so sad I wasn't paying attention when Debian was choosing init systems... I would have burned a TON of time getting anything they claimed in good faith was missing in 'openrc' into it, had I known that that clusterfuck was going on.

Re: Why systemd is a problem for embedded Linux

#93

Post by 0xbadcafebee »

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

That is almost by definition not an embedded device. There's a reason we have vfork().

Re: Why systemd is a problem for embedded Linux

#94

Post by metalforever »

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…

I was just thinking "there is no way this person works on embedded devices". Then I read the last paragraph where you bring up "over 1GB of RAM". Explains that.

Re: Why systemd is a problem for embedded Linux

#95

Post by 0xbadcafebee »

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, sadly, don't win out. The ones that win out are the ones that serve the interests of the largest players. And the largest players are usually RedHat, Google, and other vendors, who just want to get "their" needs met and move on. They couldn't give a fig about compatibility with some other random tiny project, or an embedded device. And those people working on tiny projects aren't in the room when "standards" are decided for the entire community.

There are some hold-outs. Slackware went a long time without it, but next release will unfortunately use systemd. I've run Alpine Linux (systemd-free, so far) as my laptop OS for years. I'll probably switch to another distro that's more user friendly, is easier to contribute to. But it's embarrassing and annoying that we have to pretend to be systemd-compatible just to run a desktop. We should call it "GNU/Systemd/Linux" since it's now one big monolith.

Re: Why systemd is a problem for embedded Linux

#96

Post by binkHN »

blueflow wrote: post #51
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…

That "occasional weird problem" is because systemd is not designed to be used with other software. While you technically still have the choice to roll your own non-systemd initramfs, it will be an uphill battle.

Not an uphill battle at all; Void Linux does this by default and has for many years.

Re: Why systemd is a problem for embedded Linux

#97

Post by simoncion »

hactually wrote: post #58

> I wish I knew the solution to this problem Ooh ooh, I know! It's to improve systemd for the use-cases outlined and build a really great open source init/process manager.

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 should be super straightforward). Every one of these failures and misbehaviors we've run into has been met with a "Wow. That's weird. Sucks to be you, I guess." with a dash of "No, we won't be updating the documentation to mention that." if the actual behavior is contrary to the documentation.

In short, while it may be true (I really don't know) that the systemd project welcomes changes and patches, IME it's pretty clearly true that if you're working on a problem that the project management doesn't understand, and/or doesn't want to think through, your work won't be considered. [0]

[0] Which, fine, it's not my project, so I don't get to tell you what to work on. Doesn't mean I have to like it or recommend that people use it.

Re: Why systemd is a problem for embedded Linux

#98

Post by worthless-trash »

Excellent plan, go to the other inits, bug bounties are what I do over christmas and init systems and hand rolled init scripts are a great source of security flaws.

Taking notes on which distros dont run systemd, for when I want to make some money over christmas.

Re: Why systemd is a problem for embedded Linux

#99

Post by metalforever »

detaro wrote: post #33
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)…

I remember when I used to run gnome 2 (i.e. mate) on a machine with 256mb of ram. It was a full experience and it worked with youtube videos and so on. What are we even doing .

Re: Why systemd is a problem for embedded Linux

#100

Post by binkHN »

fyrn_ wrote: post #9

https://chimera-linux.org/ https://chimera-linux.org/docs/faq#what-is-the-projects-take... Is going a really interesting direction with it's service management and login / seat management. Fwiw, I think it's author also has a more gounded perspective on systemd then many others. For Chimera the main issue is systemd's high volume use of gnulibc and gcc extensions, which is a porabiluty issue for Chimera which uses a…

I like the direction Chimera is taking; the lead is an ex-Void maintainer and there's clearly a lot of inspiration from there.
Post reply on HN