[SlugLUG] Help Me Choose
cerise at armory.com
cerise at armory.com
Fri Sep 29 14:11:21 PDT 2006
On Fri, Sep 29, 2006 at 01:04:16PM -0700, Sean Kellogg wrote:
> attending grad school. I started running Linux for the first time while in
> the dorms back in 2000. My friend installed slackware on my aging Pentium 90
> with a dual boot into Windows98. Ah, good days...
You mean back in the good ol' days when you had to hack in the modelines
for your X server by hand...uphill...both ways? ; )
I think it was that point that I realized that the mark of a true linux
geek was one who had a really pretty graphical desktop because it was *way*
harder to set all that up than it was to run everything in text mode. 8)
> In 2001 I, and several of my friends, made the slow and painful transition
> from various distros (slackware/red hat/mandrake) to debian. None of us have
> ever looked back.
My own history is similar -- I started with Slack, Red Hat, and Mandrake.
Slackware came out of that fight and enveloped the other two partitions.
Eventually, I moved to SMGL (which was based on Sorcerer). After a particularly
vexing glibc problem, I was convinced to move to Gentoo. I've stayed there
since.
> I'll leave the Debian bashing to someone else on the list, because there are
> usually plenty of detractors.
Not as many as I'd ever like to see. I'm the only person on the list who
regularly bashes it.
> Whenever I have to hunt
> down a bug fix for a problem I read "make sure you compile X with flag Y."
> And without fail, Debian has done it for me. Not only that... but with many
> bugs, if I wait a few days, the deb package will fix it for me.
Unless, of course, it's the first X.org release or a controversial package.
Besides, most distros work that way. It's the reason they have maintainers!
> After completeness comes consistency. Regardless of how upstream feels
> something should work, the debian packagers ensure the software conforms to
> detailed Debian Policies. This means that all services have an entry in
> the /etc/init.d/ directory, conf files are properly stored in /etc/,
> documents are in /usr/share/docs/PACKAGE/ and the crontab system is neatly
> organized. Once you learn how a piece of debian architecture works for
> software X, you've learned how it works for 99% of what remains.
Most distros do that too. LSB and FHS have helped a lot in that regard.
> After consistency comes continuous. I love that every day I run apt-get
> dist-upgrade and everything gets a little better. A handful of libraries, a
> few base-system pieces, maybe even software I use on a daily basis. I didn't
> need to know a new version was released upstream, it just comes when it's
> ready. And, if I don't want to get the upgrades, I can turn them down.
Most distros do that. I emerge --sync ; emerge -u world/apt-get update ;
apt-get dist-upgrade/yum update/sorcery system-update/whatever every night as
part of normal maintenance.
> First, note that stable is two releases behind current.
I've always found it helpful to adapt Harrison Ford in his first appearance
onscreen in "Indiana Jones and the Last Crusade". Imagine Indy in a computer
room yelling at some geek installing stable on a mainframe: "IT BELONGS IN A
MUSEUM!"
> I consider Debian releases to be more of a
> political statement than anything else. Yes, there are folks who only run
> stable, god bless them, but I don't think that's the kind of stability most
> people require. (Lord only knows when Etch is going to be released...
> debian-vote has three (maybe two) different general resolutions right how
> which are part of a larger political fight. Blah. But even with all the
> chaos among the development team, packages continue to get updated.)
Deb politics have actually tied up a number of updates and changeovers
over the years. They were late coming out with an AMD 64 release for similar
reasons, IIRC. In the event of X.org, people were so sick of waiting that
they were including ubuntu sources in their lists so that they could switch
over.
> Then you've got the differences in testing and unstable. Note that there is
> no version difference, but there is a difference in the number after the
> dash. That is the debian package number. Each deb comes with a myriad of
> stuff beyond the software itself to ensure conformance with the policies I
> mentioned above. So, in testing you've got 3.2, but it may not have the
> latest wizbang debian feature. Back in unstable, with -8, they've gone
> through six debian packages in an effort to get wizbang "just right"(TM).
> Once they figure it out, the unstable package will propagate up to testing.
> Could be a week, could be a month.
One thing I *will* give Deb here. In general, they do a great job of
kicking back the bad releases before they hit unstable.
One thing I hate about the Deb maintainers -- complete disregard for certain
bits of history. Imagine my surprise when I found I had to tar -xjvpf a
tarball instead of tar xjvpf.
> Now, for 95% of the software, these debian package version differences are
> rarely a problem. But every now and then some debian developer will be
> asleep at the switch, screw up some dependency, and then the next time you
> apt-get dist-upgrade... well, let's just say you might have a problem. The
> nature of that problem could be any number of things. But over time you
> learn how to fix stuff, revert packages, hold ones you know are "BAD." I
> think in my five+ years of debian I've only once had an upgrade that required
> a boot disk to repair (some idiot screwed up glibc).
I've done a few of those myself. Usually I knew I was shooting myself in
the foot though. I'd bet that glibc bit was the same annoyance that chased
me away from SMGL.
As I was saying before though -- Most distros do that. Someone always
screws up and lets a bad package through. That's when you *really* learn
things though 8)
> Okay, there is my two cents... plus an additional buck fifty. Sorry about
> the verbosity of the post. You'd never guess, but I'm actually a lawyer by
> training[1].
Crap -- you're going to sue me for libel now, aren't you? ; )
-Phil/CERisE
More information about the Sluglug
mailing list