"I'm using a thing in a way it's not meant to be used and it sucks"
Is this even a serious post.
Why systemd is a problem for embedded Linux
171–180 of 308 posts
Re: Why systemd is a problem for embedded Linux
#172Earlier quoted context omitted.
> 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.
> 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.
I do not think the monster CPUs running Android or iOS nowadays are representative of embedded CPUs.
RAM still requires power to retain its contents. In devices that sleep most of the time, decreasing the amount of RAM can be the easiest way to increase battery life.
I would also think many of the small computers inside my phone have less memory. For example, there probably is at least one CPU inside the phone module, a CPU doing write leveling running inside flash memory modules, a CPU managing the battery, a CPU in the fingerprint reader, etc.
Re: Why systemd is a problem for embedded Linux
#173Earlier quoted context omitted.
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.
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.
Re: Why systemd is a problem for embedded Linux
#174Earlier quoted context omitted.
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.
Void Linux dropped systemd because it wouldn't work with a different libc than glibc. Which i would add as next point in my systemd lock-in list.
Re: Why systemd is a problem for embedded Linux
#175Earlier quoted context omitted.
> 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 w…
Arch changed to systemd in 2012, at which point systemd was 2 years old. It surely had quite a few growing pains, but I don't think that's representative of the project. In general it was the first init system that could properly parallelize, and as I mentioned, it is significantly faster on most desktop systems than anything.
Re: Why systemd is a problem for embedded Linux
#176Earlier quoted context omitted.
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.
> That "occasional weird problem" is because systemd is not designed to be used with other software. That's not true, systemd has an explicitly documented and supported initrd interface: https://systemd.io/INITRD_INTERFACE/ It's actually really easy, there's rarely a reason for the initrd to be more complex than a single 50-line busybox script on an embedded device with built-in drivers.
"really easy" except for the hotplug events that don't get to systemd and cause your problem.
Re: Why systemd is a problem for embedded Linux
#177Earlier 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…
> They didn't used to "just work" like that before systemd.
They used to "just work" for _decades_ before systemd. Like, everything.
I see reasons for systemd as PID1 and it's great in that role, hands down.
Everything else looks like a malignant growth to me, including much praised journald and DoA pieces like resolved.
Re: Why systemd is a problem for embedded Linux
#178Earlier quoted context omitted.
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.
Spending hundreds of thousands of dollars in additional bulk cost for the privilege of nothing other than adding systemd to the device, what a steal!
Re: Why systemd is a problem for embedded Linux
#179Earlier 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…
> systemd-resolved give me
gives me #1 source of troubles on any desktop computer I have ever ran under the systemd era. I feel like resolved is specifically designed to be removed from fresh installations, sort of like a transparent peel on new devices' screens.
In my strong opinion, resolved is the most brain damaged part of systemd. Unconfigurable, unmaintainable, unmanageable.
> systemd-networkd gives me
Oh, there is no point in learning systemd-networkd. By the time you do Ubuntu folks will swap the set of the network initialization tools once again and you'll have to start over. Thankfully, 'apt install ifupdown' still works kind of like `apt install upstart` worked a few years ago.
Re: Why systemd is a problem for embedded Linux
#180Earlier quoted context omitted.
I think the problem is that small tools are missing that "comprehensively" part.. trying something as simple as getting full system startup log (something very useful on headless system!) - it was basically impossible until systemd came. Only gentoo tried to do this for a few years, but then that functionality broke. Same goes for service startup - why does start-stop-daemon discards stdout/stderr instead of logging…
This seems like the motte and bailey thing. Some of the oldest init systems made decisions that were sensible at the time but not so much now, e.g. when storage is hundreds of thousands of dollars per GB you don't want to log everything, when it's tens of cents per GB you do. But you can obviously make a non-monolithic init system that causes output to be stored to a log instead of being discarded. So then systemd co…
> lacks clean and stable interfaces between its own components, inhibiting anyone else from providing a viable competing implementation
That's exactly what Microsoft did back in the era with Word and others, just like GP stipulated.