Re: Debian is slower than time (was: adrian's 2.4.x packages)
> > > And if you want an up to date workstation just run testing/unstable and
> > > you are way ahead of any other dist.
> >
> > Good in theory, bad in practice.
>
> Works great in practice. Everyone who uses Linux here use Debian
> Unstable.
I don't have a problem with "unstable" except that it's unstable. My guys
depend on their linux boxes working. Every time I do an upgrade, I risk
breaking something and imacting their schedule. That would not make me
a very popular sysadmin.
The problem with "unstable" (for this kind of use -- it's not a problem
in general) is that there is no restriction on what kind of changes can
go in to it, and that can wreak havoc on a functioning system. What if
exim were to change its config-file a bit and mail was unavailable? (This,
by the way, actually happened when exim moved its config file from /etc
to /etc/exim.)
What if a change to glibc caused an incompatibility with the ASIC tools
they run? I simply can't take those kind of chances. I need a distribution
that is unchanging except for bug fixes. On the other hand, I can't let
the software get too out of date. The "unstable" distribution does not
meet the first criterion and "stable" has not been meeting the latter.
> > So now, my servers run unstable because they need newer software. But
> > guess what... There is no security tracking. If a vulnerability is
> > found, there are no notices to tell me about it.
>
> That is a huge problem. But that will not change with short release
> cycles. Either you always keep up to date, or the security department
> have to take care of more than one release.
I would disagree with the first point. For the second, I agreed that the
security department should not have to monitor "unstable".
A shorter release cycle of, say N months, will mean that software is no
more than N months ouf of date. You need to balance N with stability and
a "maximum N" is (as you said yourself) what this discussion boils down to.
> > I don't have the time to re-certify all of the packages on all of my servers
> > every week. Once every 6 months I could do. In the intermediate time, I'd
> > love to be able to install bug fixes without having to worry about
> > compatibility.
>
> I just said that a 1 year release cycle is okay. I do not think too long
> release cycles are good. Potato are outdated, yes. I do run woody on my
> servers too. What I said was that release cycles about a year is okay.
> That way you run software that has been tested for awhile, you do not
> need to update all the time (which most users does not need to, since
> when a server works it'll probably just sit there and do it's work).
I don't disagree with you at all here. I would prefer a 6-month cycle
but in truth I think a 12-month cycle would function nearly as well.
For a server that is static and working, there is little reason to upgrade
except for security patches. I had a 486dx2-66 running 2.0 and never touched
it. There was no need -- the thing was a rock. It servered over 250,000
web hits a day and had been up for nearly 400 days when I finally powered
it down to ship it elsewhere.
> 4 month release cycles are too short imo. 2 years is too long. I'm just
> trying to say that I do not want to see a release every 4-6 months.
I agree that 4 is too short. I think 6 would be great but I'm not sure
that is practical. The steps in performing a release are just too large
to be done that often.
> I have apparently not been clear enough. Let's just drop this
> discussion, and come to the conclusion that potato is outdated, shall
> we?
I think we were just coming at the thing from different points. Our
opinions on the subject aren't all that different. The real problem
as I see it, is how can we work at getting things out more frequently.
Brian
( bcwhite@pobox.com )
-------------------------------------------------------------------------------
Don't marry someone you can live with. Marry someone you can't live without.
Reply to: