Live data from Hacker News

Why systemd is a problem for embedded Linux

kevinboone.me

161–170 of 308 posts

Re: Why systemd is a problem for embedded Linux

#161

Earlier quoted context omitted.

Three decades perhaps. In 2014 it was Windows 8, SSDs, 5th gen i7 (Haswell), 8-16GB of DDR4 ram. Even the iPhone 6 came with 1GB of ram.

There's a huge chunk of people out there, not able to afford the latest.

Indeed, but still wrong.

In 2014 i got myself a second- or third-hand thinkpad X220, released in 2011, off eBay. It came with 8gb ram (two 4GB sticks) but it supported 16GB ram as well (two 8gb sticks).

The laptop (Asus A8Jc) I got when I was a teenager in ~2005 came with a dual core intel cpu and 1GB ram. So "512mb desktops" are way older than that.

Re: Why systemd is a problem for embedded Linux

#162

Earlier quoted context omitted.

Huh? Been a while since I was in the digital signage space but a lot of the equipment runs of the shelf RK3288 plugged into commercial displays. 2GB of RAM was pretty common. IIRC's though LG's WebOS TV's have minimum 2GB of RAM in the digital signage space directly built into the units themselves. I believe Samsung Tizen based units has similar RAM. My router has 1GB of RAM in it. But even my cheapest routers have 1…

A decade ago, I had to settle for 512MB of ram for my Windows XP desktop.

That was the amount of RAM in my Athlon Windows XP multimedia PC, bought in 2002, by 2006 my newly acquired ThinkPad PC RAM was already measured in GB.

Re: Why systemd is a problem for embedded Linux

#163
post #119
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…

I think the problem is that small tools are missing that "comprehensively" part.. trying something as simple as getting full system startup log (something very useful on headless system!) - it was basically impossible until systemd came. Only gentoo tried to do this for a few years, but then that functionality broke. Same goes for service startup - why does start-stop-daemon discards stdout/stderr instead of logging…

This seems like the motte and bailey thing.

Some of the oldest init systems made decisions that were sensible at the time but not so much now, e.g. when storage is hundreds of thousands of dollars per GB you don't want to log everything, when it's tens of cents per GB you do. But you can obviously make a non-monolithic init system that causes output to be stored to a log instead of being discarded.

So then systemd comes in, solves some of the old problems and independently, unnecessarily introduces new ones by being a huge monorepo that lacks clean and stable interfaces between its own components, inhibiting anyone else from providing a viable competing implementation of an individual component.

Then people complain about the latter and the defense that comes back is of the former. But that's no defense -- we could instead be making the good change and not the bad change.

Re: Why systemd is a problem for embedded Linux

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

I don't agree with comprehensively.

for example timesyncd is barebones and not super accurate when it comes to timekeeping, while chrony and ntp actually manage the system time.

similar - systemd-boot is barebones, systemd-networkd is barebones (but has gotten more MVP-featured in a busybox way), etc

Maybe 10 more years and everyone will be used to things, and people won't be arguing about chesterton's fence.

https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...

Re: Why systemd is a problem for embedded Linux

#165

Earlier quoted context omitted.

Huh? Been a while since I was in the digital signage space but a lot of the equipment runs of the shelf RK3288 plugged into commercial displays. 2GB of RAM was pretty common. IIRC's though LG's WebOS TV's have minimum 2GB of RAM in the digital signage space directly built into the units themselves. I believe Samsung Tizen based units has similar RAM. My router has 1GB of RAM in it. But even my cheapest routers have 1…

A decade ago, I had to settle for 512MB of ram for my Windows XP desktop.

Three decades ago was 1995 and Windows 95 ran on 8MB of RAM.

Re: Why systemd is a problem for embedded Linux

#166
post #80
post #36

Earlier quoted context omitted.

> the good things are the things you don't notice; the things that just work sorry, no, at least in any meaningful sense, because init already just worked for me. and when something didn't, I could find how to fix it in a way that was transparent and I understood and could even modify or make better, without being connected to the internet looking for cargo cult incantations on stack overflow init was a tool; systemd…

Okay, I'll bite. What kind of problems do you have with the part of systemd that replicates sysvinit /every other day/?

I've got the waiting ages for shutdown feature on reboot, so I tend to force reboot it. I never bothered trying to fix it because firstly I don't know where to start and secondly I only reboot after updates once every few months.

Re: Why systemd is a problem for embedded Linux

#167
post #158

Earlier quoted context omitted.

> But of new devices? Absolutely not, and that's what I'm talking about. The trouble with "new" is that it keeps getting old. There would have been a time when people would have said that 32MB is a crazy high amount of memory -- enough to run Windows NT with an entire GUI! But as the saying goes, "what Andy giveth, Bill taketh away". Only these days the role of Windows is being played by systemd. By the time the >1GB…

> There would have been a time when people would have said that 32MB is a crazy high amount of memory Those days are long gone though, for better or worse. We live in the 2020s now and ram is plenty. The small computers we all carry in our pockets (phones) usually have between 4 and 16g GB ram.

That's entirely the point. In the days of user devices with 32MB of RAM, embedded devices were expected to make do with 32KB. Now we have desktops with 32GB and the embedded devices have to make do with 32MB. But you don't get to use GB of RAM now just because embedded devices might have that in some years time, and unless something is done to address it, the increase in hardware over time doesn't get you within the budget either because the software bloat increases just as fast.

And the progress has kind of stalled:

https://aiimpacts.org/trends-in-dram-price-per-gigabyte/

We've been stuck at ~$10/GB for a decade. There are plenty of devices for which $10 is a significant fraction of the BOM and they're not going to use a GB of RAM if they can get away with less. And if the hardware price isn't giving you a free ride anymore, not only do you have to stop the software from getting even bigger, if you want it to fit in those devices you actually need it to get smaller.

Re: Why systemd is a problem for embedded Linux

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

Windows 11 probably uses Fast Startup for those speedy boot times, which is to say that it's not a "cold" boot. Apples and oranges and all that...

Re: Why systemd is a problem for embedded Linux

#169

Earlier quoted context omitted.

Three decades perhaps. In 2014 it was Windows 8, SSDs, 5th gen i7 (Haswell), 8-16GB of DDR4 ram. Even the iPhone 6 came with 1GB of ram.

There's a huge chunk of people out there, not able to afford the latest.

But desktops with those specs are If they can't afford those specs then you're approaching the group of people who can't afford a computer in the first place.

Re: Why systemd is a problem for embedded Linux

#170

Earlier quoted context omitted.

Sugar is not, in fact, a poison. As for drugs: > Alle Dinge sind Gift, und nichts ist ohne Gift; allein die Dosis macht, dass ein Ding kein Gift ist. - Paracelsus, 1538 https://en.wikipedia.org/wiki/The_dose_makes_the_poison

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.

Everything is a poison. It's simply a question of dosage.
Post reply on HN