7 ms·

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

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 https://github.com/systemd/systemd/issues/34683 Memory use is irrelevant to me: 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.

avaldez_ 2y ago
Small typo: Zephyr https://zephyrproject.org/ https://zephyrproject.org/
blueflow 2y ago
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.
- noncoml 2y ago
  Not uphill at all; try buildroot
- jcalvinowens 2y ago
  > 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/ 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.
  - blueflow 2y ago
    "really easy" except for the hotplug events that don't get to systemd and cause your problem.
    - jcalvinowens 2y ago
      I got an immediate answer with a solution from the upstream developer when I asked about it: I can't imagine how that could have been easier to solve. And it was also trivial to hack around by leaving the entry out of fstab and mounting it in a script.
- blucaz 2y ago
  Debian, Ubuntu and all derivatives thereof use initramfs-tools, which does not use systemd in the initrd, and things work just fine
  - bmicraft 2y ago
    Ubuntu is literally trying to replace it with dracut as we speak.
    - helloka 2y ago
      https://dracut-ng.github.io/dracut-ng/developer/compatability.html#_dependencies 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.
      - blueflow 2y ago
        Alpine uses mkinitfs per default, tho.
- binkHN 2y ago
  Not an uphill battle at all; Void Linux does this by default and has for many years.
  - blueflow 2y ago
    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.
- chasil 2y ago
  The embedded people will naturally look at busybox. I saw it running on a credit card scanner at Old Navy a few years ago. It has an init: $ /home/busybox-1.35 init --help BusyBox v1.35.0 (2022-01-17 19:57:02 CET) multi-call binary. Usage: init Init is the first process started during boot. It never exits. It (re)spawns children according to /etc/inittab. Signals: HUP: reload /etc/inittab TSTP: stop respawning until CONT QUIT: re-exec another init USR1/TERM/USR2/INT: run halt/reboot/poweroff/Ctrl-Alt-Del script On an embedded system, that will be a strong contender for pid 1.
  - blueflow 2y ago
    This is what Alpine Linux use, Alpine also uses OpenRC for service startup.
0xbadcafebee 2y ago
> 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().
- jcalvinowens 2y ago
  Well, you can gatekeep all you want, but it's increasingly practical and common to have what would have seemed like an absurd amount of RAM a decade ago on things like toasters.
  - Aurornis 2y ago
    You have been living in a strange world if you’ve been getting away with 1GB in the average consumer IoT device for the past 5 years. That’s not typical at all. I’ve done a lot of work with production runs in the millions. There is no way we’d put that much RAM on a device unless it was absolutely, undeniably required for core functionality.
    - jcalvinowens 2y ago
      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.
      - kelnos 2y ago
        > 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: you are definitely going to increase the price by more than a negligible amount if you 2x or 3x the amount of RAM in your design. Also consider the Raspberry Pi, since the article mentions it quite a bit: RAM size on the Pi is the sole driver of the different price points for each Pi generation.
metalforever 2y ago
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.
Aurornis 2y ago
> 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. That’s said, it’s more than just RAM. It increases boot times (mentioned in the article) which is a pretty big deal on certain consumer products that aren’t always powered on. The article makes some good points that you’ve waved away because you’ve been working on a different category of devices.
- jcalvinowens 2y ago
  > 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't: 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. > It increases boot times (mentioned in the article) which is a pretty big deal on certain consumer products that aren’t always powered on. The article makes some good points that you’ve waved away because you’ve been working on a different category of devices. I've absolutely worked on that category of devices, I almost never run Linux on them because there's usually an easier and better way. Especially where half a second of boot time is important.
  - AnthonyMouse 2y ago
    > 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.
rurban 2y ago
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.
TwoNineFive 2y ago
Systemd trolls on HN are really out of hand. This isn't even credible.
helpfulContrib 2y ago
[dead]
pengaru 2y ago
Anything mass produced is going to be pressured to reduce BOM cost, RAM capacity is still and will continue to be a prime target.
deleted 2y ago
[deleted]

avaldez_ 2y ago

Small typo: Zephyr https://zephyrproject.org/ https://zephyrproject.org/

blueflow 2y ago

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.

noncoml 2y ago
Not uphill at all; try buildroot
jcalvinowens 2y ago
> 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/ 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.
- blueflow 2y ago
  "really easy" except for the hotplug events that don't get to systemd and cause your problem.
  - jcalvinowens 2y ago
    I got an immediate answer with a solution from the upstream developer when I asked about it: I can't imagine how that could have been easier to solve. And it was also trivial to hack around by leaving the entry out of fstab and mounting it in a script.
blucaz 2y ago
Debian, Ubuntu and all derivatives thereof use initramfs-tools, which does not use systemd in the initrd, and things work just fine
- bmicraft 2y ago
  Ubuntu is literally trying to replace it with dracut as we speak.
  - helloka 2y ago
    https://dracut-ng.github.io/dracut-ng/developer/compatability.html#_dependencies 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.
    - blueflow 2y ago
      Alpine uses mkinitfs per default, tho.
binkHN 2y ago
Not an uphill battle at all; Void Linux does this by default and has for many years.
- blueflow 2y ago
  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.
chasil 2y ago
The embedded people will naturally look at busybox. I saw it running on a credit card scanner at Old Navy a few years ago. It has an init: $ /home/busybox-1.35 init --help BusyBox v1.35.0 (2022-01-17 19:57:02 CET) multi-call binary. Usage: init Init is the first process started during boot. It never exits. It (re)spawns children according to /etc/inittab. Signals: HUP: reload /etc/inittab TSTP: stop respawning until CONT QUIT: re-exec another init USR1/TERM/USR2/INT: run halt/reboot/poweroff/Ctrl-Alt-Del script On an embedded system, that will be a strong contender for pid 1.
- blueflow 2y ago
  This is what Alpine Linux use, Alpine also uses OpenRC for service startup.

0xbadcafebee 2y ago

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

jcalvinowens 2y ago
Well, you can gatekeep all you want, but it's increasingly practical and common to have what would have seemed like an absurd amount of RAM a decade ago on things like toasters.
- Aurornis 2y ago
  You have been living in a strange world if you’ve been getting away with 1GB in the average consumer IoT device for the past 5 years. That’s not typical at all. I’ve done a lot of work with production runs in the millions. There is no way we’d put that much RAM on a device unless it was absolutely, undeniably required for core functionality.
  - jcalvinowens 2y ago
    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.
    - kelnos 2y ago
      > 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: you are definitely going to increase the price by more than a negligible amount if you 2x or 3x the amount of RAM in your design. Also consider the Raspberry Pi, since the article mentions it quite a bit: RAM size on the Pi is the sole driver of the different price points for each Pi generation.

metalforever 2y ago

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.

Aurornis 2y ago

> 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. That’s said, it’s more than just RAM. It increases boot times (mentioned in the article) which is a pretty big deal on certain consumer products that aren’t always powered on. The article makes some good points that you’ve waved away because you’ve been working on a different category of devices.

jcalvinowens 2y ago
> 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't: 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. > It increases boot times (mentioned in the article) which is a pretty big deal on certain consumer products that aren’t always powered on. The article makes some good points that you’ve waved away because you’ve been working on a different category of devices. I've absolutely worked on that category of devices, I almost never run Linux on them because there's usually an easier and better way. Especially where half a second of boot time is important.
- AnthonyMouse 2y ago
  > 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.

rurban 2y ago

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.

TwoNineFive 2y ago

Systemd trolls on HN are really out of hand. This isn't even credible.

helpfulContrib 2y ago

[dead]

pengaru 2y ago

Anything mass produced is going to be pressured to reduce BOM cost, RAM capacity is still and will continue to be a prime target.

deleted 2y ago

[deleted]