Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Systemd and dbus are standard parts of the Linux userland now, nearly as essential as the kernel itself as they provide vital services.


Plenty embedded projects developed today don't use them (and functional desktop and server distros without them are around), "nearly as essential as the kernel" is really overstating it.


We'll be headed down this path soon for some custom appliances. I can't find a compelling reason for systemd or dbus.


If you can fit it in your image, systemd is amazing for embedded. Dependency tracking, auto service restarts on crash, unified start/stop and enable/disable, even journald is nice with per-unit unified logging.

It is miles better than SysV or monit. I haven't needed to try the 'suggested' replacements like runit or openrc.


Which are all great festures for devices where you'll have interaction. Auto restart on failure has been done for years, so the weight of systemd doesn't justify it for us. We'll have a single binary service, so dependency tracking isn't really a problem. Same for journald. 100% of the useful logs will be moved off the device, so the system journal isn't useful.

Not every nail needs to be hut by the systemd hammer. We've had really fantastic and light weight init systems for decades without all the bloat and creep of systemd.


The fact that desktop Linux systems mostly run systemd is (unfortunately) a reason to run a Linux distro that also runs systemd on new embedded projects (for large values of embedded. Storage is cheap these days, as is a CPU with an MMU).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: