[gentoo-amd64] glibc-2.6.1 cpu error

[gentoo-amd64] glibc-2.6.1 cpu error

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

when i try to upgrade to glibc-2.6.1 from gentoo stable repo i get this
error:

../include/sys/socket.h:21: warning: 'stdcall' attribute ignored
> make[2]: *** [/var/tmp/paludis/sys-libs/glibc-2.6.1
> /work/build-x86-x86_64-pc-linux-gnu-nptl/tcb-offsets.h] Error 1
> make[2]: *** Waiting for unfinished jobs....
> ../sysdeps/generic/initfini.c:1: error: CPU you selected does not support
> x86-64 instruction set
> ../sysdeps/generic/initfini.c:1: error: CPU you selected does not support
> x86-64 instruction set
> make[2]: *** [/var/tmp/paludis/sys-libs/glibc-2.6.1/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/initfini.s]
> Error 1
> make[2]: Leaving directory `/var/tmp/paludis/sys-libs/glibc-2.6.1
> /work/glibc-2.6.1/csu'
> make[1]: *** [csu/subdir_lib] Error 2
> make[1]: Leaving directory `/var/tmp/paludis/sys-libs/glibc-2.6.1
> /work/glibc-2.6.1'
> make: *** [all] Error 2
>

everytime i also get this another thing that doesn't break the compilation:

../nptl/sysdeps/i386/i686/../tls.h:66:3: error: #error "TLS support is
> required."
>

i use -march=k8 and i've also tried with athlon64 but i get the same error.
i have a turion64 processor with a multilib env and crossdev installed to
crosscompile for x86 hw. i use icecream to do this.

-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 1630 bytes --]

[gentoo-amd64] Re: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560710170112u6c8769a9j78eeb474899102d6@mail.gmail.com, excerpted
below, on  Wed, 17 Oct 2007 10:12:43 +0200:

> when i try to upgrade to glibc-2.6.1 from gentoo stable repo i get this
> error:
> 
> ../include/sys/socket.h:21: warning: 'stdcall' attribute ignored
>> make[2]: *** [/var/tmp/paludis/sys-libs/glibc-2.6.1
>> /work/build-x86-x86_64-pc-linux-gnu-nptl/tcb-offsets.h] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> ../sysdeps/generic/initfini.c:1: error: CPU you selected does not
>> support x86-64 instruction set ../sysdeps/generic/initfini.c:1: error:
>> CPU you selected does not support x86-64 instruction set

Did you ever have the eselect-compiler module, aka gcc-config-2.0, 
installed?  Presumably you've removed it now if you did, but the unmerge 
left some files behind that triggered frustrating errors such as this at 
times.  Let's see if I can find the bug, which has a command that can be 
run to trace down and remove these files (be sure to read my comment on 
the bug, as the initial form of the command as posted caused problems for 
a number of people, removing too much stuff due to bad quoting)...

OK, here we are: http://bugs.gentoo.org/show_bug.cgi?id=133209

Pay particular attention to comments 25,35,39.

That may or may not be your problem, but if it is, it's a fairly easy fix 
for what can be an otherwise extremely frustrating problem.  

FWIW, a few months ago I finally decided to switch to the 64-bit only no-
multilib profile here, since I won't merge binary-only stuff here anyway 
out of principle, and that's mainly why one would need 32-bit 
compatibility as virtually any commonly used freedomware is long since 
ported.  Less problems, and compiling gcc and glibc take MUCH less time 
now, since only the 64-bit stuff has to be compiled, not the 32-bit stuff 
as well.  If I did do 32-bit, I'd now go the 32-bit chroot route, 
installing from a full 32-bit stage-3 thus keeping 32-bit and 64-bit 
separate, instead of fooling with the multilib stuff.  Less problems that 
way, and when there /is/ a problem, it's far more likely to be limited to 
one bitness or the other, not some weird combination of both.  Those dual-
bitness problems aren't common, but they are sure frustrating to try to 
figure out and solve, so eliminating that entire class of problem was at 
least for me a good choice; one I'd have made much earlier if I had it to 
do over again.

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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: glibc-2.6.1 cpu error

[Beso]

[-- Attachment #1: Type: text/plain, Size: 3399 bytes --]

i don't want to chroot to another profile just to use a 32bit double
firefox.... i'm using 64bit firefox with wrapper and 32bit apps and it runs
quite well. i don't want to use a double thing. there are lesser apps that
go only on 32bit so i hope that i won't need the multilib profile for
long....
anyway the find would remove me some crosscompilers, fact that i don't
want.... and now i don't what the heck has happened since i can't compile
anymore.... it gives me errors on gcc compiler.... i'll try reemerging it
and see if i can do it.... i can't do it what should i do?!

2007/10/17, Duncan <1i5t5.duncan@cox.net>:
>
> Beso <givemesugarr@gmail.com> posted
> d257c3560710170112u6c8769a9j78eeb474899102d6@mail.gmail.com, excerpted
> below, on  Wed, 17 Oct 2007 10:12:43 +0200:
>
> > when i try to upgrade to glibc-2.6.1 from gentoo stable repo i get this
> > error:
> >
> > ../include/sys/socket.h:21: warning: 'stdcall' attribute ignored
> >> make[2]: *** [/var/tmp/paludis/sys-libs/glibc-2.6.1
> >> /work/build-x86-x86_64-pc-linux-gnu-nptl/tcb-offsets.h] Error 1
> >> make[2]: *** Waiting for unfinished jobs....
> >> ../sysdeps/generic/initfini.c:1: error: CPU you selected does not
> >> support x86-64 instruction set ../sysdeps/generic/initfini.c:1: error:
> >> CPU you selected does not support x86-64 instruction set
>
> Did you ever have the eselect-compiler module, aka gcc-config-2.0,
> installed?  Presumably you've removed it now if you did, but the unmerge
> left some files behind that triggered frustrating errors such as this at
> times.  Let's see if I can find the bug, which has a command that can be
> run to trace down and remove these files (be sure to read my comment on
> the bug, as the initial form of the command as posted caused problems for
> a number of people, removing too much stuff due to bad quoting)...
>
> OK, here we are: http://bugs.gentoo.org/show_bug.cgi?id=133209
>
> Pay particular attention to comments 25,35,39.
>
> That may or may not be your problem, but if it is, it's a fairly easy fix
> for what can be an otherwise extremely frustrating problem.
>
> FWIW, a few months ago I finally decided to switch to the 64-bit only no-
> multilib profile here, since I won't merge binary-only stuff here anyway
> out of principle, and that's mainly why one would need 32-bit
> compatibility as virtually any commonly used freedomware is long since
> ported.  Less problems, and compiling gcc and glibc take MUCH less time
> now, since only the 64-bit stuff has to be compiled, not the 32-bit stuff
> as well.  If I did do 32-bit, I'd now go the 32-bit chroot route,
> installing from a full 32-bit stage-3 thus keeping 32-bit and 64-bit
> separate, instead of fooling with the multilib stuff.  Less problems that
> way, and when there /is/ a problem, it's far more likely to be limited to
> one bitness or the other, not some weird combination of both.  Those dual-
> bitness problems aren't common, but they are sure frustrating to try to
> figure out and solve, so eliminating that entire class of problem was at
> least for me a good choice; one I'd have made much earlier if I had it to
> do over again.
>
> --
> 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
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 4205 bytes --]

[gentoo-amd64] Re: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560710171006i2ae2af28q64922c7c3f3416ac@mail.gmail.com, excerpted
below, on  Wed, 17 Oct 2007 19:06:29 +0200:

> i don't want to chroot to another profile just to use a 32bit double
> firefox.... i'm using 64bit firefox with wrapper and 32bit apps and it
> runs quite well. i don't want to use a double thing. there are lesser
> apps that go only on 32bit so i hope that i won't need the multilib
> profile for long....
> anyway the find would remove me some crosscompilers, fact that i don't
> want.... and now i don't what the heck has happened since i can't
> compile anymore.... it gives me errors on gcc compiler.... i'll try
> reemerging it and see if i can do it.... i can't do it what should i
> do?!

[Referencing this bug: http://bugs.gentoo.org/show_bug.cgi?id=133209 ]

If you are using the find in my comment (#39), then it's probably /not/ 
the cross-compilers directly, but rather some wrappers for them that 
eselect-compiler left behind, that are now causing problems.  That find 
is specifically on a string that only occurred in eselect-compiler (aka 
gcc-config-2.0-preX) and in the wrappers it placed, so shouldn't list 
anything other than them.

If you are using the earlier find, as the comment explains, you may be 
getting false-hits due to the screwed quoting in the original find 
(comment 25, problems noted in 35), thus my cautioning to be sure and 
read thru to my comment, thus using that find rather than the original 
one.

If you have any doubts, backup the files by moving them elsewhere, say to 
a test subdir, or by renaming them to *.remove.  That way, if the results 
don't please you you can get them back without having to recompile 
whatever they might be from.  However, if you are using my find, with the 
single quotes (' instead of "), I'm relatively sure that the results are 
indeed the old wrappers, and based on that and other bugs, that removing 
them (or temporarily renaming them to test and be sure) will cure your 
problem.

BTW, you can see if the files belong to anything else with this command, 
assuming you have gentoolkit merged: equery belongs <file>

If it belongs to something else, say your crosscompiler, then something 
is indeed wrong with the find.  If it doesn't belong to anything, it's 
either an orphan or a config file not tracked by portage.  Not all such 
"orphans" are unneeded, but it's a good hint, which coupled with the 
temporary rename technique above will be pretty solid.

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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: glibc-2.6.1 cpu error

[Beso]

[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]

2007/10/17, Duncan <1i5t5.duncan@cox.net>:
>
> Beso <givemesugarr@gmail.com> posted
> d257c3560710171006i2ae2af28q64922c7c3f3416ac@mail.gmail.com , excerpted
> below, on  Wed, 17 Oct 2007 19:06:29 +0200:
>
> > i don't want to chroot to another profile just to use a 32bit double
> > firefox.... i'm using 64bit firefox with wrapper and 32bit apps and it
> > runs quite well. i don't want to use a double thing. there are lesser
> > apps that go only on 32bit so i hope that i won't need the multilib
> > profile for long....
> > anyway the find would remove me some crosscompilers, fact that i don't
> > want.... and now i don't what the heck has happened since i can't
> > compile anymore.... it gives me errors on gcc compiler.... i'll try
> > reemerging it and see if i can do it.... i can't do it what should i
> > do?!
>
> [Referencing this bug: http://bugs.gentoo.org/show_bug.cgi?id=133209 ]
>
> If you are using the find in my comment (#39), then it's probably /not/
> the cross-compilers directly, but rather some wrappers for them that
> eselect-compiler left behind, that are now causing problems.  That find
> is specifically on a string that only occurred in eselect-compiler (aka
> gcc-config-2.0-preX) and in the wrappers it placed, so shouldn't list
> anything other than them.


never used eselect-compiler. mine is a 2,5 months old gentoo fresh install
due to a disk change  with backup gone wild. eselect-compiler has never got
into my system. the wrappers were inserted manually by me when i needed them
to make icecream work (i didn't have to do almost anything since icecream
functions quite well without wrappers).

If you are using the earlier find, as the comment explains, you may be
> getting false-hits due to the screwed quoting in the original find
> (comment 25, problems noted in 35), thus my cautioning to be sure and
> read thru to my comment, thus using that find rather than the original
> one.


i've used the 25th comment command. i've moved the indicated files to a
backup dir and then done a gcc-config -f x86_64-pc-linux-gnu-4.1.2 and
retried compiling glibc but no luck. i've tried with an older version and by
disabling and enabling ccache but i had no luck.

ps. i don't really want to compile again all the entire system.

>
> 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
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 3889 bytes --]

[gentoo-amd64] Re: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560710171419k6c821d8fm70b60547a38de390@mail.gmail.com, excerpted
below, on  Wed, 17 Oct 2007 23:19:40 +0200:

> i've used the 25th comment command. i've moved the indicated files to a
> backup dir and then done a gcc-config -f x86_64-pc-linux-gnu-4.1.2 and
> retried compiling glibc but no luck. i've tried with an older version
> and by disabling and enabling ccache but i had no luck.

If you used the 25th comment command, then you probably got some bad 
hits, which would explain why moving them didn't help.  Since you say 
it's a pretty new system and has never had eselect compiler on it, it's 
gotta be a different problem for you.

Good luck.  I'd suggest checking glibc bugs now, and filing one of your 
own if you don't find one similar.

I'm just glad I was able to get rid of such problems entirely, by going 
64-bit only (no-multilib profile).  If you can't, you can't, but it's 
sure nice when you can. =8^)

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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: glibc-2.6.1 cpu error

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

i recompiled gcc and used portage and that worked. i think that mine is a
paludis bug. i'll post the bug on the paludis bugzilla.
thanks for your help anyway.

2007/10/18, Duncan <1i5t5.duncan@cox.net>:
>
> Beso <givemesugarr@gmail.com> posted
> d257c3560710171419k6c821d8fm70b60547a38de390@mail.gmail.com, excerpted
> below, on  Wed, 17 Oct 2007 23:19:40 +0200:
>
> > i've used the 25th comment command. i've moved the indicated files to a
> > backup dir and then done a gcc-config -f x86_64-pc-linux-gnu-4.1.2 and
> > retried compiling glibc but no luck. i've tried with an older version
> > and by disabling and enabling ccache but i had no luck.
>
> If you used the 25th comment command, then you probably got some bad
> hits, which would explain why moving them didn't help.  Since you say
> it's a pretty new system and has never had eselect compiler on it, it's
> gotta be a different problem for you.
>
> Good luck.  I'd suggest checking glibc bugs now, and filing one of your
> own if you don't find one similar.
>
> I'm just glad I was able to get rid of such problems entirely, by going
> 64-bit only (no-multilib profile).  If you can't, you can't, but it's
> sure nice when you can. =8^)
>
> --
> 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
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 2065 bytes --]

[gentoo-amd64] paludis Was: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560710180732t6d270ca1pec4697ea7fc5817a@mail.gmail.com, excerpted
below, on  Thu, 18 Oct 2007 16:32:11 +0200:

> i recompiled gcc and used portage and that worked. i think that mine is
> a paludis bug. i'll post the bug on the paludis bugzilla. thanks for
> your help anyway.

Thanks for the fix report.  You may be right.  I've not used paludis.

Talking about which... does paludis have proper binary package support 
yet?  That's the main reason I hadn't tried it back some time ago (when 
ciaranm was still a Gentoo dev, IIRC).  Portage's FEATURES=buildpkg is my 
favorite underdocumented power-user portage feature (for all sorts of 
reasons I could detail but don't really belong in this post), and back 
then, paludis didn't handle binpkgs at all, let alone have anything as 
useful as portage's tar.bz2-with-some-extra-metadata-tacked-on binpkg 
format, so regardless of paludis' other features, there was simply no way 
I could seriously consider it.  Maybe that has changed by now?

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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] paludis Was: glibc-2.6.1 cpu error

[Beso]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

2007/10/19, Duncan <1i5t5.duncan@cox.net>:
>
> Beso <givemesugarr@gmail.com> posted
> d257c3560710180732t6d270ca1pec4697ea7fc5817a@mail.gmail.com, excerpted
> below, on  Thu, 18 Oct 2007 16:32:11 +0200:
>
> > i recompiled gcc and used portage and that worked. i think that mine is
> > a paludis bug. i'll post the bug on the paludis bugzilla. thanks for
> > your help anyway.
>
> Thanks for the fix report.  You may be right.  I've not used paludis.
>
> Talking about which... does paludis have proper binary package support
> yet?  That's the main reason I hadn't tried it back some time ago (when
> ciaranm was still a Gentoo dev, IIRC).  Portage's FEATURES=buildpkg is my
> favorite underdocumented power-user portage feature (for all sorts of
> reasons I could detail but don't really belong in this post), and back
> then, paludis didn't handle binpkgs at all, let alone have anything as
> useful as portage's tar.bz2-with-some-extra-metadata-tacked-on binpkg
> format, so regardless of paludis' other features, there was simply no way
> I could seriously consider it.  Maybe that has changed by now?


i don't know of that option being supported. i currently use the 0.24.6 from
august and that don't seem to list that feature. what does that feature in
portage?!
i'm using paludis for a speed reason. portage is really really slow and it
makes you die before determining deps. it's awful in that terms. i foud out
paludis which has a great speed and that seems to give a lot of debug infos
and that has a more modular approach when compared to portage. the last
useful thing is that i with portage i used to get some times compilation
errors that would go away when resuming; this thing don't happen almost
anytime with paludis. the only thing is that you'll have to install the
hooks or you risk doing some damage to the world db by deleting something
like some baselayout files when updating baselayout. that was some file
linking problem fixed when installing the collision protect hook.
but the function that i think is the best of paludis is the repositories:
you can administrate your layouts in a very good way and have a different
configuration for the various repos packages.

--
> 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
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 3240 bytes --]

[gentoo-amd64] Re: paludis Was: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560710190236q3de96984h39a5a092c30b4528@mail.gmail.com, excerpted
below, on  Fri, 19 Oct 2007 11:36:53 +0200:

>> Talking about which... does paludis have proper binary package support
>> yet?  [...] Portage's FEATURES=buildpkg is my favorite underdocumented
>> power-user portage feature
 
> i don't know of that option being supported. i currently use the 0.24.6
> from august and that don't seem to list that feature. what does that
> feature in portage?!

Simply put, it automatically creates tarballed binary packages every time 
it emerges something, storing those binary packages by default in 
$PORTDIR/packages.  That way, should you ever need to remerge that 
package-version (say on another machine if you have more than one, or if 
you need to revert to an old version because the new version you just 
merged doesn't work for some reason), you can do so using emerge --
usepackage (or --usepackageonly), and it'll grab the binary package you 
created the first time, merging it much faster since it doesn't have to 
recompile anything.

IOW, except for the first time you merge a package, it's as if you were 
using a binary distribution, except you created and customized the 
binaries yourself, using Gentoo's usual features.  Of course, the first 
time, the package is compiled as it normally is, so there's no direct 
advantage there -- but it can still be useful.

Obviously, the folks that will get the most use out of this are the folks 
running several similarly configured machines, same USE flags, etc, since 
they can then compile once and merge the same binary package on all their 
machines.  However, it's quite useful even if you run only a single 
machine, as I do here.  As I said, it's helpful if you need to remerge a 
package for some reason.  I've reinstalled from my binpkgs once after a 
problem with disk corruption, and it goes MUCH faster.  Also, because the 
packages are basically tar.bz2s with a bit of extra metadata glued onto 
the end, they can be browsed with your favorite archiver (I use mc, as I 
do for many of my sysadmin tasks), and it's easy to retrieve just a 
single file, say a config file you screwed up and want to start over 
with.  The binpkgs are also useful for comparing the contents of packages 
between versions -- I've filed and had fixed a couple bugs because new 
versions ended up missing some file or another, for some reason, caught 
because once I figured out something was wrong, it was easy to compare 
the files in an older working version with the files in the newer broken 
version.

The format also allows one to fix a broken portage or python.  Consider 
how you'd emerge a package if your package manager is broken.  With 
automatically created tarballs, it's easy.  Simply backup any config 
files you want to save, and untar the working version directly on top of 
the live root filesystem.  (Or, if it's /really/ broken, and tar and/or 
bzip2 are dead as well, boot your recovery disk and use the tar and bzip2 
from there to do the job.)

The metadata glued onto the tarball includes the ebuild itself, and that 
can also be handy.  What do you do if you use a package that gets removed 
from the tree (for example, xmms)?  Well, as long as you still have the 
binpkg around, you still have a copy of the ebuild, and can copy it to 
your overlay and continue to use it from there, even rebuilding if 
necessary (say if you upgrade gcc), even after the copy in the tree is 
long gone.

So it's not just the binary packages, useful enough in their role as 
backups as it is, but the fact that the data in those packages can still 
be accessed with ordinary tools like tar and bzip2, that makes portage's 
binpkgs so useful.  If an alternative package manager supported binpkgs, 
I'd hope it used something equally accessible with standard tools.

> i'm using paludis for a speed reason. portage is really really slow and
> it makes you die before determining deps. it's awful in that terms.

I've found that to be true only for the first "cold cache" run, when it 
has to read everything in from disk.  Once the data is in cache, portage 
is MUCH faster.  With a gig of memory, it should be in cache pretty much 
as long as you are using it, tho if you go a few days between using 
portage, or if you reboot, the data will probably be flushed from cache 
and need to be read in from slow disk once again.  With a couple gigs, 
it's likely you'll only have to do that initial portage run once, and 
after that it'll remain in memory until the next reboot.  With the 8 gigs 
of memory I have... lets just say I normally don't worry about it, tho 
that first emerge --pretend world I run does take a bit.  Of course, 
syncing also takes a bit, but that's not too terribly often either, 
compared to the number of times you might actually run emerge in a 
session.

So speed isn't the problem for me it is for some.

> i
> foud out paludis which has a great speed and that seems to give a lot of
> debug infos and that has a more modular approach when compared to
> portage. the last useful thing is that i with portage i used to get some
> times compilation errors that would go away when resuming; this thing
> don't happen almost anytime with paludis.

The more modular is of course good on its own merits, as is faster, tho I 
explained that's not a big problem for me here.  As for compilation 
errors, I don't tend to get any of those that go away on resume, altho 
there was a bit of an order resolving problem in ~arch portage for a few 
months that caused a few issues.  However, I'm pretty religious about 
running --newuse and --deep (both run by default on my --update world 
runs), and --depclean and revdep-rebuild as well.  That likely has a lot 
to do with it, as my dependencies are going to be quite a bit cleaner 
than someone who doesn't routinely practice "good package hygiene".  =8^)

In any case, as I said, unless a package manager has good binary package 
support, there's little chance of me seriously considering it.  Thus the 
question, since the lack of such binary package support is what ended my 
initial paludis investigation back then.  Of course, different strokes 
for different folks and all that, and what works so well for me may 
indeed be intolerable for you, so as they say, YMMV.

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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: paludis Was: glibc-2.6.1 cpu error

[Beso]

[-- Attachment #1: Type: text/plain, Size: 7699 bytes --]

2007/10/19, Duncan <1i5t5.duncan@cox.net>:
>
> Beso <givemesugarr@gmail.com> posted
> d257c3560710190236q3de96984h39a5a092c30b4528@mail.gmail.com, excerpted
> below, on  Fri, 19 Oct 2007 11:36:53 +0200:
>
> >> Talking about which... does paludis have proper binary package support
> >> yet?  [...] Portage's FEATURES=buildpkg is my favorite underdocumented
> >> power-user portage feature
>
> > i don't know of that option being supported. i currently use the 0.24.6
> > from august and that don't seem to list that feature. what does that
> > feature in portage?!
>
> Simply put, it automatically creates tarballed binary packages every time
> it emerges something, storing those binary packages by default in
> $PORTDIR/packages.  That way, should you ever need to remerge that
> package-version (say on another machine if you have more than one, or if
> you need to revert to an old version because the new version you just
> merged doesn't work for some reason), you can do so using emerge --
> usepackage (or --usepackageonly), and it'll grab the binary package you
> created the first time, merging it much faster since it doesn't have to
> recompile anything.
>
> IOW, except for the first time you merge a package, it's as if you were
> using a binary distribution, except you created and customized the
> binaries yourself, using Gentoo's usual features.  Of course, the first
> time, the package is compiled as it normally is, so there's no direct
> advantage there -- but it can still be useful.
>
> Obviously, the folks that will get the most use out of this are the folks
> running several similarly configured machines, same USE flags, etc, since
> they can then compile once and merge the same binary package on all their
> machines.  However, it's quite useful even if you run only a single
> machine, as I do here.  As I said, it's helpful if you need to remerge a
> package for some reason.  I've reinstalled from my binpkgs once after a
> problem with disk corruption, and it goes MUCH faster.  Also, because the
> packages are basically tar.bz2s with a bit of extra metadata glued onto
> the end, they can be browsed with your favorite archiver (I use mc, as I
> do for many of my sysadmin tasks), and it's easy to retrieve just a
> single file, say a config file you screwed up and want to start over
> with.  The binpkgs are also useful for comparing the contents of packages
> between versions -- I've filed and had fixed a couple bugs because new
> versions ended up missing some file or another, for some reason, caught
> because once I figured out something was wrong, it was easy to compare
> the files in an older working version with the files in the newer broken
> version.
>
> The format also allows one to fix a broken portage or python.  Consider
> how you'd emerge a package if your package manager is broken.  With
> automatically created tarballs, it's easy.  Simply backup any config
> files you want to save, and untar the working version directly on top of
> the live root filesystem.  (Or, if it's /really/ broken, and tar and/or
> bzip2 are dead as well, boot your recovery disk and use the tar and bzip2
> from there to do the job.)
>
> The metadata glued onto the tarball includes the ebuild itself, and that
> can also be handy.  What do you do if you use a package that gets removed
> from the tree (for example, xmms)?  Well, as long as you still have the
> binpkg around, you still have a copy of the ebuild, and can copy it to
> your overlay and continue to use it from there, even rebuilding if
> necessary (say if you upgrade gcc), even after the copy in the tree is
> long gone.
>
> So it's not just the binary packages, useful enough in their role as
> backups as it is, but the fact that the data in those packages can still
> be accessed with ordinary tools like tar and bzip2, that makes portage's
> binpkgs so useful.  If an alternative package manager supported binpkgs,
> I'd hope it used something equally accessible with standard tools.


this could be an interesting feature and could have you do a full system
backup.

> i'm using paludis for a speed reason. portage is really really slow and
> > it makes you die before determining deps. it's awful in that terms.
>
> I've found that to be true only for the first "cold cache" run, when it
> has to read everything in from disk.  Once the data is in cache, portage
> is MUCH faster.  With a gig of memory, it should be in cache pretty much
> as long as you are using it, tho if you go a few days between using
> portage, or if you reboot, the data will probably be flushed from cache
> and need to be read in from slow disk once again.  With a couple gigs,
> it's likely you'll only have to do that initial portage run once, and
> after that it'll remain in memory until the next reboot.  With the 8 gigs
> of memory I have... lets just say I normally don't worry about it, tho
> that first emerge --pretend world I run does take a bit.  Of course,
> syncing also takes a bit, but that's not too terribly often either,
> compared to the number of times you might actually run emerge in a
> session.
>
> So speed isn't the problem for me it is for some.


i have a notebook that i  usually shut down more than 3-4 times/day and the
chache problem for me is fundamental. i don't have to wait for portage
almost 7minutes for a world preview update while paludis does it in less
than 2min.

> i
> > foud out paludis which has a great speed and that seems to give a lot of
> > debug infos and that has a more modular approach when compared to
> > portage. the last useful thing is that i with portage i used to get some
> > times compilation errors that would go away when resuming; this thing
> > don't happen almost anytime with paludis.
>
> The more modular is of course good on its own merits, as is faster, tho I
> explained that's not a big problem for me here.  As for compilation
> errors, I don't tend to get any of those that go away on resume, altho
> there was a bit of an order resolving problem in ~arch portage for a few
> months that caused a few issues.  However, I'm pretty religious about
> running --newuse and --deep (both run by default on my --update world
> runs), and --depclean and revdep-rebuild as well.  That likely has a lot
> to do with it, as my dependencies are going to be quite a bit cleaner
> than someone who doesn't routinely practice "good package hygiene".  =8^)
>
> In any case, as I said, unless a package manager has good binary package
> support, there's little chance of me seriously considering it.  Thus the
> question, since the lack of such binary package support is what ended my
> initial paludis investigation back then.  Of course, different strokes
> for different folks and all that, and what works so well for me may
> indeed be intolerable for you, so as they say, YMMV.


fortunately i still run both packages and have paludis --report the state of
the system then portage to depclean and see if there are differences. i
didn't find to have problems of orphaned or other problems of package
management. the one interesting function that i'd like to test is the
parallel compilation feature, which i happened to find by chance in the
forum. a patch that allows portage to compile more packages at the same time
if the second package compiled does not trigger an installation of the first
one. for example i could compile gimp and knetworkmanager at the same time
if i had a good processor.

--
> 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
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 9308 bytes --]

[gentoo-amd64] Re: paludis Was: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560710200235p3cfe1396u7e9057fa6a427f84@mail.gmail.com, excerpted
below, on  Sat, 20 Oct 2007 11:35:35 +0200:

> i have a notebook that i  usually shut down more than 3-4 times/day and
> the chache problem for me is fundamental. i don't have to wait for
> portage almost 7minutes for a world preview update while paludis does
> it in less than 2min.

With mainline kernel suspend-to-disk working, and setting /sys/power/
image_size to the largest possible given the size of the swap partition, 
I've discovered that cache is retained up to that size.

The default size if nothing is written to image_size is only 500 MB, 
enough to do a decent job of suspending what's running, but not enough to 
really get much if any cache.

However, my swap setup is four partitions of 4 gigs each, each on 
different drives and with the priority set equal on all four, so the 
kernel will stripe across all four automatically, thus speeding swap 
activity dramatically over what it would be with just a single disk.  
Since the suspend image must be on a single kernel device (and while swap 
works on combined devices such as RAID, suspend doesn't seem to, even 
when said devices are assembled from kernel mode directly, before user 
mode is invoked), that limits me to using a single 4 gig image.  More 
precisely, I can see the active swap devices in /proc/swaps along with 
their size, and set /sys/power/image_size to the precise swap size in KB 
shown there for my chosen device, that being 3909 MB (so slightly less 
than 4 GB) here.

With a just under 4 GB suspend image size, it's actually roomy enough to 
retain a decent amount of cache (not all, since I've 8 gigs of memory, 
but dramatically more than the 500 MB default, that's for sure!), and the 
cached info from my Gentoo tree and overlays, plus that from the package 
database, portage config, and world files, is much less than that, 
significantly less than a gig.  In fact, unless I've been copying 5 GB 
DVD images around or some such, just under 4 GB is quite enough to cache 
my entire file access profile from boot up thru my normally loaded X and 
normal working set of apps, and including a routine emerge --update --
deep --newuse world run.

Thus, with a suitable suspend image size, even suspend to disk, and even 
using the mainline kernel suspend code (no fancy susp2 sources required, 
tho I'm told it's even /more/ efficient at maintaining cache), 
maintaining cache isn't a big deal.  For the most part, it "just works", 
once image_size is set correctly.

Of course, with that big a suspend image, wakeup times are dramatically 
longer, since it has to read all that extra data back in off of disk.  
However, it's definitely worth it, since I get back a fully responsive 
system, not one with virtually no cache, that has to read everything back 
in before it can actually do anything.

So... I'd suggest you investigate /proc/swaps and write an appropriate 
image size to /sys/power/image_size.  Assuming you are using at least one 
swap partition of 2 GB, or even if it's only a single gig, writing an 
appropriate value to image_size should make your resume MUCH more 
responsive than it was before, maintaining at least /some/ of your 
cache.  The trade-off will be somewhat longer suspend and resume times, 
but at least here, I've found it very much worth it.  What's great is 
that this hint is generic enough it should apply to pretty much anyone 
using suspend to disk, at least on Linux, regardless of what package 
manager they are using, or even what distribution.  IOW, those running 
Red Hat or Fedora or SuSE or Ubuntu or even Linspire/Freespire, as long 
as they are using a relatively recent kernel with suspend to disk 
compiled in, should be able to make use of this. =8^)

> the one interesting function that i'd like to test is the parallel
> compilation feature, which i happened to find by chance in the forum. a
> patch that allows portage to compile more packages at the same time if
> the second package compiled does not trigger an installation of the
> first one. for example i could compile gimp and knetworkmanager at the
> same time if i had a good processor.

I do this all the time, but "manually".  That is, I routinely have 2-4, 
sometimes more (I've had up to 11, more than that I couldn't keep ahead 
of ensuring I was free of dependencies and doing the etc-updates faster 
than the things were getting compiled) windows open, compiling different 
things at the same time.  That's especially true when KDE comes out with 
an update, and I have 90-some packages to update just from it, all coming 
out the same day.

When I get my dual dual-cores, I expect it'll be even more so, altho 
practically speaking, I'm more likely to just set up two compiles at once 
and then go do something else (like checking the lists =8^) with the rest 
of my CPU time.

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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: paludis Was: glibc-2.6.1 cpu error

[Beso]

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

> With mainline kernel suspend-to-disk working, and setting /sys/power/
> image_size to the largest possible given the size of the swap partition,
> I've discovered that cache is retained up to that size.


it doesn't work well with xpress200m chipset and tends to break the system
stability. or at least the last time i tried it (2.6.22). it works for me
the suspend to ram, but that consumes the battery and on shutdown it
releases everything stored into ram. my notebook does only support a 80gb
(i'm planning an upgrade to 160 when it runs out of waranty - on february)
so i don't have neither the space needed for a great swap neither a raid
array on it. i'm also meditating to acquire a new notebook the next year so
i really wonder how much would it repay a disk upgrade to the old one.

I do this all the time, but "manually".  That is, I routinely have 2-4,
> sometimes more (I've had up to 11, more than that I couldn't keep ahead
> of ensuring I was free of dependencies and doing the etc-updates faster
> than the things were getting compiled) windows open, compiling different
> things at the same time.  That's especially true when KDE comes out with
> an update, and I have 90-some packages to update just from it, all coming
> out the same day.


for what i've learned portage is not thread safe. thus, i've myself been
using 2 or three paludis threads at the same time after verifying that the
packages compile in one terminal don't relate to other ones.
but having something that actually does this without me needing to worry for
that would be better.

When I get my dual dual-cores, I expect it'll be even more so, altho
> practically speaking, I'm more likely to just set up two compiles at once
> and then go do something else (like checking the lists =8^) with the rest
> of my CPU time.


i also compile normally when i don't need the pc to do something particular
for me, ie. web browsing, or when i program something. i don't have a dual
core pc so i cannot put a lot of compile threads at the same time.
by the way, i've seen a thread of you speaking of a tyan with opteron and
i'd like to think what you think of opteron vs athlon.
i'm planning a desktop middle ranged home server with some db, mail, rsync,
mythtv, compilation server and occasionally running some games and i'd like
to know if it worths buying an opteron dualcore or it's better an athlonx2.

--
> 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
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 3519 bytes --]

[gentoo-amd64] Re: paludis Was: glibc-2.6.1 cpu error

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560710200721v2aa321fak9a7bbf3b0eb3b145@mail.gmail.com, excerpted
below, on  Sat, 20 Oct 2007 16:21:39 +0200:

>> With mainline kernel suspend-to-disk working
> 
> it doesn't work well with xpress200m chipset and tends to break the
> system stability. or at least the last time i tried it (2.6.22). it
> works for me the suspend to ram, but that consumes the battery and on
> shutdown it releases everything stored into ram.

That's interesting... most docs I've read, including most of the docs in 
the kernel Documentation dir (mostly in Documentation/power) indicate 
that suspend-to-RAM is considerably more iffy than suspend-to-disk (aka 
hibernate).  I've not tried suspend-to-RAM in ages, mainly because it 
doesn't shut all the fans and etc. off on my system, so it's hardly worth 
the hassle, particularly when support is iffy anyway, tho I did have it 
sort of working at one point...

Hibernate, however, I'm very glad I have, and that it works... most of 
the time anyway.  I will note that it breaks from time to time with -rc 
kernels and etc, and I've had problems when I was trying to use an image 
larger than the swap partition I was putting it on (I tried 4 gig at one 
point, but with headers and etc, the actual available size is slightly 
under that... that one was hard to diagnose because it takes awhile to 
get a 4 gig memory set, so it would work for several suspends, then 
break...) or when I (experimentally) forced it to suspend to RAID, which 
apparently isn't up when the resume attempt is made.

I'd try with 2.6.23.  They did do some major changes re hibernate 
with .23, which broke it until rc-7 or so.  Maybe whatever they did fixed 
it for your system.

Do note that in many cases, the video drivers don't properly restore into 
X after a hibernate.  If you CTRL-ALT-Fn out of X to a text console, you 
may have better results.  Additionally, if you are running a framebuffer 
console, consider trying text mode vgacon.  Resuming from it may work 
better.

Also, my (self-developed) hibernate script stops the ntp and ntp-client 
services and restarts them after resume.  You probably don't have those 
on a laptop, but it's possible other services you have interfere.  It's 
often recommended that you build your NIC drivers as modules, for 
instance, and shut down your network and remove the modules before 
hibernate.  That tends to work better on some systems.  You may wish to 
consider dropping to single-user mode (telinit 1) for initial testing.  
If that works reliably, you know it's possible.  From there, you can 
create a new runlevel that's almost empty, and add services one or two at 
a time, until you find what's causing the problem.

To reduce the chance of filesystem issues due to a bad shutdown when it 
doesn't resume correctly, always sync the disk at least three times in a 
row before you hibernate.  You can either make this part of your 
hibernate script or, if you have the emergency SYSRQ keys configured into 
your kernel, use that (Alt-SysRq-S) to sync.  That has saved me corrupted 
filesystem hassles a number of times, when I was testing -rcs or for some 
other reason ended up not being able to suspend properly.

Finally, I don't know a lot about it, but a lot of people who can't get 
the mainline kernel hibernate to work swear by swsusp2.  It's worth 
trying a kernel patched with that and the related userspace tools and 
config, if you haven't.

Anyway, if you are truly shutting all the way down multiple times per day 
as it looks like, yes, I can certainly understand the irritation you'd 
have with portage, because it indeed takes a quite a bit of time to do 
its thing from a cold cache.

> my notebook does only
> support a 80gb (i'm planning an upgrade to 160 when it runs out of
> waranty - on february) so i don't have neither the space needed for a
> great swap neither a raid array on it. i'm also meditating to acquire a
> new notebook the next year so i really wonder how much would it repay a
> disk upgrade to the old one.

Well, you haven't mentioned what size swap you /are/ running, or what 
size memory, for that matter.  I originally referenced 4 gig since that's 
what each of my four swap partitions are, but anything larger than the 
default half gig hibernate image_size is going to be dramatically 
better.  If you have a single 1-gig swap partition, checking the exact 
size in KB (as found in /proc/swaps) and setting that in /sys/power/
image_size will double it from the default, and that alone will be quite 
noticeable.  A gig of swap is the normally recommended size for a half-
gig of memory.  If you happen to have a gig of memory and two gigs of 
swap, so much the better.  (I honestly don't know if two gigs swap/
suspend-image with only a half gig memory is worth it or not.)  Beyond 
that, I'd not worry about unless you really do have the resources to 
spare.


> for what i've learned portage is not thread safe. thus, i've myself been
> using 2 or three paludis threads at the same time after verifying that
> the packages compile in one terminal don't relate to other ones. but
> having something that actually does this without me needing to worry for
> that would be better.

It didn't used to be, but portage has been relatively parallel-build safe 
for quite some time now, altho there are very occasional bugs at least in 
~arch portage related to it, but occasional bugs are expected in ~arch, 
and even then, I've not read of any corruption for quite some time.  At 
the worst, one has to manually stop one of the parallel merges to let the 
other proceed, if they get deadlocked.  There's a single bug open on that 
ATM, but it's pretty rare to hit it.  (I've never hit it myself and only 
noticed it browsing thru bugs out of curiosity.)

> by the way, i've seen a thread of you speaking of a tyan
> with opteron and i'd like to think what you think of opteron vs athlon.
> i'm planning a desktop middle ranged home server with some db, mail,
> rsync, mythtv, compilation server and occasionally running some games
> and i'd like to know if it worths buying an opteron dualcore or it's
> better an athlonx2.

The differences aren't that great, really, if you are staying with a 
single socket, and I'd actually recommend going with the desktop rather 
than the server version, not so much for performance, but simply due to 
cost, unless you do need a dual (or more) socket system -- which with 
dual-cores and now quad-cores you probably don't.

The main reason I went Opteron originally was to get dual socket support 
and the close cooperation of the Opteron Hyper-transport CPU interlink 
between them, back before the dual-cores came out.  I had never run a 
dual CPU system before, but after having been very happy with the upgrade 
to my original Athlon 500 MHz way back when, I had been disappointed with 
my single-CPU upgrades since then.  It just didn't seem they did all that 
much better than the half-gigahertz Athlon of several generations 
earlier.  I realized that what I really wanted/needed for my workload was 
a real dual CPU system, and took the chance when the Opterons came out 
with their close cooperation over the Hyper-transport link, to upgrade to 
64-bit and dual CPU both at the same time.

I wasn't disappointed.  Both the AMD64 architecture and the dual Opterons 
in SMP way more than met my expectations.  The press was and to a degree 
still is complaining about how folks don't /need/ dual-core or dual-CPU, 
and much of the time one sits there idle.  That's true to some extent, 
yes, but OTOH, it /really/ makes a difference on responsiveness, 
especially when one CPU/core is going flat-out, perhaps because it got 
stuck in a runaway loop or whatever.  I'd honestly have a very hard time 
going back to a single core single CPU system (and in fact, find myself 
frustrated sometimes, working on other systems... that seem so /slow/).

However, dual socket mobos are relatively expensive, generally more than 
twice what a comparative single-socket mobo would cost, because they 
simply aren't mainstream enough.  With the introduction of dual-cores, 
and now quad-cores, there's really little reason to go dual-socket at the 
mainboard.  If one's not doing that, there's little reason to go Opteron.

Add to that the fact that AFAIK, Opterons still require registered 
memory, while Athlon-X2s use standard memory at a MUCH lower cost, and 
the balance clearly tips toward the consumer/desktop chip.  As a 
practical matter of cost, I'd tend to recommend a quad-core Barton or 
whatever they call the desktop targeted version now, over a quad or dual 
dual-core Opteron.  I'd certainly go at least dual-core, but that's 
almost a given, these days.

The other thing is memory.  While registered memory is expensive 
overkill, one of the reasons I do NOT recommend an Opteron now, it can be 
worth getting a mobo and memory that support ECC.  ECC is arguably worth 
the extra money, while registered memory is not.  Of course, it's up to 
you, and many don't wish to spend that money, but I've had enough memory 
issues to appreciate solid memory and the stability it brings, and ECC 
does bring a bit of additional assurance in that regard.  I'm not 
positive that the AthlonX2s and X4s or whatever they call them support 
ECC now, but if they do, I'd certainly consider that.  If they don't, the 
balance tips back toward Opterons a bit, but I still don't think the 
registered memory is worth it, and believe Opterons require it, so I'd 
still say AthlonX2 or quad-core, and if ECC isn't available, just buy 
good memory and possibly run it slightly underclocked, if you want that 
extra stability.

MHO, FWIW.

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

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: paludis Was: glibc-2.6.1 cpu error

[Beso]

[-- Attachment #1: Type: text/plain, Size: 3949 bytes --]

2007/10/20, Duncan <1i5t5.duncan@cox.net>:
>
> Beso <givemesugarr@gmail.com> posted
> d257c3560710200721v2aa321fak9a7bbf3b0eb3b145@mail.gmail.com, excerpted
> below, on  Sat, 20 Oct 2007 16:21:39 +0200:
>
> >> With mainline kernel suspend-to-disk working
> >
> > it doesn't work well with xpress200m chipset and tends to break the
> > system stability. or at least the last time i tried it (2.6.22). it
> > works for me the suspend to ram, but that consumes the battery and on
> > shutdown it releases everything stored into ram.
>
> I'd try with 2.6.23.  They did do some major changes re hibernate
> with .23, which broke it until rc-7 or so.  Maybe whatever they did fixed
> it for your system.


i still cannot compile madwifi on 2.6.23 and i don't know if ati 8.42 will
support it. the 8.40 does not so i'll wait a little before switching to
2.6.23.


> Well, you haven't mentioned what size swap you /are/ running, or what
> size memory, for that matter.  I originally referenced 4 gig since that's
> what each of my four swap partitions are, but anything larger than the
> default half gig hibernate image_size is going to be dramatically
> better.  If you have a single 1-gig swap partition, checking the exact
> size in KB (as found in /proc/swaps) and setting that in /sys/power/
> image_size will double it from the default, and that alone will be quite
> noticeable.  A gig of swap is the normally recommended size for a half-
> gig of memory.  If you happen to have a gig of memory and two gigs of
> swap, so much the better.  (I honestly don't know if two gigs swap/
> suspend-image with only a half gig memory is worth it or not.)  Beyond
> that, I'd not worry about unless you really do have the resources to
> spare.


i have 1gb ram and 3gb swap (never filled of more than 200mbs in runtime).
i'm actually considering removing swap because i don't use hibernate.


> The other thing is memory.  While registered memory is expensive
> overkill, one of the reasons I do NOT recommend an Opteron now, it can be
> worth getting a mobo and memory that support ECC.  ECC is arguably worth
> the extra money, while registered memory is not.  Of course, it's up to
> you, and many don't wish to spend that money, but I've had enough memory
> issues to appreciate solid memory and the stability it brings, and ECC
> does bring a bit of additional assurance in that regard.  I'm not
> positive that the AthlonX2s and X4s or whatever they call them support
> ECC now, but if they do, I'd certainly consider that.  If they don't, the
> balance tips back toward Opterons a bit, but I still don't think the
> registered memory is worth it, and believe Opterons require it, so I'd
> still say AthlonX2 or quad-core, and if ECC isn't available, just buy
> good memory and possibly run it slightly underclocked, if you want that
> extra stability.


i was thinking of a gigabyte supersilent mb with support of ddr2 - 800 and
ddr3 1333 and support for all the athlons around and for some opterons and
fsb dual 1000mhz with hypertransport, of a 2gb ddr2 800 ocz kit, a gigabyte
supersilent ati hd2600pro 256ddr3 or 512ddr2 vram, 2 sata-2 250 or 300gbs
hds with at least 8mb cache in raid 1/lvm and some other minor modding
things like the dual fan system from thermaltake with 2 supersilent fans and
a silent case fan. my problem was the choice of the processor. i thought
that taking a mb like that i could be able to switch from a middle-high dual
to a quad without great problem and from ddr2 to ddr3. this should be able
to do the trick for at least two years (or more considering the expansion of
the proc and memory) and then pass to a simple desktop if the market start
to run a lot.

MHO, FWIW.
>
> --
> 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
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 5226 bytes --]