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

241–250 of 308 posts

Re: Why systemd is a problem for embedded Linux

#241

Post by 0xbadcafebee »

TheCycoONE wrote: post #124
0xbadcafebee wrote: post #95

Systemd, Wayland, DBus, and other modern Linux "solutions" are all problematic for the same reason: they are complex monoliths that are extremely difficult to replace, in part or in whole. Systems often won't work without them, because the entire ecosystem has grown dependent on them. You literally can't run a modern desktop without a bunch of "shims" whose sole purpose is to fake being systemd. The best designs, sad…

Wayland seems like an odd entry in that list. It's mostly a strugle for people because it's not the monolith X was and now we have dozens or hundreds of different applications from different vendors to cover a subset of the functionality that was built in. In that sense X was the complex monolith that is extremely difficult to replace. Also unlike the complaints about systemd in the article, Wayland is well suited to…

That is an odd one. While X is definitely an ugly monolith, Wayland is microservices. I think that speaks volumes...

Re: Why systemd is a problem for embedded Linux

#242

Post by rascul »

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.

> In general it was the first init system that could properly parallelize

I'm not sure what you mean by "properly" but didn't initng and upstart (and probably some others I can't recall) do the parallel stuff before systemd?

Re: Why systemd is a problem for embedded Linux

#243

Post by vetinari »

lmm wrote: post #190
dralley wrote: post #89

Earlier quoted context omitted.

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)

`systemctl disable` and `systemctl mask` work today just like they worked decade and half ago.

Re: Why systemd is a problem for embedded Linux

#244

Post by oguz-ismail »

bmicraft wrote: post #237
oguz-ismail wrote: post #225

Earlier quoted context omitted.

> the “Shutdown” button is a lie: it logs you out and hibernates the system instead of actually shutting it down I'm okay with that. How do I enable this on Ubuntu?

Are you seriously complaining right now that systemd doesn't have a specific feature no other init for linux has either, while at the same time complaining it is too complicated and does too much stuff?

I'm asking a question

Re: Why systemd is a problem for embedded Linux

#245

Post by imtringued »

egorfine wrote: post #181
mattpallissard wrote: post #135

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

Cron is probably the worst example you could have chosen. For my uses cases that, you know, involve manually running jobs to see if they actually work, cron has been broken for decades and is still to this day basically unusable. Systemd timers work far better than cron.

Re: Why systemd is a problem for embedded Linux

#246

Post by righthand »

consteval wrote: post #232
righthand wrote: post #147

Earlier quoted context omitted.

Sugar is indeed poison. Personally, I like to add a bit more science and reasoning to my understanding rather than rely on quotes from someone in 1538.

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.

Re: Why systemd is a problem for embedded Linux

#247

Post by saurik »

RandomThoughts3 wrote: post #193
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…

I switched to systemd when Arch switched and from the get go, it was massively easier to parallelise with systemd than with the old system and that was with an HDD. 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…

Running things in parallel isn't going to make the disk faster... with a HDD I'd think it is actually even more likely to make the disk slower.

Re: Why systemd is a problem for embedded Linux

#248

Post by felixgallo »

consteval wrote: post #236
felixgallo wrote: post #20

Earlier quoted context omitted.

All of those things are trivially true. What are you disagreeing with?

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 than it does today, and routinely bricked or crashed systems. The adoption was forced and 100% political.

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. That's why you get this ridiculous dns nonsense, this ridiculous container nonsense, this ridiculous cron nonsense, hostnamed (!), the list is endless.

The technical argument is that it's a giant tasteless bag of ever increasing poorly implemented scope. The rest of Unix, by comparison, is generally not that way. If you pick up a BSD or even an alpine, you'll find that you don't need a bunch of badly written, hacked together garbage in order to get your work done. The system can be entirely readable and repeatable without cramming a bunch of cruft and poor decisions into pid 1.

The idea that systemd doesn't 'force' anything is, of course, hilarious. 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.

Every time someone mentions systemd, some random apologist dutifully trots out the idea that systemd-init is small and therefore systemd is not a monolith, checkmate. 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.

Re: Why systemd is a problem for embedded Linux

#249

Post by chasil »

blueflow wrote: post #51
jcalvinowens wrote: post #45

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…

That "occasional weird problem" is because systemd is not designed to be used with other software. While you technically still have the choice to roll your own non-systemd initramfs, it will be an uphill battle.

The embedded people will naturally look at busybox. I saw it running on a credit card scanner at Old Navy a few years ago.

It has an init:

  $ /home/busybox-1.35 init --help
  BusyBox v1.35.0 (2022-01-17 19:57:02 CET) multi-call binary.

  Usage: init

  Init is the first process started during boot. It never exits.
  It (re)spawns children according to /etc/inittab.
  Signals:
  HUP: reload /etc/inittab
  TSTP: stop respawning until CONT
  QUIT: re-exec another init
  USR1/TERM/USR2/INT: run halt/reboot/poweroff/Ctrl-Alt-Del script
On an embedded system, that will be a strong contender for pid 1.

Re: Why systemd is a problem for embedded Linux

#250

Post by [deleted] »

jcalvinowens wrote: post #45

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…

[deleted]
Post reply on HN