28 Jan
2021
28 Jan
'21
4:47 p.m.
Hello,
On:
https://bitfolk.com/techspec.html#toc_2_Available_Linux_distributions
I am listing Ubuntu EOL dates as found at:
https://wiki.ubuntu.com/Releases
However, it seems that the EOL dates from the Ubuntu wiki refer to
Extended Security Maintenance:
https://ubuntu.com/security/esm
If I understand things correctly, this:
- covers only a small subset of the archive
- requires an Ubuntu Advantage account
- entitlement to ESM updates is only available for free for
personal use on up to 3 machines
So, for example, the recent "sudo" security issue is not available
for 14.04 LTS users unless they meet the above requirements.
If I have misunderstood things can someone correct me?
If not, I don't think it is particularly clear of us to list those
EOL dates on BitFolk's page and instead we should list the "End of
Standard Support" ones.
Thoughts?
And if we do list "End of Standard Support" dates, should that be
matched with "end of stable support" dates for Debian? The situation
for Debian is not straightforward either:
https://wiki.debian.org/DebianReleases#Production_Releases
While LTS and ELTS are available free to everyone (BitFolk is one of
monetary sponsors that makes that possible), they do only cover a
subset of what was in Debian stable.
A summary of what each thing means for Debian is something like:
Stable Security:
- Supported until release end of life
- Package maintainers and security team are supposed to provide
security fixes for every package in the stable release
- buster EOL: some time in 2022
Long Term Support:
- Dedicated team of paid developers provide security fixes on a
best effort basis; sometimes package maintainers help.
- Known to only cover a subset of the archive; most important
packages do get updates.
- buster LTS EOL: likely some time in 2024
Extended LTS:
- Even smaller team of paid developers provide security fixes
- buster ELTS EOL: likely some time in 2026
Which is these things is fair to call a supported Debian release?
Really I'd just like to keep some consistency.
(Personal controversial interjection: I'm no CentOS fan but this is
exactly what people will miss about CentOS. It was a straightforward
10 year support commitment. Which was a massive commitment. It
wasn't always timely, but you knew that RHEL would get an update and
then CentOS would. For 10 years. That has value.)
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
30 Jan
30 Jan
11:31 a.m.
Hey Andy,
I'd argue for using the "end of standard support" dates for Ubuntu. I
suspect that's the generally well known "EOL" date (5 years from release of
the LTS) that most folk will know. It's certainly the date that I try to
stick to with upgrades and such.
Cheers,
James
On Thu, 28 Jan 2021, 4:47 pm Andy Smith, <andy(a)bitfolk.com> wrote:
Hello,
On:
https://bitfolk.com/techspec.html#toc_2_Available_Linux_distributions
I am listing Ubuntu EOL dates as found at:
https://wiki.ubuntu.com/Releases
However, it seems that the EOL dates from the Ubuntu wiki refer to
Extended Security Maintenance:
https://ubuntu.com/security/esm
If I understand things correctly, this:
- covers only a small subset of the archive
- requires an Ubuntu Advantage account
- entitlement to ESM updates is only available for free for
personal use on up to 3 machines
So, for example, the recent "sudo" security issue is not available
for 14.04 LTS users unless they meet the above requirements.
If I have misunderstood things can someone correct me?
If not, I don't think it is particularly clear of us to list those
EOL dates on BitFolk's page and instead we should list the "End of
Standard Support" ones.
Thoughts?
And if we do list "End of Standard Support" dates, should that be
matched with "end of stable support" dates for Debian? The situation
for Debian is not straightforward either:
https://wiki.debian.org/DebianReleases#Production_Releases
While LTS and ELTS are available free to everyone (BitFolk is one of
monetary sponsors that makes that possible), they do only cover a
subset of what was in Debian stable.
A summary of what each thing means for Debian is something like:
Stable Security:
- Supported until release end of life
- Package maintainers and security team are supposed to provide
security fixes for every package in the stable release
- buster EOL: some time in 2022
Long Term Support:
- Dedicated team of paid developers provide security fixes on a
best effort basis; sometimes package maintainers help.
- Known to only cover a subset of the archive; most important
packages do get updates.
- buster LTS EOL: likely some time in 2024
Extended LTS:
- Even smaller team of paid developers provide security fixes
- buster ELTS EOL: likely some time in 2026
Which is these things is fair to call a supported Debian release?
Really I'd just like to keep some consistency.
(Personal controversial interjection: I'm no CentOS fan but this is
exactly what people will miss about CentOS. It was a straightforward
10 year support commitment. Which was a massive commitment. It
wasn't always timely, but you knew that RHEL would get an update and
then CentOS would. For 10 years. That has value.)
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
1:39 p.m.
It would seem that the standard support is the most logical. I never use
Ubuntu, only Debian, but I guess the same principle for both. That is what
I would have thought most people would understand by the term EOL
On Sat, 30 Jan 2021 at 11:32, James Gregory-Monk <jgxenite(a)gmail.com> wrote:
Hey Andy,
I'd argue for using the "end of standard support" dates for Ubuntu. I
suspect that's the generally well known "EOL" date (5 years from release
of
the LTS) that most folk will know. It's certainly the date that I try to
stick to with upgrades and such.
Cheers,
James
On Thu, 28 Jan 2021, 4:47 pm Andy Smith, <andy(a)bitfolk.com> wrote:
Hello,
On:
https://bitfolk.com/techspec.html#toc_2_Available_Linux_distributions
I am listing Ubuntu EOL dates as found at:
https://wiki.ubuntu.com/Releases
However, it seems that the EOL dates from the Ubuntu wiki refer to
Extended Security Maintenance:
https://ubuntu.com/security/esm
If I understand things correctly, this:
- covers only a small subset of the archive
- requires an Ubuntu Advantage account
- entitlement to ESM updates is only available for free for
personal use on up to 3 machines
So, for example, the recent "sudo" security issue is not available
for 14.04 LTS users unless they meet the above requirements.
If I have misunderstood things can someone correct me?
If not, I don't think it is particularly clear of us to list those
EOL dates on BitFolk's page and instead we should list the "End of
Standard Support" ones.
Thoughts?
And if we do list "End of Standard Support" dates, should that be
matched with "end of stable support" dates for Debian? The situation
for Debian is not straightforward either:
https://wiki.debian.org/DebianReleases#Production_Releases
While LTS and ELTS are available free to everyone (BitFolk is one of
monetary sponsors that makes that possible), they do only cover a
subset of what was in Debian stable.
A summary of what each thing means for Debian is something like:
Stable Security:
- Supported until release end of life
- Package maintainers and security team are supposed to provide
security fixes for every package in the stable release
- buster EOL: some time in 2022
Long Term Support:
- Dedicated team of paid developers provide security fixes on a
best effort basis; sometimes package maintainers help.
- Known to only cover a subset of the archive; most important
packages do get updates.
- buster LTS EOL: likely some time in 2024
Extended LTS:
- Even smaller team of paid developers provide security fixes
- buster ELTS EOL: likely some time in 2026
Which is these things is fair to call a supported Debian release?
Really I'd just like to keep some consistency.
(Personal controversial interjection: I'm no CentOS fan but this is
exactly what people will miss about CentOS. It was a straightforward
10 year support commitment. Which was a massive commitment. It
wasn't always timely, but you knew that RHEL would get an update and
then CentOS would. For 10 years. That has value.)
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
2:38 p.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
Hi Keith,
On Sat, Jan 30, 2021 at 01:39:18PM +0000, Keith Williams wrote:
It would seem that the standard support is the most
logical. I never use
Ubuntu, only Debian, but I guess the same principle for both.
So you wouldn't include Debian's LTS either then? I personally do
consider Debian's LTS as sufficient basic security cover for a
system because they seem to have enough resources to backport all
the important security fixes in a reasonable time period.
Do note that Ubuntu's standard support is only for things from
"main". I don't have an Ubuntu server spun up right now but my
Ubuntu 18.04 desktop has 728 out of 2821 packages from universe,
thus relying on community updates for those:
$ aptitude search "?installed" | wc -l
2821
$ aptitude search "?section (universe) ?installed" | wc -l
728
Those of you with Ubuntu VMs, how many packages do you have from
universe? I do expect it to be a lot lower percentage than my
desktop, because they're servers.
I'm not sure that Ubuntu's standard security support is really more
complete than Debian's LTS. It depends on what packages you use.
That is what I would have thought most people would
understand by
the term EOL
I think I'm going to have to use different terms anyway because
Ubuntu considers the EOL to be the end of Extended Security
Maintenance period, so I either go with that or I don't use the term
"EOL". I think it would be confusing to diverge from the term that
Ubuntu uses, at least when referring to Ubuntu.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
5:10 p.m.
I guess it's down, really, to the way I use it. I tend to upgrade my
release soon after it has come out. Not using my VPS or home computers
commercially makes a big difference to how I see the whole issue. I don't
tend to think in terms of EOL but more interms of the latest release. I am
running Buster now and when the "official" release of Bullseye occurs later
this year will upgrade to that, which I realise is a totally different use
case to most. So my opinion will probably not really be totally relevant to
the question you have asked
Keith
On Sat, 30 Jan 2021 at 14:38, Andy Smith <andy(a)bitfolk.com> wrote:
Hi Keith,
On Sat, Jan 30, 2021 at 01:39:18PM +0000, Keith Williams wrote:
It would seem that the standard support is the
most logical. I never use
Ubuntu, only Debian, but I guess the same principle for both.
So you wouldn't include Debian's LTS either then? I personally do
consider Debian's LTS as sufficient basic security cover for a
system because they seem to have enough resources to backport all
the important security fixes in a reasonable time period.
Do note that Ubuntu's standard support is only for things from
"main". I don't have an Ubuntu server spun up right now but my
Ubuntu 18.04 desktop has 728 out of 2821 packages from universe,
thus relying on community updates for those:
$ aptitude search "?installed" | wc -l
2821
$ aptitude search "?section (universe) ?installed" | wc -l
728
Those of you with Ubuntu VMs, how many packages do you have from
universe? I do expect it to be a lot lower percentage than my
desktop, because they're servers.
I'm not sure that Ubuntu's standard security support is really more
complete than Debian's LTS. It depends on what packages you use.
That is what I would have thought most people
would understand by
the term EOL
I think I'm going to have to use different terms anyway because
Ubuntu considers the EOL to be the end of Extended Security
Maintenance period, so I either go with that or I don't use the term
"EOL". I think it would be confusing to diverge from the term that
Ubuntu uses, at least when referring to Ubuntu.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
5:28 p.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
Hi Keith,
On Sat, Jan 30, 2021 at 05:10:01PM +0000, Keith Williams wrote:
My opinion will probably not really be totally
relevant to the
question you have asked
Well it's not about what I think, it's about what prospective
customers think. If you say you consider a Debian release to be EOL
when its standard support period ends (typically 1 year after the
release of the next stable version) then I have to accept that even
if I don't agree with it!
The purpose of this was to find out what people really consider
"EOL" to mean. It doesn't appear to have grabbed many people's
interest though so I will probably just have to have a think about
it and put whatever I think is right.
At the moment all I am sure of is that setting Ubuntu's EOL to the
end of the 5 year ESM period is not consistent with what "EOL" means
for other distributions so I will probably have to use other terms
to describe it. That's just, like, my opinion, man. Because it's
difficult to compare the exact details of each distributions'
support offerings.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
7:40 p.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
On Sat, Jan 30, 2021 at 05:10:01PM +0000, Keith Williams wrote:
I don't tend to think in terms of EOL but more
interms of the latest
release. I am running Buster now and when the "official" release of
Bullseye occurs later this year will upgrade to that, which I realise
is a totally different use case to most.
I'll be doing the same, as soon as Sympl (my preferred server management
package) is brought up to date with Bullseye.
Since Debian tends to be a bit behind the curve with versions of
packages (WordPress is already complaining that PHP7.3 is out of date) I
shouldn't be surprised if most Debian users are happy to upgrade quickly
to each new stable release. It helps a lot that a Debian upgrade can be
done in place.
--
Anahata
anahata(a)treewind.co.uk -+- http://www.treewind.co.uk
Home: 01535 501017 Mob: 07976 263827
6:45 p.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
Hi [bit]folks,
On 30/01/2021 14:38, Andy Smith wrote:
Do note that Ubuntu's standard support is only for
things from
"main". I don't have an Ubuntu server spun up right now but my
Ubuntu 18.04 desktop has 728 out of 2821 packages from universe,
thus relying on community updates for those:
$ aptitude search "?installed" | wc -l
2821
$ aptitude search "?section (universe) ?installed" | wc -l
728
Those of you with Ubuntu VMs, how many packages do you have from
universe? I do expect it to be a lot lower percentage than my
desktop, because they're servers.
I ran the latter command on my Ubuntu 18.04 VPS just now, and there
weren't many packages there. 48 to be precise.
However, some of the packages where what I'd consider critical. They
include:
* Let's Encrypt certbot
* Some dovecot components
* fail2ban (!)
* greylistd
* libssh2-1 (!)
* a number of php modules, including imagemagick, fpm and mbstring
* quite a few python 3 modules, probably for Lets Encrypt certbot
I suspect that the PHP modules are probably critical for some web
frameworks - in particular I think mbstring is needed to allow
unicode/international characters in some cases, and fpm is part of the
webserver config for many.
So I guess I'll be upgrading my VPS to 22.04 sometime next year, so that
I don't get hit by the end of standard support. I don't want to find
myself missing updates for things I know I'm using...
In that regard, the 5 year date seems not only reasonable, but wise. I
doubt many servers are using ONLY main, unless they're very simple.
Regards,
Phil
7:41 p.m.
Hi Andy,
My question would be - what is your aim in putting the EOL date on
that page? You're not (presumably) implying any level of support at
bitfolk with regards to those dates? Or perhaps you should be - if I
want to pay for Ubuntu extended support, I'd hope you wouldn't make
changes that would prevent me running ye olde Ubuntu at bitfolk.
I think it's easy to assume that Debian is in a better position than
Ubuntu because it supports the whole archive, but in practice surely
it is still driven by the maintainer to some degree and hence can vary
from package to package. For popular packages I'm sure things will get
fixed, but for smaller, less well known packages I just think issues
are more likely to pass them by.
Regards,
Roger
9:16 p.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
Hi Philip,
On Sat, Jan 30, 2021 at 06:45:01PM +0000, Philip Storry wrote:
So I guess I'll be upgrading my VPS to 22.04
sometime next year, so that I
don't get hit by the end of standard support. I don't want to find myself
missing updates for things I know I'm using...
I don't think you have "standard security support" on anything in
"universe", only in "main" - ever. As far as I understand Ubuntu
security updates for packages in "universe" are best effort by the
community, not by the Ubuntu Security Team.
https://wiki.ubuntu.com/SecurityTeam/FAQ
or have I misunderstood?
I doubt many servers are using ONLY main, unless
they're very
simple.
In my experience very few people understand about "main" vs
"universe" and "multiverse". I might be one of them.
Once again I will say that CentOS's straightforward 10 year support
promise was one of the reasons why people liked it. But
understandably that was a lot of work for Red Hat.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
9:24 p.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
On Sat, Jan 30, 2021 at 09:16:20PM +0000, Andy Smith wrote:
In my experience very few people understand about
"main" vs
"universe" and "multiverse". I might be one of them.
Er, as in I might be one of the people that doesn't understand! My
reading of Ubuntu's Security Team FAQ has long led me to believe
that packages in the "universe" and "multiverse" section actually
have no official security support, only Ubuntu developers deciding
to push an update. But maybe I have that wrong.
Cheers,
Andy
9:35 p.m.
My experience is that in universe it's either the community working
with the security team, or the security team deciding to push a fix
themselves.
So yes, I think you're about right.
Regards,
Roger
On Sat, 30 Jan 2021 at 21:24, Andy Smith <andy(a)bitfolk.com> wrote:
On Sat, Jan 30, 2021 at 09:16:20PM +0000, Andy Smith wrote:
In my experience very few people understand about
"main" vs
"universe" and "multiverse". I might be one of them.
Er, as in I might be one of the people that doesn't understand! My
reading of Ubuntu's Security Team FAQ has long led me to believe
that packages in the "universe" and "multiverse" section actually
have no official security support, only Ubuntu developers deciding
to push an update. But maybe I have that wrong.
Cheers,
Andy
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
31 Jan
31 Jan
10:10 a.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
On 30/01/2021 21:16, Andy Smith wrote:
I don't think you have "standard security
support" on anything in
"universe", only in "main" - ever. As far as I understand Ubuntu
security updates for packages in "universe" are best effort by the
community, not by the Ubuntu Security Team.
https://wiki.ubuntu.com/SecurityTeam/FAQ
or have I misunderstood?
I'm probably the one misunderstanding. :-)
It doesn't change my reasoning much though - "best effort" means that
effort is more likely to boil down to "upgrade to the newest LTS" rather
than backporting a patch. Best practice should be to be on a supported LTS.
In my experience very few people understand about
"main" vs
"universe" and "multiverse". I might be one of them.
Once again I will say that CentOS's straightforward 10 year support
promise was one of the reasons why people liked it. But
understandably that was a lot of work for Red Hat.
Yeah, although the downside is that it some projects just don't work
over such a timescale anyway. I have some CentOS servers I inherited at
work, and noticed one hadn't been updated for a long time. So I did an
update, which broke a PHP based website. I soon discovered that the
website used a very old PHP bytecode cache/accelerator configuration
that was no longer supported - and hadn't been for years. Fortunately it
was an easy fix - disable the accelerator, which was possible because
the website has very little traffic these days so it wasn't needed.
In the interests of balance, plenty of CentOS servers also updated
without issue. But it's plainly not guaranteed.
I think that the pace of many projects mean that assuming support for
longer than four to five years is probably unrealistic anyway. There are
some very mature and static projects that are less likely to have
breaking fixes - typically infrastructure like DNS/DHCP/mail servers/web
servers. But those servers should still be reviewed every few years,
just to ensure that their configuration meets modern norms. Leaving a
server in a metaphorical corner and hoping it's still fine is probably
not a good strategy...
Regards,
Phil
12:01 p.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
On 2021-01-31 10:10+0000, Philip Storry wrote:
It doesn't change my reasoning much though -
"best effort" means that
effort is more likely to boil down to "upgrade to the newest LTS"
rather than backporting a patch. Best practice should be to be on a
supported LTS.
This depends a lot on popularity of the package affected I believe. If
there's only three or four installs recorded in popcon then I doubt
there will be much effort to backport. I suspect. This is also largely
going to be based upon what the upstream author has done, did they
branch at the point that the distro absorbed? If not, backporting a
patch will be much harder.
Ed
30 Jan
30 Jan
7:41 p.m.
Hi Andy,
My question would be - what is your aim in putting the EOL date on
that page? You're not (presumably) implying any level of support at
bitfolk with regards to those dates? Or perhaps you should be - if I
want to pay for Ubuntu extended support, I'd hope you wouldn't make
changes that would prevent me running ye olde Ubuntu at bitfolk.
I think it's easy to assume that Debian is in a better position than
Ubuntu because it supports the whole archive, but in practice surely
it is still driven by the maintainer to some degree and hence can vary
from package to package. For popular packages I'm sure things will get
fixed, but for smaller, less well known packages I just think issues
are more likely to pass them by.
Regards,
Roger
On Thu, 28 Jan 2021 at 16:47, Andy Smith <andy(a)bitfolk.com> wrote:
Hello,
On:
https://bitfolk.com/techspec.html#toc_2_Available_Linux_distributions
I am listing Ubuntu EOL dates as found at:
https://wiki.ubuntu.com/Releases
However, it seems that the EOL dates from the Ubuntu wiki refer to
Extended Security Maintenance:
https://ubuntu.com/security/esm
If I understand things correctly, this:
- covers only a small subset of the archive
- requires an Ubuntu Advantage account
- entitlement to ESM updates is only available for free for
personal use on up to 3 machines
So, for example, the recent "sudo" security issue is not available
for 14.04 LTS users unless they meet the above requirements.
If I have misunderstood things can someone correct me?
If not, I don't think it is particularly clear of us to list those
EOL dates on BitFolk's page and instead we should list the "End of
Standard Support" ones.
Thoughts?
And if we do list "End of Standard Support" dates, should that be
matched with "end of stable support" dates for Debian? The situation
for Debian is not straightforward either:
https://wiki.debian.org/DebianReleases#Production_Releases
While LTS and ELTS are available free to everyone (BitFolk is one of
monetary sponsors that makes that possible), they do only cover a
subset of what was in Debian stable.
A summary of what each thing means for Debian is something like:
Stable Security:
- Supported until release end of life
- Package maintainers and security team are supposed to provide
security fixes for every package in the stable release
- buster EOL: some time in 2022
Long Term Support:
- Dedicated team of paid developers provide security fixes on a
best effort basis; sometimes package maintainers help.
- Known to only cover a subset of the archive; most important
packages do get updates.
- buster LTS EOL: likely some time in 2024
Extended LTS:
- Even smaller team of paid developers provide security fixes
- buster ELTS EOL: likely some time in 2026
Which is these things is fair to call a supported Debian release?
Really I'd just like to keep some consistency.
(Personal controversial interjection: I'm no CentOS fan but this is
exactly what people will miss about CentOS. It was a straightforward
10 year support commitment. Which was a massive commitment. It
wasn't always timely, but you knew that RHEL would get an update and
then CentOS would. For 10 years. That has value.)
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
9:06 p.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
Hi Roger,
On Sat, Jan 30, 2021 at 07:41:27PM +0000, Roger Light wrote:
My question would be - what is your aim in putting the
EOL date on
that page?
Just so that people can make a good informed decision when picking
which Linux distribution to order.
We get customers from time to time that pick older releases and
don't understand when they cease getting security support. There
have also been several new signups since December that picked CentOS
8 without realising its EOL was less than a year away.
if I want to pay for Ubuntu extended support, I'd
hope you
wouldn't make changes that would prevent me running ye olde Ubuntu
at bitfolk.
Ubuntu doesn't have explicit support for Xen either as a guest or as
a hypervisor (it's in the "universe" section) so BitFolk isn't in a
position to *ensure* Ubuntu guests remain usable. In fact as you may
have noticed Ubuntu has more than once made a decision to ship
something that doesn't boot even under versions of Xen that in are
in their own archive. That was unlikely to have been on purpose - I
expect it just wasn't tested.
e.g. the Xen hypervisor packaged by Ubuntu right now cannot boot Ubuntu
19.10 and beyond due to the LZ4 kernel compression.
Older things continue to work mainly because no one wants to changes
them!
Going the other way, the aim would obviously be to keep being able
to run Linux distributions that are still considered viable by the
vendor where possible. And longer if possible. There's plenty of
Debian etch still running in the BitFolk customer base. :(
This is going off into the weeds somewhat - we aren't in a position
to tell existing customers what they should be running, we always
have to try to make it work. This is just about what guidance is
published regarding end of life dates. I'm not comfortable just
putting an EOL date that includes a 5 year period you have to
maintain a (free for personal use on <= 3 hosts) subscription for.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
10:34 p.m.
New subject: Ubuntu EOL dates - which to quote in general documentation?
On Sat, Jan 30, 2021 at 09:06:47PM +0000, Andy Smith wrote:
On Sat, Jan 30, 2021 at 07:41:27PM +0000, Roger Light
wrote:
In theory you could try to establish what levels of security support are
roughly equivalent in each distribution and pick a date for each distro
when that level is reached.
As that's impossible, I think the best attempt to be helpful to the
prospective customer is to describe as well as you can in a few words
what levels of support are available until which dates for each
distribution, even if it's as vague as "full: june 2021, partial: June
2023"
In special cases like the truncated EOL for Centos 8, you
can always include a warning and link for further explanation. Ideally all
distributions should have a page you can link to which explains their
security support policy, but I realize it may not be quite as easy as
that :-)
Anahata
My question would be - what is your aim in
putting the EOL date on
that page?
Just so that people can make a good informed decision when picking
which Linux distribution to order.
We get customers from time to time that pick older releases and
don't understand when they cease getting security support. There
have also been several new signups since December that picked CentOS
8 without realising its EOL was less than a year away.
1180
days inactive
1183
days old
16 comments
7 participants
participants (7)
-
Anahata -
Andy Smith -
Ed Neville -
James Gregory-Monk -
Keith Williams -
Philip Storry -
Roger Light