5 ms·
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 yo
by 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 agoYou're probably being downvoted because your opening 'graph kinda sounds mean. shrug (Not that I read it that way, but one could.)
- 2trill2spill 11y agoI'm sorry my question made you so upset, but I have seen several comments by you asserting nosh is superior to launchd, and that the NextBSD project is misguided, yet I haven't really seen much specifics, on those assertions. So I thought that because you would wrote... > nosh is, by far, the single most masterfully architected and carefully researched toolkit for init, process management, supervision (also with auxiliary utilities for user mode VTs and UCSPI) out there at present, trailing only with s6. The FreeBSD community will do itself a great favor by adopting it over the NextBSD experiment. You would have specific examples of nosh being a better init system than launchd. I would also add that you didn't really address my question, you explained some deficiencies of launchd, but didn't explain how nosh address's those issues or how it avoids them. Finally If you really wan't to advocate for nosh over launchd your best off not writing sentences like... > 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. If nosh really is an improvement on launchd great! But petty verbal attacks are no way to get the FreeBSD community to adopt nosh.
- vezzy-fnord 11y agoI would also add that you didn't really address my question, you explained some deficiencies of launchd, but didn't explain how nosh address's those issues or how it avoids them. Those deficiencies are all intrinsic to launchd's architecture specifically, and not intrinsic to the problem domain. As such, simply not being launchd is sufficient to avoid them. If nosh really is an improvement on launchd great! But petty verbal attacks are no way to get the FreeBSD community to adopt nosh. There are no petty verbal attacks anywhere. That your question was noncognitivistic is I think not of dispute, but even if it is, it's still not a "petty verbal attack" that was leveled, but a methodological criticism. Instead, you're ignoring all of the flaws I listed in favor of a red herring dismissal by focusing on my criticism of your question. Not everything revolves around your feelings.
- 2trill2spill 11y ago> Instead, you're ignoring all of the flaws I listed in favor of a red herring dismissal by focusing on my criticism of your question. Not everything revolves around your feelings. I'm not ignoring the issue you have pointed out, rather It would be nice to hear about nosh. There's significantly more information about launchd than nosh, for example launchd has two videos, explaining the reasoning and methodology for bringing in launchd and the other apple libraries. FreeBSD next 10 years: https://www.youtube.com/watch?v=Mri66Uz6-8Y https://www.youtube.com/watch?v=Mri66Uz6-8Y NextBSD intro: https://www.youtube.com/watch?v=49sPYHh473U https://www.youtube.com/watch?v=49sPYHh473U A quick search on google and their are no videos about nosh. The nosh website doesn't contain much information about the design of nosh. Looking around the source of nosh the various html files look promising and i'm going through those. Unfortunately my c++ skills are inadequate to judge the code quality of nosh effectively. Which on a side note I think will hurt nosh chances of being adopted, because the open source os world seems biased to using C. I't just harder to find stuff out about nosh and you seemed knowledgeable on the subject, hence the original question. So is there any good documentation on nosh besides the source it's self?
- Camillo 11y agoDude. You opened with: > nosh is, by far, the single most masterfully architected and carefully researched toolkit for init, process management, supervision (also with auxiliary utilities for user mode VTs and UCSPI) out there at present, trailing only with s6. The FreeBSD community will do itself a great favor by adopting it over the NextBSD experiment. Isn't your statement cognitively devoid of meaning without giving a frame of reference, methodology, heuristic or other a priori anchor to give a reasonable comparison between multiple software architectures? If it isn't, shouldn't basic human courtesy and common sense lead you to assume that 2trill2spill's question should be interpreted in whatever frame of reference etc. you were using when making your initial claim of nosh's superiority over all other options? I can't believe people are not downvoting you. Everyone should be downvoting you for the uncharitable, rude, and hypocritical way you are approaching this discussion, regardless of any technical points.
- nkurz 11y agoOdd that I'm being downvoted for specific technical points. No, I presume you are being downvoted for your apparent rudeness despite your excellent technical points. For me, the two cancelled, and I simply chose not to upvote an otherwise excellent post. I like your wit, but sometimes it's a bit sharp. Others apparently felt the rudeness was the dominant factor, and (as is their right) downvoted.