Re: When Debian 4.1 will arrive... will anyone care?
On Fri, Apr 20, 2007 at 05:34:39PM +0200, Frank Küster wrote:
> > and the same is true of packages in backports. a serious bug can break
> > your system (or, at least, require significant effort to get it back to
> > a known good state).
>
> I argue that the probability of a serious bug in testing, and hence in
> backports, is less than in unstable. Moreover, there's an additional
> check built in, a person has to decide "this package is fit for a
> backport".
a serious bug in testing can last a lot longer than it does in unstable.
if a buggy package trickles from unstable to testing before anyone
notices the bug and files a report, then (depending on the state of
other packages that might be held up, or holding it up) it can stay
in testing in that buggy state for weeks before a fix trickles in. in
unstable, a new version is there immediately, almost as soon as it is
uploaded.
testing is not lesser risk, it is different risk.
> And it's also safer than running a mix of "stable" with partially
> upgraded libraries.
but that's what backports is.
> > AND, as i said before, anyone with any sense whatsoever will test
> > *ALL* upgrades, even the most trivial, on another machine first
> > BEFORE applying it to their production servers. anyone who doesn't
> > do that should be blaming themselves before they blame either
> > unstable or testing or backports.
>
> There are users who do not own a production server, instead a single
> computer, and still feel the need for newer packages.
then they should run testing. or ubuntu.
i dont get those who whine about debian being old and stale. if they
used 'testing' or 'unstable' rather than being scared off by the name,
they'd have a system at least as bleeding-edge new as ubuntu or any of
the others.
and if they choose to use stable then they should quit whinging about
it.
they have a basic choice - is a stable environment or bleeding-edge
packages more important to them? they can't have both, because they're
mutually exclusive. choose one. live with the decision, and quit
whining.
one of debian's big advantages over other distributions was that it
is a "live", internet-based, constantly updating system (if you use
testing or unstable)...and that upgrades actually work. other dists
(esp. debian-based ones like ubuntu) have the same feature now......but
we still have debian developers and debian users who refuse to even
recognize that it IS a feature. they insist on seeing debian as just the
stable release.
> > if you're going to attempt lame grammar flames, then at least do so only
> > in languages in which you are proficient.
>
> The fact that you compare backports libraries to *unstable* still makes
> me wonder whether you know what you are talking about, grammar or not.
> If you'd used "testing" up there, I would not have wondered. And you
i've been talking about both testing and unstable all along. it just gets
tedious typing 'testing and/or unstable' every time so occasionally i just
refer to one of them when i mean both or either.
my point remains the same whether it's testing or unstable. just as
'testing' is a variant on unstable, backports is another variant on
unstable. it's not less risky, it just has a different set of risks.
> won't deny that there are serious breakages in unstable every now and
> then, and that they affect testing much less?
actually, i've had a lot more trouble with 'testing' systems than
unstable. there can be very long delays for packages to trickle from
unstable to testing - one important package held up by a bug report can
cause dozens of other packages to be held back too...some of them with
important bug fixes. in 'unstable', there's a fix for that same problem
in the next day or so...in 'testing', it could take weeks.
> > sometimes it happens, sometimes it doesn't. it may or may not
> > happen. that's besides the point. the point is, you can't count
> > on it. tex may have had the upgrade path tested. apache or php or
> > whatever may not have. the point is, that the upgrade path from
> > backports is far less tested than either 'testing' or 'unstable'.
>
> That's all true. But this only means that running stable is safer
> than running stable+backports. It doesn't say anything about
> stable+backports vs. testing (or unstable).
i disagree with that too. stable isn't necessarily safer than testing
or unstable or backports. it too has its own set of risks. specifically
the risk of running ancient software with security holes that no-one
has discovered (or backported a patch for) yet or, more commonly,
that is incompatible with some other newer software that you might
want to run (hence providing the motivation to install stuff from
testing/unstable/backports).
many times over the years i've seen security updates come in for
'stable' packages, and when i check the version i'm running in
'unstable' find that it was fixed months before or that the conditions
required to exploit it aren't possible with that version. i've also
seen the occasional security update for stable that isn't yet in
unstable....that doesn't last for very long, at least not if a package
has an active maintainer.
quite often the security update occurs in unstable before it occurs in
stable because the stable update is often a backport of a fix in the
newer version anyway.
security-wise, 'unstable' (and, to a lesser extent, 'testing') is a
much smaller risk than 'stable'. IMO *AND* IME.
there may be other reasons to stick with stable for a particular
machine, but security updates isnt one of them.
craig
--
craig sanders <cas@taz.net.au>
BOFH excuse #6:
global warming
Reply to: