12

Do nothing This is not a problem; it is fine how it is. Any confusion caused is far too minor to require any action. Any possible gain is too small to be worth the effort.


9

Small amounts of certain types of programming are reasonably within the scope of what a system administrator does. Uncontroversially, writing a shell script to start a daemon, check if its running, and stop it is within scope (i.e., an init script). So is a shell scripting to automate system administration tasks, configure the environment for users (e.g., ...


7

In https://unix.stackexchange.com/questions/125744/mounting-a-file-system-using-a-c-program, what makes the question off-topic is “How do I write a C program”. In the previous discussion, I wrote (in an answer that seems consensual: no downvotes, no opposing views in comments or other answers) that the system interfaces (system calls and certain C library ...


7

Having looked at this question, it is pretty clearly about Unix system programming, which is in C by definition, but which comprises a small subset of C programming. This belongs on a Unix site if anything does, in my opinion. I'd suggest adding a clarification/exception to the no programming rule, that Unix system programming is in scope. I agree with @...


5

Make this clearer Use the phrases "operating system" or "kernel" where necessary to avoid ambiguity.


4

"Linux is the name of a kernel, isn't it?", new users could think. No, because new users think that Linux is an operating system. Only a very few people who already know about the topic are aware that there's a kernel called Linux. And even if someone did know about the Linux kernel, the sentence is explicitly about operating systems, therefore there is no ...


4

Why should we have a specific close reason for this? Ok, that's the suggestion on Meta Stack Exchange. But I disagree, because this is not a site-specific policy, it's a general thing everywhere on Stack Exchange that tutorial requests don't work. While none of the built-in close reasons are a perfect fit, I go with “too broad” or “primarily opinion-based” ...


2

I don't know where you've seen these "wrong" examples. The basic rule is that one is italic and two is bold: _italic1_ and *italic2* : italic1 and italic2 __bold1__ and **bold2** : bold1 and bold2 Finally, three means italic and bold: ***italic & bold*** and ___italic & bold___ : italic & bold and italic & bold That's exactly what is ...


2

In the 90s I would go over all of the package descriptions after an update of my SuSE linux, mark anything that seemed useful and read more about that, and tried to keep an overview. I gave up on that, but when looking for alternatives to a specific command, mostly use the projects web page (good projects don't fear to mention potential competition), or ...


2

This sentence has now been added to the on-topic help page. I don't think a specific close reason is needed, too broad should serve fine. Please note that requests for learning materials (tutorials, how-tos etc.) are off topic. The only exception is questions about where to find official documentation (e.g. POSIX specifications).


Only top voted, non community-wiki answers of a minimum length are eligible