[gentoo-amd64] Re: nvidia only nvidia logo [SOLVED]

[Duncan <1i5t5.duncan@cox.net>]

Nuitari posted <Pine.LNX.4.63.0510141023280.8162@melchior.nuitari.net>,
excerpted below,  on Fri, 14 Oct 2005 10:24:11 -0400:

>> Are u sure you want your whole system built out of the testing (~amd64) 
>> "release" of gentoo?
> 
> My laptop runs with ~amd64 and it's the amd64 system I had the least 
> problems with...

Likewise here, with my dual Opteron workstation.

While I'm not going to say any particular Gentoo user should be running
stable or ~arch (testing), amd64 is a bit different than x86 regarding
stable.  Altho the degree to which this is still true is fading, it's
still true to some extent that the folks likely to be running amd64 in the
first place are more likely to be leading-edge type folks.  Thus, it's
likely that a higher proportion of amd64 users use ~arch than x86 users,
which corresponds to a more reliable ~amd64 than ~x86, because it has been
better tested as there are more folks running it.  (One way to ensure this
even further would be to delay upgrades on critical packages by 3-4 days
after they first appear in the upgrade list, watching to see if there's a
bunch of problem reports on them.  Such packages would certainly include
gcc/glibc/binutils/portage/baselayout/xorg, and your X environment of
choice, kde/gnome/whatever.)

Correspondingly, stable amd64 users /may/ at times have /more/ troubles
than ~amd64, because stable will by definition mean older versions, and
with fewer folks running it, there might be occasional compatibility
problems between older packages and something freshly marked stable --
which passed the tests to stable because everyone running it was running
newer ~arch versions of whatever it had problems with.

That said, ~arch /will/ at times have issues, particularly if you upgrade
as soon as something gets marked ~amd64.  As I mentioned, one way to avoid
this would be waiting a couple days after a portage says a package is
available, to upgrade to it, for packages which are either generally
critical, or critical to you.

Here, as mentioned, I run a ~amd64 system.  I even unmask and merge
masked-for-testing packages on occasion.  Right now, for instance, I'm
running gcc-4.0.1 as my main compiler, using eselect compiler to switch
back to gcc-3.4.4 for stuff (like xorg) that doesn't yet compile with
gcc-4.x.  As part of that process, I also had to unmask newer versions of
binutils with fixes for gcc4, and I'm running a still masked glibc with
gcc4 fixes as well.  I haven't yet tried the kde-3.5 alpha packages, but I
did run the kde-3.4 betas, which as betas were never unmasked, and will
probably do the same with kde-3.5 at some point.  I tried the still masked
modular-xorg stuff, but couldn't get it to run, so dropped back to the
last monolithic xorg-x11 snapshot build, now xorg-x11-6.8.99.15-r4, as of
last portage tree update a few days ago (I'll do another tonight, and may
try kde-3.5 after that).  I often run portage and baselayout snapshots
before they are keyworded ~amd64 as well, altho the versions I'm running
now (portage-2.0.53_rc5 and baselayout-1.12.0-pre9-r1), while rc/pre and
therefore unlikely to ever go stable, are ~amd64 keyworded and not masked.

As I said, far be it from me to tell someone they should run
unstable/testing/~arch, but for those willing to work around the
occasional issue, ~amd64 is probably safer than ~x86 would be, and for
specific packages at specific times, has proven safer even than stable
amd64.  Again, for those wanting to try it but still a bit cautious,
consider running ~amd64, but waiting a couple days after critical packages
show up on the upgrade list, before trying them, to see if anybody "stupid
enough to try them first" <g> runs into issues.  (I can say that since I'm
"that stupid"!  <g>)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list