3

I ran across a question today with the following close reason:

Questions should demonstrate reasonable business information technology management practices. Questions that relate to unsupported hardware or software platforms or unmaintained environments may not be suitable for Server Fault

With the particular question I was looking at, I think it was more about "reasonable" practices (and I will try to keep my opinions to myself on that point), but it got me thinking: What is the rational for not allowing questions about unsupported platforms? It's been my experience that a big part of being an IT professional is dealing with old stuff. ServerFault has helped me a time or two when some content locked behind a sevice contract seemingly vanished from the internet. Additionally, it seems like this policy would be a problem for existing questions whenever a platform reaches end-of-life or a company goes out of business.

3 Answers 3

5

As it happens, the Stack Enterprise solution you can buy for your company includes a "content health" close-queue specifically to capture this aging concept.

But this is not Stack Enterprise, this is ServerFault. As with every close-queue, you need a few people to pick that reason for it to be closed and not everyone sees the questions the same way. One reason that text is there is because it isn't 'best practices' to be running out of support hardware/software in the production systems that ServerFault is for. If enough people think that a specific question isn't on the right side of 'best practices', this close reason is useful.

Is this wibbly wobbly? Yep. We've had a few discussions about older stuff, and the sorts of lab-testing and self-improvement work we all do to trial things before going into production

Unfortunately, this is one of the "smell" close-reasons.

3
  1. Security. Orphaned products and platforms do not receive security updates, which results in vulnerabilities that cannot be fixed.

  2. Support. Although it should be obvious, few people like systems that there is no support for and no-one knows anything about anything. Wandering the countryside knocking on doors asking for help is not a good long term IT support strategy.

  3. Support-ability. If a product's vendor does not support a product, it is unlikely that another vendor can provide support, although this area is rife with fraudulent claims of such, but they really just end up in forums like the other guy roaming the countryside. Another example are products that are problematic, and do not have credible formal support from the vendor/creator. Shopping around flaky/problematic products that originate from vendors that are not engaged and not interested in resolution and proper support are unwelcome.

  4. Reliability. The failure rate of hardware increases over time. That's bad.

  5. The policy does not apply to existing answered questions, although there is nothing wrong with closing old unanswered questions for products and platforms that are end of life.

If someone finds themselves dealing with a lot of products and platforms that are end of life, that is a red flag that there is insufficient funding and planning, a definition that is synonymous with suck. Most people prefer to work in environments where there is sufficient funding and planning.

2

What is the rationale for not allowing questions about unsupported platforms? It's been my experience that a big part of being an IT professional is dealing with old stuff.

In general each question gets reviewed by the community and when they consider a question unsuitable they can vote to have it closed or migrated to a different community. There are a number of generic closure reasons found on all sites powered by the SE platform and the code-base allows some to be tailored to a specific site. (Additionally people can provide a custom reason for the vote-to-close but doesn't happen very often).

The closure reason:

Questions should demonstrate reasonable information technology management practices. Questions that relate to unsupported hardware or software platforms or unmaintained environments may not be suitable for Server Fault.

is one of the limited number of custom reasons specific for ServerFault.

That close reason does not exist for the genuine IT professional that for whatever reasons has to continue to support a legacy environment or is in the progress of migrating away from such legacy platform.

Such questions are often on-topic and when it's a good question people won't (or shouldn't) vote to close on them.

It is also does NOT constitute a blanket ban on questions about legacy environments. See this poll from a couple of years ago.

But there is range of questions that are in the category: as professional you really shouldn't be doing with a legacy environment what you're asking support for. And we, as a community by and for IT professionals, are not your safety net and won't be spending time and effort in supporting you in this (anymore).


Some recurring examples of things I consider as something I won't be providing support for on ServerFault because they're legacy:

  • Migration from a legacy OS to a release that is already EOL.

    IMHO Why even attempt such a migration when the effort will essentially soon be wasted anyway and you could and should skip a release (or two) and go directly to a current one with many years of future support instead?
    Second: everybody who did such a migration, they did so many years ago and whatever knowledge and experience they have, it won't be on top of their minds any more and their resources will most like also be gone.

  • People asking where to find/install "the latest" security updates for their EOL OS/application. (mirrors have been closed down and/or the regular update mechanism doesn't work anymore).

    IMHO people who ask that often already neglected to do updates in the many years before their system actually went EOL and are fooling themselves if they think that finally addressing those years of neglect and applying updates now achieves the result of making their systems current and secure. At the end of the day their system will be slightly less out-of-date but still very much EOL and will still be vulnerable to all vulnerabilities discovered after the EOL date.

  • Sometimes it is hard to discern if a question comes from the IT professional that can't let go of enterprise hardware that was really expensive and cool, back in the day when it came out, or the hobbyist that went dumpster diving. (Or they are one and the same.) But whatever problem they're asking about isn't about keeping that legacy equipment running, but rather a resurrection attempt pushing it towards a hobby project IMHO. (For example : this question )

  • When people are completely unprepared for the fact that their environment has reached EOL and often enough already did so years ago. You made your made bed, now lie in it.

    Legacy does not crop up overnight, in a professional environment your projects know that they will need to continue supporting their environment beyond the vendor supported life time and have been planning ahead. They have spare parts and/or old systems that can cannibalised for spares, they isolate the application to minimise exposure. They are prepared for disaster recovery etc.

You must log in to answer this question.

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