By Jake Edge
August 28, 2013
The allure of "long-term support" (LTS) releases for a distribution is strong.
We have seen various distributions struggle with the idea of an LTS release
over
the years and, of
course, Ubuntu has five years of official support for its LTS. More recently,
Debian started discussing a "Debian LTS" on the debian-devel mailing list.
As is often the case, the "many years of support" idea may well run aground
due to a
typical
problem for community distributions: people power.
The posting of a June announcement
that the DreamHost hosting service would be moving from Debian to Ubuntu LTS
sparked the discussion. The switch was made because the "release
cycle for Debian is stable, but it's not long enough for us to focus on
stability", according to DreamHost. The support window for
a Debian release is one year after the next stable release, which generally
works out to around three years.
For some—DreamHost included—three years is not enough time. The main
problem for extending the Debian support window, unsurprisingly, is
security updates. Though, as Russ Allbery pointed out, some Ubuntu LTS users may not
actually be getting the full support they are expecting, because it is only
the packages in the "main" (and not "universe") repository that get that
support.
Rather, they just blindly assume that LTS having security
support for five years means that, as long as they regularly upgrade, they
don't have to worry about security.
They therefore end up running various non-core software with open security
vulnerabilities.
But that problem is not limited to Ubuntu, as Paul Wise noted. Currently, Iceweasel (Debian's version
of Firefox) is no longer supported for squeeze (Debian 6.0) and other
packages have fallen out of support during the one-year oldstable support
period in the past, he said. The sheer size of the Debian package
repository makes the support problem that much harder, which is presumably
why Ubuntu has focused its support on a smaller subset.
There also seems to be some disagreement among Debian developers with
regard to handling security updates. Some, like Pau Garcia i Quiles see security updates as the responsibility of
the package maintainer (with some assistance from the security team). Others, like Steve Langasek, believe it is a security team function with
input and assistance from the maintainer. In
the end, it may not really matter; without volunteers to prolong the
support, no LTS is possible. As Ian Jackson put it: "unless and until we have
people who volunteer to do the security support for an LTS, we won't
have an LTS".
There is more to it than that, however, according to Allbery. He argued that beyond two years, security support
is somewhat illusory, even for the enterprise distributions. Once the
upstream projects have moved on—and by two years after a release, they mostly
have—it becomes harder and harder to support older releases.
I'm painfully aware of the steep cliff
dropoff of upstream support for security fixes once you go beyond two
years after the release of the software. Beyond that point, even if you
do get security fixes, you're probably getting fixes that have been
backported by people with only a vague knowledge of the code, fixes that
often have not been thoroughly tested or tested by someone who uses the
software in question and that upstream has never looked at and will
disclaim any knowledge of or support for.
As painful as it is, if you are worried about security in a production
environment, falling more than a couple of years behind current
distribution releases is probably not in your best interests no matter
what security support you supposedly have.
Wookey took a different tack, however,
noting that organizations like DreamHost should, if they are interested in
longer-term
support, be funding the work. Philip Hands agreed, pointing out that it is "not an exciting task that
volunteers can be expected to flock to". He suggested that
interested companies band together:
If that made the somewhat more enlightened
companies band together to share the LTS workload amongst themselves
somehow (possibly by having a limited distribution model of some sort,
restricted to members of the mutual-support-club) then that would be no
bad thing either.
Hands also cautioned that community efforts at long-term support could be
detrimental to the distribution as a whole:
"I suppose it would be nice if we could provide this long term support,
but really it's going to consume scarce volunteer effort which will
almost certainly have a negative impact on the progress of Debian
proper." In many ways, that is the overall conclusion in the
thread. While there were numerous maintainers volunteering to support
their packages for longer, it really requires a distribution-wide
commitment (or that of a dedicated team), which doesn't seem to be appearing.
LTS releases are clearly popular with certain segments of the Linux
community, but it is a big effort—one that is difficult for a
distribution made up of volunteers to commit to. Even distributions that
are supported by companies, like Fedora, find that commitment to be
difficult, though Ubuntu LTS and openSUSE's Evergreen do provide
counterexamples. It doesn't seem unreasonable that those who want longer
support help make it happen, either via their efforts or their money. The
latter
is one way to look at the enterprise distribution model. For Debian,
though, money alone won't solve the LTS problem—it will require a fair
amount of effort from those
who need it.
Comments (12 posted)
Brief items
Hi, everyone who is bringing up removing the names (especially myself).
Let It Go. Move along,
Go find something positive to do and go do that. Let the people who have
fun doing this, do it and get out of their way.
--
Stephen J Smoogen
Comments (none posted)
The NetBSD Project has
announced NetBSD 6.1.1, the first security/bugfix update of the NetBSD 6.1 release branch. It represents a selected subset of fixes deemed important for security or stability reasons.
Comments (none posted)
OSTree
2013.6 has been released. "
It’s a tool for parallel installation
and atomic upgrades of general-purpose Linux-kernel based operating
systems, and designed to integrate well with a systemd/GNU userspace. You
can use it to safely upgrade client machines over plain HTTP, and longer
term, underneath package systems." See the announcement for a long
discussion of the motivation behind this project, along with
this LWN article from August 2012.
Comments (none posted)
The Ubuntu team has released the third update to its latest Long Term
Support release. The 12.04.3 LTS release is available for Desktop, Server,
Cloud, and Core products, as well as other flavors (Kubuntu, Edubuntu,
Xubuntu, Mythbuntu, and Ubuntu Studio). "
As usual, this point
release includes many updates, and updated installation media has been
provided so that fewer updates will need to be downloaded after
installation. These include security updates and corrections for other
high-impact bugs, with a focus on maintaining stability and compatibility
with Ubuntu 12.04 LTS."
Full Story (comments: none)
Distribution News
openSUSE
The openSUSE Evergreen team has announced that openSUSE 13.1 will be the
next Evergreen release. "
This means that openSUSE 13.1 will
continue to be supplied with security updates and important bugfixes
until it has had a total life time of at least three years."
Full Story (comments: none)
Newsletters and articles of interest
Comments (none posted)
Matthew Garrett
argues for
a clearer focus for the Fedora project. "
Bluntly, if you have a
well-defined goal, people are more likely to either work towards that goal
or go and do something else. If you don't, people will just do whatever
they want. The risk of defining that goal is that you'll lose some of your
existing contributors, but the benefit is that the existing contributors
will be more likely to work together rather than heading off in several
different directions."
Comments (31 posted)
The SUSE openSUSE blog has an
article with some in-depth statistics on the reach of the distribution. It includes various numbers and graphs on downloads, installations, the use of the
Open Build Service, as well as a comparison with Fedora. "
As you can see, Fedora has more downloads than openSUSE. Looking at the users, the situation is reverse: openSUSE has quite a bit more users than Fedora according to this measurement. How is this possible? The explanation is most likely that most openSUSE users upgrade with a 'zypper dup' command to the new releases, while Fedora users tend to do a fresh installation. Note that, like everybody else, we're very much aware of the deceptive nature of statistics: there is always room for mistakes in the analysis of data. To at least provide a way to detect errors and follow the commendable example set by Fedora, here are our data analysis scripts in github."
Comments (15 posted)
Page editor: Rebecca Sobol
Next page: Development>>
