Re: [tlug] Looking for a distribution to replace Ubuntu

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

Curt Sampson writes:
 > On 2008-11-24 17:40 +0900 (Mon), Stephen J. Turnbull wrote:
 > 
 > > Debian provides a decent resolver (liblwres and lwresd) and has done
 > > so for ages.
 > 
 > Hm. Fair enough. However, I can't say I'm terribly interested in using
 > it because, for various reasons, I don't want to set up lwresd. (Note
 > that liblwres does not use the DNS protocol.)

So what?  That's generally a purely internal affair, with the possible
exception of getting arbitrary DNS records.  It just happens that to
provide a global cache they put it in a separate process rather than
fsck things up with file locking or whatever.  You have your various
reasons, of course, but the alternative is setting up BIND or djbdns
or something, right?  Not obvious to me that lwres isn't cheaper in
some sense than the alternatives.

 > > Recent releases of binary packages are almost by definition not
 > > production-ready.  Who are you kidding?
 > 
 > Well, then perahps we differ on our definition of "production-ready." Or
 > are the binary packages of authors latest releases generally less stable
 > for some reason than the authors' releases compiled from source?

Yes, they are.  You know what DLL hell is.  Un*x is not exempt.  At
least if you compile from source you know that what configure saw is
pretty darn close to what will be on your system in production.

 > But anyway, here are a couple of examples of what I'm looking for. (You
 > can let me know your term for this, if you like.)

"Wishful thinking." ;-)

 > I'd really like a 2.5.x version of pidgin. 2.5.2 has been out for over a
 > month,

If you think a month is a long lag, then you aren't a long-time binary
package user.  On the bleeding edge (Debian "sid", which is actually
quite usable for a workstation but I don't trust for a production
server), you'll see 15 releases of the package for that version come
out in 3 months for an active package.  8 of them will have broken
infrastructure and won't install right, 5 of them will have some
Debian-policy-mandated change, and 2 will have security "fixes".  That
kind of thing.  If you're unlucky, the Debian maintainer will also be
an upstream developer, and use his Debian power as a ruse to sneak in
some of his favorite patches that upstream didn't accept yet.

If the package depends on more or less unstable libraries (can you
spell "GNUMB"^W"GNOME"?), then things get worse.  Some packages will
depend on more recent versions of the libraries, other on an older
legacy version.  Since Debian policy strongly discourages creating a
fork, you can't just upgrade the internal APIs for the "legacy" app.
So you end up with maintainers of packages whose upstream aggressively
follows new versions of the prereq libs negotiating with the
laggards.  This can take time, and when the version bump happens,
existing packages that didn't know they have a problem can get broken.
More fixing, etc.

This is all a caricature, and worst-case, of course.  But it's based
solidly in fact.  The bad case won't necessarily hit you in your
mission-critical cojones, but it won't necessarily miss, either.

My experience with the distros that try to keep up that way (Debian
sid, Gentoo, MacPorts) is that source-based distros are a lot more
stable.  But even in Gentoo and (especially) MacPorts something is
broken (usually in GNOME, often gnomevfs) "most" of the time.

 > Last time I was using Debian, some time after PostgreSQL 8.1.1 was
 > released (after a long and happy 8.0.x set of releases and an 8.1.0
 > release), Debian's latest package was still a 7.4.x release, which at
 > that point was deprecated by the PostgreSQL project.
 > 
 > It could well be that I'm missing something here about Linux distro
 > upgrade procedures, as compared to NetBSD pkgsrc.

With a source release you rely on the upstream QA, configure, and (in
a pinch) end-user creativity in rebuilding.  The first two are
generally pretty good, and not much is left for the end-user admin to
catch.  Binary distros require several more sigmas for the same degree
of user satisfaction.

Also, I think you may have missed something (unless you were using
Debian stasis^Wstable), because I've been using the Debian PostgreSQL
packages since 5.x IIRC (I don't really care, I don't use any
strenuous SQL, but it was a matter of upkeep on the libpq bindings in
XEmacs Lisp).  There were like 6 month lags for all the "point oh"
releases.  This is in "sid".  However, since PostgreSQL 7, they aren't
named "postgresql".  They're named "postgresql8" and now
"postgresql-8.1" etc, as many users don't want to upgrade.  So they
provide several versions built against the current base package.

 > issues like the PostgreSQL one above, certainly I don't want to be
 > running on my servers versions deprecated by their vendors and no longer
 > getting security fixes from them!

Guess what?  There are plenty of Debian stable users who disagree with
you, and those who don't learn to use the mix'n'match features of apt
to pull in more recent versions of a few mission-critical packages.

That doesn't mean you're wrong (and I wouldn't be surprised if "they"
*are* wrong), but it does mean friction.