Skip to main content
edited body
Source Link
Tim
  • 103.2k
  • 14
  • 11

I generally agree with the following statement in the question.

  1. Programming questions about the standardized, unix-specific APIs. Especially about the posixPOSIX standard.
  2. Programming questions with deeply unix-specific object (especially kernel / libc hacking).
  3. Programming questions about the internal workings of unix-specific software (some examples: kernels, apache module internals).

There is actually no clear concensus on this issue, as you can see from the question Is the Unix C API still on-topic?, where derobert and myself spoke for (roughly speaking), and Gilles spoke against. And there does not appear to be a clear mechanism within Stack Exchange for clarifying scope. Such decisions would presumably be needed to be made by some kind of voting mechanism or by some hypothetical higher authority, and no such procedure exists.

There also seems to be a lot of hairsplitting/debate over whether a C question (for example) about the C API is really a question about C the programming language or really about the Unix C API. As you can see, I favor not worrying about this that much, and allowing questions which involve asking about the C API as long as the C API is an significant part of the question. I.e. the C API could not easily be substituted by something else in the question. A question which is really a C programming question, say where the question is how to include headers in a C file, and which involves Unix content only incidentally should be moved to Stack Overflow, I agree.

It is also true that there is a gray area here, but in case of doubt, I favor coming down more strongly on the side of inclusion vs the side of exclusion.

In practice it seems that such questions end up getting closed, but this is more a reflection of the fact that the people who don't like such questions close or migrate them, and the people who are fine with them don't vote to reopen. I'm not sure why this is. Perhaps they don't want to have more arguments.

Please explain “kobject” is a recent question, for example, that I consider to be on-topic here. However, others apparently disagree. This is, in your words, a "deeply Unix-specific" question. It's not a good question, but that's a separate issue.

I also agree with your view that Unix system stuff should be an important part of a Unix site like this one. Specifically, when you write

Most of the questions request for help in some awk/sed/sh scripting or some similarly trivial task for a power user. Answering them is an easy way to collect reputation, but doesn't attract highly qualified visitors. For example, a developer of kernel drivers won't be here too long, because the topics which are interesting here for him, would be closed or migrated to the StackOverflow.

To some extent I think this also reflects the fact that the current membership is interested in things like shell programming, which is considered to be more of general interest, while Unix programming type stuff is considered to be of marginal/minority interest. It's true that we (probably) would not want to be overrun by the Linux Kernel mailing list, but I doubt that is an issue,any more than being overrun by Debian development mailing lists.

(Answering late, because I just saw this question - nobody pointed me to it.)

I generally agree with the following statement in the question.

  1. Programming questions about the standardized, unix-specific APIs. Especially about the posix standard.
  2. Programming questions with deeply unix-specific object (especially kernel / libc hacking).
  3. Programming questions about the internal workings of unix-specific software (some examples: kernels, apache module internals).

There is actually no clear concensus on this issue, as you can see from the question Is the Unix C API still on-topic?, where derobert and myself spoke for (roughly speaking), and Gilles spoke against. And there does not appear to be a clear mechanism within Stack Exchange for clarifying scope. Such decisions would presumably be needed to be made by some kind of voting mechanism or by some hypothetical higher authority, and no such procedure exists.

There also seems to be a lot of hairsplitting/debate over whether a C question (for example) about the C API is really a question about C the programming language or really about the Unix C API. As you can see, I favor not worrying about this that much, and allowing questions which involve asking about the C API as long as the C API is an significant part of the question. I.e. the C API could not easily be substituted by something else in the question. A question which is really a C programming question, say where the question is how to include headers in a C file, and which involves Unix content only incidentally should be moved to Stack Overflow, I agree.

It is also true that there is a gray area here, but in case of doubt, I favor coming down more strongly on the side of inclusion vs the side of exclusion.

In practice it seems that such questions end up getting closed, but this is more a reflection of the fact that the people who don't like such questions close or migrate them, and the people who are fine with them don't vote to reopen. I'm not sure why this is. Perhaps they don't want to have more arguments.

Please explain “kobject” is a recent question, for example, that I consider to be on-topic here. However, others apparently disagree. This is, in your words, a "deeply Unix-specific" question. It's not a good question, but that's a separate issue.

I also agree with your view that Unix system stuff should be an important part of a Unix site like this one. Specifically, when you write

Most of the questions request for help in some awk/sed/sh scripting or some similarly trivial task for a power user. Answering them is an easy way to collect reputation, but doesn't attract highly qualified visitors. For example, a developer of kernel drivers won't be here too long, because the topics which are interesting here for him, would be closed or migrated to the StackOverflow.

To some extent I think this also reflects the fact that the current membership is interested in things like shell programming, which is considered to be more of general interest, while Unix programming type stuff is considered to be of marginal/minority interest. It's true that we (probably) would not want to be overrun by the Linux Kernel mailing list, but I doubt that is an issue,any more than being overrun by Debian development mailing lists.

(Answering late, because I just saw this question - nobody pointed me to it.)

I generally agree with the following statement in the question.

  1. Programming questions about the standardized, unix-specific APIs. Especially about the POSIX standard.
  2. Programming questions with deeply unix-specific object (especially kernel / libc hacking).
  3. Programming questions about the internal workings of unix-specific software (some examples: kernels, apache module internals).

There is actually no clear concensus on this issue, as you can see from the question Is the Unix C API still on-topic?, where derobert and myself spoke for (roughly speaking), and Gilles spoke against. And there does not appear to be a clear mechanism within Stack Exchange for clarifying scope. Such decisions would presumably be needed to be made by some kind of voting mechanism or by some hypothetical higher authority, and no such procedure exists.

There also seems to be a lot of hairsplitting/debate over whether a C question (for example) about the C API is really a question about C the programming language or really about the Unix C API. As you can see, I favor not worrying about this that much, and allowing questions which involve asking about the C API as long as the C API is an significant part of the question. I.e. the C API could not easily be substituted by something else in the question. A question which is really a C programming question, say where the question is how to include headers in a C file, and which involves Unix content only incidentally should be moved to Stack Overflow, I agree.

It is also true that there is a gray area here, but in case of doubt, I favor coming down more strongly on the side of inclusion vs the side of exclusion.

In practice it seems that such questions end up getting closed, but this is more a reflection of the fact that the people who don't like such questions close or migrate them, and the people who are fine with them don't vote to reopen. I'm not sure why this is. Perhaps they don't want to have more arguments.

Please explain “kobject” is a recent question, for example, that I consider to be on-topic here. However, others apparently disagree. This is, in your words, a "deeply Unix-specific" question. It's not a good question, but that's a separate issue.

I also agree with your view that Unix system stuff should be an important part of a Unix site like this one. Specifically, when you write

Most of the questions request for help in some awk/sed/sh scripting or some similarly trivial task for a power user. Answering them is an easy way to collect reputation, but doesn't attract highly qualified visitors. For example, a developer of kernel drivers won't be here too long, because the topics which are interesting here for him, would be closed or migrated to the StackOverflow.

To some extent I think this also reflects the fact that the current membership is interested in things like shell programming, which is considered to be more of general interest, while Unix programming type stuff is considered to be of marginal/minority interest. It's true that we (probably) would not want to be overrun by the Linux Kernel mailing list, but I doubt that is an issue,any more than being overrun by Debian development mailing lists.

(Answering late, because I just saw this question - nobody pointed me to it.)

replaced http://meta.unix.stackexchange.com/ with https://unix.meta.stackexchange.com/
Source Link

I generally agree with the following statement in the question.

  1. Programming questions about the standardized, unix-specific APIs. Especially about the posix standard.
  2. Programming questions with deeply unix-specific object (especially kernel / libc hacking).
  3. Programming questions about the internal workings of unix-specific software (some examples: kernels, apache module internals).

There is actually no clear concensus on this issue, as you can see from the question Is the Unix C API still on-topic?Is the Unix C API still on-topic?, where derobert and myself spoke for (roughly speaking), and Gilles spoke against. And there does not appear to be a clear mechanism within Stack Exchange for clarifying scope. Such decisions would presumably be needed to be made by some kind of voting mechanism or by some hypothetical higher authority, and no such procedure exists.

There also seems to be a lot of hairsplitting/debate over whether a C question (for example) about the C API is really a question about C the programming language or really about the Unix C API. As you can see, I favor not worrying about this that much, and allowing questions which involve asking about the C API as long as the C API is an significant part of the question. I.e. the C API could not easily be substituted by something else in the question. A question which is really a C programming question, say where the question is how to include headers in a C file, and which involves Unix content only incidentally should be moved to Stack Overflow, I agree.

It is also true that there is a gray area here, but in case of doubt, I favor coming down more strongly on the side of inclusion vs the side of exclusion.

In practice it seems that such questions end up getting closed, but this is more a reflection of the fact that the people who don't like such questions close or migrate them, and the people who are fine with them don't vote to reopen. I'm not sure why this is. Perhaps they don't want to have more arguments.

Please explain “kobject” is a recent question, for example, that I consider to be on-topic here. However, others apparently disagree. This is, in your words, a "deeply Unix-specific" question. It's not a good question, but that's a separate issue.

I also agree with your view that Unix system stuff should be an important part of a Unix site like this one. Specifically, when you write

Most of the questions request for help in some awk/sed/sh scripting or some similarly trivial task for a power user. Answering them is an easy way to collect reputation, but doesn't attract highly qualified visitors. For example, a developer of kernel drivers won't be here too long, because the topics which are interesting here for him, would be closed or migrated to the StackOverflow.

To some extent I think this also reflects the fact that the current membership is interested in things like shell programming, which is considered to be more of general interest, while Unix programming type stuff is considered to be of marginal/minority interest. It's true that we (probably) would not want to be overrun by the Linux Kernel mailing list, but I doubt that is an issue,any more than being overrun by Debian development mailing lists.

(Answering late, because I just saw this question - nobody pointed me to it.)

I generally agree with the following statement in the question.

  1. Programming questions about the standardized, unix-specific APIs. Especially about the posix standard.
  2. Programming questions with deeply unix-specific object (especially kernel / libc hacking).
  3. Programming questions about the internal workings of unix-specific software (some examples: kernels, apache module internals).

There is actually no clear concensus on this issue, as you can see from the question Is the Unix C API still on-topic?, where derobert and myself spoke for (roughly speaking), and Gilles spoke against. And there does not appear to be a clear mechanism within Stack Exchange for clarifying scope. Such decisions would presumably be needed to be made by some kind of voting mechanism or by some hypothetical higher authority, and no such procedure exists.

There also seems to be a lot of hairsplitting/debate over whether a C question (for example) about the C API is really a question about C the programming language or really about the Unix C API. As you can see, I favor not worrying about this that much, and allowing questions which involve asking about the C API as long as the C API is an significant part of the question. I.e. the C API could not easily be substituted by something else in the question. A question which is really a C programming question, say where the question is how to include headers in a C file, and which involves Unix content only incidentally should be moved to Stack Overflow, I agree.

It is also true that there is a gray area here, but in case of doubt, I favor coming down more strongly on the side of inclusion vs the side of exclusion.

In practice it seems that such questions end up getting closed, but this is more a reflection of the fact that the people who don't like such questions close or migrate them, and the people who are fine with them don't vote to reopen. I'm not sure why this is. Perhaps they don't want to have more arguments.

Please explain “kobject” is a recent question, for example, that I consider to be on-topic here. However, others apparently disagree. This is, in your words, a "deeply Unix-specific" question. It's not a good question, but that's a separate issue.

I also agree with your view that Unix system stuff should be an important part of a Unix site like this one. Specifically, when you write

Most of the questions request for help in some awk/sed/sh scripting or some similarly trivial task for a power user. Answering them is an easy way to collect reputation, but doesn't attract highly qualified visitors. For example, a developer of kernel drivers won't be here too long, because the topics which are interesting here for him, would be closed or migrated to the StackOverflow.

To some extent I think this also reflects the fact that the current membership is interested in things like shell programming, which is considered to be more of general interest, while Unix programming type stuff is considered to be of marginal/minority interest. It's true that we (probably) would not want to be overrun by the Linux Kernel mailing list, but I doubt that is an issue,any more than being overrun by Debian development mailing lists.

(Answering late, because I just saw this question - nobody pointed me to it.)

I generally agree with the following statement in the question.

  1. Programming questions about the standardized, unix-specific APIs. Especially about the posix standard.
  2. Programming questions with deeply unix-specific object (especially kernel / libc hacking).
  3. Programming questions about the internal workings of unix-specific software (some examples: kernels, apache module internals).

There is actually no clear concensus on this issue, as you can see from the question Is the Unix C API still on-topic?, where derobert and myself spoke for (roughly speaking), and Gilles spoke against. And there does not appear to be a clear mechanism within Stack Exchange for clarifying scope. Such decisions would presumably be needed to be made by some kind of voting mechanism or by some hypothetical higher authority, and no such procedure exists.

There also seems to be a lot of hairsplitting/debate over whether a C question (for example) about the C API is really a question about C the programming language or really about the Unix C API. As you can see, I favor not worrying about this that much, and allowing questions which involve asking about the C API as long as the C API is an significant part of the question. I.e. the C API could not easily be substituted by something else in the question. A question which is really a C programming question, say where the question is how to include headers in a C file, and which involves Unix content only incidentally should be moved to Stack Overflow, I agree.

It is also true that there is a gray area here, but in case of doubt, I favor coming down more strongly on the side of inclusion vs the side of exclusion.

In practice it seems that such questions end up getting closed, but this is more a reflection of the fact that the people who don't like such questions close or migrate them, and the people who are fine with them don't vote to reopen. I'm not sure why this is. Perhaps they don't want to have more arguments.

Please explain “kobject” is a recent question, for example, that I consider to be on-topic here. However, others apparently disagree. This is, in your words, a "deeply Unix-specific" question. It's not a good question, but that's a separate issue.

I also agree with your view that Unix system stuff should be an important part of a Unix site like this one. Specifically, when you write

Most of the questions request for help in some awk/sed/sh scripting or some similarly trivial task for a power user. Answering them is an easy way to collect reputation, but doesn't attract highly qualified visitors. For example, a developer of kernel drivers won't be here too long, because the topics which are interesting here for him, would be closed or migrated to the StackOverflow.

To some extent I think this also reflects the fact that the current membership is interested in things like shell programming, which is considered to be more of general interest, while Unix programming type stuff is considered to be of marginal/minority interest. It's true that we (probably) would not want to be overrun by the Linux Kernel mailing list, but I doubt that is an issue,any more than being overrun by Debian development mailing lists.

(Answering late, because I just saw this question - nobody pointed me to it.)

added 186 characters in body
Source Link
Faheem Mitha
  • 35.4k
  • 20
  • 27

I generally agree with the following statement in the question.

  1. Programming questions about the standardized, unix-specific APIs. Especially about the posix standard.
  2. Programming questions with deeply unix-specific object (especially kernel / libc hacking).
  3. Programming questions about the internal workings of unix-specific software (some examples: kernels, apache module internals).

There is actually no clear concensus on this issue, as you can see from the question Is the Unix C API still on-topic?, where derobert and myself spoke for (roughly speaking), and Gilles spoke against. And there does not appear to be a clear mechanism within Stack Exchange for clarifying scope. Such decisions would presumably be needed to be made by some kind of voting mechanism or by some hypothetical higher authority, and no such procedure exists.

There also seems to be a lot of hairsplitting/debate over whether a C question (for example) about the C API is really a question about C the programming language or really about the Unix C API. As you can see, I favor not worrying about this that much, and allowing questions which involve asking about the C API as long as the C API is an significant part of the question. I.e. the C API could not easily be substituted by something else in the question. A question which is really a C programming question, say where the question is how to include headers in a C file, and which involves Unix content only incidentally should be moved to Stack Overflow, I agree.

It is also true that there is a gray area here, but in case of doubt, I favor coming down more strongly on the side of inclusion vs the side of exclusion.

In practice it seems that such questions end up getting closed, but this is more a reflection of the fact that the people who don't like such questions close or migrate them, and the people who are fine with them don't vote to reopen. I'm not sure why this is. Perhaps they don't want to have more arguments.

Please explain “kobject” is a recent question, for example, that I consider to be on-topic here. However, others apparently disagree. This is, in your words, a "deeply Unix-specific" question. It's not a good question, but that's a separate issue.

I also agree with your view that Unix system stuff should be an important part of a Unix site like this one. Specifically, when you write

Most of the questions request for help in some awk/sed/sh scripting or some similarly trivial task for a power user. Answering them is an easy way to collect reputation, but doesn't attract highly qualified visitors. For example, a developer of kernel drivers won't be here too long, because the topics which are interesting here for him, would be closed or migrated to the StackOverflow.

To some extent I think this also reflects the fact that the current membership is interested in things like shell programming, which is considered to be more of general interest, while Unix programming type stuff is considered to be of marginal/minority interest. It's true that we (probably) would not want to be overrun by the Linux Kernel mailing list, but I doubt that is an issue,any more than being overrun by Debian development mailing lists.

(Answering late, because I just saw this question - nobody pointed me to it.)

I generally agree with the following statement in the question.

  1. Programming questions about the standardized, unix-specific APIs. Especially about the posix standard.
  2. Programming questions with deeply unix-specific object (especially kernel / libc hacking).
  3. Programming questions about the internal workings of unix-specific software (some examples: kernels, apache module internals).

There is actually no clear concensus on this issue, as you can see from the question Is the Unix C API still on-topic?, where derobert and myself spoke for (roughly speaking), and Gilles spoke against. And there does not appear to be a clear mechanism within Stack Exchange for clarifying scope. Such decisions would presumably be needed to be made by some kind of voting mechanism or by some hypothetical higher authority, and no such procedure exists.

There also seems to be a lot of hairsplitting/debate over whether a C question (for example) about the C API is really a question about C the programming language or really about the Unix C API. As you can see, I favor not worrying about this that much, and allowing questions which involve asking about the C API as long as the C API is an significant part of the question. I.e. the C API could not easily be substituted by something else in the question. A question which is really a C programming question, say where the question is how to include headers in a C file, and which involves Unix content only incidentally should be moved to Stack Overflow, I agree.

It is also true that there is a gray area here, but in case of doubt, I favor coming down more strongly on the side of inclusion vs the side of exclusion.

In practice it seems that such questions end up getting closed, but this is more a reflection of the fact that the people who don't like such questions close or migrate them, and the people who are fine with them don't vote to reopen. I'm not sure why this is. Perhaps they don't want to have more arguments.

Please explain “kobject” is a recent question, for example, that I consider to be on-topic here. However, others apparently disagree. This is, in your words, a "deeply Unix-specific" question. It's not a good question, but that's a separate issue.

I also agree with your view that Unix system stuff should be an important part of a Unix site like this one. Specifically, when you write

Most of the questions request for help in some awk/sed/sh scripting or some similarly trivial task for a power user. Answering them is an easy way to collect reputation, but doesn't attract highly qualified visitors. For example, a developer of kernel drivers won't be here too long, because the topics which are interesting here for him, would be closed or migrated to the StackOverflow.

To some extent I think this also reflects the fact that the current membership is interested in things like shell programming, which is considered to be more of general interest, while Unix programming type stuff is considered to be of marginal/minority interest.

(Answering late, because I just saw this question - nobody pointed me to it.)

I generally agree with the following statement in the question.

  1. Programming questions about the standardized, unix-specific APIs. Especially about the posix standard.
  2. Programming questions with deeply unix-specific object (especially kernel / libc hacking).
  3. Programming questions about the internal workings of unix-specific software (some examples: kernels, apache module internals).

There is actually no clear concensus on this issue, as you can see from the question Is the Unix C API still on-topic?, where derobert and myself spoke for (roughly speaking), and Gilles spoke against. And there does not appear to be a clear mechanism within Stack Exchange for clarifying scope. Such decisions would presumably be needed to be made by some kind of voting mechanism or by some hypothetical higher authority, and no such procedure exists.

There also seems to be a lot of hairsplitting/debate over whether a C question (for example) about the C API is really a question about C the programming language or really about the Unix C API. As you can see, I favor not worrying about this that much, and allowing questions which involve asking about the C API as long as the C API is an significant part of the question. I.e. the C API could not easily be substituted by something else in the question. A question which is really a C programming question, say where the question is how to include headers in a C file, and which involves Unix content only incidentally should be moved to Stack Overflow, I agree.

It is also true that there is a gray area here, but in case of doubt, I favor coming down more strongly on the side of inclusion vs the side of exclusion.

In practice it seems that such questions end up getting closed, but this is more a reflection of the fact that the people who don't like such questions close or migrate them, and the people who are fine with them don't vote to reopen. I'm not sure why this is. Perhaps they don't want to have more arguments.

Please explain “kobject” is a recent question, for example, that I consider to be on-topic here. However, others apparently disagree. This is, in your words, a "deeply Unix-specific" question. It's not a good question, but that's a separate issue.

I also agree with your view that Unix system stuff should be an important part of a Unix site like this one. Specifically, when you write

Most of the questions request for help in some awk/sed/sh scripting or some similarly trivial task for a power user. Answering them is an easy way to collect reputation, but doesn't attract highly qualified visitors. For example, a developer of kernel drivers won't be here too long, because the topics which are interesting here for him, would be closed or migrated to the StackOverflow.

To some extent I think this also reflects the fact that the current membership is interested in things like shell programming, which is considered to be more of general interest, while Unix programming type stuff is considered to be of marginal/minority interest. It's true that we (probably) would not want to be overrun by the Linux Kernel mailing list, but I doubt that is an issue,any more than being overrun by Debian development mailing lists.

(Answering late, because I just saw this question - nobody pointed me to it.)

added 158 characters in body
Source Link
Faheem Mitha
  • 35.4k
  • 20
  • 27
Loading
Source Link
Faheem Mitha
  • 35.4k
  • 20
  • 27
Loading