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

151–160 of 308 posts

Re: Why systemd is a problem for embedded Linux

#151

Post by kaba0 »

vbezhenar wrote: post #143
jcalvinowens wrote: post #116

Earlier quoted context omitted.

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.

Even Apple produced laptops with 8 GB RAM just recently, which they sold for hundreds of dollars with huge margins (AFAIK). If you're going to produce something with $50 cost, 1GB RAM cost will be meaningful. In my experience production people will eat your soul for a single resistor if they can cut costs on it.

That RAM is unified though, not a good comparison.

Also, just because something holds true at large numbers doesn't mean it scales all the way down. Either due to economies of scale, or the negligibly different architecture/components at that size.

Re: Why systemd is a problem for embedded Linux

#152

Post by kaba0 »

skydhash wrote: post #138
gnabgib wrote: post #132

Earlier quoted context omitted.

Three decades perhaps. In 2014 it was Windows 8, SSDs, 5th gen i7 (Haswell), 8-16GB of DDR4 ram. Even the iPhone 6 came with 1GB of ram.

There's a huge chunk of people out there, not able to afford the latest.

I see you, but win XP was literally end of life 10 years ago.

Re: Why systemd is a problem for embedded Linux

#153

Post by rurban »

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…

Same for me. Incredibly useful on the bloated sensors running Linux.

All the smaller systems with no RAM run on baremetal anyway. There's no room and no need to run Linux or a threaded RTOS. Much less security headaches also.

Re: Why systemd is a problem for embedded Linux

#154

Post by AnthonyMouse »

jcalvinowens wrote: post #127
Aurornis wrote: post #110

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

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

The trouble with "new" is that it keeps getting old.

There would have been a time when people would have said that 32MB is a crazy high amount of memory -- enough to run Windows NT with an entire GUI! But as the saying goes, "what Andy giveth, Bill taketh away". Only these days the role of Windows is being played by systemd.

By the time the >1GB systems make it into the low end of the embedded market, the systemd requirements will presumably have increased even more.

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

This seems like assuming the conclusion. The thing people are complaining about is that they want Linux to be good in those environments too.

Re: Why systemd is a problem for embedded Linux

#155

Post by AnthonyMouse »

kaba0 wrote: post #151
vbezhenar wrote: post #143

Earlier quoted context omitted.

Even Apple produced laptops with 8 GB RAM just recently, which they sold for hundreds of dollars with huge margins (AFAIK). If you're going to produce something with $50 cost, 1GB RAM cost will be meaningful. In my experience production people will eat your soul for a single resistor if they can cut costs on it.

That RAM is unified though, not a good comparison. Also, just because something holds true at large numbers doesn't mean it scales all the way down. Either due to economies of scale, or the negligibly different architecture/components at that size.

The RAM is ordinary LPDDR5 organized into what is de facto just a large number of memory channels. It's not HBM or anything exotic, the cost of the RAM chips themselves are the same cost they are anywhere else.

Re: Why systemd is a problem for embedded Linux

#156

Post by dhjvgfkvhy »

kaba0 wrote: post #150
Aurornis wrote: post #110

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

> It increases boot times Is it really the case? On desktops it is significantly faster than all the other alternatives. Of course if you do know your hardware there is no need for discovering stuff and the like, but I don't know. Would be interested in real-life experiences because to me systemd's boot time was always way faster than supposedly simpler alternatives.

When Arch Linux switched to systemd, my laptop (with an HDD) boot times jumped from 11 seconds to over a minute. That 11 seconds was easy to achieve in Arch’s config by removing services from the boot list and marking some of the others as supposed to be started in parallel without blocking others. After the switch to systemd there was no longer a such a simple list in a text file, and systemd if asked for the list would produce such a giant graph that I had no energy to wade through it and improve things.

Later, when I got myself a laptop with an SSD, I discovered that what my older Arch configuration could do on an HDD is what systemd could do only with an SSD.

Re: Why systemd is a problem for embedded Linux

#157

Post by AnthonyMouse »

richardfey wrote: post #145
cedilla wrote: 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…

> now I have to avoid that and minimise tinkering/hacking.

I think this right here hits at the crux of the issue.

There are people who like systemd because it's integration-tested with itself and its own defaults, so if you never change those defaults you don't have many problems.

Then there are people who don't like systemd because if you do have to change any of its defaults, it often doesn't go well. And, of course, the latter behavior as a box users are expected to live in is poisonous, because everyone is being conditioned to be passive and uniform.

Re: Why systemd is a problem for embedded Linux

#158

Post by znpy »

AnthonyMouse wrote: post #154
jcalvinowens wrote: post #127

Earlier quoted context omitted.

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

> But of new devices? Absolutely not, and that's what I'm talking about. The trouble with "new" is that it keeps getting old. There would have been a time when people would have said that 32MB is a crazy high amount of memory -- enough to run Windows NT with an entire GUI! But as the saying goes, "what Andy giveth, Bill taketh away". Only these days the role of Windows is being played by systemd. By the time the >1GB…

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

Re: Why systemd is a problem for embedded Linux

#159

Post by adgjlsfhk1 »

0xbadcafebee wrote: post #93
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().

there are 2 types of embedded systems: those that ship 1 million units, an and this that ship 50. if you're shipping 1mil units, you need to optimize RAM size, but if you're only shipping a few, them it's not worth squeezing everything down as long as it doesn't break your power/cost target. there's a ton of devices out there that literally just use a cheap smartphone as an "embedded" CPU because that way, Google has already done 90% of your R&D for you

Re: Why systemd is a problem for embedded Linux

#160

Post by pjmlp »

vbezhenar wrote: post #143
jcalvinowens wrote: post #116

Earlier quoted context omitted.

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.

Even Apple produced laptops with 8 GB RAM just recently, which they sold for hundreds of dollars with huge margins (AFAIK). If you're going to produce something with $50 cost, 1GB RAM cost will be meaningful. In my experience production people will eat your soul for a single resistor if they can cut costs on it.

That is the Apple tax on everything the fruit company sells, they always push the margins as far as fans are willing to pay for.
Post reply on HN