[Pan-users] Re: Reproducible crash retrieving headers in million-header group

[Duncan]

walt posted on Mon, 02 Aug 2010 17:22:30 -0700 as excerpted:

> On 08/01/2010 06:38 PM, Duncan wrote:
>> ...assuming the user's still on 32-bit, which is getting more and more
>> legacy, these days...
> 
> As a fellow gentoo-geek, I've noticed a very distinct change in the way
> packages are updated for my x86 and amd64 machines.
> 
> Only a few short months ago, the gentoo packages for x86 were
> 'stabilized' way before amd64, but now it's completely reversed.  These
> days, if you run x86 you wait at the end of the queue for your table
> scraps while the amd64 people feast at the banquet.  (I'm both, so
> obviously I'm ambivalent.)

Well, I'm both ~x86 (on the netbook) and ~amd64 (main machine).  Actually, 
even ~arch is often too old and stale for me.  AFAIK, they've not 
keyworded gcc-4.5 yet, for instance, and I run both the x11 and the kde 
overlays, as stuff takes too long to get into the tree at all, even hard-
masked.  Binutils is another package I run ahead of ~arch, as I have it 
permanently keyworded ** (take the latest version regardless of 
keywording).

gcc is nice as with its slotting, one can keep the version they were 
running installed, but gcc-config to the new version for most things, 
unless something won't build and doesn't yet have patches available to 
allow it to build.  But one still has to worry about C++ apps, including 
all of kde, where it's possible to have a couple hundred packages that 
build fine with the new version, only to have one that won't... but 
because it depends on multiple other packages that have already been built 
with the new version, it won't build with the old version either, unless 
the dependencies are rebuild with the old version first, too.  All stuff 
one must get used to dealing with when one runs a still hard-masked gcc, 
particularly when they're also running something as large as kde that 
depends on C++ and thus the gcc version specific libstdc++.

Thru about gcc 4.2, while gcc 32-bit x86 support was relatively mature and 
thus version bumps not that big a deal for it, amd64 was far less mature, 
and the improvements with a new gcc version much more drastic.  So I used 
to try to upgrade as soon as possible.  But starting with about 4.2 (so 
with the upgrade to 4.3), gcc's amd64 support was relatively mature as 
well, and the improvements with a new gcc more incremental, similar to 
x86.  So now, it's not such a big deal to be running the absolute latest 
gcc, on amd64, and with the upgrade to 4.5, I waited longer to unmask and 
install it than I did with earlier versions.  My patience paid off, as 
Flameeyes has been busy with his tinderbox and had long since filed gcc-4.5 
bugs on packages that broke with it.  By the time I got around to 
installing it and then doing the emerge --emptytree @world, the gcc 4.5 
bugs for all the packages I run had been fixed, at least in the latest 
~arch or for X and kde, overlay versions. and I didn't have a single 
package needing a manual patch for the new version before it'd build.  It 
was quite nice for a change. =:^)

And of course I run kernels straight off of Linus' git (I've never run a 
gentoo packaged kernel at all, IIRC) starting a bit after -rc1, so if I 
find issues I can git bisect and bug them at kernel.org.  That's the 
equivalent of a live vcs build, which is never allowed in ~arch, so 
definitely newer than ~arch.

So yeah, with some packages, even ~arch is old and stale for my usage, let 
alone stable arch.  So by the time something goes stable, I've normally 
been running it for months (years in the case of baselayout-2/openrc, 
which still isn't stable, for various reasons), and the only dealings with 
stable I have are when reading arch-stable users' posts on the lists, 
etc.  But even so, I'd seen enough comments both on the amd64 list and on 
the gentoo-dev list to realize that the relative positions of x86 and 
amd64 had reversed, recently, and while x86 is still well ahead of #3 (ppc, 
I believe) and is projected to continue to be for years, yet, amd64 is 
definitely the leading arch, these days.

But it's still useful and interesting to have another user confirm it, 
especially /because/ I'm generally so far ahead of stable that I've 
basically no idea at all what's actually going on with it, save for what I 
happen to read on the amd64 or dev lists. =:^)

-- 
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