Re: [tlug] Firefox 3.0.1 doesn't respect <meta http-equiv="content-type">

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > > Since QAM is not a vendor, it can't provide that help....

 > I don't see why we are any less unable than Debian to "provide that
 > help" for Apache software.

Because AIUI QAM is a configuration manager, and not a database
mapping product versions to conffiles (which is what a modern distro's
PMS is, basically, except that it comes with a bunch of nearly
irrelevant cruft like binaries and docs ;-).

 > In fact, we're probably more able, since we at least leave you with
 > the vendors defaults, rather than making up our own and changing
 > them on you without notice.

But in almost all cases, Debian et al are simply updating to the
vendors' new defaults.  In most cases (ie, where it's a package I use
twice a month and can't remember what last week's defaults were) I
*want* this to happen.  In some cases, where old defaults were
security risks and new defaults tighten them up, I *need* either the
tighter defaults or the kick in the pants when an unsafe service fails
due to tightened defaults.

 > > I have to go find out what TRT is myself. QAM might be a better way
 > > for *vendors* to manage these things, but I don't use QAM so I can't
 > > judge that.
 > 
 > I'm not sure who you think a "vendor" is, but QAM is designed for the
 > guy at the pointy end who's actually deploying and running a server.

The vendor here is the entity that distributes the software, and
persists in kicking my legs out from under me by changing conffiles
behind my back at upgrade time.  Typically an OS distribution.

 > > As I mentioned, Gentoo does this right (without the aid of QAM AFAIK
 > > ;-).  It took me about 15 minutes to work through 150 conffiles
 > > updates when I got back from California and updated my system to
 > > current.
 > 
 > Riiiight.. Anybody who thinks that spending time working through config
 > files during an upgrade is a good thing doesn't manage many systems,
 > I'll tell you that.

If you are doing upgrades of software you receive from other vendors
without finding out what has happened to the conffiles, I'm scared for
your clients.  Of course I assume that what you mean is that you start
by reviewing whether the upgrade is needed, then work that conffiles
stuff out *before* you start mucking with the production hosts, and
you check the desired changes into QAM (however you spell what you do
with conffiles and QAM), test on "sacrificial" hosts as appropriate,
then distribute to the server farm or whatever.

I would do the same thing, except I don't have the responsibility for
keeping things up 24x7 (which I couldn't fulfil anyway because my
ISP's network and even electricity goes down for many hours at a time
for "scheduled maintenance" about once a quarter).  So I short-circuit
a lot of that.

 > What you do works for you, with only a couple of machines and a handful
 > of applications to manage. Try it with a couple of dozen production
 > applications on top of all the usual stuff (mail and so on) and a couple
 > of dozen servers running all of these.

Uh, no.  This works for me on my workstations and servers, with only a
couple of machines and thousands of packages to manage.

If I were running mission-critical stuff, I would do it differently.
But I would still want the advice of the system vendor at intervals,
and Gentoo's method seems like a good way to get it.