-11

Imagine a world in which J, an IT administrator, manages the computing cluster for a handful of labs at a major research university in the United States.

Now imagine that a scientist in one of these labs has done something stupid: He's attempted to install glibc to his user account, the installation has failed, and his user account has gotten all screwed up.

J has restored functionality to the user account, but the broken installation remains in the user's home directory. Now he needs to remove it.

The question arises, What files are included in glibc? Of the files in ~/bin, ~/etc, ~/include, and ~/lib, which does the user need to remove? The answer isn't obvious to J or to the idiot scientist.

So the scientist comes to serverfault and asks this question.

He gets told the question is off-topic because

1) He isn't J.

2) He screwed up when he tried to install glibc.

The scientist responds,

1) So if J asked this question, it would be on-topic?

2) Duh, that's why I need help.

He is told,

1) J would never ask this question.

2) I'm sick of you and I don't want to debate this so why don't you go over to meta.

So he comes to meta. And his question is, What if J did ask this question?

8
  • 7
    J wouldn't bother mucking around, but rather would just restore the user's home directory from the most recent known-good backup.
    – EEAA
    Oct 12, 2015 at 4:04
  • @EEAA i just emailed J about how to remove the broken installation. i'll post an update here when she responds. but rather than try to guess what J would or wouldn't do, why not just give that as an answer to my question: i.e., Q: how do i remove glibc? A: don't bother. just restore the most recent known-good backup. then J might respond, "i can't, because . . ." or she might respond, "ah, yes, that worked."
    – abcd
    Oct 12, 2015 at 4:05
  • 1
    @EEAA i guess my broader point is this: i understand closing questions when they can't be answered or when the required answer is so long it wouldn't be feasible for anyone to write it out. but why close a question because answering it is too easy?
    – abcd
    Oct 12, 2015 at 4:14
  • Your question was not closed because it was too easy. Please don't put words in our mouths. We made it very clear why your question was closed.
    – EEAA
    Oct 12, 2015 at 4:15
  • @EEAA sorry, i should have said, "why close a question when answering it is so easy?" but i guess your answer would be that you (and the other members of this site) don't want to have to answer questions like this. and it is in part because they're too easy -- i.e., because they're so easy, a professional IT admin would never ask them.
    – abcd
    Oct 12, 2015 at 4:17
  • @EEAA this is comparable to people who ask ELL questions on the english site and people who ask basic math questions on mathoverflow (which is meant for professional mathematicians). as for those cases, there is at least one site for amateurs where the kind of question i want to ask can be asked.
    – abcd
    Oct 12, 2015 at 4:19
  • 1
    unix.stackexchange.com
    – EEAA
    Oct 12, 2015 at 4:20
  • 2
    @EEAA exactamente. or SO, or super user.
    – abcd
    Oct 12, 2015 at 4:22

3 Answers 3

7

We do not generally accept questions from end users because they generally do not have the skills, authority or permissions to carry out the necessary activity.

In this particular case you don't need the last two as, it's in your own home directory. This puts you very firmly in the end user category. Things that you do in your own home directory are not system administration and are, therefore not topical on Serverfault where we expect questions to be about

Managing systems in a business environment.

So, you were told your question was not topical because you are an end user - this is reasonable. You then constructed an elaborate scenario in an attempt to justify your position. That really doesn't work well here, clearly your system administrator didn't need to ask this question because ... they knew what to do and fixed your problem for you.

If some other sysadmin had asked this question they probably would have been told similar things to you.

  • Don't do that - glibc is not to be trifled with.
  • If you really need to do this do it in a test environment/virtual machine.
  • Use a clean environment so you can see what changes have been made etc.

You would hope though that a competent sysadmin wouldn't need to be told the above.

You are an end user. You made an end user mistake. Your question is not topical on Serverfault because it is an end user problem. You have been educated.

5
  • haha, a bit vainglorious (sorry, did i say a bit?), but yes, this is the answer. i have indeed been educated . . . about serverfault.com. everything in this answer had already been stated elsewhere, but this is the best summary of the relevant points.
    – abcd
    Oct 12, 2015 at 7:38
  • wait, on rereading, i realized you said, "your system administrator . . . knew what to do and fixed your problem for you." this is false. why do you think my system administrator fixed my problem for me? the answer i got came from SO -- and, for what it's worth, it was an answer that none of the sys admins here came up with (though the sys admins here did come up with answers that didn't work for me).
    – abcd
    Oct 12, 2015 at 7:40
  • @dbliss I think what Iain means is that Luckily, my system administrator was able to move my .bashrc -- which was pointing to the broken glibc under my home directory -- and revert me to a default .bashrc. So I can log into my account again and do stuff. that was your first and direct problem solved. The cleanup that followed was only that, cleanup.
    – Reaces
    Oct 12, 2015 at 7:44
  • 3
    @dbliss please remember your terminological inexactitude, believe it or not, we read stuff and remember it here. Your question clearly sates Luckily, my system administrator was able to move my .bashrc is that not true ?
    – user9517
    Oct 12, 2015 at 7:46
  • be careful with your vaingloriousness here, because you're risking looking like a fool. what my sys admin helped me with was not the problem i posted about on serverfault. as @Reaces points out, the sys admin helped with an initial problem, which led me to the cleanup, which is what i posted to serverfault about.
    – abcd
    Oct 12, 2015 at 8:07
7

What if J did ask this question?

It depends. If there was sufficient detail in the question on the system involved, perhaps it would get answered.

But honestly, and I'm not trying to be obtuse here, this is not a question that I would expect to get here from a competent admin. One of their users messed up their home directory. So restore it to a known-good state. No one but the system's owner knows exactly how things are set up on this system, and as such, the value of anyone else's answer would be questionable.

4
  • yeah, fair enough. i don't care too much to fight for this question here, as it does seem to be on-topic for a number of other SE sites. but i figured i'd fight for it a little.
    – abcd
    Oct 12, 2015 at 4:15
  • for what it's worth, restoring the system to a known-good state -- i.e., the most recent back-up -- is not a good solution in this case. back-ups are made once a day. there's a lot of work i did on the day when this problematic package was installed that i don't want to lose. but i think this underscores why this question doesn't work here. that is the sort of answer an IT admin would provide. and it's a bad one for this question.
    – abcd
    Oct 12, 2015 at 5:08
  • 3
    ...which gets us back to the system's owner knowing their system. In that case, they would nab a copy of your critical data and then restore to a known food state.
    – EEAA
    Oct 12, 2015 at 5:11
  • 2
    restoring the system to a known-good state ... is not a good solution in this case. - Why? The sysadmin could simply restore to a temporary location, and then compare directories. That would give you the same information you got from the find command in that stackoverflow answer you seemed to like.
    – Zoredache
    Oct 14, 2015 at 22:54
7

There is already a perfect place for a question about Unix/Linux that don't quite fit the Serverfault profile. That place is Unix/Linux. A question like this one should, if it's a good one, be migrated there. (If it's a bad one, i.e. one that doesn't fullfil the requirements of Unix/Linux it should be closed - we don't migrate junk.)

10
  • i asked this question here, on SO, on super user, and on unix/linux. it received a great answer on SO. so yeah, it was double-dipping to try to stick it here, and i agree with the decision to close/migrate. (at the time i was fighting for it, it hadn't yet been answered elsewhere.)
    – abcd
    Oct 12, 2015 at 6:30
  • 3
    Please do not post the same question on multiple sites. It is clearly against the rules of StackExchange. If I'd seen the question I would have closed it for that reason.
    – Jenny D
    Oct 12, 2015 at 6:31
  • i suppose responding to this would be more appropriate on yet another meta discussion, but . . . when it's unclear where a question belongs, posting to multiple sites is the most efficient way to find out. had i posted to just one site, i'd still be waiting for an answer. in fact, if the site i chose was other than SO, i might be waiting for an answer forever. i'm going to delete the versions of the question that haven't been answered. so, as far as i'm concerned (though i'm sure others will disagree), no harm, no foul.
    – abcd
    Oct 12, 2015 at 6:37
  • @dbliss There are mechanisms in place for moving good questions to places where they will likely get a good answer if they are not topical where you asked them. Posting to multiple sites just annoys people, the very people you want to help you. Please don't do it.
    – user9517
    Oct 12, 2015 at 6:40
  • 3
    You are effectively saying "I know the rules, but I will ignore them when it suits me". This is rude - which you may not consider "harm". It is also wasting people's time on multiple platforms - which is both rude and harmful. Again, please don't do that.
    – Jenny D
    Oct 12, 2015 at 6:41
  • @Iain agreed, but those mechanisms are slow. JennyD i guess in a highly indirect way i am being rude. but i think there is another perspective here. it would be nice if these rules were a perfect fit to reality, but of course rules never are. the reality is that different people patrol different SE sites, and many times questions are suitable for multiple SE sites. posting to multiple sites is the best way to get everyone who may have an answer to see your question as quickly as possible. but i see that there are situations in which that is annoying. so i probably won't do it anymore.
    – abcd
    Oct 12, 2015 at 6:45
  • @JennyD the best system, i think, would be to allow multi-posting, but have all the questions link to each other. but, again, this is probably a conversation that is best off held somewhere else. (what annoys me, by the way, is multi-posting on the same SE site, which i see fairly regularly.)
    – abcd
    Oct 12, 2015 at 6:48
  • @dbliss That conversation has already been asked and answered on Meta-SE - see meta.stackexchange.com/questions/64068/… Now would be a good time for you to stop digging your hole deeper.
    – Jenny D
    Oct 12, 2015 at 7:43
  • @JennyD indubitably it has -- indeed, i upvoted the accepted answer there who knows how long ago -- but if you look at the most up-voted comments there, you'll see that this issue is quite controversial. "stop digging your hole" -- why do you all have to be so adversarial? i asked a question. i got an answer. can we all just let this go?
    – abcd
    Oct 12, 2015 at 8:11
  • 8
    @dbliss Why? Probably because you're a) being rude, b) refusing to abide by site rules, c) accusing others of being self-centered for not being willing to spend their time handling your problems for you despite said problems being blatantly off-topic, and d) even after accepting one answer you are still arguing against it.
    – Jenny D
    Oct 12, 2015 at 8:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .