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

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.

                                  ( bcwhite@pobox.com )

 Don't marry someone you can live with.  Marry someone you can't live without.

Reply to: