linux-kernel - Re: gcc 5 & 6 & others already out of date?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221013165155.GJ16609@1wt.eu>
Date:   Thu, 13 Oct 2022 18:51:55 +0200
From:   Willy Tarreau <w@....eu>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Mark Brown <broonie@...nel.org>, linux-toolchains@...r.kernel.org,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: gcc 5 & 6 & others already out of date?

On Thu, Oct 13, 2022 at 10:37:21AM -0600, Jason A. Donenfeld wrote:
> On Thu, Oct 13, 2022 at 05:26:04PM +0100, Mark Brown wrote:
> > Note that I'm not saying we shouldn't upgrade our requirements at all,
> > just that I'm worrying about going from one extreme to the other in
> > terms of version requirements - it feels like there's a step change when
> > you move from things you can get in current release distros people are
> > likely to be using to things that will require a large proportion of
> > people to install extra stuff.  At the minute we're more at the other
> > end where it can be hard to figure out who'd even have the oldest
> > versions we support without deliberately seeking them out and keeping
> > them going is noticably making work for people.
> 
> Regarding "one extreme to the other", I suspect that in spite of my
> arguments, which would seem to justify an extreme, the actual thing I
> suggested is a bit more moderate: let's support the latest 2 or 3 gccs
> at the time of kernel release. If we choose 3, that's roughly 3 years of
> gccs, right?

Ideally we should support at the very least those of the oldest
supported LTS kernels, because one thing for LTS users is that we
also want to encourage them to try new kernels, and if they can't
build newer kernels from the start we all know they'll give up
very quickly. And this eases the backport to those kernels as it
is expected that a mainline fix will support those versions (even
if it may break from time to time by accident, but the intent is
there).

> 3 years seems like a fairly long amount of time.

For a developer changing their distro every 6 months, possibly. Not
for users who took time to stabilize their system to something working
and who are curious about what the new kernel provides from time to
time.

Willy