In my experience programming problems come with time to resolve them. Asking a programming question and getting an answer the next day (Thanks guys!) is very useful indeed as the millions of Stackoverflow users have no doubt noticed.

But it occurred to me that hardware and system configuration problems are usually very serialised, i.e. until the problem is solved, nothing else can proceed. I cannot imagine for most server problems I know having a day to wait for a solution. This is obviously not Serverfault's fault.

I wonder how this will turn out. Maybe I am totally wrong.

  • 2
    The only programming issues I have tend to be of the "nothing else can proceed" variety too... May 20, 2009 at 15:17

11 Answers 11


The end hope is that the question is already asked on both sites and when you google for your problem SF or SO simply are the top returned item with an answer.

The user interaction helps build to that end goal.

  • +1 for this observation.
    – tomjedrz
    May 20, 2009 at 15:19
  • Good point. Often I don't even have to ask my question because it's already been asked and answered.
    – Matt
    May 20, 2009 at 15:28
  • I also think that most system administration problems aren't the "omg must fix NOW" type. Many are "what is a better way to do this" type things. Kind of like bug fixes.
    – sclarson
    May 20, 2009 at 15:40

I think response times will improve as the number of users grows. Lots of questions on SO get answers in minutes I've gotten good answers in very much less than a day. In fact, quick answers can even be seen as a bit of a problem; see: the fastest gun in the west problem.


Well, right now this is on private beta soon to go to public beta, and at some point official production. For the looks of this private beta, I have to say the response is pretty good.

As far as hardware/software configuration problems, yes it's most of the time more specific, but I think most of the time we're not really looking for the solution, but guidance as to what else to try. Even talking/writing about the problem serves as a helpful trouble-finding tool as you tend to ask yourself the questions you might expect from IT admins here.

Basically, it will be up to admins here how usable serverfault will be FOR THEM AND FOR OTHERS. The procedures for troubleshooting will be up to each one of us to decide (here's mine):

  1. Find problem, get stuck
  2. Search ServerFault for archived issues related to yours
  3. Post question
  4. Keep researching (while updating question page for answers)
  5. However you find the answer, post it on ServerFault and award the answer (or award someone else's answer).

Pretty much keep a knowledge base of questions<>answers for others to search in the future. At some point maybe people will find the ServerFault database more useful than asking questions... and that's not such a bad thing.

  • Pretty much exactly what I'd say. The answer is instantaneous if it's already there. If not, you get the answer later and it is instantaneous for the next person to ask.
    – GreenKiwi
    May 20, 2009 at 17:07

Not all questions here are "immediate fix" issues. There are plenty of people asking about network design, server configs, router setups, security auditing etc etc. These sorts of questions can take a few days to get good answers.


Even for the ones that are in need of immediate fixes, there's nothing to say that you can't drop a question in here while still pursuing your other research avenues and check back to see if someone who knows the stuff you're stumped with in their sleep has solved it for you.

I'm in a low-sysadmin phase right now working mostly on development, but when my sysadmin duties pick back up I can see Server Fault being very useful.

  • Yes, I realise that and I agree. I was just thinking about the typical problems I myself run into (I am a 70% system engineer/30% developer according to my job description) tend to be can-work-on-it-for-a-day programming problems and must-be-fixed-immediately system configuration problems. That said the only (real) question I posted here so far is a can-work-on-it-for-a-days system configuration problem. May 20, 2009 at 15:32

As others have said, response time is sure to pick up when the site goes out of beta; if anything, the number of people with IT questions at any given time will probably dwarf the number of people with programming questions, so we're likely to see even more quick answers here on balance.

The other half of the "useful" equation, though, is that Server Fault is sure to have a lot more questions that are simply unanswerable. The hairiest IT questions, in my experience, are the ones that don't have one simple answer because they apply only to a very specific scenario with dependencies that even an expert couldn't possibly fully understand. Answering a question like "Why do I get an error when I call foo() with these parameters?" is likely to be a snap next to understanding that WinWTF 2.0 crashes 7 seconds after you launch it on alternate Thursdays because a transitory disk error eight months ago corrupted one of 200 DLLs in a library called by another library called by WinWTF if you're running it on 64-bit Windows Server 2008 in Hyper-V mode on an AMD platform, etc.


In my experience programming problems come with time to resolve them.

My experience shows that most programmers want and answer now just like most system administrators.

I've had very, very good response on both stackoverflow (less than 5 minutes usually) and here on serverfault (less than 30 minutes usually). Serverfault is slower as it's still in beta, but once it's open, it should pick up significantly.

If you aren't getting quick responses on either system, you may need to evaluate whether your question is easily understood and accessible. There are some questions that just have no good answer, or are esoteric or niche enough that it'll take some time to answer, but for the vast majority of day-to-day problems, answers usually come quickly.



Many sysadmins are in a situation where they have a helpdesk filled with issues, which, according to the users, are all critical. ServerFault enables them to ask a question and still make forward progress on it (as other people may answer it) while they work on the dozens of other pressing issues.


Not every problems need to be fixed the next minute. Some problems might be for future changes. Or someone might have a temporary fix and try to find a better solution by asking a question here.

Also, on stackoverflow the questions gets answered pretty fast sometimes. When serverfault is not in beta anymore the answers might start getting answered in minutes. Or better yet, the question might already have been answered.


I want to expand on sparks answer.

One of the goals expressed by Jeff/Joel for StackOverflow is that it become a repository for existing knowledge. As they have said on the podcast, Google is the front page for these sites. If you need an answer now, hopefully SF or SO will have it. It doesn't need to be immediately responsive to new questions in order to be successful.

If something is broken, needs to be fixed right now, and there isn't a useful answer on SF, I would post the question, but I would also engage other support resources. Certainly, there are responsive folks paying attention, but one can't count on the best (or correct) answer popping up immediately. The idea is that the best answer will bubble to the top of the list through editing, comments and voting.

SF is not intended to be a substitute for proper support mechanisms on key systems! My expectation is that it will become a useful tool in our arsenal, but not the only tool.


A separate issue about relative value of StackOverflow vs. ServerFault: How quickly does the underlying technology mutate, such that yesterday's correct, best-in-class answer is no longer a correct answer at all? I'd argue that programming probably has a longer 'tail': languages are by design backwards compatible: yesterdays answer will still work, even if it's not the best.

Admin solutions tend to age more quickly: once a particular class of hardware is end-of-lifed, or software has had a major rev., how to deal with its quirks of configuration is of little or no help to the next generation. And the admin interfaces to software tend to be the least designed, most user-unfriendly part of the system.

You must log in to answer this question.

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