Nem ilyen egyszeru ez. Van udev, de mi van, ha bluetooth usb adapter bedugaskor el kellene inditani a blueman-t, es az ugye egy service, tehat valaminek utana felugyelnie kellene (stop/restart/log/...). Vagy a dns resolver esete: ahogy roam-ol a laptop-od kulobozo wifi-k, mobilinternet kozott, elvarod, hogy a dns mindig jol alljon be, de amig pl. a ceges halozatban dnsmasq-olni akarsz, addig mobilneten pl. nem.
Elvarod, hogy low battery eseten governor-t kapcsoljon, meg feldobjon pop-up-ot az arcodba.
Persze lehet ezt kulon-kulon service-ben csinalni, de akkor meg az szemetelne ossze a processzlistad. :)
Az udev nem rossz, sot. En is imadtam, mert olyan egyszeru, felhasznalobarat volt, amennyire kellett. De vegyuk eszre, limitaltak a lehetosegei, mind megfigyelt event-ek, mind erre reakciokent adhato action-ok tekinteteben. A systemd tobbmindenre tud reagalni, es sokkal szerteagazobban.
En is utalom a systemd-t, mert imho ahhoz kepest, amire az atlagember hasznalna, tulbonyolitott. Avagy az emberek 90%-a a feature-ei 10%-t hasznalja, de sajnos nem figyeltek oda, hogy ez a 10% faek egyszeruseggel elerheto, kezelheto legyen. Ha mar pl. csinaltak volna egy /etc/init.d virtualis filerendszert, benne minden service-nek egy automatikusan generalt good-old start/stop/restart/reload/... init script, becslesem szerint tizedennyi ellenallas lenne systemd ellen.
szoval tl;dr, kell a systemd, de lehetett volna ezt baratiabban is csinalni.
update: btw ha azt hiszed, a systemd gaz, latnod kene macos-en a launchctl -t... :P