[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Another "testing" vs "unstable" question



David Fokkema wrote:


The problem is someone deploying stable _now_ has a little over a year, someone deploying stable in two years can expect two years of life...

The cycles are too long.

If the cycles were shorter, people would install systems which would be
outdated in less than six months time, to take a RedHat point release
for an example. Right after 7.1, you would have 6 months. After _only
three months_, you would have to start looking for 7.2.

While RH was releasing about every six months, releases were supported by security (and other) fixes for some years. I think RHL 6.2 and 7.3 became unsupported last December.

The cycles are too short. RedHat's and some other's, that is.

Just my opinion, of course.

I'm a refugee from Red Hat because its free support model became too short, and there was no paid-for support I found attractive (far too dear).

If you found RedHat's cycle too short, why is Debian's too long?

The support cycle was quite a deal longer than the release cycle. RH didn't drop support a year after the next release.



I have been to www.apt-get.org and I got Mozilla from here, pine from there, KDE from somewhere else, Xfree from another... Do you get the picture?

Yes, I get it. Your sources.list grows. But if you have been careful
constructing it (newlines, comments, etc.) you know what comes from
where.

What if the pine person also provided Mozilla? Or worse, glibc 2.3? It got completely out of control.

Then don't go to apt-get.org and stick with backports.org. You have to
specify new sources for _each_ package. You _only_ get what you want.

My desktop system, while it still worked, was becoming a real mess until I upgraded to Sarge (not without some difficulty, the upgrade wanted to remove lots of kit I didn't want removed).

Don't tell me I could pin things, until you point to the obvious documentation I missed.

I won't.

And what about security updates? I'm not going down that path with any system I'm paid to support.

I agree with you. No testing on servers.

A coordinated, official system of official backports would be a fine thing, and the workforce to do it is already there - they're the people making these unofficial backports.

Official? Debian has made its decisions: a great amount of freezing,
testing, installing, testing, trying to break things, etc. goes into a
stable release. The _whole_ system is tested, not individual packages.
You can't do that for individual packages between stable releases,
because updates come too fast. Run unstable for a while, you'll know
what I mean.

And hey! What's the difference between official and unofficial anyway?
What kind of extra support do you expect if Debian would just label
www.backports.org as official?

For starters, links from the official website. Perhaps the hostname backports.debian.org, or the location www.debian.org/backports/

The ability to tick "backports" when doing a package search.


Please, no. Debian stable is rock solid, something RedHat, in my
opinion, has never been able to achieve. I would love to hear from
people who are still running a RedHat system older than two years. I
know of a lot of people who are running such Debian systems and are
satisfied with it, apart from the usual thoughts: oh, would that I had
_both_ that stability _and_ the newer software. But still, they choose
stability.

I've got three of these to care for:
[summer@ts summer]$ rpm -q redhat-release
redhat-release-7.3-1
[summer@ts summer]$

and one running RHL 7.0 that I've already mentioned.

None of them has given any particular problems. We even had up2date working on one of them, but for various reasons I didn't usually bother with up2date.

fwiw I was much amused when I first tried Knoppix (it was, I think, a 3.2 beta but it might have been 3.1). The hardware detection is done with Red Hat's tools.

The RHL 7.0 system is due to retire.




Reply to: