Prerequisites for Canonisable Questions / Scope of Ask Different

Question

Sparked by the question: What is coreduetd?

This got criticised for being: "it’s also a canonical question for one we want to close as “too broad” and “too wiki” - we don’t want to encourage questions that lack a practical question to be solved and we certainly don’t want to write a “macOS system internals” book one chapter a time and one daemon a time. I’ll refrain from closing from now - but there are fundamental problems with doing this systematically"

Compared to other canonical questions, like the whole section of

Daemons

• What is assistantd?
• What is "hidd"?
• What is nfsd on macOS?
• What is parsecd?
• What is "secd"?
• What is touristd?
• What is "usernoted" and why is it eating my CPU?

this policy seems to be in need of clarification.

Compared to What is on topic here? the question in question is about Apple software, and not matching the section of "refrain from asking".

Compared to "Don't ask" the question in question is "a practical, answerable question, based on actual problems", "I would like others to explain…". It is not like "What are all those daemons doing under the hood", that would indeed be too broad for one question.

And since actual official documentation on this and similar processes seems to be lacking, most of the points under "subjective questions" could also be applied.

The actual problems that will be solved by answering these kind of questions will be indirect but important: can one safely and reliably disable such daemons through the Apple way (GUI, defaults-write, launchctl, other command line tools provided by Apple), unofficial to unsupported means (like deleting essential files, using 3rd party programs), just blocking net access. Are there potential benefits or disadvantages, increased or decreased security, privacy implications.

Currently I think this is perfectly in scope, if the right balance is found. For this balance (=no complete book about sys-internals) I would suggest to define an "atomic level": "sub-atomic" would be that not every single file on a stock install shall have an entry, and "atomic threshold" that every daemon and any higher level process shall be named and explained (as a goal and thereby be on topic).

Currently I think this is tremendously useful to document, learn, educate, and enable users: to alert them to trouble, to calm the paranoid, and generally much more informed decision making.

I am mildly OK with a consensus that says "not for us", but if that is the case I would also like and hereby plead to have updated help center entries reflecting this with a much clearer definition.

In the meantime, what are the fundamental issues and difficulties of this approach?

Answer 1

It's an excellent question.

Some of the daemon questions are mine. And I answered also a few other daemon questions. For me it's fun to find out what a particular daemon's functions are and write a little bit about it.

Some self-answering questions were downvoted at the start. But people who see value in the Q&A will upvote it.

@bmike suggested to me to write a more general Q&A with information how someone can find information and do research on daemons and other internal processes. Which is also an excellent idea. Actually doing some research right now. That Q&A will come later this week or otherwise next week.

My personal thought on this matter is, it would be great if there where more high quality Q&A. Not only for closing questions as duplicates, but also to get more high quality content, which leads to more visitors through Google. (Let's hope people Google before asking questions.) Which, again, leads to more Ask Different users.