Earlier quoted context omitted.
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.
So what?
Why systemd is a problem for embedded Linux
301–308 of 308 posts
Re: Why systemd is a problem for embedded Linux
#302Big systemd on embedded devices is actually A GOOD THING! Imagine what Gentoo, Buildroot/OpenWrt or even Busybox alone could do with so much memory after removing all that bloated OS!
Re: Why systemd is a problem for embedded Linux
#303Earlier quoted context omitted.
> Now it can host telephony services, full-blown Docker orchestration systems, etc. What features that systemd provides that aren't provided by openrc, runit, monit, openrc's init system, etc, etc, etc that are needed by software like Asterisk, Docker/runc, Kubernetes, and similar? If what OpenWRT is running works fine to bring that up, then systemd doesn't have any relevant compelling features that aren't provided b…
> What features that systemd provides that aren't provided by openrc, runit, monit, openrc's init system, etc, etc, etc that are needed by software like Asterisk, Docker/runc, Kubernetes, and similar? Dependencies, watchdogs, start only when the given network interfaces are available, declarative configuration so that can be partially customized, etc. > If what OpenWRT is running works fine Unless you try to update i…
Ah, you're that CyberAx. Right.
So, briefly:
1) That's a list of systemd features. Some of which are nice to have, but none of which are needed for the software I mentioned.
2) On-upgrade merge conflicts for entirely-unmodified-from-their-stock-settings system configuration files are why I gave up on Ubuntu. Systemd doesn't solve anything here.
3) Systemd doesn't handle BIND configuration... or any non-systemd application configuration. And most nontrivial init systems (with systemd as one notable exception) have facilities for printing info, warn, and error messages in service startup files rather than demanding that you pick through the application logs to find out why startup failed.
Re: Why systemd is a problem for embedded Linux
#304Earlier quoted context omitted.
remembered another one. They use the same code for VM and bare metal. Including the easy-login convenience hacks. So now anyone wanting physical access to your host, just have to intercept plain-text communication with the BIOS (after secureboot did its thing), and reply with a new root password when the OS request bios key 11 or something. evil maids are living the dream.
Is that with systemd logind? Why does logind interact with BIOS? https://vincent.bernat.ch/en/blog/2021-startx-systemd
it's before logind. it creates arbitrary files in the root filesystem and is intended to write to the user authorized keys. so it works later with sort of login or remote access
Re: Why systemd is a problem for embedded Linux
#305Earlier quoted context omitted.
i think the "unsustainable wild west" of sending sigterm, waiting and sending sighup was very good because it was adaptable (you were on your own if you had non standard stuff, but at least you could expect a contract) Nowadays if you start anything more serious from your user session (e.g. start a qemu vm from your user shell) it will get SIGHUP asap on shutdown, because systemd doesn't care about non service pids.…
The old way has literally no way to differentiate between a frozen process and one that just simply wants to keep on running after the session's end, e.g. tmux, screen. It's trivial to run these as a user service, which can linger afterwards. Also, systemd has a configurable wait time before it kills a process (the "dreaded" 2 mins timer is usually something similar)
which was fine for everything that didn't need a watchdog. systemd on the other hand still lacks most common usecase and people bend over backwards to implement them with what's available. ask distro maintainers who know the difference between the main types of service files...
Re: Why systemd is a problem for embedded Linux
#306Earlier 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…
every. single. one.
pick any modem from linksys or dlink or netgear. then buy one in south America and compare what's really inside
look at all the revB on openwrt wiki, sometimes ram lowers. sometimes arm cpu change to mediatek. often the wifi chip changes from qualcomm to rtl. and it's always the revisions sold outside of usa and China in the observation fields.
Re: Why systemd is a problem for embedded Linux
#307Earlier quoted context omitted.
If you're shipping 1 million units, don't use Linux. Done.
You are implying hardware vendor is the one who got to choose the OS, but that's often not how it works.
Who's forcing it on them? Or, are they systemically incapable of evaluating what their suppliers are providing? Sounds defeatist to me.
Re: Why systemd is a problem for embedded Linux
#308Earlier quoted context omitted.
Did you ever dig in to see why that changed? I'm surprised that in a steady-state (not booting or restarting services) systemd/not-systemd would have an impact.
A little bit. The tldr; is that there are a lot of periodic activities including log rotation, automatic updates, time syncing, waking up to check if such things were currently needed, .... Those are generally nice (aside from automatic updates, which are sometimes good but I think usually more harmful than whatever they're fixing), but systemd doesn't know anything about what my userspace demands on the hardware are…
So pretty much, Gentoo+systemd and Gentoo-without-systemd aren't the same OS? One does auto updates, auto time syncing, auto logrotating etc, and apparently the other doesn't?
Or is the fact that systemd is the one doing it that much worse? Does systemd-timesyncd take more time than chronyd launched by some other init? I'd be surprised.