On Sat, Sep 23, 2017 at 3:52 PM, Keith Lofstrom <[log in to unmask]> wrote:
> On Tue, Sep 19, 2017 at 11:47 PM, Bill Maidment <[log in to unmask]> wrote:
>> So much for security issue support for 10 years. Probably best to assume
>> only 7 years in real life.
>
> On Wed, Sep 20, 2017 at 07:24:25AM -0700, Akemi Yagi wrote:
>> Here's the description about "Production 3 phase":
>> "During the Production 3 Phase, Critical impact Security Advisories
>> (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be
>> released as they become available. Other errata advisories may be delivered
>> as appropriate."
>> So, yes, not all security updates are available once RHEL (therefore
>> Scientific Linux) goes into that phase.
>
> In a larger sense: how much work is it to semi-automate
> the process of backporting all these security fixes from
> SL6 and SL7 to earlier distros?

> While SL7 follows what RedHat does (and rightly so),
> perhaps there are enough of us here (and using CentOS
> for similar reasons) to fork a "superstable" distro
> and pay a few people to support the fork.

Have you *any* idea what real regression testing costs? Especially
when you run into this?

* https://xkcd.com/1172/

> For example, I spend more hours than I would like
> struggling to learn about systemd (after more than three
> decades of SysV).  I worry about having to learn about
> systemd's replacement in SL8 or SL9.  For me, computing
> is a utility.  I crunch numbers, not "tweet" (or "twang"

Its core author is a Red Hat employee. I'm afraid we're stuck with
systemd for the foreseeable future.

> or whatever will be stylish in 2027), and prefer to change
> how I do it as often as I change electrical wall sockets
> and plugs.  I prefer to leave a numerical code legacy
> that is useful (or at least testable) three decades
> from now, which does not die when Stephen Wolfram does.

Heh. Understandable. But it's not "a few employees" to nail down
complete stability. It's also racks of older and newer hardware for
kernel regression and compatibility testing. And clients *will* want
tools that were built fro maven, gradle, CPAN, or pypi.org last week
and bring in a whole fleet of dependencies. I've been through this a
lot, and published fleets of RPM's to support newer tools in older
environments, and it is a *lot* of work to run the newer tools on an
older, more stable OS. It can in fact be destabilizing to have to
build those forests of dependencies from 2 or 3 years ago.

> Sigh.  Many 20th and early 21st century "accomplishments"
> are best forgotten.  Perhaps Linux, and our work based on
> it, will be forgotten as well.
>
> Keith
>
> --
> Keith Lofstrom          [log in to unmask]