<html><head></head><body><div>On Sat, 2015-09-12 at 13:26 -0400, Michael B. Trausch wrote:</div><blockquote type="cite"><div>At the end of the day, it saves time and resources for those of us who make our living managing systems. For my part, I manage things ranging from smaller than the Rπ to larger than a 1U. And systemd saves me time and resources across the board.</div><div></div></blockquote><div><br></div><div>And just to clarify here: While some of my real small systems are only using systemd in testing, as I mentioned several emails back, this is just lack of time to move it to production on my part. I've done enough work to see for myself the benefits of moving.</div><div><br></div><div>And one more clarification:</div><div><br></div><blockquote type="cite"><div>udev provides a much more convenient method of handling things than standard scripting. If you need to load a userspace driver to handle a particular USB device (e.g., a generic HID sensor not handled by the kernel, or something similar), then you plug the rule in and systemd/udevd make it happen. (Of course, you do not need systemd for udevd, but since systemd and udevd play very well together, it'd be silly to not use it.)</div></blockquote><div><br></div><div>Not only is this a benefit all by itself, but it means userspace drivers no longer have to internally reproduce the logic required to find their devices. Udev tells you your device node for the userspace driver. This allows me to cut out the probe logic which traverses sysfs or devtmpfs directly, which is error prone and can screw up other similar-looking devices. In other words, it's more robust by design than The Old Ways. And that's kinda the whole gist of systemd/networkd/journald/etc.: small, robust tools.</div><div><br></div><div>"systemd" refers to more than PID 1, but it also contains more than /sbin/init. It's true to its name, otherwise it'd have been called sysinitd, and not systemd.</div></body></html>