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

261–270 of 308 posts

Re: Why systemd is a problem for embedded Linux

#261

Post by oblio »

AnthonyMouse wrote: post #157
richardfey wrote: post #145

Earlier quoted context omitted.

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

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

No, it's not, this assumes that the other camp are all idiots.

Mainstream distros should be rock solid and boring.

Linux never got anywhere with the standard distros because they're all so different.

Tinkering is a different mindset (and has a different place) than professional engineering work.

Systemd is basically engineering, SysV & co. were basically old school tinkering/hacking.

In the same vein, don't be creative with bolt sizes. Be creative with what those bolts allow you to achieve. Be creative at a higher level. That should be the nature of humanity.

Re: Why systemd is a problem for embedded Linux

#262

Post by fsckboy »

cedilla wrote: post #80
fsckboy wrote: post #36

Earlier quoted context omitted.

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

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

well, systemd is doing things that init did not do, so that's not a replication, but if I kill something, it should stay dead till I restart it; if I dismount a volume, it should stay dismounted; if I set the permissions on something, they should not reset back. Don't treat me like I'm the anomoly.

"I'm afraid I can't do that, Dave."

Re: Why systemd is a problem for embedded Linux

#263

Post by bmicraft »

BeefWellington wrote: post #142
metalforever wrote: post #99

Earlier quoted context omitted.

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 .

Sure, back when videos were at most 480p/720p that's feasible. I'm not saying software is any more efficiently written these days but I do think it's important to recognize that just the act of pushing more pixels on its own requires more RAM.

Honestly, no. Prior to 2009 there were almost no 720p videos on the platform. In 2009 Windows 7 came out with a minimum requirement of 1GB RAM (Vista in 2007 also already recommended 1GB). What I'm trying to say is, 1GB wasn't much even before 720p got common. The amount of people watching 720p on systems with less than 1GB has likely always been minuscule.

Re: Why systemd is a problem for embedded Linux

#264

Post by bmicraft »

Spooky23 wrote: post #49
cbmuser wrote: post #34

The memory comparison isn’t really fair as SysVInit relies on external utilities for starting and stopping processes. At the very least, SysVInit requires a shell for running init scripts which systemd doesn’t need for native service files.

Real embedded developers wouldn’t stand for the overhead of modern stuff like SysVInit.

Those 'real developers' you're talking about wouldn't stand for the overhead of a kernel either

Re: Why systemd is a problem for embedded Linux

#265

Post by mkipper »

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?

I ran into this issue on an embedded system before it was raised / fixed:

https://github.com/systemd/systemd/issues/8398

FWIW, I'm generally a fan of systemd. That's a pretty minor issue in the grand scheme of things and it's not really "mysterious" -- the behaviour was consistent but didn't line up with the documentation.

In my experience, almost every time I hit an issue with systemd, it's when I'm interacting with it at a (relatively) low level. e.g. Monitoring / controlling units via D-Bus. There is theoretically enough documentation to do that, but it's often incomplete or ambiguous and you're left trying to figure out systemd's behaviour via experimentation.

But as I said, this isn't _really_ a dig against systemd. Even if monitoring service state transitions via D-Bus is finnicky, it's a heck of a lot easier than the alternatives with busybox init or whatever.

Re: Why systemd is a problem for embedded Linux

#266

Post by helloka »

bmicraft wrote: post #230
blucaz wrote: post #74

Earlier quoted context omitted.

Debian, Ubuntu and all derivatives thereof use initramfs-tools, which does not use systemd in the initrd, and things work just fine

Ubuntu is literally trying to replace it with dracut as we speak.

https://dracut-ng.github.io/dracut-ng/developer/compatabilit...

Dracut is used both in Void Linux and on Alpine without systemd and with busybox.

It even runs continuous integration with musl based containers.

Re: Why systemd is a problem for embedded Linux

#267

Post by 0xbadcafebee »

happymellon wrote: post #169
skydhash wrote: post #138

Earlier quoted context omitted.

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

But desktops with those specs are If they can't afford those specs then you're approaching the group of people who can't afford a computer in the first place.

Yes, that's about 3 billion people. They use whatever they can afford. Usually that's whatever is very old, because new software doesn't run well except on very new hardware which is more expensive.

I recently wanted an MP3 player for an art project. Local stores don't sell mp3 players anymore, they only sell smartphones. So I bought an MVNO smartphone for $40. When I charged it up and tried to use it, I thought maybe it was broken, because it would take 10-30 seconds to load a settings menu or app. Nope, all these bargain carrier-branded phones are that slow. The hardware is [somewhat] old, but the new Android OSes run like molasses on them. It was like going back in time. Remember how Windows 98 would make your hard drive screech for a good couple minutes as it struggled to juggle the swap memory so you could open MS Word? That's the experience with most software today with "affordable" hardware even a few years old.

So using Windows XP is often the only choice, if you don't have a lot of money, like 1/3rd of the planet. (And it's not just the third world. 59% of American households with K-12 school kids don't have a working computer, or it works too slowly to be useful)

Re: Why systemd is a problem for embedded Linux

#268

Post by almatabata »

crote wrote: post #216
kelnos wrote: post #125

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

At quantities of 100, 512Mbit of RAM is $1.01 [0]. 1Gbit of RAM is $1.10 [1]. 2Gbit is $1.05 [2]. 4Gbit is $1.16 [3]. It is only at 8Gbit that prices substantially increase to $2.30 [4]. So no, at those sizes price really does not change all that much, and installing 512MB of RAM instead of 64MB only increases the product's cost by $0.15. It's a commodity made on legacy processes, things like packaging, testing, and…

At a company I worked at they explicitly told us they will do anything to avoid upgrading the hardware from 1GB to 4GB because it increases costs. They would rather we optimize the software to use less RAM than upgrade the hardware.

I remember arguing as well with people about 0.10$ components. They told me it was a no go, not even a point of bringing it up. Sometimes even a 0.01$ is a big deal.

Re: Why systemd is a problem for embedded Linux

#269

Post by lmm »

vetinari wrote: post #243
lmm wrote: post #190

Earlier quoted context omitted.

It's due to systemd in that systemd makes it too fiddly to figure out or change which services are enabled on boot. (I used to know a way to disable certain services on boot under systemd, but it doesn't work any more, and I've reached a state of learned helplessness at this point)

`systemctl disable` and `systemctl mask` work today just like they worked decade and half ago.

I don't know if they're the recommended way of doing things today, but they weren't what was in the manual when I was learning.

Re: Why systemd is a problem for embedded Linux

#270

Post by phendrenad2 »

tliltocatl wrote: post #173
phendrenad2 wrote: post #129

Earlier quoted context omitted.

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

Except those $2.50 for customer will turn into $2500000.00 for the hardware vendor. And they would rather keep the $2500000.00 and let it be someone else's problem.

If you're shipping 1 million units, don't use Linux. Done.
Post reply on HN