EOL announcement in changelogs

[Henrik Carlqvist]

I saw the following in the changelog for Slackware 12.0:

-8<--------------------------
Thu Jun 14 05:02:39 UTC 2012
####################################################################
# NOTICE OF INPENDING EOL (END OF LIFE) FOR OLD SLACKWARE VERSIONS #
# #
# Effective August 1, 2012, security patches will no longer be #
# provided for the following versions of Slackware (which will all #
# be more than 5 years old at that time): #
# Slackware 8.1, 9.0, 9.1, 10.0, 10.1, 10.2, 11.0, 12.0. #
# If you are still running these versions you should consider #
# migrating to a newer version (preferably as recent as possible). #
# Alternately, you may make arrangements to handle your own #
# security patches. If for some reason you are unable to upgrade #
# or handle your own security patches, limited security support #
# may be available for a fee. Inquire at secu...@slackware.com. #
####################################################################
-8<--------------------------

I understand that maintaining many different versions is a heavy burden
and even worse when some versions come in different flavors like i686 and
x86_64. Still, I think that marking so many versions as EOL at once was a
very big step in an unfortunate direction.

It has been really nice to have 8.1 still being maintained more than 10
years since it release even though I never run 8.1 myself. Instead I
jumped on the 8.0 train which never really got much support after its
release.

Only having 13.0, 13.1 and 13.37 as supported releases is about as few
supported releases as Fedora Core, even though FC comes out with new
releases more often.

Right now I have a number of production servers running Slackware64 13.1,
Slackware 12.0, Slackware 9.1 and a single LDAP server still running
Slackware 8.0. Some of the machines running 12.0 have recently got that
version because installed their hardware is only capable of 32-bit OS.
Some of the machines running 12.0 or older have some kind of production
server functinality like LDAP-server, NIS-server, NFS-server or
web-server. During the time required for an upgrade of such a machine
users would suffer and after such an upgrade there is allways the fear of
the configuration no longer working exactly as before.

Does anyone here know why a decision was made to decrease the number of
supported years since release from more than 10 years to only about half
that time? Does anyone know more about the terms for "limited security
support for a fee"?

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[Aaron W. Hsu]

On Fri, 22 Jun 2012 02:18:05 +0200, Henrik Carlqvist wrote:

> Does anyone here know why a decision was made to decrease the number of
> supported years since release from more than 10 years to only about half
> that time? Does anyone know more about the terms for "limited security
> support for a fee"?

I do not have anything official, but I have to say that I am really surprised
support for the older versions lasted as long as it did. As it stands, I do
know that the 13.0 and later releases were pretty big ones, IMO, and there
seems to be a strong difference in those before 13.0 and those after. It would
make sense to have a release near 13.0 be the cutoff point for things. It's
also a pretty long time for support, if you compare it to the one or two
years that are the support cycle of most non-enterprise distributions.

--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[Grant]

On Fri, 22 Jun 2012 02:18:05 +0200, Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:

>I saw the following in the changelog for Slackware 12.0:
>
>-8<--------------------------
>Thu Jun 14 05:02:39 UTC 2012
>####################################################################
># NOTICE OF INPENDING EOL (END OF LIFE) FOR OLD SLACKWARE VERSIONS #
># #
># Effective August 1, 2012, security patches will no longer be #
># provided for the following versions of Slackware (which will all #
># be more than 5 years old at that time): #
># Slackware 8.1, 9.0, 9.1, 10.0, 10.1, 10.2, 11.0, 12.0. #

I'm still running 11.0 on Internet facing box, keep the kernel updated
to a point, been avoiding the jump from apache 1.3, pure laziness ;)

grant@deltree:~$ uname -r
2.6.27.62a

I have acquired an hp Compaq d530 SFF for a new server box:

http://bugsplatter.id.au/kernel/boxen/deimos/

but this old Dell OptiPlex GX100 just refuses to die

http://bugsplatter.id.au/kernel/boxen/deltree/

Another thought back of my mind is to get an ARM or Intel Atom based
box that uses far less power, but that is more expensive than retasking
unwanted machines I pick up occasionally.

OT:
Thinking of EOL, it was a year ago that I was in a coma in Intensive
Care with a very poor survival outlook. Today I passed on-road driving
assessment[1] in order to keep my driver license, after being released
from near eight months health care late January this year... Times flies!

[1] Assessment in two pieces, first off-road two hour assessment
last week covered medical, reflexes, reaction times, road knowledge
and so on, second on-road assessment was a 50 minute drive around town
and some highway driving, much longer than a standard license test.

Henrik: I'm told the 'Got Slack' T was a huge help back then :) Thanks.

Grant.

[Glyn Millington]

Grant <o...@grrr.id.au> writes:

> OT: Thinking of EOL, it was a year ago that I was in a coma in
> Intensive Care with a very poor survival outlook. Today I passed
> on-road driving assessment[1] in order to keep my driver license,
> after being released from near eight months health care late January
> this year... Times flies!

Fantastic! Congratulations - that's pretty good going :-)



atb



Glyn
--
RTFM http://www.tldp.org/index.html
GAFC http://slackbook.org/ The Official Source :-)
STFW http://groups.google.com/groups?hl=en&group=alt.os.linux.slackware
JFGI http://jfgi.us/

[Henrik Carlqvist]

"Aaron W. Hsu" <arc...@sacrideo.us> wrote:
> I do not have anything official, but I have to say that I am really
> surprised support for the older versions lasted as long as it did.

Well comparing the support for Slackware 8.0 with Slackware 8.1 it is a
little bit surprising that 8.1 was supported for more than 10 years and
8.0 had almost no support at all.

Maybe what is really missing is some kind of official policy stating the
intention of future support for current and upcoming releases. Looking at
the support for 8.1 it would a few weeks ago be easy to expect support for
13.37 for at least 10 years. Now with this announcement you might expect
13.37 to be supported for five years from release, that would be until
2016/04/28, less than 4 years from now. On the other hand, someone might
make some new decision once Slackware 14 is released that Slackware 13
will no longer be supported...

People using their workstation for development purposes usually want to
give their users or maybe even paying customers some kind of future
support. That future support usually depends upon still being able to run
the same development environment. Not knowing how long you might expect
support for a release makes Slackware less useful as a development
platform.

> As it stands, I do know that the 13.0 and later releases were pretty big
> ones, IMO, and there seems to be a strong difference in those before
> 13.0 and those after.

They were big as it was about a year between each release. However, they
are all, like the 12-releases running kernel 2.6. They haven't made any
major libc switchover like when we switched from libc5 to glibc2 (was it
with Slackware 7?). We still have the same basic naming convention for
packages as we had since Slackware 9 even though the compression was
changed from gzip to xz with Slackware 13.0. We still have the same elf
format for executables that we have had since Slackware 3. Slackware 13
still uses udev to automagically load modules like Slackware 12.

During the years there have been many major improvements to Slackware like
loadable kernel modules for hardware support and later also automating
that with the hotplug daeomn. However, when I compare Slackware 13.1 with
Slackware 12.0 I can only come to think of one minor improvement which
makes me think that 13.1 is a little better than 12.0 and that is the
automounter being able to show the names of directories before they are
being used. There are other parts that differ like KDE4 vs KDE3, but I
wouldn't say that 13 has brought a very big progress compared to Slackware
12.

But I do understand that a distribution like Slackware keeps on growing
with new packages added and old packages growing bigger for each relase.
Maintining more software means more work and might explain both why
releases come less often and why a decision was made cutting support for
many old releases at once.

> It's also a pretty long time for support, if you compare it to the one
> or two years that are the support cycle of most non-enterprise
> distributions.

Yes, I have since I started using Slackware 9.1 considered the long
support to be one big advantages of Slackware compared to other
distributions.

[Henrik Carlqvist]

Grant <o...@grrr.id.au> wrote:
> Today I passed on-road driving assessment[1] in order to keep my driver
> license,

Congratulations!

> Henrik: I'm told the 'Got Slack' T was a huge help back then :) Thanks.

Nice to hear that it was useful in some way :-)

[Robby Workman]

The sheer amount of time and effort required to backport patches for
many of the older versions is/was too much - every time a CVE is issued,
at least a whole day would be consumed doing compiles and tests, and
that was for the "easy" ones. These days, official patches are often
created only for recent upstream releases, so anything older (e.g. bind)
would have to be manually backported, and so there's the real risk of
introducing yet more holes due to incomplete understanding of the code
(note that bind was *upgraded* in the most recent /patches, precisely
because of that concern - the known certainty that admins would have to
update bind configs was deemed to be a better choice than the unknown
certainty of whether the patched bind was truly fixed (correctly)).

I do understand your concern, and while it's little consolation, this
was not a hasty decision. I'd love to see 11.0 still maintained (since
it was the last Slackware to have a 2.4.x kernel), and in fact, I have
a local installation running the latest 2.4.37.whatever kernel. I had
once considered trying to do some backports and such for it, specifically
for users like you, but I can't find the time either. Basically, time
constraints have led me (and apparently Pat too) to having to make a
decision between "support *old* releases" and "work on new releases,"
and given that choice, the only rational decision is the one he made.
Put simply, supporting old releases brings in zero revenue - making
new releases brings in nonzero revenue.

On that note, I think that was the idea behind "limited security support
for a fee" -- if an individual and/or organization determines that the
cost of upgrading the old systems is too much (and they can negotiate a
"fee" less than that amount), the option is available. IOW, "make it
worth my time to do old stuff instead of new development."

-RW

[Henrik Carlqvist]

Robby Workman <newsg...@rlworkman.net> wrote:
> The sheer amount of time and effort required to backport patches for
> many of the older versions is/was too much - every time a CVE is issued,
> at least a whole day would be consumed doing compiles and tests, and
> that was for the "easy" ones.

Thanks for sharing som of your inside knowledge of the Slackware team.

> These days, official patches are often created only for recent upstream
> releases, so anything older (e.g. bind) would have to be manually
> backported, and so there's the real risk of introducing yet more holes
> due to incomplete understanding of the code (note that bind was
> *upgraded* in the most recent /patches, precisely because of that
> concern - the known certainty that admins would have to update bind
> configs was deemed to be a better choice than the unknown certainty of
> whether the patched bind was truly fixed (correctly)).

Yep, that was noted. I still haven't decided when or maybe even if that
patch is going to be applied to a production intranet DNS server.

> Put simply, supporting old releases brings in zero revenue
> - making new releases brings in nonzero revenue.
>
> On that note, I think that was the idea behind "limited security support
> for a fee" -- if an individual and/or organization determines that the
> cost of upgrading the old systems is too much (and they can negotiate a
> "fee" less than that amount), the option is available. IOW, "make it
> worth my time to do old stuff instead of new development."

I think that it will be hard to find a few individuals or organisations
willing to give offers that would give enough revenue. Maybe it would be a
better idea to have some kind of commercial support program for older
releases.

Example of a pricing scheme for commercial support:

The first 3 years security patches are free.
Year 4 patches cost like installation media (50$)
Year 5 patches cost like 2 * installation media (100$)
Year 6 patches cost like 3 * installation media (150$)
Year 7 patches cost like 4 * installation media (200$)
Year 8 patches cost like 5 * installation media (250$)
Year 9 patches cost like 6 * installation media (300$)
Year 10 patches cost like 7 * installation media (350$)
...

With such a pricing scheme sooner or later the customers will find that
upgrading to the latest Slackware will be cheaper than paying growing
maitainance fees. Releases with no remaining customers can be abandoned.

I think that it will be easier to find customers for such support programs
if you publish some price list rather than only write a note saying "give
us an offer and we will see what we can do".

[Henrik Carlqvist]

By email I got a reply from E.J.M. Hartman who used to be a
rather frequent poster in this NG:

On Fri, 22 Jun 2012 18:03:00 +0200
"E.J.M. Hartman" <E.J.M....@tudelft.nl> wrote:

> Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> >Only having 13.0, 13.1 and 13.37 as supported releases is about as few
> >supported releases as Fedora Core, even though FC comes out with new
> >releases more often.
>

> Pat is only stopping 12.0 (the 5 year old one), 12.1 and 12.2 will still
> be maintained.
> So that makes 5 releases, of which the last 3 (the 13.x ones) in 2
> architectures (32- cq 64-bit).

Yes, you are right there. So there is now 5 maintained versions. But
still, there are plans to stop support for 8 of 13 maintained releases
August 1.

> If _I_ would have been Pat I would have eol'ed 12.1 too, 12.2 is the
> better release.
> And the update support for releases before 11.0 was rather minimal
> anyway. I.e. 10.2 in 2011/12 only got updates for sudo, dhcp, fetchmail,
> libpng, libtiff, samba and libxml2 (some of them multiple times). That's
> only 7 packages that have been maintained. 11.0 got more then double
> that. So these version were getting too old for maintenance anyway.
>
> PS: I haven't got newsgroups anymore, the university and surfnet (the
> academic network within the Netherlands) have stopped support for it, so
> that's why this reaction in E-mail. I saw your message in google groups,
> which I _sometimes_ watch to see if anything interesting pops up.

[Henrik Carlqvist]

Continuing the email to usenet conversation...

On Mon, 25 Jun 2012 09:59:22 +0200
"E.J.M. Hartman" <E.J.M....@tudelft.nl> wrote:

> On Fri, 2012-06-22 at 22:20 +0200, Henrik Carlqvist wrote:
> > there are plans to stop support for 8 of 13 maintained releases August
> > 1.
>

> Which have been maintained in some form a lot longer then anyone had a
> right to expect. 8.1 has been released just about 10 years ago (and even
> 10.2 is already almost 7 years old), I expected Pat to stop support for
> IT and the 9.x versions a long time ago.

Yes, still supporting Slackware 8.1 from 2002/06/18 is really impressive.
To compare this with some other distributions:

The first Ubuntu version was 4.1 warty from 2004/10/20, more than two
years younger than the oldest Slackware release still being maintained
today!

RedHat went a little bit more commercial with their Enterprise Linux 2.1
2002/03/26 for which they offered commercial support. 2009/06/01 they
noted that their 7 year life cycle had ended.

> Those very old versions aren't all that maintainable anyway, too many
> newer upgrades won't even compile in it anymore. I must admit I didn't
> expect 11.0 and 12.0 either, those are still reasonably up-to-update.

5 years support is still rather good, but it isn't as awesome as the
support we have today. I don't expect any release to be supported forever,
but I was a little unplesantly surprised that so many releases was dropped
at once.

[Henrik Carlqvist]

Robby Workman <newsg...@rlworkman.net> wrote:
> Put simply, supporting old releases brings in zero revenue - making
> new releases brings in nonzero revenue.

Another idea...

Today it is possible to subscribe to Slackware releases which might ship
"approximately every six months" or maybe not that often which will give
less revenue to Slackware.

What about making it possible to subscribe to monthly updated installation
media containing the contents of the patches directory?

Or maybe at least producing updated installation media including the
latest patches every 6 months? Something like releasing "Slackware 13.37
with service pack 1" 2011-10-28, six months after 13.37 was released. And
a "Slackware 13.37 service pack 2" 2012-04-28 one year after 13.37 release.

To get subscribers to monthly patch CDs it would probably be necessary to
cut costs, trying to find cheap shippings and some other package than
jewel case.

[er1ch]

Am Tue, 03 Jul 2012 20:46:00 +0200 schrieb Henrik Carlqvist:
[...]
> Another idea...
[...]

> What about making it possible to subscribe to monthly updated
> installation media containing the contents of the patches directory?
>
> Or maybe at least producing updated installation media including the
> latest patches every 6 months? Something like releasing "Slackware 13.37
> with service pack 1"

[...]

> To get subscribers to monthly patch CDs it would probably be necessary
> to cut costs, trying to find cheap shippings and some other package than
> jewel case.
>
> regards Henrik

This is a good idea, I'd subscribe to a patch media like that.

Erich