| |||||||||||||
Poettering: The Biggest MythsPoettering: The Biggest MythsPosted Feb 7, 2013 5:50 UTC (Thu) by dlang (✭ supporter ✭, #313)In reply to: Poettering: The Biggest Myths by khim Parent article: Poettering: The Biggest Myths
the GPS daemon does have a socket that systemd understands, what are you suggesting? making a different socket for every possible location so that systemd can set dependencies on if that socket responds???
Just because systemd doesn't handle something doesn't mean that the something is worthless or stupid.
(Log in to post comments)
Poettering: The Biggest Myths Posted Feb 7, 2013 8:00 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
If systemd cannot handle something, is there a bug report? If not, why not?
Poettering: The Biggest Myths Posted Feb 7, 2013 8:39 UTC (Thu) by paulj (subscriber, #341) [Link]
There'll be no bug report on systemd because the applications involved are likely already using some other system. E.g. DBus IPC. DBus-daemon also can do "socket activation", and did before systemd existed I think.
Poettering: The Biggest Myths Posted Feb 7, 2013 12:33 UTC (Thu) by khim (subscriber, #9252) [Link] There'll be no bug report on systemd because the applications involved are likely already using some other system. E.g. DBus IPC. If it used DBus IPC then it can be easily be used with systemd thus error report will be entirely unnecessary. I've said "convert it to signals systemd understands" and not "convert it to socket activation" exactly for this reason: because systemd handles many different activation requests and makes sure they don't conflict. Socket activation is just one of them (even if one of the most important ones).
Poettering: The Biggest Myths Posted Feb 7, 2013 17:02 UTC (Thu) by paulj (subscriber, #341) [Link]
Interesting, thanks. :)
Bit of a dance, to have the IPC nexus hand-off this activation. It feels like really these should be part of one thing...
Poettering: The Biggest Myths Posted Feb 7, 2013 8:25 UTC (Thu) by anselm (subscriber, #2796) [Link] The GPS daemon provides the current location on a socket. It is probably unreasonable to expect systemd to be able to deal with that sort of information directly (systemd detractors would immediately jump on features such as these and call them out as »bloat«, with some justification). Hence, a reasonable way of handling this would be to write a (not very complicated) subsidiary daemon that listened to the GPS daemon's output and triggered various systemd actions based on them. This might be a good idea in any case in order to provide »smoothing« of the location data or additional rules (»tell me about bars in the vicinity but only during happy hour«). This daemon itself would of course be managed by systemd. This approach should also please the Unix traditionalists who insist that programs should »do one job and do it well«.
|
|||||||||||||