All of lore.kernel.org
 help / color / mirror / Atom feed
From: <samuel.progin@gmail.com>
To: <wireguard@lists.zx2c4.com>
Subject: RE: Should we sunset Windows 7 support?
Date: Tue, 10 Nov 2020 13:56:06 +0100	[thread overview]
Message-ID: <00fa01d6b760$da95c480$8fc14d80$@gmail.com> (raw)
In-Reply-To: <20201110134743.1615fcf4@frign.de>

Dear all,

FWIW, Microsoft sells extended support (Windows 7 ESU) to corporate
customers using Pro or Enterprise editions. It can be extended until Jan
10th 2023.

https://docs.microsoft.com/en-us/troubleshoot/windows-client/windows-7-eos-f
aq/windows-7-extended-security-updates-faq

Kind regards.

Samuel

-----Original Message-----
From: WireGuard <wireguard-bounces@lists.zx2c4.com> On Behalf Of Laslo
Hunhold
Sent: mardi, 10 novembre 2020 13:48
To: wireguard@lists.zx2c4.com
Subject: Re: Should we sunset Windows 7 support?

On Tue, 10 Nov 2020 13:27:20 +0100
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

Dear Jason,

> Windows 7 has been EOL'd by Microsoft since January of this year. It
> is no longer receiving security updates or fixes. This email is to get
> the conversation started about doing the same with WireGuard for
> Windows.
> [...] Do we really want to keep maintaining gross stuff like this? It
> makes me uncomfortable to have kludges like that sitting around in the
> code. Shouldn't I write an auto-downloader that then checks hashes?
> Shouldn't I build this into the installer? Shouldn't I....
> waste tons of time supporting Windows 7 better?
>
> Probably not.
>
> But I know so many users are still using Windows 7. I'd like to hear
> from you to understand why, in order to assess when is the right
> moment to sunset our Windows 7 support.
>
> So, if you care for Windows 7, please pipe up! We're not going to
> remove support for it overnight, and we're not prepared yet to
> announce any sort of formal deprecation plan, but the world is moving
> on at some point.

this is a really difficult judgement to make, which comes up every time
Microsoft EOLs an operating system, because it really often is still heavily
used.

My stance is that we as open source developers don't owe anybody anything,
and if Windows 7 users really care about WireGuard they can create, share
and maintain a patchset that implements the fixes themselves. You shouldn't
be the one paying the price (i.e. time spent) because people insist on using
an EOL'd operating system, which presents a security issue in many other
aspects as well. If they can't do it themselves, they could pay somebody to
deal with such a patchset, or just keep running the last supported version
of WireGuard.

In an utilitarian sense, because you're losing time over Windows 7 support,
everyone else is negatively affected, because it's time you could spend on
aspects of WireGuard everyone benefits from, and not only those running an
EOL'd operating system.

To put it shortly, I'm completely in support of sunsetting Windows 7
support, or even just keeping the Windows-7-changes in the next release for
one last time and then immediately dropping them right afterwards in the
git-master. I'm not sure what you exactly mean with sunsetting, which is why
I've given the above "drastic" proposal in case sunsetting means dealing
with this nonsense for another year or something.

With best regards

Laslo Hunhold


--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus


  reply	other threads:[~2020-11-10 13:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10 12:27 Should we sunset Windows 7 support? Jason A. Donenfeld
2020-11-10 12:47 ` Laslo Hunhold
2020-11-10 12:56   ` samuel.progin [this message]
2020-11-10 13:06     ` Jason A. Donenfeld
2020-11-10 12:57 ` Isaac Boukris
2020-11-10 15:06 ` Reiner Karlsberg
2020-11-12  8:34   ` Jason A. Donenfeld
2020-11-12  9:13     ` Roman Mamedov
2020-11-10 17:38 ` Andrew Fried
2020-11-12  8:38   ` Jason A. Donenfeld
2020-11-12  8:46     ` Phillip McMahon
2020-11-12  8:50       ` Jason A. Donenfeld
2020-11-12  9:03       ` Berge Schwebs Bjørlo
2020-11-13  2:56         ` Jeffrey Walton
2020-11-19 16:59           ` Jason A. Donenfeld
2020-11-19 17:16             ` akloster
2021-10-07 23:35             ` Jason A. Donenfeld
2020-11-12 21:56   ` Panagiotis Kalogiratos
2020-11-12 17:38 ` Jeffrey Walton
2020-11-12 17:42   ` Phillip McMahon
2020-11-12 18:11   ` Neal Gompa

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='00fa01d6b760$da95c480$8fc14d80$@gmail.com' \
    --to=samuel.progin@gmail.com \
    --cc=wireguard@lists.zx2c4.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.