Debian flamewar (was: OpenOffice doc...)

Derek Martin invalid at pizzashack.org
Thu Feb 17 23:12:01 EST 2005


On Thu, Feb 17, 2005 at 06:30:10AM -0500, Neil Joseph Schelly wrote:
> So use those kernels? It's still the same code.  Pick your kernel from 
> kernel.org or from various patchsets or what have you.  The kernel really 
> doesn't have to do with the distro.

What part of "the installer doesn't have the kernel I need to install
this bloody distro on my hardware" are you not comprehending?

> You keep telling me about mission critical systems in your business.
> You insist that stable is necessary for that, but turn the argument
> around when it comes to the shiny bleeding edge desktop and say that
> Sarge isn't close enough.  

You're suggesting that bleeding edge can't be stable...  I think this
is where you're going wrong.  A new release of Red Hat Linux was
generally pretty stable.  There were always a few gotchas after it was
first released, but no more than with Debian stable.  Oh yes, as
stable as stable is, it still has bugs, and requires updates.

FC3 is probably a bad example, because Fedora Core is more bleeding
edge and less reliable than stable releases of Red Hat Linux used to
be, but that's intentional.  So let's say Suse Pro instead.  It's more
current than Woody, and I believe more so than Sarge also, but it's
still considered stable and by all acounts very reliable.  At Mission
Critical Linux, we used the latest stable releases of Red Hat for all
new installs.  Only the kernel guys ran Debian, they all ran unstable,
and it was fine for them.  But fixing problems they found was their
job... so it worked for them.  For everyone else, we had a lot of
banging going on at our door whenever there was a slight glitch.
Risking bugs in testing or unstable was not an option.

> Pick one point of view and stick with it. 

Once again, you're completely missing the point.  Only Debian takes 3
years to put out a stable release.  Other distros HAVE stability while
also being more up-to-date.  And because of that (and support reasons
too), they are better choices than Debian for production environments.
I am not saying Debian is bad software, it isn't.  Nor am I saying
you are a bad person for choosing it.  There simply are better
distributions for production environments.  Your sysadmin team seems
to agree with me, you've already said they use RH in production...

> Pick the right release for whatever you're using.  Don't keep coming back to 
> me and saying Stable is too old for a desktop and Testing is too unstable for 
> a server.  

I'm not saying that at all.  I'm saying Stable is too old for nearly
ANYTHING, in a production environment, and Testing is too unstable for
nearly ANYTHING, in a prooduction environment.  The reason is simple:
other distros have just as much stability while at the same time being
newer and more featureful than their Debian counterparts.  As a side
issue, they also usually come with vendor support, though Red Hat
seems to have dropped the ball on that account.  If I were evaluating
distros for production environments TODAY, I'd probably give Suse a
good hard look before I even considered Debian.  It's been a long time
since I've seen what they have to offer.  And if I didn't go with Suse
for some reason, I'd almost certainly pick RHES or its counterparts
over Debian.

> I'm well aware of that, but you're using that argument as a means 
> of describing how neither is useful at all.

No, they're plenty useful.  But for the vast majority of production
environments, other choices make more sense from both a usability
perspective and a configuration management perspective.  Most distros
have a lot of their own bells and whistles to make a variety of things
a lot easier.  In my experience, Debian lacks in this department also,
requiring a lot of things to be done manually and in some cases even
painstakingly.

> New development happens in unstable/sid. I've said it way too many
> times now that, this close to a stable release, testing is just as
> solid on a desktop.  

Even if that's true (which I dispute), so what?  The problem is that
you are dependent upon being at a specific stage of a development
cycle for that to be the case, and SANE businesses can't and won't
depend on that.  It's clear that you still don't grasp the ideas and
importance of configuration management.  I must not be required to
change the software on my machine simply because the developers are
entering a different phase of development...  Reconfiguring systems
must be done on MY terms, and my terms only.  In other words, changes
need to be able to be planned solely on busines need, not because of
what the vendor is doing.  You simply don't have that with Debian.

> To call it "stable" as an adjective is not lying.  Calling it by the
> stable/testing/unstable release names is just semantics.  

That's preposterous.  It's called testing because it's being tested.
When problems are found, changes are made.  

I also occasionally write free software, and I had software which was
in Debian testing, which was pulled from testing (or so I was told by
the maintainer) because I decided I didn't want to fix a bug.  That
happened a month ago.  A change was made.  It's not stable.  Stable,
by definition, means IT DOES NOT CHANGE.  Why is that such a hard
concept for you?

Note that this was not just a simple bug fix, which happen in all
stable releases (including debian), but a package was actually
removed from the distro!  That doesn't seem very stable to me...

> If you recount experience from way in the past about testing
> breaking things a year or more ago, there's a good reason.  Stable
> was new enough that you didn't need to use Testing for modern
> software.

That's not a good reason, and I don't agree.  Other distros were just
as stable and a good bit newer.

> > > Take that assumption and you realize that everything you said
> > > above is meaningless.
> >
> > That assumption is patently false.
> 
> You're not very good at math are you.  

I don't see what it matters, but yes actually, I am.  Pretty much
traight A's all through high school and college (except for one year
when I had working and bands and girls on my mind ;-)...  Since we're
on the subject, it was about the same for my MIS, computer science,
and Unix system administration classes, too.  But I don't see how math
comes into it.  We're not talking about math at all here.

> That assumption is supposed to be made to guide the discussion in
> the right direction.  

I say it again, that assumption is patently false.  If an assumption
is false, then using it to guide anything in the right direction is
folly.  If I were to make an assumption which I knew to be false, and
rely on that asumption to support any argument, I would be stupid.  I
suggest you take a logic class...

> Either we work with that assumption or we work on discussing that
> assumption.  Not both at the same time which makes my responses to
> you as randomly guided as the back and forth arguments you're
> making.

All of the arguments I have made were in direct response to comments
that YOU made... so if we're meandering, by all means blame yourself.

> If you disagree, that's alright.  Since you disagree with that,
> there's no point in further discussing here.  

That at least seems evident by this point.

> You obviously just have a preference for other setups and a lack of
> patience for things that aren't what you're used to.

You haven't the slightest idea what I'm used to...  I've personally
used Debian and supported it in production for about 3 years...  I've
been using Linux and/or managing it in production environments, both
large and small, along with Solaris and HP-UX, since 1996.  I prefer
other things because I prefer them, and if I'm less familiar with
Debian it's because I don't prefer it.  FWIW, I tried Debian before I
used Red Hat...  I still like Red Hat better.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20050217/508d3613/attachment.bin


More information about the gnhlug-discuss mailing list