People who are reading Slackware ChangeLogs out of habit will have noticed this in June, but others may still be unaware.
Slackware has a history of releasing patches for versions of the distro going back as far as Slackware 8.1 (which saw the light on 18 June 2002). That is a longer “long-term support” (LTS) than any other Linux distro out there!
With each release that followed, the work load of backporting patches to old Slackware versions became bigger – naturally so, since Pat saw this as his sole responsibility and none of the others in the team were involved. This summer, the point was reached where decisions needed to be made in order to keep the work manageable when yet another release is going to be added: version 14.
And so, almost 10 years to the day after Slackware 8.1 was officially released, the following text appeared in the ChangeLog.txt of all releases from 8.1 upward to 12.0:
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 security@slackware.com. # ####################################################################
Yes folks, this is Pat’s EOL announcement for all Slackware releases prior to 12.1. The aforementioned date of August 1st ihas come and gone. From now on, you will only see new patches arriving for Slackware 12.1 , 12.2 , 13.0 , 13.1 and 13.37 (and of course any newer version that follows). Rest assured that your favourite distro will remain strong, focused and secure as ever!
Eric
That’s one of the thing that sets Slackware apart from the mere hobbyist distros… and even from some of the bigger players. Let’s take Debian, for example, which provides updates for one year after release+1. Now let’s imagine the upcoming Debian 7.0 Wheezy gets released around December this year (my bet). This means that when a client asks me to install a server for his company in October or November, I can choose to either a) install the not-yet-stable Wheezy and go for approximately three years of updates, or b) stay on the safe side, go for the stable 6.0.5 Squeeze… and see updates stop after a little more than a year. One of the many reasons to choose Slackware.
That being said, I wonder what happens if there are any serious security issues in the Slackware release kernel. As far as I remember, I never saw any security patches provided for the kernel. Did I miss something here?
Follow-up: my bad. http://www.slackware.com/lists/archive/viewer.php?l=slackware-security&y=2010&m=slackware-security.548585
I started slacking with 12.0 but happily follow -current. As my rig is getting “up there “I think I’ll stabilize on 14 when it arrives.
Since I generally only follow the -current ChangeLog, I was unaware of Pat’s EOL notice. Thanks for pointing it out.
I’m sure it will reduce Pat’s workload by a good bit.
> With each release that followed, the work load of backporting patches to old Slackware versions became bigger
Slackware usually doesn’t backport patches but packages upstream updates instead.
@ammo42
Your statement “Slackware usually doesn’t backport patches but packages upstream updates instead” is incorrect.
Slackware _does_ backport patches for old releases, but only in those cases where the developer of the bugged software released his patches just for the most recent version(s) of his software.
The farther you go back (i.e. the older the Slackware release) the more difficult it becomes to create proper patches for the old software versions contained in that Slackware release. This is probably the main reason why maintaining old releases was becoming such a burden for Pat.
Eric
> Slackware _does_ backport patches for old releases, but only in those cases where the developer of the bugged software released his patches just for the most recent version(s) of his software.
But only in some cases: for example Slackware doesn’t backport Firefox patches, while Debian does.
Actually, since I kept the advisories in my mailbox, I could count how much there was backports vs. upstream updates: there were more upstream updates than backports since Jan11.
I’m not calling Pat a lazybones or anything — even upstream updates still have to be built and tested.
Indeed, only in some cases. Your example of firefox is typical of a case where Slackware just adds the new firefox to the /patches directory of an older stable release where other distros would stick with the old firefox version and backport patches from the newest version to that old version.
Slackware takes a pragmatic approach – there is only so much you can do single-handedly. That is not a bad thing, it’s just different.
Eric