public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Warren Young <wyml@etr-usa.com>
To: The Cygwin Mailing List <cygwin@cygwin.com>
Subject: Re: Windows XP Support
Date: Mon, 11 Jan 2016 19:25:00 -0000	[thread overview]
Message-ID: <2602B7D3-FD9E-489E-B5FD-1694469B966F@etr-usa.com> (raw)
In-Reply-To: <5692EEA8.4000703@gmail.com>

On Jan 10, 2016, at 4:52 PM, Juan Miguel Navarro Martínez <juanmi.3000@gmail.com> wrote:
> 
> No software version can live forever

Indeed, not even Linux.

There’s a thread over on the CentOS mailing list right now started by someone who’s trying to get something working on CentOS 3, which is about three years younger than Windows XP, but which dropped out of support in 2010.  The answer is the same: no one’s going to help you, and if it breaks, you get to keep the pieces.

And CentOS (RHEL, really) is the longest-supported open source Linux OS distro available.  SLES matches it, but there is no open source rebuild like CentOS is to RHEL; openSUSE only has a 3- or 4-year support cycle for its Evergreen releases.

Theoretically, some group of motivated developers could fork CentOS 3 and continue to maintain it indefinitely, but I haven’t seen the idea suggested on the mailing list.

My point is that even when the sources are freely available, it’s practically impossible to get developers to support ancient code.  There has to be a motivation, which is the support contract length in the case of the LTS Linuxes.  Once that runs out, the software developers are retasked.

The same is true over in Redmond.  The only difference is that there isn’t an open source version of Windows, so we can only speculate whether a sufficiently strong developer community could form around it to support it past the EOL date.

I suspect that’s the real reason Microsoft refuses to open source Windows: they’re worried that such a maintenance effort could form.  If there were a community-supported version of Windows XP, they’d have an even harder time getting people to adopt modern versions of Windows.  It would effectively fork the Windows platform.

Bottom line: it’s long past time to get off XP.  The Cygwin developers should not be expected to expend any additional effort to maintain XP compatibility.

> Linux Kernel LTS support is 2-3 years, for Debian is 1 year after
> release of next stable version, Ubuntu is 5 years and 9 months for STS
> and both LinuxMint and Trisquel 5 years as well.

RHEL/CentOS and SLES both have 10 year support cycles.

> At least Windows XP got 13 years of support and since Windows Vista its
> 10 years.

XP support was supposed to run for 10 years, too, but got pushed back twice due to customer base foot-dragging, IIRC.

Windows 8.1 extended support is scheduled to run for 10 years.  If you want to add in 8.0, that comes to 11.

Windows 10 is also scheduled for 10 years of extended support.

You can’t hold back the tide.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  parent reply	other threads:[~2016-01-11 17:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-10 17:43 Herbert Stocker
2016-01-10 23:52 ` Terry McCarty - WA5NTI
2016-01-11  2:05   ` Juan Miguel Navarro Martínez
2016-01-11 17:20     ` Erik Soderquist
2016-01-11 21:31       ` cyg Simple
2016-01-11 22:44         ` Erik Soderquist
2016-01-12  4:25           ` Peter A. Castro
2016-01-11 19:25     ` Warren Young [this message]
2016-01-12  9:28       ` Andrey Repin
2016-01-11  3:54   ` Mike Brown
2016-01-11 14:39 ` Corinna Vinschen
2016-01-11 15:41   ` wilson
2016-01-11 17:46     ` Erik Soderquist
2016-01-11 18:31       ` Jon Beniston
2016-01-11 17:05   ` Warren Young
2016-01-11 19:59     ` Corinna Vinschen
2016-01-11 17:08 ` Warren Young

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2602B7D3-FD9E-489E-B5FD-1694469B966F@etr-usa.com \
    --to=wyml@etr-usa.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).