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…
Why systemd is a problem for embedded Linux
191–200 of 308 posts
Re: Why systemd is a problem for embedded Linux
#192> 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.
People already did the latter (sadly no-one used it because there was no mechanism that forced distros to adopt it), and would do the former if the systemd maintainers would let them.
Re: Why systemd is a problem for embedded Linux
#193Earlier 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…
Systemd already parallelises by default so I don't know what insanely strange things you were doing but I fail to see how it could bring boot time form 11s to 1 minute. Also, it's very easy to get a list of every services enabled with systemctl (systemctl list-unit-files --state=enabled) so I don't really know what your point about a giant graph is.
Re: Why systemd is a problem for embedded Linux
#194Earlier quoted context omitted.
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.
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.
Re: Why systemd is a problem for embedded Linux
#195Earlier quoted context omitted.
except thanks to availability crisis hitting the industry for the past decade you have to go with the 4mb sometimes just look at wifi routers. in the usa and China they are all sold with 64 or 128mb ram. south America and Europe they are all 16 or 32 for no clear reason.
Do you have some examples? I have a very hard time imagining a modern Wifi router supporting the latest standards and IPv6, admin web interface and so on running on 16 MB of RAM. I also have issue with "wifi routers in Europe are all 16 or 32 MB of RAM". In what decade? My ISP provided router also does VPN, VoIP, mesh networking, firewalling, and it's towards the lower end of feature set (as it's offered for free and…
Re: Why systemd is a problem for embedded Linux
#196I 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…
Re: Why systemd is a problem for embedded Linux
#197Earlier quoted context omitted.
> systemd is sort of like if microsoft word took on system init. In the beginning it was small, but now it is web based and does videoconferencing. It's actually a suite of tools that do solve individual problems comprehensively. Not as small as the programs in coreutils, but still not a huge monolith.
> It's actually a suite of tools It's a suite of tools created with hate to the unix philosophy. That's something that all of them have in common. There was no reason to create systemd timers as cron worked just fine for decades .
It's a suit of a tools each doing one thing and communicating together via a message bus. How exactly is that hating the "unix philosophy" whatever that means? From where I stand, it's extremely close to the way Unix has ever done things. The design is even directly lifted from the boot system of a certified Unix.
Re: Why systemd is a problem for embedded Linux
#198Earlier 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?
PS: personally I like systemd more that the script mess which preceded it. But the are some outstanding issues with it to be improved.
Re: Why systemd is a problem for embedded Linux
#199Earlier quoted context omitted.
> It's actually a suite of tools It's a suite of tools created with hate to the unix philosophy. That's something that all of them have in common. There was no reason to create systemd timers as cron worked just fine for decades .
> with hate to the unix philosophy It's a suit of a tools each doing one thing and communicating together via a message bus. How exactly is that hating the "unix philosophy" whatever that means? From where I stand, it's extremely close to the way Unix has ever done things. The design is even directly lifted from the boot system of a certified Unix.
Re: Why systemd is a problem for embedded Linux
#200Earlier quoted context omitted.
Do you have some examples? I have a very hard time imagining a modern Wifi router supporting the latest standards and IPv6, admin web interface and so on running on 16 MB of RAM. I also have issue with "wifi routers in Europe are all 16 or 32 MB of RAM". In what decade? My ISP provided router also does VPN, VoIP, mesh networking, firewalling, and it's towards the lower end of feature set (as it's offered for free and…
My TP-Link MR3020 from around 2015 only has 4^H 16 MB of ram (4 MB flash) and thus cannot even run OpenWRT anymore.