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

251–260 of 308 posts

Re: Why systemd is a problem for embedded Linux

#251

Post by jalgos_eminator »

cyberax wrote: post #115
jalgos_eminator wrote: post #108

Earlier quoted context omitted.

OpenWRT is VERY sensitive to firmware size. I developed for a device with 16 MB flash that had both a normal (~11 MB) and recovery firmware (~3MB) on flash. The rest of flash was used for persistent storage, bootloaders, and calibration data. This is very common for older routers and APs which is the whole reason that OpenWRT exists.

Well, OpenWRT doesn't even officially support devices with less than 16Mb of flash anymore: https://openwrt.org/toh/views/toh_available_16128 > The rest of flash was used for persistent storage, bootloaders, and calibration data. So you couldn't spare around 1Mb of compressed flash or 2Mb of uncompressed flash for systemd? > This is very common for older routers and APs which is the whole reason that OpenWRT exists.…

> So you couldn't spare around 1Mb of compressed flash or 2Mb of uncompressed flash for systemd?

Absolutely not.

> That hasn't been the case in quite some while

These routers and APs still exist and are in use. Yes, they are 10+ years old, but they're still out there. One of the main goals of OpenWRT is to support legacy networking hardware that vendors abandoned.

Re: Why systemd is a problem for embedded Linux

#252

Post by consteval »

felixgallo wrote: post #248
consteval wrote: post #236

Earlier quoted context omitted.

Except none of these are true, they're just things people have made up to conceal the fact they oppose systemd for ideological reasons. There's little to no technical arguments against systemd - it's fast, much more robust than what came before it, and services 99% of usecases. Users DID want systemd. Ask any sys admin, most much prefer systemd. Also systemd doesn't "force" anything. Most distributions don't even shi…

oh definitely not, and it's a matter of record. Red Hat and Poettering wanted systemd in order to control more of the platform; this is why they absorbed in udev (which had been a separate repo), came out saying that there are certain parts of the system that, despite all this being open source, were forbidden to modify or replicate, and stacked the debian voting. Systemd at the time sucked, incredibly, even worse th…

> Red Hat and Poettering wanted systemd in order to control more of the platform

Speculative and ideological. From a technical perspective, I don't care about this.

> despite all this being open source, were forbidden to modify or replicate

This isn't true - you're allowed to modify or replicate any parts of systemd and always have been.

> systemd is, of course,today a continuing shambling feature factory behemoth in which hundreds of product managers try to shoehorn in more mandatory features in order to cement grip on the platform

I'm not sure you understand what systemd is.

systemd is not a piece of software, systemd is an endeavor. Many, many projects are under "systemd", as in they have the name, but they are all individual binaries. Practically 0 distros include all systemd binaries, because they're optional. Many projects already existed before systemd, like gummi boot, and were just given the name.

> The rest of Unix, by comparison, is generally not that way

This is untrue, as systemd follows unix principles. systemd-init does one thing and one thing only - it's only the init system. systemd-networkd is just the network daemon. systemd-journald is just the logger. And on and on. Despite what you may think, they ARE optional, and distros mix and match constantly.

> without cramming a bunch of cruft and poor decisions into pid 1

Again, out of the dozens and dozens of binaries under the systemd umbrella, only one (1) runs under PID 1. This simply isn't true.

> Systemd is designed to try to be the ultimate mandatory dependency for essentially everything on the system. That's the way Red Hat wanted it to be, and that's the way it is

Speculation, ideological, and not evidence backed.

> Of course, journald, libudev, localed, logind, hostnamed, homed, networkd, resolevd, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd, and all of the other array of dumbass bolted-on second-system-effect-driven product-managed nonsense somehow don't get mentioned

Yeah... because those are separate programs. Maybe you just don't understand how computers work, but these programs are unrelated. They talk over IPC, they're not even linked together on any systems. You can take or leave any of them, and many distros do. Even Debian, the supposed systemd cocksucker, doesn't include half of these.

Re: Why systemd is a problem for embedded Linux

#253

Post by consteval »

egorfine wrote: post #239
consteval wrote: post #235

Earlier quoted context omitted.

Okay. How? They're all individual binaries that just happen to use the systemd name. You realize systemd isn't just one big program, right? It's like 30 programs, all independent of each other, with integrations to other programs.

I believe they were not created to solve real problems. No one wanted a cron replacement, really. Thus they are created out of political or ego reasons.

This is purely speculative. From my talks with sys admins, all the ones I've met greatly appreciate systemd. Also timers and cron have different requirements, notably timers can do much more. Also timers is purely optional and most distros DO use cron.

There's a major disconnect, I've seen, from what systemd haters proclaim and what is reality. Nobody is forcing anything, you don't have to use 99% of systemd, it's not a monolith, and many people do want the features. To be clear, this isn't my opinion - this is the truth. You can find all this out by perusing the repos and mailing list.

Re: Why systemd is a problem for embedded Linux

#254

Post by consteval »

righthand wrote: post #246
consteval wrote: post #232

Earlier quoted context omitted.

Sugar is not poison. It can be, in certain situations, "bad for you". But sugar is found naturally in a variety of fruits and vegetables and has been a staple of the human diet for all of history and pre-history. There's no way to describe it as "poison".

The sugar being discussed is not natural sugars but refined processed sugars, that are absolutely poisons. Booze has been a staple of diets for a long time too. Doesn’t mean it’s not poison just because society is stupid enough to embrace it.

Do you have any evidence of this or is this just your belief? I think, if it's just your belief, you should say that.

Re: Why systemd is a problem for embedded Linux

#255

Post by cyberax »

jalgos_eminator wrote: post #251
cyberax wrote: post #115

Earlier quoted context omitted.

Well, OpenWRT doesn't even officially support devices with less than 16Mb of flash anymore: https://openwrt.org/toh/views/toh_available_16128 > The rest of flash was used for persistent storage, bootloaders, and calibration data. So you couldn't spare around 1Mb of compressed flash or 2Mb of uncompressed flash for systemd? > This is very common for older routers and APs which is the whole reason that OpenWRT exists.…

> So you couldn't spare around 1Mb of compressed flash or 2Mb of uncompressed flash for systemd? Absolutely not. > That hasn't been the case in quite some while These routers and APs still exist and are in use. Yes, they are 10+ years old, but they're still out there. One of the main goals of OpenWRT is to support legacy networking hardware that vendors abandoned.

> Absolutely not.

So basically, you're dealing with devices that use obsolete hardware and are designed to be extra-brittle (no safety margin), with a built-in planned obsolescence (what if the new update requires just a bit more space for "calibration data"?). Got it.

sysvinit indeed fits perfectly. Make the system extra unreliable, to provide a stimulus to buy a newer version.

> One of the main goals of OpenWRT is to support legacy networking hardware that vendors abandoned.

And OpenWRT abandoned this goal. OpenWRT also can do nothing about firmware vulnerabilities in the old WiFi chipsets.

Moreover, 10 years ago, systems with 32Mb were already common.

Re: Why systemd is a problem for embedded Linux

#256

Post by LtWorf »

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?

Rust would have the same issues since you'd need to use unsafe code to achieve certain things systemd does.

Re: Why systemd is a problem for embedded Linux

#257

Post by pwg »

0xbadcafebee wrote: post #240
pwg wrote: post #123

Earlier quoted context omitted.

There's nothing named "systemd" in the FILE_LIST [1] for Slack64-current (which is what eventually becomes "the next release" at the appropriate time. So it would seem the GP has been taken in by some rumor somewhere. [1] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-cur...

I thought I saw in the last release a note that the next one would come with systemd. It could be I hallucinated it. Maybe I'm becoming a real LLM!

RELEASE_NOTES [1] contains no mention of systemd (or at least does not contain that string).

README.TXT [2] also does not contain the string "systemd"

ANNOUNCE.15.0 [3] also does not contain the string "systemd"

If such a 'note' were included in the last release (15.0) it should have been in one of the above three files. So there is nothing in the release that appears to indicate a shift to systemd.

[1] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-15....

[2] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-15....

[3] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-15....

Re: Why systemd is a problem for embedded Linux

#258

Post by felixgallo »

consteval wrote: post #252
felixgallo wrote: post #248

Earlier quoted context omitted.

oh definitely not, and it's a matter of record. Red Hat and Poettering wanted systemd in order to control more of the platform; this is why they absorbed in udev (which had been a separate repo), came out saying that there are certain parts of the system that, despite all this being open source, were forbidden to modify or replicate, and stacked the debian voting. Systemd at the time sucked, incredibly, even worse th…

> Red Hat and Poettering wanted systemd in order to control more of the platform Speculative and ideological. From a technical perspective, I don't care about this. > despite all this being open source, were forbidden to modify or replicate This isn't true - you're allowed to modify or replicate any parts of systemd and always have been. > systemd is, of course,today a continuing shambling feature factory behemoth in…

"these programs are unrelated" ok, enough feeding the systemd troll. Good luck with all of whatever that is.

Re: Why systemd is a problem for embedded Linux

#259

Post by akira2501 »

oblio wrote: post #202
akira2501 wrote: post #24

Earlier quoted context omitted.

Turns out many people don't care to change their distribution defaults.

Exactly, because I don't care about the plumbing in my house unless it's really bad. Systemd is opinionated and quirky but it does the job just fine for 99.999% of people and it provides a standardized approach to things just by virtue of how it works, and there is a lot of value in that.

The real question is would anything else also be able to do 99.9999% of the job with less code and better semantics.

People seem to think it is.

Re: Why systemd is a problem for embedded Linux

#260

Post by oblio »

akira2501 wrote: post #259
oblio wrote: post #202

Earlier quoted context omitted.

Exactly, because I don't care about the plumbing in my house unless it's really bad. Systemd is opinionated and quirky but it does the job just fine for 99.999% of people and it provides a standardized approach to things just by virtue of how it works, and there is a lot of value in that.

The real question is would anything else also be able to do 99.9999% of the job with less code and better semantics. People seem to think it is.

Poettering actually took his idea to completion.

A lot of people claim the same, but the proof is in the real life pudding.

Don't forget that geeks idealize perfection and especially minimalist perfection.

Post reply on HN