[clue-talk] Hello CLUE

[T. Joseph Carter]

On Mon, Jul 31, 2006 at 07:21:02PM -0600, Collins Richey wrote:
> >> Hi Joseph.  Welcome to town.  I like your posts already!  (And I bet you
> >> know how to use a turn-signal, unlike the majority of folks who've moved
> >> here in the last 5 years or so!)  ;-)
> >
> >You'd bet wrong as I have never driven a car, and am not likely to in the
> >near future.  *grin*
> 
> I guess we won't be seeing you at CLUE meetings, then, or do you have
> a full time chauffeur?

DTC?  Probably a lightrail hop away from Littleton.  Of course, on a
Tuesday I will be at Littleton Downtown station near 5pm, so this causes
me to wonder what most nerds do for food before/during/after CLUE
meetings.  I can't imagine Oracle people letting us order a pizza or
something.  *grin*

I am unlikely to be lugging a tower anywhere unless someone to/from the
area in general--it's quite possible I will have to walk home from Mineral
station, which is at least a mile from here.  Littleton transit sucks, and
unfortunately I don't have a whole lot of choice as to where I live.  I've
got a friend who lives about three blocks from the 16th St. mall.  Lucky
razzin' frazzin' ...  He can get pretty much anywhere, anytime, without
ever even considering a car.


> >> I've been doing all sorts of Distros for a very long time, and the "one
> >> thing I can count on" is that Debian Stable will WORK for servers, no
> >> muss, no fuss, the damn thing just runs and runs and runs and gets
> >> timely security patches.
> >
> >It is, but only at the cost of being potentially unable to install on a
> >new server.  There's also something to be said for holding up ia32, amd64,
> >and powerpc architectures for a month while you wait for an Atari Falcon
> >to finish compiling X before release.  ;)  Or more importantly, before
> >releasing a security patch for other platforms.
> 
> Holding up is the primarily criteria for Debian release. If it doesn't
> work on all supported platforms, it's not ready for the 90% of us who
> use the most popular platform.

Holding up a patch for a remote root exploit for hours or days while you
wait for it to compile on some Atari Falcon that should have been
consigned to the bin a decade ago never makes for good security policy.
Get the patch out as fast as possible for as many architectures as
possible.  That policy is the only one that makes sense.


> >Again, I'd have no trouble with Debian stable if they'd actually consider
> >things like an updated kernel and maybe X11 now and then.
> 
> I would not say that Deian sucks for desktops, it just doesn't
> sparkle. I was quite pleasantly surprised when I put up a Debian
> Testing system. Not as polished as Ubuntu Dapper, but parsecs ahead of
> anything Debian did in the past. Neither Debian nor Ubuntu is likely
> to consider a really up-to-date kernel, and Ubuntu has screwed the
> pooch thus far with the attempt to incorporate modular X.

I think you are making a glaring omission in your logic: that support for
current hardware is something you want in a desktop, not a server, and
this therefore makes Debian ideal for servers.  I'm not talking about a
kernel with the latest NV driver support here, I'm talking about a kernel
new enough to be able to read the #*@! hard drive, and maybe write an OS
on to it during the install process!  If Debian's installer is limited at
... what, 2.6.8 or so today?  Then it probably doesn't support 3GB SATA
chipsets very well or maybe at all.

Today any server I build is likely to have the IDE bus used only for the
DVDRW drive I installed from.  (Yes, I'd put a DVDRW on a server, you can
get them for $35 bucks nowadays, and its awfully handy to be able to throw
4GB of stuff on a $.25 disc..)


> > I digress though, sarge has the same problem regarding relatively recent 
> > hardware,
> >in the range of six months to a year old.
> 
> Yep, but the manufacturers insure that new hardware remains just
> beyond the grasp of Linux. Reverse engineering takes time.

The problem is that Ubuntu seems to have no trouble supporting hardware
that Debian won't with a release Ubuntu made first.  If you freeze your
kernel for stable 8 months to a year before you release it and flatly
refuse to upgrade the installer's kernel for three years, you are going to
get complaints about hardware support, such as those I am making, period.

Does Debian even use a 2.6 kernel by default in sarge?  How hard would it
be to update the installer to use 2.6.15 or even .17.7?  Not that much of
the toolchain would need to be updated to do it.  In fact, from 2.6.8,
maybe modutils.

Joel Klecker, may he forgive me for using this, said once: "We need to
divide Debian into 'core' and 'wtf-uses-this'", and he was almost dead on
the money with it.  I say almost because he was defining core to be a
larger set of packages than I would.  Basically, if Debian maintained a
relatively current but carefully scrutinized and small set of packages
that form "just enough to get Linux installed" on a separate release
timescale, every single technical objection I have to Debian would just
immediately evaporate.

Back in the days when dpkg -BORGiE was invoked often, we called the
project that maintained this stuff boot-floppies.  Sometime back then,
about four of us came up with this concept that would revolutionize Debian
and cut our release cycle times called Package Pools.  Rather than just
freezing unstable and making sure everything worked, we would maintain an
installable "testing" distribution where packages could move once they had
been found to be not more buggy than those they would replace.

One of the benefits of this was that it would allow the boot-floppies team
to have a reasonably clean and current set of base packages to work with
on a continual basis.  When a new release is made, it just uses the most
current set of boot-floppies.

If it had been implemented as designed, today with apt and everything,
you'd have something like this in sources.list:

# Main archive, currently "sarge"
deb http://http.us.debian.org/debian stable main contrib
deb-src http://http.us.debian.org/debian stable main contrib

# Debian base system, usually "current" at time of installation
deb http://http.us.debian.org/debian base 2006-07-22
deb-src http://http.us.debian.org/debian base 2006-07-22

# Updates to stable (may also be updates for base if your base is old)
deb http://http.us.debian.org/debian stable-updates main contrib
deb-src http://http.us.debian.org/debian stable-updates main contrib

# Security updates
deb http://security.debian.org/debian stable main contrib
deb http://security.debian.org/debian base current

# Uncomment these to make Richard Stallman cry...
# deb http://http.us.debian.org/debian stable non-free
# deb-src http://http.us.debian.org/debian stable non-free
# deb http://security.debian.org/debian stable non-free

For a package contained in base, the lifecycle works out sortof like this:
The package starts in unstable, as all do, and then is determined to be at
least as bug-free as the current one in testing.  (This is crucial for a
package in base, for obvious reasons.)  As needed, a snapshot of the base
packages in testing are tagged and tested, the result is tagged as the
distribution base, with today's date.  The current symlink is updated.

The last base before a new stable release should be tagged immediately
before the release is made since, at the time of release, base current
should have exactly the same packages as stable.  If you want to be 100%
sure that you have 100% stable, and your hardware is 100% old, you can use
the base packages that come with stable.  If you need to grab a newer or
current set of base packages, do so.

There are some minor details to be worked out here--basically that there
needs to be a method for obsoleting an old base.  Generally this should
happen at stable revisions, but because apt and the Debian archive evolved
differently than I would have wanted, apt doesn't have a way to have the
server say, "by the way, the base archive you're using has been folded in
to stable now."


I realize this would probably go better on -tech, but I figured it was
worth explaining so that you knew I wasn't just bitching about Debian CDs
belonging in a museum the day they are pressed.  I see this as a viable
technical problem, even for servers, and its one I hatched the basic
solution to on the debian-devel list back in 1998.

Back then, everyone but the archive maintainers thought it was a great
idea.  They grumbled about who exactly was going to take the time to do
the work.  A few people stepped up and were rejected because James Troup
didn't trust them with the archive.  (My understanding is that he didn't
trust pretty much anyone who wasn't already an archive maintainer with the
archive..)  Some years later, James rewrote the archive manager scripts
and we got the current pools implementation.  It's a little more manually
controlled than I intended, and it doesn't make having distribution tags
as easy as I'd have wanted, but that wouldn't be all that hard to add to
the current system.

It's just not likely to happen, mostly for reasons that have nothing to do
with the technical feasibility of doing it.