Re: Another "testing" vs "unstable" question
On Wed, Jun 23, 2004 at 01:10:11AM +0000, John Summerfield wrote:
> David Fokkema wrote:
>
> >On Tue, Jun 22, 2004 at 04:01:20PM +0800, John Summerfield wrote:
> >
> >
> >>Monique Y. Mudama wrote:
> >>
> >>
> >>
> >>>Indeed. I actually meant my statement to be in support of the stable
> >>>distribution. I guess I should have made that clearer.
> >>>
> >>>Still, no one benefits from having blinders over their eyes. Stable is
> >>>the most stable, and it's also the least current. I don't see how it
> >>>could be any other way. They're on opposite ends of the same spectrum.
> >>>
> >>>
> >>>
> >>>
> >>For me its lack of currency is becoming a serious problem. I'm deploying
> >>new systems: do I really want to deploy software that's not going to be
> >>supported much beyond a year? Do I really want to go through migration
> >>to new releases just after I've got it bedded down?
> >>
> >>
> >
> >That's the beauty of stable. It _is_ supported for well over a year.
> >Actually, make that two years. The only problem _right now_ is that if
> >you go with stable _now_, there is sarge coming. But apart from that,
> >stable is supported for years.
> >
> >
> >
>
> It's an on-going problem because new stables come out so infrequently.
> Someone deploying Sarge as soon as it becomes stable can look forward to
> four years (going on past performance) of support for it. I have no
> problem with that.
Ok.
> 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.
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?
> >>No I don't.
> >>
> >>My choices are going with testing: what then about security patches? or
> >>unstable? From my reading it's not unknown for unstable to be seriously
> >>borked for a time: I think new glibc did it a while ago, and gcc was
> >>forecast to do it shortly after.
> >>
> >>If I want to support a USB Laserjet 1200, then I really need the latest
> >>hpoj stuff: Woody is far too old.
> >>
> >>
> >
> >Woody is old, but have you looked at www.backports.org? A list of
> >
> >
>
> I have.
>
> >well-supported backports is available there. Security updates will be a
> >tad slower than unstable, which is behind stable. But then, you're not
> >backporting glibc, but imap servers or whatever.
> >
> >
> >
> I need my security updates _before_ they become a problem. Don't you?
Of course. That's why I won't even think of installing testing on a
server and won't install unstable either. In my opinion, servers should
be running stable. So they do. But then, I like mutt on my server to be
the same version as on my desktop running unstable. So I run that as a
backport. Also, a newer spamassassin is nicer than the one from stable.
These are both applications which run for local users and don't allow
incoming connections or things like that. If there is a security problem
with them, I can live with the slight delay. In my experience, security
updates are thoroughly and quickly done by the DD and the people at
backports.org read debian-security-announcements as well.
Again, I'm not backporting glibc, some unsafe kernel, apache or a mail
server. Probably that won't even be problem...
> >>What I find myself doing increasingly is building the occasional package
> >>from Sid for Woody: sometimes it's easy, sometimes it's too much trouble
> >>(think xfree where I think I found circular dependancies).
> >>
> >>
> >
> >Also, see www.apt-get.org for various backports, including xfree. But
> >then, www.backports.org also has an xfree backport. Check it out.
> >
> >
>
> 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?
> Until Red Hat Linux 8.0, Red Hat had two cycles of releases:
>
> Major numbers, 5.x, 6.x, 7.x maintained binary compatibility. Those came
> out with about the same frequencies as Debian releases.
>
> Then there were the minor releases, x.[0-3] coming out at about
> six-monthly intervals. One could take a package from x.2 and install it
> with minimal bother on x.0 or x.1, with every expectation of not
> breaking anything.
I'm sorry, I downloaded RedHat cd's, used them for a while with _no
updates_ whatsoever, downloaded a new set of cd's and the fun would
start all over again. I tried up2date or whatever it was called, but I
never got it too work properly. Maybe I'm too stupid, but it took me
only a while to figure out Debian and within a few weeks, I was tracking
unstable on my desktop. Of course, I could only do that because of this
fine list!
> It's a model Debian would do well to look at and see how it can adapt
> it, adopt it. Using this model, Sarge would be 4.0, not 3.1 because it
> breaks binary compatibility (new gcc, new glibc).
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.
David
--
Hi! I'm a .signature virus. Copy me into
your ~/.signature to help me spread!
Reply to: