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

291–300 of 308 posts

Re: Why systemd is a problem for embedded Linux

#291

Post by richardfey »

bmicraft wrote: post #233
richardfey wrote: post #145

Earlier quoted context omitted.

My most common issues with systemd are related to those long timeouts when something at boot/shutdown is not working as intended, and unexplained/unexplainable changes to the order of boot of some components. For the former I have given up playing whackamole with all the timeouts you need to reconfigure, for the latter I didn't even try because I know that there's something peculiar about my setup that will never wor…

/etc/systemd/{user,system}.conf.d/dont-wait.conf: [Manager] DefaultTimeoutStopSec=5s There, done. That's all the timeouts you'll ever need. Go and complain to your distribution they are setting the wrong defaults, even desktop environment(s) already recommend[1] setting it to a low value. You can stop hating on systemd now, everything you needed was in `man systemd-system.conf` all along. [1] https://community.kde.or…

> There, done. That's all the timeouts you'll ever need. Go and complain to your distribution they are setting the wrong defaults, even desktop environment(s) already recommend[1] setting it to a low value. You can stop hating on systemd now, everything you needed was in `man systemd-system.conf` all along.

Here's another example of cultism repressing any dissent.

Let me make a bullet points list for you:

* I do not hate systemd, I have never stated that, I have been using it for possibly longer time than you and love most of it

* I am entitled to write about what I don't like, you can disagree and move on, we all need to do this exercise on a daily basis

* there are cases where systemd will change the order of dependencies during boot, that's by design because systemd works in a way that tries to achieve states. It's not really enforcing a graph with order

* in a sufficiently complex system, this constitutes a source of non-determinism and it is basically undebuggable: you see the failure, learn about the corresponding configuration, change it and hope that you did the correct change (you have no way to test this until next random occurrence)

That's all, it's based on my experience; I write plenty units on a regular basis and 99% of the times everything goes very well.

Re: Why systemd is a problem for embedded Linux

#292

Post by vv_ »

bmicraft wrote: post #229
vv_ wrote: post #194

Earlier quoted context omitted.

Typically in IoT you'll count RAM in kB not MB and definitely not GB. See STM32 H5/H7/L4/L4+/U0 as an example.

Typically in IoT you'll use an soc that actually supported some kind of network connection

Depends.

In Automotive (i.e. telematics devices) you'll want a separate MCU for CAN-bus. For example, if you are doing Request-Response model you'll want to make use of the built-in filters. Besides, it is unlikely that a modem would support the CAN interface.

In Cellular IoT you'll prefer a separate MCU as it is much easier to port to different hardware. For example, you can hook-up the module via UART and use CMUX (AT/GNSS/PPP) and you'll cover 80%+ of the modules available in the market with very minimal specific implementation layers to enter into these modes.

Re: Why systemd is a problem for embedded Linux

#293

Post by righthand »

consteval wrote: post #254
righthand wrote: post #246

Earlier quoted context omitted.

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.

Do I have any evidence? As in have I performed studies on processed sugar and gathered evidence? No. I do not have evidence.

A quick web search will gladly provide evidence if you actually are interested.

Here’s a HN thread on an NPR article: https://news.ycombinator.com/item?id=26126183

Here’s a Canadian news agency article: https://www.cbc.ca/news/health/how-toxic-is-sugar-1.1894262

If you’re just going to knock everything off as “just your belief” then no amount of evidence will convince you.

Re: Why systemd is a problem for embedded Linux

#294

Post by egorfine »

consteval wrote: post #253
egorfine wrote: post #239

Earlier quoted context omitted.

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

> greatly appreciate systemd

Really? I have yet to see one. Kids, maybe. Experiences sysadmins may appreciate systemd as PID1, but almost everything else is pure cancer.

> There's a major disconnect, I've seen, from what systemd haters proclaim and what is reality.

I can certainly agree with that.

> Nobody is forcing anything

... until distro maintainers decide to move crucial tasks to systemd-timers from cron, change resolved to systemd-resolved, switch from ntpd to whatever its called, remove sudo in favor of another systemd thing, etc. But sure, you are free to not use any. Except the only *nix thing left is the Linux kernel. Soon to be systemd-kernel.

Re: Why systemd is a problem for embedded Linux

#295

Post by egorfine »

imtringued wrote: post #245
egorfine wrote: post #181

Earlier quoted context omitted.

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

If it's broken for decades, what took us so long to change it and who gave systemd swamp the honor to provide the one and only right solution?

Re: Why systemd is a problem for embedded Linux

#296

Post by RandomThoughts3 »

richardfey wrote: post #290
RandomThoughts3 wrote: post #282

Earlier quoted context omitted.

> it often doesn't go well Plenty of people changes systemd configuration all the time and it just goes fine. You live in fantasy. Even op is basically saying: “my issue with systemd is that I dislike the timeout configuration of some services but I stubbornly refuse to change these configurable timeout durations because it would show that the problem was myself and I prefer blaming systemd.” It takes no time whatsoe…

> Plenty of people changes systemd configuration all the time and it just goes fine. You live in fantasy. "since I have never experienced what you say, it must be fantasy" > Even op is basically saying: “my issue with systemd is that I dislike the timeout configuration of some services but I stubbornly refuse to change these configurable timeout durations because it would show that the problem was myself and I prefer…

> I have been successfully using systemd for years

You are writing that you have been unsuccessfully using systemd for years because of the annoying timeout. I'm replying that it's entierely your fault because it takes seconds to make these timeouts disappear.

That's not toxicity. That's calling out some non sense on the internet.

Re: Why systemd is a problem for embedded Linux

#297

Post by mattpallissard »

egorfine wrote: post #294
consteval wrote: post #253

Earlier quoted context omitted.

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

> greatly appreciate systemd Really? I have yet to see one. Kids, maybe. Experiences sysadmins may appreciate systemd as PID1, but almost everything else is pure cancer. > There's a major disconnect, I've seen, from what systemd haters proclaim and what is reality. I can certainly agree with that. > Nobody is forcing anything ... until distro maintainers decide to move crucial tasks to systemd-timers from cron, chang…

I've seen a lot of complaining without any facts.

I've been building and automating data centers for years now. Systems has greatly simplified my life. I use all of the systems tooling; timesyncd, networkd (which is actually does _more_ unlike what is stated above, go read the man page), timers (better than cron, again go read the man page) resolved.

Not only does it solve a lot of problems, the configuration file format consistent across the tools, and the configuration is consistent _across distros_. I can write large swaths of automation that just works on most modern Linux distros.

Anyway, I'm not one to argue on the Internet. But I'm absolutely tired of hearing that's it's a dumpster fire. Sure, there are legitimate complaints and use cases where it might not be a good fit, but that holds true for all software. But, there is a reason so many distros switched to it. It's objectively better than the way things were. Those of us that deal with this stuff day in and day out are not going back to the way it was.

Re: Why systemd is a problem for embedded Linux

#298

Post by AnthonyMouse »

oblio wrote: post #285
AnthonyMouse wrote: post #272

Earlier quoted context omitted.

> Linux never got anywhere with the standard distros because they're all so different. This is eliding the difference in what you want to be standardized. Take system logging for example. You definitely want some standard interface to do it so all the different daemons and things can implement it once regardless of which system logger the distribution is using. But once it passes that data to the other program, it's…

We've had Unix for what, close to 55 years now? Nobody standardized and got widespread adoption for those standards, which BTW, especially when you look at corporate interests regarding the web, are easily sabotaged. So I'd rather have the epoxy open source standard than no standard.

And now we're back to this:

https://news.ycombinator.com/item?id=42039273

There are things that systemd does better than SysV and other things it does worse and you can want it to stop doing the things that are worse while still doing the things that are better.

Re: Why systemd is a problem for embedded Linux

#299

Post by poettering »

johnea wrote: post #32

The article fails to mention another aspect of systemd that interferes with emmbedded dvelopment: it's utility applications (primarily systemctl, but all the others as well) are intended to be run on the booted system for which the control is being performed. When configuring boot media, like an SD card, for an embedded ssystem that is not the running system where the configuration is occurring, this is an impediment…

Most of our tools that adjust files work really well offline. systemd-tmpfiles, systemd-sysusers, systemctl and so on all support --root= and --image=.

I really don't know what the problem is suppoaed to be.

Lennart

Re: Why systemd is a problem for embedded Linux

#300

Post by M95D »

frankjr wrote: post #210
1oooqooq wrote: post #183

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

> south America and Europe they are all 16 or 32 for no clear reason I don't know where you're getting your data from but it's clearly wrong or outdated. These are the most often sold routers in Czechia on Alza (the largest online retailer) under $100: - TP-Link Archer AX53 (256MB) - TP-Link Archer AX23 (128MB) - TP-Link Archer C6 V3.2 (128MB) - TP-Link Archer AX55 Pro (512MB?) ... - Mercusys MR80X (256MB) - ASUS RT-…

"Best sellers" usually means "best advertized because of worst sales".
Post reply on HN