Systemd is most problematic because of its own-everything monolithic nature, and the changing of kernel interfaces to match. The vast majority of Linux systems are not desktops, and probably not servers either. The kernel and the core utilities around it (like init) should be designed with multiple implementations and all machine types in mind. This means phones, set top boxes, TVs, routers, automation hardware, supercomputers, and more.

If the core utilities around the kernel and the interfaces they use are well-documented, designed, and modular, then different machine types can pick and choose the components they need, and easily write their own by opening a well-defined API on something in /dev. If systemd continues to take over and alternatives smothered, very quickly the kernel will become useless to any system where systemd makes no sense, especially non-desktop embedded systems.

systemd makes a lot of sense for embedded systems:

* Embedded systems use watchdogs. systemd implements a watchdog supervisor chain, where systemd supervises applications, and the hardware watchdog supervises systemd.

* kdbus: efficient IPC

* networkd: simple network setup, very fast DHCP client

* fast boot times

* handles many complexities, so that embedded developers can focus on their application

That all sounds fantastic, but what do you do if just one component of systemd doesn't work for you? Or if you only want to use one or two components of systemd?

Regarding the first question: Then you use something else instead of that component. For instance, the existence of networkd does not preclude the use of (say) dhcpcd or your own network setup scripts. Of course, there are a few components that are more central (e.g. journald, udevd). In that case you file a bug report and/or fix it. Same as when one component of the kernel (which is vastly larger than systemd) doesn't work for you.

As for the second question: certain parts of systemd can certainly be used on non-systemd systemd (such as udev or nss-myhostname). But most would require at least some changes.

We are selling embedded device with systemd Debian since this spring and they work just fine. And it not some 5$ board made once and then sold as is. It is a big and very advanced device in the hundred thousand dollars bracket and all of them are constantly improved and upgraded. And they will be maintained for many more years.

jolla uses systemd on their hardware right now. for tablets and phones

Your comment is the very definition of FUD. You have nonfacts just baseless fear.

I developed and marketed my own embedded Linux products. It would have been difficult to do some of the customizations I did if the kernel, DHCP server, logging system, HAL/udev, etc. were all adapted to the one systemd way of doing things with dbus.

You should educate yourself about FUD, I recommend the Halloween documents, where they explain the unfeasibility of FUD tactics against an open source project, e.g. if someone tries to do it they won't get anywhere.

Why did systemd decide to ALSO take over logging and store them in a binary format, though?