4 ms·

Can you give examples of how nosh is superior to launchd?

simcop2387 11y ago
The nosh page has a bunch about that: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/launchd-on-bsd.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/lau... Largely, the author doesn't believe that launchd will ever successfully come to BSD. It's had a number of attempts, all of which either failed or fizzled out.
- feld 11y ago
  It's a hard requirement of the next FreeNAS/TrueNAS release. So it's going to exist in production on many machines. We need competition and I urge him to continue but this dismissive attitude is not healthy.
- 2trill2spill 11y ago
  I wouldn't call that a very compelling argument about why nosh is better than launchd. So what if previous attempts to port launchd failed when this port(NextBSD) appears to be working. So far I've seen several people on hacker news say that nosh is a better alternative to launchd, but I haven't seen any specifics, right now it just seems like politics.
  - simcop2387 11y ago
    Yea not saying I buy that argument either, the compatibility/conversion layers that exist for nosh could probably be built for launchd, so I wouldn't consider those significant advantages. I also wouldn't consider launchd being deployed on OSX that much of an advantage either given that it seems large parts had to be rebuilt to use the BSD kernel interfaces rather than the darwin ones. Maybe that it's already got configurations for a bunch of services for things from Homebrew/MacPorts/Fink, but they would still need to be reviewed for any broken paths and things from OSX that aren't on BSD.
vezzy-fnord 11y ago
Your question is cognitively devoid of meaning without giving a frame of reference, methodology, heuristic or other a priori anchor for me to be able to give you a reasonable comparison between two software architectures. Nonetheless, I can give you examples of where launchd is deficient in its own problem domain, and particularly for a BSD. It has non-generic socket preopening (unlike UCSPI), its service classes are daemons, agents, XPC and Mach services. The latter two are OS X-specific and bound to IPC mechanisms no less, which is an odd taxonomy. Furthermore, agents (per-user/session daemons) are subdivided into four session types: pre-login, per-user, GUI session and non-GUI session. GUI and pre-login session types are specific to OS X's Aqua and loginwindow, and an impedance mismatch anywhere else. Further, non-GUI session is related to how launchd starts sshd from a plist, which again is a rather odd taxonomy-related coupling. Further still, the process types (four of them) aren't used as information for what readiness protocol or startup discipline to use, but are tightly coupled to scheduling policies and resource limits! These four process types make sense only within the context of a desktop system where you want priority scheduling and resource accounting to keep system responsiveness as events queue up, but are meaningless in the generic case. Then, launchd strictly limits you to a lazy loading startup discipline and does not have any formal ordering or proper service relationships (other than KeepAlive, all options of which are either prone to race conditions or too narrowly defined) and instead relies on daemons to resolve relationships cooperatively via IPC with all the problems of cooperative/uncoordinated protocol negotiations. Fine for a cathedral like OS X, unworkable anywhere else. This on top of system and service state being intertwined in the same critical paths of PID 1. The whole thing is a mess of layering violations. Let's not ignore how the NextBSD developers had to break Mach thread and task semantics to port the API (as a kernel module, no less!) over to a monolithic Unix with which Mach does not properly overlap. Finally, a more minor cosmetic gripe is LaunchOnlyOnce being a key instead of a job type. It's an absolute catastrophe through and through. Awful design. EDIT: Odd that I'm being downvoted for specific technical points.
- simoncion 11y ago
  You're probably being downvoted because your opening 'graph kinda sounds mean. shrug (Not that I read it that way, but one could.)
- 11y ago

The nosh page has a bunch about that: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/launchd-on-bsd.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/lau... Largely, the author doesn't believe that launchd will ever successfully come to BSD. It's had a number of attempts, all of which either failed or fizzled out.

feld 11y ago
It's a hard requirement of the next FreeNAS/TrueNAS release. So it's going to exist in production on many machines. We need competition and I urge him to continue but this dismissive attitude is not healthy.
2trill2spill 11y ago
I wouldn't call that a very compelling argument about why nosh is better than launchd. So what if previous attempts to port launchd failed when this port(NextBSD) appears to be working. So far I've seen several people on hacker news say that nosh is a better alternative to launchd, but I haven't seen any specifics, right now it just seems like politics.
- simcop2387 11y ago
  Yea not saying I buy that argument either, the compatibility/conversion layers that exist for nosh could probably be built for launchd, so I wouldn't consider those significant advantages. I also wouldn't consider launchd being deployed on OSX that much of an advantage either given that it seems large parts had to be rebuilt to use the BSD kernel interfaces rather than the darwin ones. Maybe that it's already got configurations for a bunch of services for things from Homebrew/MacPorts/Fink, but they would still need to be reviewed for any broken paths and things from OSX that aren't on BSD.

vezzy-fnord 11y ago

Your question is cognitively devoid of meaning without giving a frame of reference, methodology, heuristic or other a priori anchor for me to be able to give you a reasonable comparison between two software architectures. Nonetheless, I can give you examples of where launchd is deficient in its own problem domain, and particularly for a BSD. It has non-generic socket preopening (unlike UCSPI), its service classes are daemons, agents, XPC and Mach services. The latter two are OS X-specific and bound to IPC mechanisms no less, which is an odd taxonomy. Furthermore, agents (per-user/session daemons) are subdivided into four session types: pre-login, per-user, GUI session and non-GUI session. GUI and pre-login session types are specific to OS X's Aqua and loginwindow, and an impedance mismatch anywhere else. Further, non-GUI session is related to how launchd starts sshd from a plist, which again is a rather odd taxonomy-related coupling. Further still, the process types (four of them) aren't used as information for what readiness protocol or startup discipline to use, but are tightly coupled to scheduling policies and resource limits! These four process types make sense only within the context of a desktop system where you want priority scheduling and resource accounting to keep system responsiveness as events queue up, but are meaningless in the generic case. Then, launchd strictly limits you to a lazy loading startup discipline and does not have any formal ordering or proper service relationships (other than KeepAlive, all options of which are either prone to race conditions or too narrowly defined) and instead relies on daemons to resolve relationships cooperatively via IPC with all the problems of cooperative/uncoordinated protocol negotiations. Fine for a cathedral like OS X, unworkable anywhere else. This on top of system and service state being intertwined in the same critical paths of PID 1. The whole thing is a mess of layering violations. Let's not ignore how the NextBSD developers had to break Mach thread and task semantics to port the API (as a kernel module, no less!) over to a monolithic Unix with which Mach does not properly overlap. Finally, a more minor cosmetic gripe is LaunchOnlyOnce being a key instead of a job type. It's an absolute catastrophe through and through. Awful design. EDIT: Odd that I'm being downvoted for specific technical points.

simoncion 11y ago
You're probably being downvoted because your opening 'graph kinda sounds mean. shrug (Not that I read it that way, but one could.)
11y ago