Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd is a problem for embedded Linux

kevinboone.me

Post reply on HN
Print view View original

181–190 of 308 posts

Re: Why systemd is a problem for embedded Linux

#181

Post by egorfine »

mattpallissard wrote: post #135
m463 wrote: post #83

I think what he's running into is "the unix philosophy". It is basically about small tools, limited in scope, that solve a problem surgically and comprehensively. They work together by mixing and matching to solve the problem. 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. I don't know, it is sort of like busybox, repla…

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

Re: Why systemd is a problem for embedded Linux

#182

Post by DaSHacka »

worthless-trash wrote: post #98

Excellent plan, go to the other inits, bug bounties are what I do over christmas and init systems and hand rolled init scripts are a great source of security flaws. Taking notes on which distros dont run systemd, for when I want to make some money over christmas.

No need to stop at non-systemd inits!

https://security.gentoo.org/glsa

https://security.archlinux.org/issues/all

^ (ctrl+f systemd)

https://ubuntu.com/security/cves?package=systemd&limit=100

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Systemd

Re: Why systemd is a problem for embedded Linux

#183

Post by 1oooqooq »

cyberax wrote: post #136
Aurornis wrote: post #110

Earlier quoted context omitted.

> 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…

> The gap between “over 1GB of RAM” and 8MB RSS contains the vast majority of embedded Linux devices The gap between 16MB RAM and 64MB RAM doesn't exist, though. Literally doesn't, the components have the same cost down to a cent in the BOM. And if you can have 64MB, then there's systemd's own true memory use (around 3-4MB) is completely immaterial.

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.

Re: Why systemd is a problem for embedded Linux

#184

Post by 1oooqooq »

kaba0 wrote: post #175
dhjvgfkvhy wrote: post #156

Earlier quoted context omitted.

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.

it was only faster if you started with bloated redhat systems to begin with. but yes, it was the beginning of parallelism on init...

but the "faster boot" you're remembering are actually a joke at the time. since the team working on it were probably booting vms all the time, the system was incredible aggressive on shutdown and that was the source of it. something like it reboots so fast because it just throws everything out and reboot, or something. i don't really care much for the jokes but that was why everyone today remembers "systemd is fast".

Re: Why systemd is a problem for embedded Linux

#185

Post by 1oooqooq »

dcsommer wrote: post #77
transpute wrote: post #16

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).. c…

How many systemd CVEs are memory or thread safety related?

I'd bet you get more CVEs and actual remote exploit entry points by systemd forcing mdns, bonjour, upnp and other zero conf hacks just because that was the work the systemd team was doing in rh before.

Re: Why systemd is a problem for embedded Linux

#186

Post by kaba0 »

1oooqooq wrote: post #184
kaba0 wrote: post #175

Earlier quoted context omitted.

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.

it was only faster if you started with bloated redhat systems to begin with. but yes, it was the beginning of parallelism on init... but the "faster boot" you're remembering are actually a joke at the time. since the team working on it were probably booting vms all the time, the system was incredible aggressive on shutdown and that was the source of it. something like it reboots so fast because it just throws everyth…

It mandates strict session termination, unlike the unsustainable wild west approach of older Unix systems. Proper resource deallocation is crucial for modern service management. When a user exits without approval of "lingering user processes," all their processes should be signaled to quit and subsequently killed.

Re: Why systemd is a problem for embedded Linux

#187

Post by 1oooqooq »

lambda wrote: post #31
fsckboy wrote: post #14

Earlier 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…

i don't think many distros use networkd. they all ship it disabled with nm instead

Re: Why systemd is a problem for embedded Linux

#189

Post by sph »

1oooqooq wrote: post #183
cyberax wrote: post #136

Earlier quoted context omitted.

> The gap between “over 1GB of RAM” and 8MB RSS contains the vast majority of embedded Linux devices The gap between 16MB RAM and 64MB RAM doesn't exist, though. Literally doesn't, the components have the same cost down to a cent in the BOM. And if you can have 64MB, then there's systemd's own true memory use (around 3-4MB) is completely immaterial.

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 not a fancy router I bought).

Are you talking about devices from the early 2000?

Re: Why systemd is a problem for embedded Linux

#190

Post by lmm »

dralley wrote: post #89
oguz-ismail wrote: post #86

Earlier 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 And it's slow. Windows 11 boots in 5 seconds on my laptop, Ubuntu 22 used to take about a minute before I finally made the switch.

That almost certainly has little to do with systemd itself, and more to do with which services are enabled on boot.

It's due to systemd in that systemd makes it too fiddly to figure out or change which services are enabled on boot. (I used to know a way to disable certain services on boot under systemd, but it doesn't work any more, and I've reached a state of learned helplessness at this point)
Post reply on HN