I like it a lot and my team uses it extensively to precisely specify the behavior of our embedded products. systemd has a low memory footprint for what it does. It also helps us make our products more secure by making it easier to isolate processes / different system services as much as possible. So the risk of getting hacked over a network service is reduced a lot. Without systemd we would be forced to create our own which wouldn't be as secure.

The service manager? It manages services with many of the same features of systemd units, including advanced features, like firewall integration. This is combined with windows event system which provides many of the same features of the systemd journal.

> making it easier to isolate processes / different system services as much as possible

These features are built into the operating system. systemd provides a particular method of accessing them, but certainly not the only one.

> So the risk of getting hacked over a network service is reduced a lot.

Your risk of getting hacked has nothing to do with systemd. You are hoping that the easy process isolation features you're referencing actually work and thus _mitigate_ the potential damage of that hack. This is not bad strategy, but is on it's own, entirely incomplete.

> Without systemd we would be forced to create our own which wouldn't be as secure.

At the risk of being hyper critical, this is precisely the type of logic I would use to sell snake oil, too.

I don't get all the hate, that primarily argues about the philosophy of Linux, when the philosophy made everything just harder..but I guess some people just want to suffer for their believes, mich like some Catholics

It was about the udev/systemd maintainers writing "fuck you Gentoo developers" in a mailing list when they wanted udev to support only systemd, actually that udev should be part of systemd (for no real reason) and reimplementing things (sometimes badly for years) instead of reusing what was in place. It was about pretty big bugs (I remember a bug around coredumps being cut at ~700MB in size, which the systemd maintainers responded with the equivalend "well that's your problem not ours, journald is not fast enough and so we cut the max size" and was only closed eventually - ~3 years - probably because some RH customer screamed loudly enough). And the original discussions were even before systemd decided to hardcode what essentially is random IP addresses into resolved ("maintainers should change those values if they don't like them!") and other network services (NTP? I don't remember now anymore). It was about the billion libraries (later on there have been some security fun issues) it brought in and made your stuff link to (I vaguely remember something to parse qr codes?). It was about not-documented DBUS interfaces and making DBUS a core part of the system...

Most complex services still had heavy, long prestart script written in bash anyway at that point in time even when using systemd, so the script complexity was not really gone (and I think postgresql for example still has something like that).

Now, Redhat pushed hard for it and you cannot just ignore what they do and go your own way since the number of maintainers they employ is massive along the entire stack, from kernel to GNOME - Systemd was convenient to use and people went for it even with all the issues it had/has for good reasons (same as pulseaudio), but thinking the only discussion at the time was about the "linux philosophy" is a strawman and changing history a fair bit. :)

"But it is just harder to learn how to write proper software that would work on a machine slightly different than my own"...

I've seen some software depend on libsystemd for the sd_notify but I think after the whole security kerfuffle there won't be many of those anymore.

If you just wanted simple/easy init scripts you could do that with runit for years without having to switch dozens of unrelated system components over to the systemd-approved version and render your system unbootable every so often.