[gentoo-amd64] MAKEOPTS values for Athlon 64 X2

[gentoo-amd64] MAKEOPTS values for Athlon 64 X2

[PaulNM]

Hey folks,

	I'm wondering if anyone has experimented with different values for 
MAKEOPTS="-jx" on Athlon 64 X2's.  The guides usually suggest # of 
cores/processors plus one. Looking at "man make.conf" doesn't help much, 
it just says "Suggested settings are between CPUs+1 and  2*CPUs+1". The 
only thing "man make" mentions about  the "-j" option is "If the -j 
option is given without an argument, make  will  not limit the number of 
jobs that can run simultaneously." I've also seen some mentions of -j9 
by people with dual core systems elsewhere, indicating it drastically 
speed up some emerges.

	So this leaves me with several possibilities. There's -j3 (current 
setting), -j5, -j (no limit), -j9, or some other random number. Any 
suggestions/warnings/links would be appreciated.

Thanks,
	PaulNM

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] MAKEOPTS values for Athlon 64 X2

[Toshinori Endo]

Hello PaulNM,


PaulNM wrote:
> Hey folks,
>
>     I'm wondering if anyone has experimented with different values for 
> MAKEOPTS="-jx" on Athlon 64 X2's.  The guides usually suggest # of 
> cores/processors plus one. Looking at "man make.conf" doesn't help 
> much, it just says "Suggested settings are between CPUs+1 and  
> 2*CPUs+1". The only thing "man make" mentions about  the "-j" option 
> is "If the -j option is given without an argument, make  will  not 
> limit the number of jobs that can run simultaneously." I've also seen 
> some mentions of -j9 by people with dual core systems elsewhere, 
> indicating it drastically speed up some emerges.
>
>     So this leaves me with several possibilities. There's -j3 (current 
> setting), -j5, -j (no limit), -j9, or some other random number. Any 
> suggestions/warnings/links would be appreciated.
>
> Thanks,
>     PaulNM
>

On my 4x Dual-Core Opteron system, -j9 actually worked as expected, but 
not as much on the other system with two CPUs.

Is that what you want?

Here is the story.
The value of MAKEOPTS including -jx is passed to the `make' command so 
that x kid jobs at most can be executed.  If 1+#CPU is given as the 
parameter, each CPU is assigned a single kid process because make 
command itself does have much to do while the kids are working hard.  
Giving the larger number just let them do extra job to switch among kids 
in expense of performance down.

te
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] MAKEOPTS values for Athlon 64 X2

[Thomas Rösner]

PaulNM wrote:
> Hey folks,
[...]
> I've also seen some mentions of -j9 by people with dual core systems 
> elsewhere, indicating it drastically speed up some emerges.

...and drastically slow down others?

>     So this leaves me with several possibilities. There's -j3 (current 
> setting), -j5, -j (no limit), -j9, or some other random number. Any 
> suggestions/warnings/links would be appreciated.

Compiling the kernel with -j is a popular benchmark, because it really 
stresses the VM/disk/CPU. And before you get your hopes up too high: the 
ebuilds that really take long (mozilla, openoffice, glibc, gcc) won't 
use your makeopts anyway.

My guess; going higher than -j5 won't do much for you, there will always 
be a process not waiting for IO (if your disk can handle the load, that 
is) for each CPU. -j3 will be better for cpp compiles, which hog the CPU 
longer and won't have to be scheduled out like with -j5.

Other factors: is this a desktop system? Do you want to actually do 
something with it while it compiles? How much RAM do you have?

(These are rethorical questions ;-))

Regards,
    T.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Duncan]

Thomas Rösner <Thomas.Roesner@digital-trauma.de> posted
45ABA032.4070601@digital-trauma.de, excerpted below, on  Mon, 15 Jan 2007
16:39:30 +0100:

> Compiling the kernel with -j is a popular benchmark, because it really 
> stresses the VM/disk/CPU. And before you get your hopes up too high: the 
> ebuilds that really take long (mozilla, openoffice, glibc, gcc) won't 
> use your makeopts anyway.
> 
> My guess; going higher than -j5 won't do much for you, there will always 
> be a process not waiting for IO (if your disk can handle the load, that 
> is) for each CPU. -j3 will be better for cpp compiles, which hog the CPU 
> longer and won't have to be scheduled out like with -j5.
> 
> Other factors: is this a desktop system? Do you want to actually do 
> something with it while it compiles? How much RAM do you have?
> 
> (These are rethorical questions ;-))

Rhetorical or not, I've been curious at just how parallelizable things
such as kernel compiles actually are.  I have 8 gigs of memory now, and a
dual Opteron (242, to be upgraded to dual cores soon) that I was running
at -j5 to -j8 for kernel compiles (set in a patch routinely applied by my
kernel maintenance scripts) for some time. However, recently, I've tried,
apparently depending on make version, either -j (unlimited in some, I get
a warning now and it reduces it to -j1, which isn't any fun...) or -j1000,
just to see how high I could make my load average climb!  =8^).

I've been frustrated due to being unable to find an easy way to measure
load averages of less than the 1 minute rolling, but with even with it,
I've been highly amused to see it climb to something over 250! (I want to
say 450 as I think I remember that, but I'm keeping the claim to what
I know I've seen, several times. =8^) It's still fascinating to me to see
how well the AMD64 arch and kernel copes with that, with the Linux kernel
naturally scheduling interactive processes (which generally spend a lot of
time idling, waiting for input) at a higher priority, thus keeping the
system amazingly smoothly running even at that sort of load average,
without any nicing on my part other than what the kernel does normally. =8^)

Memory-wise, four gig would be plenty, even for semi-contrived usage like
this one, but I expect to keep this system for a a couple more years yet
and as I said will be upgrading to dual-dual-cores, so I decided I might
as well go for it when I did the upgrade, and went 8 gigs. Those 250+
tasks ready-to-run do noticeably load the memory, but only by a gig or
two.  Often, that won't even push cache off the top of the 8 gig, so as I
said, even here, four gigs would still be very reasonable.

As for disk access, the average guy with a single hard drive will
certainly find that the bottleneck in an unlimited jobs scenario such as
the above.  I'm running a four disk SATA based RAID array, RAID-6 (so
two-way-striped, with two-way recovery as well) on my main system, but
full four-way RAID-0/striped for my temp-data stuff, including both the
portage tree and kernel sources, and again, while the mouse movement does
chop up slightly, and ksysguard does late-update the activity plots during
the initial load, there's no way I'd know the system was running 250+ load
average if I wasn't actually watching the ksysguard one-minute load average
graph.

As for portage, no matter the -j setting and despite running
$PORTAGE_TMPDIR on tmpfs, as you (Thomas) mention, not a whole lot even
keeps the two CPUs busy all the time.  In particular, the autotools
configure scripts are normally serialized, so single thread only.  If I
have a lot of updates to do, as when a KDE version refresh comes along,
I'll routinely run five merges in parallel, as separate konsole tabs,
keeping an emerge --pretend --tree in one tab or a different console
window, using the tree layout to keep the dependency trees separate so
none of the emerge tabs interferes with the others.

Still, it's often just easier to run with a single emerge --update --deep
--newuse world and $PORTAGE_NICENESS=20, and just let the update run on
one CPU/core, and basically forget about it, going about my normal
business as if the update wasn't running.  It doesn't take /that/ much
longer, as while it's not so efficient at using every bit of CPU, there's
less scheduling contention so it's more efficient there, and with
dual-core/cpu, $PORTAGE_TMPDIR on tmpfs, and an effective two-way striped
(as a four-spindle RAID-6) main system, there's little I/O contention with
my regular tasks, so it just runs and I do what I'd do if it weren't
running (well, I've not tried burning a CD while doing it, or something
like that, but streaming Internet radio doesn't mind), and don't worry
about it.

All that said, it does seem enough stuff is beginning to be designed with
multi-core in mind, that I can actually see a dual-dual-core system being
of some use, and am looking forward to that upgrade, both for the clock
cycles upgrade (1.6GHz Opteron 242s, 2.6 GHz Opteron 285s) and the
dual-cores, giving me four cores total to work with.

-- 
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: MAKEOPTS values for Athlon 64 X2

[Thomas Rösner]

Duncan wrote:
> As for disk access, the average guy with a single hard drive will
> certainly find that the bottleneck in an unlimited jobs scenario such as
> the above.  I'm running a four disk SATA based RAID array, RAID-6 (so
> two-way-striped, with two-way recovery as well) on my main system, 

Uhm, if you'd use RAID-1-1, you wouldn't have to calculate those 
checksums...

Btw, may I come to your place when UT2007 is out? ;-)

Regards,
    T.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Andrei Slavoiu]

--- Thomas Rösner <Thomas.Roesner@digital-trauma.de>
wrote:
> Btw, may I come to your place when UT2007 is out?
> ;-)
Unless it will be released under a free license I
doubt Duncan will let you run it on his computer :-p


 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Neil Bothwick]

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

On Tue, 16 Jan 2007 00:28:26 -0800 (PST), Andrei Slavoiu wrote:

> > Btw, may I come to your place when UT2007 is out?
> > ;-)  
> Unless it will be released under a free license I
> doubt Duncan will let you run it on his computer :-p

He didn't say he'd go round when Duncan was IN :)


-- 
Neil Bothwick

If I save time, when do I get it back?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Peter Humphrey]

On Tuesday 16 January 2007 10:27, Neil Bothwick wrote:

> He didn't say he'd go round when Duncan was IN :)

Cue Christmas joke by Les Dawson:

My mother-in-law's been round to our house the last seven Christmases. This 
year I think I'll let her in!

/OT -sorry.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Thomas Rösner]

Andrei Slavoiu wrote:
> --- Thomas Rösner <Thomas.Roesner@digital-trauma.de>
> wrote:
>   
>> Btw, may I come to your place when UT2007 is out?
>> ;-)
>>     
> Unless it will be released under a free license I
> doubt Duncan will let you run it on his computer :-p
>   

Everyone has his dark secret, perhaps his is a dual boot to win98... (I 
really liked that flipper table!).

Regards,
    T.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Duncan]

Thomas Rösner <Thomas.Roesner@digital-trauma.de> posted
45AD8CF6.1010009@digital-trauma.de, excerpted below, on  Wed, 17 Jan 2007
03:41:58 +0100:

> Andrei Slavoiu wrote:
>> --- Thomas Rösner <Thomas.Roesner@digital-trauma.de>
>> wrote:
>>   
>>> Btw, may I come to your place when UT2007 is out?
>>> ;-)
>>>     
>> Unless it will be released under a free license I
>> doubt Duncan will let you run it on his computer :-p
>>   
> 
> Everyone has his dark secret, perhaps his is a dual boot to win98... (I 
> really liked that flipper table!).

Well, not that, but there /is/ still one slaveryware app  I still
run.  (Note, NOT a binary ring-zero kernel module, which as black-box code
at the kernel level exposes the entire system to danger, see for instance
the recent NVidia security issues they knew about but tried to cover up
while not providing a fix for some time!!) Yes that certainly does pretty
much makes me a slave to it as I've not found it acceptable to kill as yet.

The app in question?  The old original Master of Orion game, DOS version,
copyright 1993 so 14 years old now!  I run it in freedomware DOSBOX, so at
least the game's not dragging any other slaveryware with it.  I figure I
accepted it back then and if nothing else, it's a decently well known
quantity, or DOSBOX couldn't support it as well as it does, but at some
level both you and I know that's rationalization.  (FWIW, I tried MOO-2,
but wasn't particularly enthralled, as it lacked a single feature that
would have made the game nearly as addicting as the original.  It needed a
general planetary development pre-load queue, that is, a list of
enhancements that would preload into the work queue as soon as one
colonized the planet, thus saving the repetitive task of putting the same
thing into each build-queue, scores of times.  Without that, the game was
too much mundane repetition and not enough actual challenge.  To its
credit, that's one balance the original MOO obviously got /very/ right,
thus my continued addiction to it.  I think I was getting ready to switch
to Linux just as MOO-3 was coming out, and by that time wasn't buying
anything further that didn't run on Linux directly, so I never played it.)

Nothing else, however, and if I found it necessary to load other
slaveryware (say MSWormOS DLLs under WINE) to support it, I expect it
would be long gone.  Single binary-only/slaveryware app, no other binary
dependencies, but yes, I remain a slave to it, this I'll publicly admit.

(If you notice, my no slaveryware statements are almost always in a
forward-looking context.  I haven't purchased nor will I purchase any
non-freedomware software or hardware that requires it, since the switch.
(I did make the mistake of purchasing an NVidia card shortly
before the switch, having checked it for Linux drivers, but not
actually realizing that some binary-only drivers existed and the
significance of that fact.  I was /so/ glad to get off the thing,
about a year later, tho!  Since then it has been Radeons 9250 or lower,
thus freedomware driver supported, which happen to be relatively cheap,
so I haven't been complaining. =8^)  However, that's /not/ saying I don't
have that one remaining legacy app, now an incredible 14 years old. What's
14 computer years in human years? My relatively modest rule of thumb is a
5:1 ratio, so if it was a human, it'd be a good 70 years old now, at
least. I've seen others use the same 7:1 ratio often used for dogs, which
would put it at 98 human-years old! In any case, it's OLD, but still very
addicting, obviously, or I'd not still be running it!)

-- 
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: MAKEOPTS values for Athlon 64 X2

[Boyd Stephen Smith Jr.]

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

On Wednesday 17 January 2007 01:47, Duncan <1i5t5.duncan@cox.net> wrote 
about '[gentoo-amd64]  Re: MAKEOPTS values for Athlon 64 X2':
> The app in question?  The old original Master of Orion game, DOS
> version, copyright 1993 so 14 years old now!

I was never lucky enough to play the original MOO, but I was addicted for 
quite a while to MOO2, and for a lesser time to MOO3.  If what you say 
about MOO compared to MOO2 is correct I'd day there's a general trend 
throughout the series that the graphics get better but the UI+Grind gets 
worse.

I wish there was an F(L)OSS clone of that game.  I'd pay 50$ for it easily.  
Even better than that -- I'd take the 5$ I send Cedega every month and 
send it toward the developers.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Hemmann, Volker Armin]

On Wednesday 17 January 2007 08:47, Duncan wrote:

>
> Well, not that, but there /is/ still one slaveryware app  I still
> run.  (Note, NOT a binary ring-zero kernel module, which as black-box code
> at the kernel level exposes the entire system to danger, see for instance
> the recent NVidia security issues they knew about but tried to cover up
> while not providing a fix for some time!!) 

if you want to spread FUD, and you are doing it right now, inform yourself. 
Ok?

The fix was there in mere days after NVIDIA got the news.

The firm who reported the 'problem' confused the NVIDIA problem with a much 
older Xorg problem.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Bernhard Auzinger]

Am Mittwoch 17 Januar 2007 18:24 schrieb Hemmann, Volker Armin:
> if you want to spread FUD, and you are doing it right now, inform yourself.
> Ok?
>
> The fix was there in mere days after NVIDIA got the news.
>
> The firm who reported the 'problem' confused the NVIDIA problem with a much
> older Xorg problem.

I thought the nvidia bug was known for about a year?

rgds
Bernhard
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Hemmann, Volker Armin]

On Wednesday 17 January 2007 20:02, Bernhard Auzinger wrote:
> Am Mittwoch 17 Januar 2007 18:24 schrieb Hemmann, Volker Armin:
> > if you want to spread FUD, and you are doing it right now, inform
> > yourself. Ok?
> >
> > The fix was there in mere days after NVIDIA got the news.
> >
> > The firm who reported the 'problem' confused the NVIDIA problem with a
> > much older Xorg problem.
>
> I thought the nvidia bug was known for about a year?

http://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php/enduser/std_adp.php?p_faqid=1971

.
.
.
In summary, the accurate history of this issue is as follows:
NVIDIA was made aware of a problem with our 1.0-8774 driver that caused an X 
Server crash on July 2006 through a posting on nvnews.net.  The problem was 
not identified as a security risk.
We debugged and fixed the issue, and included it, along with many other bug 
fixes, in the Release 95 series.  1.0-9625 was released on September 21, 2006 
as a beta driver on nZone.com 
http://www.nzone.com/object/nzone_downloads_rel70betadriver.html. 
We were informed on Monday, October 16th, that the problem posed a security 
risk.  NVIDIA is releasing an updated driver from our stable Release 85 
series, 1.0-8776, on Thursday, October 19, 2006, which includes the bug fix. 
We encourage users of NVIDIA graphics driver version 1.0-8762  or 1.0-8774 to 
upgrade to 1.0-8776, available here: http://www.nvidia.com/object/unix.html          

.
.
.

there is a lot more information on that page.  It is worth reading it.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200701172222.16480.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Wed, 17 Jan 2007 22:22:16 +0100:

> NVIDIA was made aware of a problem with our 1.0-8774 driver that caused an X 
> Server crash on July 2006 through a posting on nvnews.net.  The problem was 
> not identified as a security risk.

This is the core of the problem, right here.

Putting it in non-technical terms, if the program is caused to crash, by
definition, it performed an action the programmer hadn't anticipated, or
it would have been tested for and dealt with.  Since a non-trivial number
of these crashes are known to have security implications, and we've just
demonstrated that the programmer hadn't anticipated the issue and thus
couldn't protect against it, any such crash must be treated as a potential
security issue until proven otherwise.  Since it's generally easier, for
someone who has the code anyway, to just find and fix the bug than to
demonstrate whether it's a security issue or not, that's what usually
happens, and it's never known whether it was a security issue.

Any crash of a native machine coded binary must be assumed to have
security implications unless it is demonstrable that's not the case, and
prioritized accordingly. Since this one WAS a security issue, that could
not be demonstrated, and NVidia erred in treating it as a
non-security-issue bug.  Had they acted correctly, they would have treated
it as a potential security issue, giving it according priority while
fixing it, and released the bug-fix as a potential security fix, even if
the issue had never been confirmed as a security vuln.

This demonstrates quite well one of the issues with binary-only code, too.
First, virtually all non-trivial code, proprietary source or FLOSS, very
reasonably comes with a disclaimer absolving the author of responsibility
if the code does something unintended.  It would be insane to do
otherwise, given the difficulty of anticipating all possible situations
under which the code might be used.  That's not a problem and as I said is
pretty much universal in the software industry, open source or not.

However, while open code (viewable without NDA or the like) gives the user
the ability to verify for themselves the degree of risk, or have someone
they trust do it if they don't have the skills themselves to do it,
"black-box" proprietary code not only disclaims any responsibility for
problems, but provides no way for the user to do his own evaluation (or
arrange for a party he trusts to do so).  The user is asked to agree to
absolve the author of responsibility, while no method is provided for same
user to intelligently ascertain for themselves what's in that black box
they are being asked to take responsibility for themselves!  IMO, that's
INSANE, and one reason I can never agree to the EULA most proprietary
software requires one agree to.  

While I agree it's unreasonable to NOT have a disclaimer absolving the
author of responsibility for damages, I'm not going to absolve someone
from responsibility for their code without first having the ability to
check it myself, or have someone of my choosing do so.  That by definition
then excludes from consideration anything closed source, since they very
reasonably only let me run it on condition I absolve them of
responsibility for what it might do, but (IMO) unreasonably expect me to
simply do so with no ability to have a look at what the code might do
myself, or have someone I trust have a look at it for me.

As it happens, I don't personally have the skills to verify the quality and
security of the code.  However, that "someone I trust" is the FLOSS
community, including the authors willing to put their source code out
there for examination in the first place.  By contrast, I do NOT trust
authors not willing to take that step, yet still require me to agree they
have no responsibility if the code doesn't work as intended if I choose to
use their programs, so I just choose not to make those agreements, and
consequently can't use their programs.

-- 
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: MAKEOPTS values for Athlon 64 X2

[Hemmann, Volker Armin]

On Thursday 18 January 2007 05:50, Duncan wrote:
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
> 200701172222.16480.volker.armin.hemmann@tu-clausthal.de, excerpted below,
>
> on  Wed, 17 Jan 2007 22:22:16 +0100:
> > NVIDIA was made aware of a problem with our 1.0-8774 driver that caused
> > an X Server crash on July 2006 through a posting on nvnews.net.  The
> > problem was not identified as a security risk.
>
> This is the core of the problem, right here.
>
> Putting it in non-technical terms, if the program is caused to crash, by
> definition, it performed an action the programmer hadn't anticipated, or
> it would have been tested for and dealt with.  Since a non-trivial number
> of these crashes are known to have security implications, and we've just
> demonstrated that the programmer hadn't anticipated the issue and thus
> couldn't protect against it, any such crash must be treated as a potential
> security issue until proven otherwise.  Since it's generally easier, for
> someone who has the code anyway, to just find and fix the bug than to
> demonstrate whether it's a security issue or not, that's what usually
> happens, and it's never known whether it was a security issue.
>

douzends of programms crash every second, without any security implications. 
SOME are problems, but most are just a crash.

> Any crash of a native machine coded binary must be assumed to have
> security implications unless it is demonstrable that's not the case, and
> prioritized accordingly. Since this one WAS a security issue, that could
> not be demonstrated, and NVidia erred in treating it as a
> non-security-issue bug.  Had they acted correctly, they would have treated
> it as a potential security issue, giving it according priority while
> fixing it, and released the bug-fix as a potential security fix, even if
> the issue had never been confirmed as a security vuln.

yeah, and nvidia has also thousands of programmers and developers just for 
linux drivers, right? And every single of them should be a genius who sees 
the security problems of all bugs.

> This demonstrates quite well one of the issues with binary-only code, too.
> First, virtually all non-trivial code, proprietary source or FLOSS, very
> reasonably comes with a disclaimer absolving the author of responsibility
> if the code does something unintended.  It would be insane to do
> otherwise, given the difficulty of anticipating all possible situations
> under which the code might be used.  That's not a problem and as I said is
> pretty much universal in the software industry, open source or not.
>
> However, while open code (viewable without NDA or the like) gives the user
> the ability to verify for themselves the degree of risk, or have someone
> they trust do it if they don't have the skills themselves to do it,
> "black-box" proprietary code not only disclaims any responsibility for
> problems, but provides no way for the user to do his own evaluation (or
> arrange for a party he trusts to do so).  The user is asked to agree to
> absolve the author of responsibility, while no method is provided for same
> user to intelligently ascertain for themselves what's in that black box
> they are being asked to take responsibility for themselves!  IMO, that's
> INSANE, and one reason I can never agree to the EULA most proprietary
> software requires one agree to.


blablabla. 

Lots of words and political agenda.

Fact is, that ALL non trivial software has bugs. Every single kind. 

So, does firefox had sec vulnerabilites in the past? Oh yes. Xpdf? Xorg?
Yes.
The kernel?
Oh yes, almost monthly such vulnerabilietes are reported.

How many people read the code?
almost noone. 
All that 'the user can read the code and look and fix for himself' is nice, 
but wishfull thinking. Most people can't read code. And most of the people 
you can, don't do it or don't find the bugs themselves.

You see lots of Open Source projects, where the security firms need to show 
them their bugs. Why? The devs should find them? Right? Or all the people 
reading the code before downloading and using it?


>
> As it happens, I don't personally have the skills to verify the quality and
> security of the code.  

yeah, that is a surprise. Not.

> However, that "someone I trust" is the FLOSS 
> community, including the authors willing to put their source code out
> there for examination in the first place. 

and still there are lots of bugs in open source software. Lots of bugs leading 
to lots of security problems. Hm.

So much text from you, but where is the 'I was wrong, sorry'?

Even if nvidia should have recognized the bug as a serious problem the moment 
it was reported, they delivered the bugfix in 3 month, 3 days after they got 
informed that it was security problem.  And they did not 'cover it up'.

So  stop spreading FUD, stop slander companies, and please, please stop using 
the term 'slaveryware'. Oh, and a little bit less of preaching, ok?
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Rob Lesslie]

> So  stop spreading FUD, stop slander companies, and please, please stop using
> the term 'slaveryware'. Oh, and a little bit less of preaching, ok?


Seconded.

-- 
Rob Lesslie
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Boyd Stephen Smith Jr.]

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

On Thursday 18 January 2007 10:16, "Rob Lesslie" <roblesslie@gmail.com> 
wrote about 'Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2':
> > So  stop spreading FUD, stop slander companies, and please, please
> > stop using the term 'slaveryware'. Oh, and a little bit less of
> > preaching, ok?
>
> Seconded.

Motion has been seconded.  There is now a vote before this mailing list.

All the Ayes?

All the Nays?

NAY!

Voting will be open for the next 24 hours.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Simon Stelling]

Boyd Stephen Smith Jr. wrote:

 > --
 > "If there's one thing we've established over the years,
 > it's that the vast majority of our users don't have the slightest
 > clue what's best for them in terms of package stability."
 > -- Gentoo Developer Ciaran McCreesh

You might want to add an "Ex-" in front of the "Gentoo" here.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Boyd Stephen Smith Jr.]

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

On Thursday 18 January 2007 12:35, Simon Stelling <blubb@gentoo.org> wrote 
about 'Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2':
> Boyd Stephen Smith Jr. wrote:
>  > -- Gentoo Developer Ciaran McCreesh
>
> You might want to add an "Ex-" in front of the "Gentoo" here.

I didn't know he'd left the project.  I guess it's time to go back to my 
old .sig.

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Simon Stelling]

Boyd Stephen Smith Jr. wrote:
> I didn't know he'd left the project.  I guess it's time to go back to my 
> old .sig.

Well he did, even if not by his free will.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Peter Humphrey]

On Thursday 18 January 2007 18:35, Simon Stelling wrote:
> Boyd Stephen Smith Jr. wrote:
>  > --
>  > "If there's one thing we've established over the years,
>  > it's that the vast majority of our users don't have the slightest
>  > clue what's best for them in terms of package stability."
>  > -- Gentoo Developer Ciaran McCreesh
>
> You might want to add an "Ex-" in front of the "Gentoo" here.

Before the "Developer", surely? Unless he's a developer of ex-Gentoo.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Thomas Rösner]

Peter Humphrey schrieb:
> On Thursday 18 January 2007 18:35, Simon Stelling wrote:
>   
>> Boyd Stephen Smith Jr. wrote:
>>  > --
>>  > "If there's one thing we've established over the years,
>>  > it's that the vast majority of our users don't have the slightest
>>  > clue what's best for them in terms of package stability."
>>  > -- Gentoo Developer Ciaran McCreesh
>>
>> You might want to add an "Ex-" in front of the "Gentoo" here.
>>     
>
> Before the "Developer", surely? Unless he's a developer of ex-Gentoo.
>   

There you have it, now we have to go through the whole sketch again. 
You'll take the shop owner's part.

Regards,
    T. 


-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200701181712.53640.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Thu, 18 Jan 2007 17:12:53 +0100:

> So much text from you, but where is the 'I was wrong, sorry'?
> 
> Even if nvidia should have recognized the bug as a serious problem the
> moment it was reported, they delivered the bugfix in 3 month, 3 days
> after they got informed that it was security problem.  And they did not
> 'cover it up'.

If I am demonstrated to be wrong, I say it, but it hasn't happened here. 
It WAS a security vuln, and as any such unhandled crash from native code,
they should have treated it as a potential security vuln from the moment
the found it until it was fixed or proven otherwise.

As for time to a fix, the point is, regardless of how long it actually
took, if the software master (see the sig) has respect for his users and
makes source available, any user can either create a fix or arrange for it
to be created.  As it happens, in something that widely used, precisely
/because/ the source is available, a decent share of such bugs (which we
both agree happen in all non-trivial software) in the FLOSS community are
fixed in rather LESS than "three months, three days". However, that's
beside the point, since any user of such software who thinks such bugs
aren't being turned around in a timely enough manner can arrange for a fix
themselves, or simply apply a patch if someone else has already done so. 
Since it was slaveryware, that option wasn't available and a slave subject
to master NVidia's whims and decisions on timing, unable to take their own
needs and priorities into consideration and arrange for a fix sooner if
they thought necessary, is /exactly/ what the users were. 

What if NVidia had taken a year to come out with a fix?  What if they
decided it wasn't worth their trouble and never came out with a fix?  If
it's Free software, there's an alternative, should the user wish to avail
themselves if it.  With slaveryware, that's exactly what the user is, a
slave to the whims of the software's master.  I make it a point to no
longer be a slave to the whims of the masters of the code I run.  That
doesn't mean you have to, it just means I do.

As for using the term slaveryware in my posts... You don't tell me how I
feel about the software I believe is slaveryware and label it so in my
posts, and I'll not insist you call it slaveryware in yours.  After all,
if you find my choice of terms offensive, you don't /have/ to read them. 
There /is/ this thing called a killfile, should you find it necessary to
use.  Call it heavenlyware in yours if you wish.  Deal? =8^)

(Oh, and backing someone into a corner by demanding an apology doesn't
tend to be a very effective way of actually getting one.  Let's not make
this too personal, and agree that we /can/ disagree.  It's not as if the
world comes to an end because of it, after all. =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: MAKEOPTS values for Athlon 64 X2

[Hemmann, Volker Armin]

On Thursday 18 January 2007 19:41, Duncan wrote:
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
> 200701181712.53640.volker.armin.hemmann@tu-clausthal.de, excerpted below,
>
> on  Thu, 18 Jan 2007 17:12:53 +0100:
> > So much text from you, but where is the 'I was wrong, sorry'?
> >
> > Even if nvidia should have recognized the bug as a serious problem the
> > moment it was reported, they delivered the bugfix in 3 month, 3 days
> > after they got informed that it was security problem.  And they did not
> > 'cover it up'.
>
> If I am demonstrated to be wrong, I say it, but it hasn't happened here.
> It WAS a security vuln, and as any such unhandled crash from native code,
> they should have treated it as a potential security vuln from the moment
> the found it until it was fixed or proven otherwise.
>
> As for time to a fix, the point is, regardless of how long it actually
> took, if the software master (see the sig) has respect for his users and
> makes source available, any user can either create a fix or arrange for it
> to be created.  As it happens, in something that widely used, precisely
> /because/ the source is available, a decent share of such bugs (which we
> both agree happen in all non-trivial software) in the FLOSS community are
> fixed in rather LESS than "three months, three days". However, that's
> beside the point, since any user of such software who thinks such bugs
> aren't being turned around in a timely enough manner can arrange for a fix
> themselves, or simply apply a patch if someone else has already done so.
> Since it was slaveryware, that option wasn't available and a slave subject
> to master NVidia's whims and decisions on timing, unable to take their own
> needs and priorities into consideration and arrange for a fix sooner if
> they thought necessary, is /exactly/ what the users were.
>
> What if NVidia had taken a year to come out with a fix?  What if they
> decided it wasn't worth their trouble and never came out with a fix?  If
> it's Free software, there's an alternative, should the user wish to avail
> themselves if it.  With slaveryware, that's exactly what the user is, a
> slave to the whims of the software's master.  I make it a point to no
> longer be a slave to the whims of the masters of the code I run.  That
> doesn't mean you have to, it just means I do.
>
> As for using the term slaveryware in my posts... You don't tell me how I
> feel about the software I believe is slaveryware and label it so in my
> posts, and I'll not insist you call it slaveryware in yours.  After all,
> if you find my choice of terms offensive, you don't /have/ to read them.
> There /is/ this thing called a killfile, should you find it necessary to
> use.  Call it heavenlyware in yours if you wish.  Deal? =8^)
>
> (Oh, and backing someone into a corner by demanding an apology doesn't
> tend to be a very effective way of actually getting one.  Let's not make
> this too personal, and agree that we /can/ disagree.  It's not as if the
> world comes to an end because of it, after all. =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


to long, did not read.

Stop preaching.

And I showed you, you were wrong. YOU said, they tried to cover it up. They 
did not. As soon, as it was known to be a vulnerabilty, it was fixed. In 
three days.

So your whole attack was nonesense.

That said, a lot of vulns are not recognized at first, because not everybody 
is a security guru.

Like the Xorg render vulnerability. Crash in render, Xorg's fault, open to 
exploit. Despite the fact, that xorg is open source. And despite the fact 
that everybody could read the code, it took a long time to find it.


Stop using the word 'slaveryware' or I might use 'that zealot' when I am 
talking about you. Slaveryware is offensive and demeaning. Everytime you use 
it, you should apologise to everybody who had the bad luck of reading it.

I am sorry that I am using that term just now. Please forgive me.

And killfile is not an option, you are sending lots and lots of your sermons 
to the ml. In fact, almost all mails of you end as a sermon. Sometimes, 
someone just had to ask for a break to show, that YOUR point of view is 
certainly NOT the one of everybody else.

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200701181951.57459.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Thu, 18 Jan 2007 19:51:57 +0100:

> And I showed you, you were wrong. YOU said, they tried to cover it up.
> They did not.

You do have a point there.  I was wrong on that.

> Stop using the word 'slaveryware' or I might use 'that zealot' when I am
> talking about you.

It's your post, your opinion to voice.  And given the choice between zealot
or slave, I'm sure you know which I'd take. =8^) I simply call it as I see
it, and I see it as slaveryware.  If you see me as a zealot, you aren't my
slave, feel free to call me that in your posts.

> Everytime you use it, you should apologise to everybody who had the bad
> luck of reading it.

And who am I, /your/ slave?  I think not!  My freely held opinion goes in
my post, with my name at the top and my sig at the bottom, and that's
something I don't apologize for!

-- 
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: MAKEOPTS values for Athlon 64 X2

[Bob Young]

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org]On Behalf Of Duncan
> Sent: Wednesday, January 17, 2007 8:51 PM
> To: gentoo-amd64@lists.gentoo.org
> Subject: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2
> 
> 
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
> 200701172222.16480.volker.armin.hemmann@tu-clausthal.de, excerpted below,
> on  Wed, 17 Jan 2007 22:22:16 +0100:
> 
> > NVIDIA was made aware of a problem with our 1.0-8774 driver 
> that caused an X 
> > Server crash on July 2006 through a posting on nvnews.net.  The 
> problem was 
> > not identified as a security risk.
> 
> This is the core of the problem, right here.
> 
> As it happens, I don't personally have the skills to verify the 
> quality and security of the code. 

And neither do 99.999% of all computer users, whether they be MAC, Linux, or Windows users. That's what's at the core of the issue, and it's never goinig to change. 

In addition, the number of people who even *could* examine a given type of code (a video driver for example) and render a valid opinion as to it's quality is *extremely* small. Somone who writes database code for a living isn't going to have a clue about the details and intricacies of a video driver module. In fact even somone who writes drivers for another kernel sub-system (SCSI disk drivers for example) will probably quickly find themselves beyond their depth of understanding when examining 2D/3D/OpenGL video driver code.

> However, that "someone I trust" is the FLOSS
> community, including the authors willing to put their source code out
> there for examination in the first place. 

Code from the OSS comunity has bugs and flaws just like code from the CSS comunity does, in fact they are often writen by the same people. If anything, it's likely that the CSS code is a bit more robust and better tested. CSS code in general (assuming the typical case of it being produced by a "company"), usually goes through more testing and a more formal Quality Assurance procedure than OSS. The quality, or lack there of for CSS, often has a direct effect on the finances of the vendor. That being the case, CSS vendors are inclined to go to a little extra trouble to keep obvious flaws out of their releases. On the OSS side of the equation there isn't any hard financial incentive to rigoriously regression test before posting a new release, because of the this and the real limitations described above, the mythical "many eyes" examining OSS code don't actually exist in any realistic sense.


> By contrast, I do NOT trust
> authors not willing to take that step, 

In the case we're talking about it's not actually the authors that aren't willing to publish their code, I'm sure that the authors are just as proud of their work as any OSS author is and would be perfectly willing to have it seen by anyone. It's the Company that feels the need to protect their intelectual property, and whether you, or RS, or anyone else, does or does not like it, they in fact have the right to do so. Also, IMO they also have a valid argument for doing so.


> yet still require me to agree they
> have no responsibility if the code doesn't work as intended if I choose to
> use their programs, so I just choose not to make those agreements, and
> consequently can't use their programs.

You're certaintly free to make choices based on whatever criteria you feel like using, I just think that in the grand scheme of things the difference between using OSS and CSS is prety insignifiant. In the long run good apps, utilities, and hardware/drivers (whether OSS or CSS) will be successful, and the bad ones, (whether OSS or CSS), will fade away. 

The vast majority of users don't care whether what they are using is OSS or CSS, what they do, and should, care about is whether or not it works and does what they want. So while you're choice to use only OSS may give you personal satisfaction, in the long run it's not a choice that the vast majority of users are ever going to, or actually have any real need to consider.

-- 
Regards,
Bob



-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Harry Holt]

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

shouldn't this discussion go off-line?  or at least into another topic such
as 'rants on the openness of software'.  I think it has strayed a bit from
'MAKEOPTS values'.


On 1/18/07, Bob Young <BYoung@nucoretech.com> wrote:
>
>
>
> > -----Original Message-----
> > From: news [mailto:news@sea.gmane.org]On Behalf Of Duncan
> > Sent: Wednesday, January 17, 2007 8:51 PM
> > To: gentoo-amd64@lists.gentoo.org
> > Subject: [gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2
> >
> >
> > "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
> > 200701172222.16480.volker.armin.hemmann@tu-clausthal.de, excerpted
> below,
> > on  Wed, 17 Jan 2007 22:22:16 +0100:
> >
> > > NVIDIA was made aware of a problem with our 1.0-8774 driver
> > that caused an X
> > > Server crash on July 2006 through a posting on nvnews.net.  The
> > problem was
> > > not identified as a security risk.
> >
> > This is the core of the problem, right here.
> >
> > As it happens, I don't personally have the skills to verify the
> > quality and security of the code.
>
> And neither do 99.999% of all computer users, whether they be MAC, Linux,
> or Windows users. That's what's at the core of the issue, and it's never
> goinig to change.
>
> In addition, the number of people who even *could* examine a given type of
> code (a video driver for example) and render a valid opinion as to it's
> quality is *extremely* small. Somone who writes database code for a living
> isn't going to have a clue about the details and intricacies of a video
> driver module. In fact even somone who writes drivers for another kernel
> sub-system (SCSI disk drivers for example) will probably quickly find
> themselves beyond their depth of understanding when examining 2D/3D/OpenGL
> video driver code.
>
> > However, that "someone I trust" is the FLOSS
> > community, including the authors willing to put their source code out
> > there for examination in the first place.
>
> Code from the OSS comunity has bugs and flaws just like code from the CSS
> comunity does, in fact they are often writen by the same people. If
> anything, it's likely that the CSS code is a bit more robust and better
> tested. CSS code in general (assuming the typical case of it being produced
> by a "company"), usually goes through more testing and a more formal Quality
> Assurance procedure than OSS. The quality, or lack there of for CSS, often
> has a direct effect on the finances of the vendor. That being the case, CSS
> vendors are inclined to go to a little extra trouble to keep obvious flaws
> out of their releases. On the OSS side of the equation there isn't any hard
> financial incentive to rigoriously regression test before posting a new
> release, because of the this and the real limitations described above, the
> mythical "many eyes" examining OSS code don't actually exist in any
> realistic sense.
>
>
> > By contrast, I do NOT trust
> > authors not willing to take that step,
>
> In the case we're talking about it's not actually the authors that aren't
> willing to publish their code, I'm sure that the authors are just as proud
> of their work as any OSS author is and would be perfectly willing to have it
> seen by anyone. It's the Company that feels the need to protect their
> intelectual property, and whether you, or RS, or anyone else, does or does
> not like it, they in fact have the right to do so. Also, IMO they also have
> a valid argument for doing so.
>
>
> > yet still require me to agree they
> > have no responsibility if the code doesn't work as intended if I choose
> to
> > use their programs, so I just choose not to make those agreements, and
> > consequently can't use their programs.
>
> You're certaintly free to make choices based on whatever criteria you feel
> like using, I just think that in the grand scheme of things the difference
> between using OSS and CSS is prety insignifiant. In the long run good apps,
> utilities, and hardware/drivers (whether OSS or CSS) will be successful, and
> the bad ones, (whether OSS or CSS), will fade away.
>
> The vast majority of users don't care whether what they are using is OSS
> or CSS, what they do, and should, care about is whether or not it works and
> does what they want. So while you're choice to use only OSS may give you
> personal satisfaction, in the long run it's not a choice that the vast
> majority of users are ever going to, or actually have any real need to
> consider.
>
> --
> Regards,
> Bob
>
>
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
Harry Holt, PMP

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

[gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Duncan]

"Harry Holt" <harryholt@gmail.com> posted
7c8072a00701181142y5c2193b4me4baf15fb1a0b534@mail.gmail.com, excerpted
below, on  Thu, 18 Jan 2007 14:42:13 -0500:

> shouldn't this discussion go off-line?  or at least into another topic
> such as 'rants on the openness of software'.  I think it has strayed a bit
> from 'MAKEOPTS values'.

Thanks.  I thought about the same, but it's difficult to resist that one
more reply, when you're in the middle of the debate. =8^)  Still, I think
both sides have made their points and no further movement is likely at
this point, so it's time to move on in any case.

-- 
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: MAKEOPTS values for Athlon 64 X2

[Peter Humphrey]

On Thursday 18 January 2007 04:50, Duncan wrote:

> Putting it in non-technical terms,

Do try to be less condescending.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: MAKEOPTS values for Athlon 64 X2

[Duncan]

Thomas Rösner <Thomas.Roesner@digital-trauma.de> posted
45AC0F0A.5050408@digital-trauma.de, excerpted below, on  Tue, 16 Jan 2007
00:32:26 +0100:

> Duncan wrote:
>> As for disk access, the average guy with a single hard drive will
>> certainly find that the bottleneck in an unlimited jobs scenario such as
>> the above.  I'm running a four disk SATA based RAID array, RAID-6 (so
>> two-way-striped, with two-way recovery as well) on my main system,
> 
> Uhm, if you'd use RAID-1-1, you wouldn't have to calculate those
> checksums...

True, but computing checksums is relatively trivial compared to the I/O
overhead, and reading (which doesn't need checksums unless the
RAID array is operating in degraded mode) would be half-speed relative to a
4-disk RAID-6 (so two-way data striped). Given the trivial checksumming,
Writing would be comparable to a three-disk RAID-1, and is slower than a
two-disk RAID-1, as for every data stripe there's two parity stripes to
update, but there's not a lot of data actually written anyway during
emerges, since all the work is done on tmpfs and only the final write is
to the disk.  When compiling the kernel, I'm working directly on disk but
that mount is a four-way striped RAID-0, so I get its speed and no
checksumming overhead there.  (/boot is RAID-1 so GRUB can read it, so
when the kernel is actually installed, it's written to 4-way RAID-1, but
that's only one writing the completed kernel, so no big deal there.)

If I was running less than four disks, the choice would be a bit tougher,
between a 3-disk RAID-5 with two-way striped read speed but
two-way-mirrored (plus checksumming) write speed, while losing the
ability to recover from a two-drive failure, a 3-disk RAID-1, keeping the
two-drive recovery but at a severe cost in speed, or a 2-disk
RAID-1/mirrored. In that instance I expect the 2-disk RAID-1/mirrored
would win as it would be too difficult to justify either of the 3-disk
options.

> Btw, may I come to your place when UT2007 is out? ;-)

As a gamer, you'd probably not appreciate my choice of video card -- an
older but freedomware driver Radeon 9250.  I won't do
proprietaryware/slaveryware.

Luckily I'm not much of a gamer, but the rest of the hardware specs are
complimented by dual 400x300 mm (21" diag) monitors, normally running @
1600x1200 stacked for 1600x2400. I used to run 2048x1536 stacked for
2048x3072, but while it worked, text was blurry as that was below the
monitors' native pixel pitch (set for 1600x1200), and the 85 Hz refresh
doesn't hurt (I was limited to 60 Hz with the higher resolution,
acceptable with the light text on dark backgrounds I prefer, but not
ideal, or even tolerable with dark text on light backgrouns) either, so I
finally caved in and downgraded my resolution.

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