mso at oz.net
Fri Nov 4 07:00:20 MSK 2005
Rick Moen wrote:
>Quoting mso at oz.net (mso at oz.net):
>>Interesting, although his sample of Gentoo users sounds highly
>>untypical. I don't know anybody who has used Mandrake, much less
>>switched from Mandrake to Gentoo. I got the Gentoo bug from fanatics
>>who had switched from Debian and Red Hat. We like Gentoo because it
>>lets us understand and control our system more; the same reason we got
>>into Linux in the first place.
>I am sympathetic with that mindset. I mostly share it (with minor
>quibbles about having gotten out of fetching, patching, and compiling
>most Linux software locally around 1993 for a _reason_ -- having each
>sysadmin do quality control and debugging is insane).
>>Plus, the lightweight "packages" mean one less layer of things to go
>>wrong, unlike the recurring Debian problem of packages appearing when
>>their dependencies aren't available yet.
>Speculation: 99% of those dependency problems involved GNOME, KDE, and
>(in rare cases) Mozilla browsers and software using the Mozilla runtime
>engine -- and hit people on Debian's testing and/or unstable branches.
>Right? My remedy upon noting those particular dependency hairballs was
>to (mostly) eschew GNOME and KDE. The Mozilla problems haven't existed
>for a long time, especially since giving up on Galeon (a 1.3.x) and
>finding ways to live with Firefox.
No, it wasn't those packages. Every six months or so there would be a
package that said, "This depends on package Y (VERSION), but package Y
(VERSION) does not appear to be available." On the devel list you'd
read that package Y was held back or was waiting for the incoming
processor to go through the backlog. I don't remember which packages
but it was a wide variety. Sometimes it would cause library problems
similar to what Ben is reporting. It got to the point that I never let
dselect "do its thing" without copying the entire system to another
partition first in case it got hosed. This was with sid of course. I'm
sure stable doesn't have that problem, but stable was unusable at the
time because it was two years out of date. I stopped upgrading
packages unless I really wanted them, and try to avoid upgrading
libraries unless I need the new features.
>>I can understand a Mandrake user being frustrated with the handholding
>>and wanting to play with the big boys, and switching to Gentoo because
>>it's so radically the opposite.
>But that was not the author's point: He pegged them as people who
>gravitate to environments that give them the _illusion_ of being cutting
>edge without the work. Typing "emerge [foo]" doesn't _in itself_ let a
>sysadmin "understand and control" his/her system any more than "make
>[foo]" did with the BSD ports system on which Portage was modeled. This
>is not to say that Gentoo cannot enable understanding and controlling
>one's system, but rather that those things can be shirked, while patting
>one's self on the back for having supposedly achieved it.
>The same is, of course, true -- a point that has been done to death
>elsewhere -- of USE flags. They're a fine tool, but also the locus of
>>And if this phenomenon is happening with Mandrake, wouldn't it also
>>happen with Lindows and the other consumer-oriented distros?
>The fact that you ask this suggests that you didn't follow the author's
>point: Lindows doesn't permit overreaching newcomers with no _actual_
>understanding/control of their systems to con themselves into thinking
>they've become L33T H4X0R L1NUX D00D2; the author argues that their
>particular way of using Gentoo Linux does.
>(The author is not criticising Gentoo; he's pointing out a particular
>category of loudmouth poseurs among its userbase.)
I guess I misunderstood the article then. I thought he was critiquing
Gentoo for consisting of features that weren't features, and also
questioning the whole concept of an auto-updateable ports-based distro.
You're right that "emerge [foo]" does not in itself reveal the secrets
of what makes the OS tick. Although watching the
patch/configure/compile/install output does, in a minor way. It's not
that using Gentoo automatically makes you a guru, just that it hinders
you less if you choose to explore into the lower levels.
>>Gentoo config files stick closer to the upstream.
>This is actually one of my qualms about Gentoo: Upstream often sucks.
>The job of a distro package maintainer is to both adapt upstream to the
>needs of the distro, and to do quality control, fixing, and porting as
>required to maintain standards.
True. I sometimes with Gentoo would standardize things a bit more. But
I would argue that Debian makes a lot of changes that seem good to the
developers or implement some distro-wide policy, that aren't necessarily
any better. Plus it makes the user think this distro-specific way is
the normal way.
There is one thing Gentoo overengineered, httpd.conf. Instead it was
split into /etc/apache2/conf/commonapache.conf and
/etc/apache2/conf/apache2.conf. A comment says:
# Splitting up apache2.conf into two files makes it easier to support
# multiple configurations on the same server. In commonapache2.conf
# you keep directives that apply to all implementations and in this
# file you keep server-specific directives. While we don't yet have
# multiple configurations out-of-the-box, this allows us to do that
# in the future easily. (PERLPROXIED *ahem*)
But the multiple configurations never materialized, so it was an
unnecessary inconvenience. Recently they went back to a standard
>I hereby refer you to any number of prior explanations I've posted about
>how to simply specify in /etc/apt/preferences Debian-testing as one's
>default branch, but with non-default access to Debian-unstable ("sid")
>packages and their dependencies for when such are desirable. If you've
>forgotten about those explanations, no problem.
Testing didn't exist during much of the time I used Debian. I agree it
was a major step forward. I may have switched to testing at one point,
but I don't remember for sure.
More information about the TAG