[HN Gopher] Why systemd is a problem for embedded Linux
___________________________________________________________________
Why systemd is a problem for embedded Linux
Author : synergy20
Score : 46 points
Date : 2024-11-03 21:42 UTC (1 hours ago)
(HTM) web link (kevinboone.me)
(TXT) w3m dump (kevinboone.me)
| is_taken wrote:
| You could checkout void and alpine.
| userbinator wrote:
| The BSDs may be more to your liking. They're a lot more
| minimalist than Linux now.
| Aurornis wrote:
| In the embedded world, BSP/driver support is the main thing
| that matters. Linux is undefeated in that area for embedded
| purposes.
| moron4hire wrote:
| I thought there was a compatibility layer available that made
| it possible to run Linux drivers on at least FreeBSD.
| CorrectHorseBat wrote:
| That's for userland, not drivers. Linux doesn't have a
| stable interface for drivers so a compatibility layer would
| be a nightmare to maintain.
| moron4hire wrote:
| That's Linuxulator, but there's also LinuxKPI:
| https://wiki.freebsd.org/LinuxKPI
| bluGill wrote:
| In embedded you should choose hardware that works. Should is
| key, all too often the, hardway guys don't ask they just give
| software something.
| nomel wrote:
| > In embedded you should choose hardware that works.
|
| I've never seen it approached with that kind of
| incompetence, in my professional life. Embedded is a system
| thing, not a hardware thing. You pick the system that will
| work. Ignoring the software side of things is ignoring the
| majority of the problem in embedded work. I would have
| agreed with you 20 years ago, but it's 2024, and why RPI is
| so often used for prototyping.
| solarkraft wrote:
| > The more fundamental problem is that the people who most like
| systemd are distribution managers. (...) a distribution manager
| doesn't have to maintain, integrate, and support a whole bunch of
| system utilities from different sources - systemd provides
| everything in one huge build.
|
| That's actually a great lesson in optimizing your product for
| adoption.
| exe34 wrote:
| it's also why corporate software is so shit - it's shiny in all
| the ways it needs to be shiny for management to make the
| decision, but it's a pain for the actual users.
|
| the trick in both cases is to know your customers!
| oblio wrote:
| Turns out, many people use systemd after what, 15? years of
| doomsday predictions :-)
| stepupmakeup wrote:
| Unfortunately not by choice
| fsckboy wrote:
| 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.
| viraptor wrote:
| Can you link some upstream issues you raised about the
| big annoyances?
| exe34 wrote:
| not many people enjoy bikeshedding.
| rjzzleep wrote:
| Random example. They randomly broke suspect-then-
| hibernate then the community manager gaslit people into
| trying to make them believe they don't actually need the
| feature in the way it's used and then silently
| acknowledged that their fix is broken after all.
|
| This is a common pattern by the way. But easily the most
| irritating thing for me is the simple issue that you used
| to be able to just go to /var/log/lastlog to see what
| failed during the last boot and that just the other day I
| had to spend hours figuring what broke in the system that
| made journalctl not log properly. In the end I had to
| reinstall all currently installed packages.
|
| https://www.reddit.com/r/archlinux/comments/zczdnq/system
| ctl...
| akira2501 wrote:
| Turns out many people don't care to change their
| distribution defaults.
| Brian_K_White wrote:
| What do you imagine this proves or disproves?
|
| How many people eat McDonalds? Or buy in to countless other
| things that can be trivially demonstrated to be against
| their own interests.
|
| I don't know about anyone else but I never heard the
| critiques of systemd to be based on any doomsday
| predictions.
|
| Everyone knew it would function, and that it even serves
| one use case better than before.
|
| The critique was only ever that it serves one purpose
| better at the expense of all others, and is a downgrade in
| flexibility and functionality from what already existed.
| pnathan wrote:
| I can only say that the obvious answer here is to throw effort
| into supporting & improving Gentoo.
| viraptor wrote:
| I'm conflicted on the name/issue. I don't have any issues with
| Linux on embedded systems, because I'd use a minimal init with
| that one single app it should be running. (Or as mentioned in
| other comment, build your minimal distro yocto-style) RPi is a
| low spec general computer at this point. The idea of running
| gnome on an embedded system just doesn't make sense in my mind...
|
| RPi took the form factor that was used for industrial control
| boards and made it into a usable desktop... which people use as a
| desktop (or home server). But it created a segment which really
| is neither. And a lot of the software just isn't written with
| that segment in mind. Maybe as it gets more popular, people will
| pay more attention. But currently it seems more of an
| expectations issue.
| fyrn_ wrote:
| https://chimera-linux.org/ https://chimera-
| linux.org/docs/faq#what-is-the-projects-take... Is going a really
| interesting direction with it's service management and login /
| seat management. Fwiw, I think it's author also has a more
| gounded perspective on systemd then many others. For Chimera the
| main issue is systemd's high volume use of gnulibc and gcc
| extensions, which is a porabiluty issue for Chimera which uses a
| LLVM toolchain and musl libc (and a bunch of really cool
| hardening and compiler engineering)
| colonwqbang wrote:
| This is anti-systemd FUD. Implying that applications which work
| without systemd are going to stop doing so. Suggesting that Linux
| distributions adopted systemd because it's good for distributors
| and not because users actually want it. We are "forced" to use
| systemd's udev implementation. Please.
| felixgallo wrote:
| All of those things are trivially true. What are you
| disagreeing with?
| viraptor wrote:
| There are extremely few use cases where your app may want to
| integrate with systemd. Out of those, you get again a small
| percentage that can't be trivially made optional. (99.9% is
| just optional notification and socket passing) Outside of
| large projects which are interested in full system
| integration like gnome, nobody breaks apps to not work
| without systemd.
| transpute wrote:
| OpenEmbedded/Yocto, Devuan and Gentoo provide multiple init
| systems.
|
| systemd CVEs:
| https://ubuntu.com/security/cves?package=systemd&limit=100
|
| Rust PoC: https://github.com/KillingSpark/rustysd
|
| _> Rustysd is a service manager that tries to replicate systemd
| behaviour for a subset of the configuration possibilities. It
| focuses on the core functionality of a service manager, not
| requiring to be PID1 (aka init process).. core systemd
| functionality is not very hard to replicate.. the advantages of
| having a systemd-like service manager can be brought to many
| other platforms.. opens up usage of systemd services outside of
| systemd based linux distros (like alpine linux, commonly used in
| docker containers and small vms) and freebsd._
| Mave83 wrote:
| For me as a user, systemd is far better than old init systems.
| The logging alone is worth it to switch to it. Add more ram to
| the embedded board and welcome to the future.
| phendrenad2 wrote:
| Wait so systemd is a problem for embedded Linux because... it
| uses 250MB of RAM? So it's only really a problem for systems
| where using a mainstream distro probably wouldn't even be a
| consideration anyway (yocto seems to be popular, as mentioned
| above). I'm not seeing a strong argument here. At the risk of
| inviting a parade of "actually, one time at band camp I saved the
| day with a first-gen raspberry pi zero", how many embedded
| systems in 2024 are really RAM-limited?
| oceanplexian wrote:
| I used it heavily at work. Then moved to a shop that does
| exclusively containers and realized how incredibly immature
| engineers' understanding of the problem space is.
|
| Container startup ordering, startup dependency management, socket
| handling and all things timing and network related are frankly a
| complete mess in modern infrastructure. Even, surprisingly in
| well maintained projects like k8s. I find myself shaking my head
| at problems solved by systemd a decade ago far too often.
| cyberax wrote:
| > With care, though, a minimal installation of systemd does run
| on a low-resource ARM board like the Pi 3. In fact, it will run
| on a board with 1Gb RAM, perhaps even lower.
|
| Come fucking on. I ran systemd on a 32Mb MIPS board (RouterBoard
| from Mikrotik) just fine.
|
| The RES column is incredibly misleading in this case, because
| systemd is the first app in the system. So it gets charged for
| loading the entire glibc and the supporting cast of libraries.
|
| If you want to look at the true usage, check the RssAnon value:
|
| > root@kmipsrv:/proc/1# cat /proc/1/status | grep RssAnon >
| RssAnon: 3220 kB
|
| You can also pare this down a bit.
|
| Similarly for journald:
|
| > root@kmipsrv:/proc/1# cat /proc/231/status | grep RssAnon >
| RssAnon: 640 kB
|
| So in reality, systemd works just fine for the vast majority of
| embedded platforms. If you can spare 3Mb of RAM, then you can run
| a full-blown dependency management system with reliable recovery,
| logging integration, and event-driven device management. Soon
| with support for verified boot with hardware root-of-trust.
___________________________________________________________________
(page generated 2024-11-03 23:00 UTC)