Why systemd is a problem for embedded Linux

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 under a different dominion of control which should operate as a black box with respect to the program generating the data and the rest of the system.

Because that's how you prevent ossification -- which is engineering. You want to make it so the other component can be improved or substituted. One system logger is designed to store the logs on a central server instead of the local machine, another supports modules so other people can easily write log-parsing scripts. And when you come up with a new idea for a third, you don't have to be on the systemd team to publish an independent implementation that other people can use as a drop-in replacement, instead of (not in addition to) the default one, without requiring it to be separately integrated with a dozen moving targets in the systemd repository.

What you're trying to do is to allow this:

> In the same vein, don't be creative with bolt sizes. Be creative with what those bolts allow you to achieve. Be creative at a higher level.

You want to standardize the bolt sizes, i.e. the interfaces between components. What you explicitly don't want is to replace bolts with having everything epoxied together.

But that's what happens when you e.g. integrate the logging system with the service manager, which is the sort of thing people are complaining about.

One of them. The others didn't work out so well. That's a curiosity in and of itself.

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

Those claims are true. Those systems exist. People use them. Every day. I've got tons of business riding on them. Systemd's defaults are simply a non starter for any real production environment.

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

They prefer a system which leaves the options open. Systemd removes them in the name of simplistic cohesion. It's all based on the flawed idea that linux will ever be a popular desktop operating system if you just make it work like windows does.

It misses the point on what computing is entirely, but hey, as long as it's "complete" implementation of this flawed vision I guess that's good enough for some people. And yet we're still no where near windows.

> And OpenWRT abandoned this goal.

They have not. Individual devices get too old to be supported, but there are plenty of 16 MB devices they still support. Its true that basically every device now has 32MB or more of flash, but there are still plenty out there that don't.

> with a built-in planned obsolescence (what if the new update requires just a bit more space for "calibration data"?). Got it.

The calibration data is from the factory to tune the wifi radios, it doesn't change since its specific to that individual device. I really hate to reply like this on HN, but you don't seem to know what you're talking about. The kinds of constraints you deal with in embedded networking are different than that in general computing. There's a reason systemd wasn't used, and there's a reason OpenWRT devs went through the trouble of developing their own init system. Just because you can't fathom those reasons doesn't mean they don't exist.

procd is only slightly better than sysvinit, it has the same ideas, and only adds simple and incorrectly implemented event triggers. And yes, I spent days debugging issues that it caused.

E.g. a USB drive for the logs becomes slow and changes the startup order, so now openvpn starts before the interface acquires the IPv6 address. Boom, broken IPv6 routing.

> They have not. Individual devices get too old to be supported, but there are plenty of 16 MB devices they still support. Its true that basically every device now has 32MB or more of flash, but there are still plenty out there that don't.

And systemd can live just fine at 16MB. I ran it on RouterBoards with 32MB (the smallest ones available) in 2014. It has grown a bit since then, but it can be slimmed down (remove compressors, auditing, SELinux/AppArmor, etc.).

> The calibration data is from the factory to tune the wifi radios, it doesn't change since its specific to that individual device. I really hate to reply like this on HN, but you don't seem to know what you're talking about.

The entire firmware for WiFi chips that were available during 16MB era is around 500KB-1MB. So it must be some other mysterious "calibration" data.

So you're thinking about more and more corner cases, that require the stars to be just right for the size of systemd to matter.