> Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working. But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.
Funny enough, FreeBSD is handling runtime hardware changes neither in its init process or rc scripts. Instead the FreeBSD kernel has a single-reader device event channel, which is read by devd. The submitted events range from ACPI laptop lid close/open, to added usb things or ZFS errors. They are matched against configurable rulesets and their respective actions executed. Loading kernel modules, starting daemons etc. Devd also multiplexes the received events to arbitrary numbers of additional consumers via a number of available sockets in /var/run.
I don't know, it's just an argument I've heard from systemd and launchd proponents. I've had hardware events via udev for a long time before systemd.
Re:FreeBSD Q2 2016 Status Report
by tedunangst on Thursday July 28, 2016 @01:06PM
(#12181503)
Rule number one: if you don't understand a claim, don't repeat it. Nobody benefits.
I keep seeing this argument, and i keep wondering what it is actually trying to say.
Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working.
But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.
Then again, maybe i am not the laptop packing dev convention goer that seems to use their laptop more like an oversized phone than a laptop (never mind a desktop).
Edit: damn keyboard ignored the copy command somehow, so i had the wrong quote pasted...