Debian flamewar (was: OpenOffice doc...)

[Neil Joseph Schelly]

On Wednesday 16 February 2005 11:18 pm, Derek Martin wrote:
> It isn't a null argument; you're missing the point.  It isn't that the
> package depends on all the other packages, clearly that's not the
> case.  The point isn't even that it does or does not interfere with
> some other package.  The point is that it *MAY* interfere with other
> packages unexpectedly, and you have to test them all in order to be

OK, I'm missing the point then... that's a common theme with your responses.  
I'm not going to try quantifying my stance on issues with made-up math that 
makes for a highly unrealistic model of package development.  If it were 
realistic, none of the major releases would ever accomplish anything.

> My experience has been different.  I once installed testing on my
> workstation at work, and nothing worked.  Granted this situation isn't
> normal, but it illustrates the point.  That hypothetical example I
> gave about glibc wasn't hypothetical at all...  Though it may not have
> been glibc specifically, I don't remember.  Something made my system
> unusable.  I didn't have time to mess with it, so I promptely
> re-installed RH...

Updating the primary library that every package is based on is a big change.  
That was going on way before Testing was ready for real usage.  At that point 
in the Debian release cycle, you shouldn't have been using testing.  My 
points so far have been about Testing now.  Testing, now, is reliable.  It 
was sort of usable then, but only with a lot of work.  I was running stable 
then on my desktops and never felt behind then either.

> Newer software may not strictly speaking be necessary, but it's often
> desireable, because it's just plain better.  Faster.  Less buggy.
> Have nice features that make life easier.  What have you.

That's fine... pick the appropriate release for your needs.  Sarge is fine for 
desktops now (not when glibc was being changed, but now).  

> If performance is a factor, newer software usually performs better,
> because the developers have had the chance to do more optimizing
> (however notable exceptions abound).  Newer software often has done a
> lot more than just plugged up old security holes; often it has
> re-designed the entire security model to make it inherently better.
> Sometimes, newer software just has happy bells and whistles that make
> managing it a lot easier than in old versions...

That's a very non-quantifiable and non-justifiable point.  To some degree I'm 
sure it's true, but on the same level as Gentoo being faster because it's 
compiled for your system.  I've never felt held back by the performance of 
the older stuff on servers.

> That doesn't mean you won't; it only means you've been lucky thus far.
> I have done similar things and been bitten by them.

Possibly, but that's unstable and I accept that.  Unstable is where this can 
happen, no question about it.  Just installing things with some intelligence 
is enough.  Don't install something that needs to upgrade/remove/replace half 
your running system without a little bit of hesitation and planning.

> My shiny new (hypothetical) server hardware is only supported by the
> 2.6 kernel...  What do I do?

You're just being silly now.  Why would you have to use 2.6 on a server?  What 
kernel does RHEL4 was only just released this week on 2.6. Does that mean 
that RHEL3 can't use 2.6 kernels?

> Historically, IIRC, just downloading an ISO was not easy to do.  If it
> is now, that's a welcome change.  But I still don't want to spend 4
> hours downloading a bunch of software that's 3 years old...
How was it hard?  You follow the links, visit the mirrors, and download it.  
That's always how it's been. And since when is testing 3 years old? Stop 
putting down stable when it suits you to make fun of age and putting down 
testing the rest of the time.  I can't even tell which you're referring to 
half the time.

> You don't seem to understand what we mean by "configuration
> management."  It refers to maintaining the software and configurations
> of the software of a group of machines in some known state.  Ideally,
> the state should be the SAME state across all the machines, unless
> there is a specific technical reason why it isn't.  APT does not and
> can not do this for you.
>
> APT does not and can not do this for you.  At least, not all by
> itself.  That's why configuration management doesn't depend on
> the package manager.

So what then do you use for this?  I can actually already see doing this with 
APT without issue.  But maybe I'm missing something still.  

> Disclaimer: Ben and I are both from the "old school" of system
> administration...  Keep everything the same, do things once, and do
> them right (as much as management will let you).  Change NOTHING
> unless not doing so will result in catastrophe (ok, I'm exaggerating
> here:-).  Do as little work as possible to keep things running well.
> Not because you're lazy, but because it shouldn't be necessary and
> your time is better spent working on something cool.  ;-)

That's why I use Debian.  And Ben seems to make much more grounded arguments 
for his stance, for the record.  I have trouble following yours and you 
continually keep jumping back and forth in your points.

Essentially, there are three points here:

Stability: Both Woody/stable and Sarge/testing have stability at this point.  
Testing doesn't always have stability, I'll admit, but right now, Sarge does.

Reliability: Both Woody/stable and Sarge/testing have reliability.  They 
aren't going to be seeing any significant changes, software versions, 
revisions from here on out.  Upgrades are safe with Sarge and very safe with 
Woody.

Cutting edge stuff: Woody is outdated and I've already accepted that.  For 
servers, this generally isn't an issue, but were I to setup a server now with 
Debian and if I needed things like Apache2, MySQL4, or Exim4, I would 
consider Sarge because it's very close.  Normally, only the stable release is 
appropriate here and this is just the worst time for stable since it is 3 
years old.

Whether you agree with those conclusions or not, I'll just say that summary is 
my perspective and I put it into practice regularly without issue and without 
difficulty.

-N