I spend about 30 mins [tops] a day building usually leave it in the background while I play SAN ANDREAS [boo fuckin ya!;-)].
If you use Gentoo for speed you're stupid.
The real reasons to use gentoo are
1. Portage 2. USE flags 3. Status of using Gentoo
Think about this. Go install Knoppix. Now try to export a TIFF with the packaged GIMP. Try to import a PS with TeTeX. etc. etc. etc. In gentoo you add USE=tiff and boom all programs that can be configured with tiff support now have it.
Gentoos configurability is what makes it so attractive to me at least.
Of course I actually use my Linux PC for more than just "playing the latest fad FPS game". I actually write software, papers, etc with it which requires having development and typesetting tools properly built.
Oh and building from source is ideal if you own an AMD64 since most "binary" distributions are for i386 not x86-64. So if "wasting" 30 mins in the background here and there is the cost of having my applications built with the latest GCC for my cpu then oh no shock and horror it's worth it.
Depends. Plomp a newbie in front of KDE [or Gnome] and I think they have equal chances as if you sat them in front of XP.
Though this raises another point. I personally don't think computers should be that easy. It makes people too complacent and likely to tolerate not only buggy software but insecure software too.
If it were common [for instance] that people had the first clue about process trees and such then I'm sure most spyware wouldn't exist. If people were forced through less automated ways to send files [e.g. put url in email instead of file] chances are there would be less email bound viruses, etc...
A 3000MIPS computer with broadband "so easy my grandmother can use" isn't always a good idea. A proper analogy would be a 300HP 7'6" SUV. Sure it may be your "right" to own one... doesn't mean you have a right to use it insecurely.
Though side rant aside...
The biggest problem I have with Linux isn't really a Linux problem at all. It's the cut-corner-make-a-buck hardware manufacturers that don't follow specs. Of course next on my list would be the scores of "OSS Developers" who write really shitty software.
But for the most part once you overcome the hardware hurdle Linux based OSes [like Gentoo + Gnome] can be every bit as "desktopy" as WindowsXP and ultimately way more useful if you do more than "check the web". Cuz I know for sure I've never seen cc in a copy of Windows.
Not ready for the desktop? I think the biggest reason why hardware [specially laptops] seem to "not work in linux" isn't because Linux isn't capable, because it is. Not because the driver infrastructure is lacking, because it isn't. But because hardware developers cut corners and provide Window drivers only.
If hardware manufacturers actually followed standards and didn't "upgrade" chipsets [specially on stable products like 802.11b cards... Realtek anyone?] every two months to be "new" we'd have systems that work fine in Linux.
I think Linux based distroes are [in particular Gentoo] just as capable as a desktop platform. It's the hardware that is lacking.
The problem is finding staff to write drivers. I mean the windows drivers for most hardware is crap. Do you really expect them to then be able to write a linux or BSD driver too?
As for things like sound/graphics there is no reason why new cards don't support AC'97 and that graphics support VESA 3.0 with hardware accel other than they're cheap and want to pander to MSFT.
So stop saying "Linux ain't ready" when it's the manufacturers that aren't!
Tom [speaking as someone who uses Linux on his Compaq Laptop and piece-meal Desktop]
Well the major difference between C and C++ being that C++ supports "native" classes while in C you emulate them with arrays of stuctures.
A class is a way of organizing "objects" in a hiarchical manner. You could almost say an OOP manner. The fact you can do more with C++ doesn't take away the fact that oop is the major difference. In fact I can't think of any other reason to use C++ over C aside from classes and the various forms of inheritance.
The point is C didn't borrow what C++ had to offer not because the ISO C committee is lazy or incompetent but that C solves DIFFERENT problems.
Yeah, who wants a common driver API for video, network, or sound cards...
Um, there is no reason why you can't do this in C relatively easily. All you have todo is make a common API and stick to it.
In my crypto library I have a dozen ciphers, hashes and prngs. Every cipher has the exact same function prototypes and can be called via a table driven system.
"C++" effectively would do the EXACT SAME THING except with less control over the actual implementation.
Say who? C++ is not a better C anymore than my an iPod is not a better alarm clock radio.
C++ and C solve different problems.
IMO C is good for low level and structured [re: modular] programming. Despite what many think this isn't limiting to say kernel development. Sadly many "developers" think a 1000-line main() function is "impressive".
C++ is meant to take C and throw it in an OOP direction. Although any program you can write in C you can write in C++ [and vice versa] this doesn't mean C++ is an "improved C"....language wars aside...
It's stupid comments like yours that really drive down the merits of actual computer science. Since you don't understand the issue you take up an irrational and off-base point of view. The problem is that the world is full of lazy stupid people just like you. They fill up the halls and next thing you know someone is leveraging your dynamic synergy between solution providers and contact base deployments!
C++ has it's uses. C has it's uses. C++ is not "C v2.0".
Don't pay under any circumstances and do your best to track down the people responsible. Paying or otherwise giving them the ego-stroking they want is just counterproductive.
This is also a good reason why companies should have gotten into the habit of using PGP/GPG to sign their emails as policy... But I guess they get what they pay for now...
I think TCC is a cool project and definitely a useful tool but what does it mean to say it's fast?
The code it makes is very likely not as optimal as GCC can make. Specially something like a Kernel I wouldn't mind some optimizations [even in the form of -O2] And really GCC with -O0 is very fast...
That's like saying memcpy() is the better cipher because it's faster than AES!
mp3 falls into that category. On a CBR file you can roughly just fseek to bitrate*seconds into the file and be approximately where you want to be.
Valid mp3 decoders must allow "garbage" data before a header. So
cat somerandomtxtfile.txt mysong.mp3 > new.mp3
new.mp3 is now a valid mp3 file/stream.
Chances are the testers aren't actually users which is why they didn't find a really slow FFW "a problem".
Though really cumbersome MP3 players are pretty much the norm. Mine [from Samsung of all companies...] doesn't sort the files so even though my tracks are numbered they never play in any particular order [and no this is with shuffle turned off]. It also "plays" as you seek which is annoying [so it's even slower than 6min/60min as this player has].
There is no solution to that problem other than to ensure that each ISP is responsible. No matter what you do at your gateway short of just disconnecting a network you can't stop packets from comming in.
What would help SYN spoofing is responsible ISPs that check the source address and discard invalid IP packets. My proposal is for people who connect flood a server.
It's easy to send 40KB/sec when your packets are 1KB in size. Not so easy when they're 40 byte SYN packets [or whatever the size is].
I agree that my idea won't stop a SYN flood. The idea is to stop stupid kiddies who "wget flood" your box.
What I don't get is why ISPs allow forged SYNs out in the first place. If they only checked the source IP before routing it outwards this wouldn't be an issue because then other ISPs could just monitor SYN traffic and ban the ip on the fly.
How do you send 25k/sec? That's 640 SYN packets/sec or roughly a latency of 1.56ms. Considering the RTTs I get with various sites that doesn't seem plausible from a cable modem.
Besides you can also augment the module to forward the IPs to ban securely to your ISP. My god you people have no creativity.:-)
The point is it's trivial to automatically cut people off on the server side [e.g. to avoid serving pages or even establishing the TCP connection]. If you make it securely tell your ISP what to ban you can even cut them off at that gate too.
um... a socket is only allocated to a connect() call. If you ban the IP on the firewall side the SYN is simply ignored.
So yes, the 40 byte SYN packet consumes bandwidth coming in. But you don't expend bandwidth or cpu time otherwise [e.g. no ACK/SYN going the otherway]
Although that raises an interesting question. Who should pay for the bandwidth coming in? Just like who should pay for SMS? I didn't choose to have a SMS plan [well ok by signing up I did, but they don't have non-SMS plans]. So if some ass decides to SMS-bomb my cell why should I pay for it when my cell company didn't protect me?
So if you firewall some jackass with a fat-pipe who decides to connect flood you and you do your part by not opening the connections who should pay for it?
I think this is a good way to transfer some responsibilities back to the ISPs [in particular the originating ISP, something fishy about the same or similar HTTP request occuring 1000s of times a minute from a DSL...] and ultimately the user. Just like how spam should [ideally] be handled....
Um you can easily do an hour ban on excessive hits from a given IP. Write a module for Apache that counts the hits from a given IP. If it hits a certain threshold [say > 100 hits a minute or >x KB per second] then it simply adds the ip to a firewall [ipchains, netfilter, etc].
By making the banning automated you can easily cope with a DDoS.
Some other things to help cope
- Make small pages, well compressed images
- Don't make highly detailed pages you can get to without loging in first [e.g. avoid server cpu load]
It wouldn't be safe to assume a pointer can be stored in 32-bits in 64-bit mode. The OS can map your data anywhere in the 64-bit space [which maps physically to a 40-bit bus, at least on my AMD64]. It's also not portable to do that. Even if your OS maps stuff within 4GB [e.g. top 32-bits are zero] another 64-bit box [sparc, ppc, etc..] may not [and likely would not] do that.
If you build in 32-bit mode [e.g. -m32] you lose the major benefits of the 64 which is namely the extra registers.
IIRC also a b-tree like structure could help this. Where you have to have pointers to nodes the actual elements ["leaves"] in the nodes would not need individual pointers.
Also this isn't much of an issue. If you're likely to have a huge database you're already likely to require 64-bit offsets [into memory/file/etc] as 4GB is often not enough.
So not only can you mitigate the "downside" to larger pointers by using more efficient data structures but the issue is largely moot anyways.
And FYI my Gentoo AMD64 box running Xorg6.8.x, GNOME, gaim, xmms, a few xterms, gedit and nedit only is using 200MB of ram [prolly cache too]. Which is comparable to when I was running the same software on my P4.
The bulk of memory used is for code [which could be shorter as the instruction set is more powerful] and it's data [which largely doesn't change with register size].
It's one thing to troll, but when you do a bad job of trolling... well that just makes you some kinda idiot. I bet you rode the "special" bus to school right?
Can't agree more. I run Gentoo on my AMD64 and from time to time there will be a package that builds only in 32-bit mode [usually cuz the developers aren't that proficient at writing portable code]. Nice to add the "-m32" switch to GCC.
Sadly though, running 32-bit code [about equivalent to a spruced up Barton core] means less people will push MSFT to make a 64-bit winders quicker.
I know a few people already that swear by their AMD64 and then run WinXP [32-bit edition] on it. For those not in the know, in 32-bit mode [e.g. not long-mode] you can't access the extra registers or 64-bit wide registers.
Essentially in 32-bit mode [say Windows] an AMD64 is a Barton with the following benefits: wider decode-bus [128-bits instead of 64-bits], SSE2 and more instructions are DirectPath instead of VectorPath [means they decode/execute quicker].
In 64-bit mode you get all that plus the extra registers [8 more ALU and SSE] as well as the 64-bit ALU registers. Which helps the most in more diverse applications [than say the mere presence of SSE2]
The K8s are much better than the K7s at power management. Granted the P4 still wins with the "never shutdown feat" the 99.999% of the time where your heatsink/fan is working fine the K8 will be taking less power, making less heat and computing more IPC.
In my experience it's the heatsink that matters the most. My fan runs at 2500RPM [constantly. It's a thermaltake K8 silentboost] and doesn't really move that much air. I'm sure it helps by a half-dozen degrees C or so but it's not as important as the HUGE BLOCK OF COPPER stuck to it.
So do you buy a P4 for that once in a million time where your heatsink falls off or a K8 which will run more efficiently?
When you take a dump and the log hits the bowl... um it's not entirely cleaned out when you flush. So no. even with pristine clear perfectly clean water coming into the bowl it wouldn't be safe to drink.
What the fuck is wrong with people? Holy crap literally!
I can attest to the power. My Athlon64 [3200+ NewCastle] runs cooler and faster than my P4 [2.8Ghz Northwood]. At 1Ghz [I clock down when idle] it goes as low as a few degrees over ambient [it's 23C now, the mobo is 21C the room with window open is probably around 17C or so].
At 2.2Ghz [full speed] the cpu idles at ~35C or about +10C over ambient and under full load hits around ~46C [about +21C over ambient].... With a 36$ Thermaltake SilentBoost K8!!!
Compared that to my P4 which had a Polo735 Thermaltake it idled at 33C and hit 55C at full load.
When you take into account that the K8 smokes the P4 [specially for building software which is what I do]... yeah.
As for gaming, well I have a GeForce 5200 so I can't really say. I get a good framerate in ut2k4 but I can't say it's "much faster". Maybe a few fps faster when there are many bots [and I run the amd64 build...] but that's about it.
My point though is that the K8 beats the P4 in both power and performance. Right now Intel is holding onto irrelevent metrics/benchmarks to win over the crowd.
I own both cpus and I know for a fact that where it matters most [and sorry, gaming isn't it] the K8 is sweeeeet!
Seems like they're falling-through on many of their more recent promisses? That couldn't possibly be to steal thunder from other people...... no way!
Hey intel, do what many of us said years ago, ditch the P4 crap, admit that it was a mistake and go the normal high IPC route already. K8's are already smoking you at "non-gaming" [re: serious work] tasks and at least as good if not better at the little fps's anyways.
Slashdot Mirror
Cuz that guy has a 100Mhz 486DX4 or something.
;-)].
I spend about 30 mins [tops] a day building usually leave it in the background while I play SAN ANDREAS [boo fuckin ya!
If you use Gentoo for speed you're stupid.
The real reasons to use gentoo are
1. Portage
2. USE flags
3. Status of using Gentoo
Think about this. Go install Knoppix. Now try to export a TIFF with the packaged GIMP. Try to import a PS with TeTeX. etc. etc. etc. In gentoo you add USE=tiff and boom all programs that can be configured with tiff support now have it.
Gentoos configurability is what makes it so attractive to me at least.
Of course I actually use my Linux PC for more than just "playing the latest fad FPS game". I actually write software, papers, etc with it which requires having development and typesetting tools properly built.
Oh and building from source is ideal if you own an AMD64 since most "binary" distributions are for i386 not x86-64. So if "wasting" 30 mins in the background here and there is the cost of having my applications built with the latest GCC for my cpu then oh no shock and horror it's worth it.
Tom
Depends. Plomp a newbie in front of KDE [or Gnome] and I think they have equal chances as if you sat them in front of XP.
Though this raises another point. I personally don't think computers should be that easy. It makes people too complacent and likely to tolerate not only buggy software but insecure software too.
If it were common [for instance] that people had the first clue about process trees and such then I'm sure most spyware wouldn't exist. If people were forced through less automated ways to send files [e.g. put url in email instead of file] chances are there would be less email bound viruses, etc...
A 3000MIPS computer with broadband "so easy my grandmother can use" isn't always a good idea. A proper analogy would be a 300HP 7'6" SUV. Sure it may be your "right" to own one... doesn't mean you have a right to use it insecurely.
Though side rant aside...
The biggest problem I have with Linux isn't really a Linux problem at all. It's the cut-corner-make-a-buck hardware manufacturers that don't follow specs. Of course next on my list would be the scores of "OSS Developers" who write really shitty software.
But for the most part once you overcome the hardware hurdle Linux based OSes [like Gentoo + Gnome] can be every bit as "desktopy" as WindowsXP and ultimately way more useful if you do more than "check the web". Cuz I know for sure I've never seen cc in a copy of Windows.
Tom
Not ready for the desktop? I think the biggest reason why hardware [specially laptops] seem to "not work in linux" isn't because Linux isn't capable, because it is. Not because the driver infrastructure is lacking, because it isn't. But because hardware developers cut corners and provide Window drivers only.
If hardware manufacturers actually followed standards and didn't "upgrade" chipsets [specially on stable products like 802.11b cards... Realtek anyone?] every two months to be "new" we'd have systems that work fine in Linux.
I think Linux based distroes are [in particular Gentoo] just as capable as a desktop platform. It's the hardware that is lacking.
The problem is finding staff to write drivers. I mean the windows drivers for most hardware is crap. Do you really expect them to then be able to write a linux or BSD driver too?
As for things like sound/graphics there is no reason why new cards don't support AC'97 and that graphics support VESA 3.0 with hardware accel other than they're cheap and want to pander to MSFT.
So stop saying "Linux ain't ready" when it's the manufacturers that aren't!
Tom [speaking as someone who uses Linux on his Compaq Laptop and piece-meal Desktop]
Your first three are part of OOP [hint: Java has them too]
"new/delete" aren't programming methodologies they're overloaded functions for heap management.
inline comments is part of C99
pass-by-reference is not a programming methodlogy either... it's just a function of C++.
Tom
Well the major difference between C and C++ being that C++ supports "native" classes while in C you emulate them with arrays of stuctures.
A class is a way of organizing "objects" in a hiarchical manner. You could almost say an OOP manner. The fact you can do more with C++ doesn't take away the fact that oop is the major difference. In fact I can't think of any other reason to use C++ over C aside from classes and the various forms of inheritance.
The point is C didn't borrow what C++ had to offer not because the ISO C committee is lazy or incompetent but that C solves DIFFERENT problems.
Yeah, who wants a common driver API for video, network, or sound cards...
Um, there is no reason why you can't do this in C relatively easily. All you have todo is make a common API and stick to it.
In my crypto library I have a dozen ciphers, hashes and prngs. Every cipher has the exact same function prototypes and can be called via a table driven system.
"C++" effectively would do the EXACT SAME THING except with less control over the actual implementation.
Tom
Say who? C++ is not a better C anymore than my an iPod is not a better alarm clock radio.
...language wars aside...
C++ and C solve different problems.
IMO C is good for low level and structured [re: modular] programming. Despite what many think this isn't limiting to say kernel development. Sadly many "developers" think a 1000-line main() function is "impressive".
C++ is meant to take C and throw it in an OOP direction. Although any program you can write in C you can write in C++ [and vice versa] this doesn't mean C++ is an "improved C".
It's stupid comments like yours that really drive down the merits of actual computer science. Since you don't understand the issue you take up an irrational and off-base point of view. The problem is that the world is full of lazy stupid people just like you. They fill up the halls and next thing you know someone is leveraging your dynamic synergy between solution providers and contact base deployments!
C++ has it's uses. C has it's uses. C++ is not "C v2.0".
Tom
Don't pay under any circumstances and do your best to track down the people responsible. Paying or otherwise giving them the ego-stroking they want is just counterproductive.
This is also a good reason why companies should have gotten into the habit of using PGP/GPG to sign their emails as policy... But I guess they get what they pay for now...
Tom
I think TCC is a cool project and definitely a useful tool but what does it mean to say it's fast?
;-)
The code it makes is very likely not as optimal as GCC can make. Specially something like a Kernel I wouldn't mind some optimizations [even in the form of -O2] And really GCC with -O0 is very fast...
That's like saying memcpy() is the better cipher because it's faster than AES!
Oh and TCC doesn't work on my AMD64
Tom
mp3 falls into that category. On a CBR file you can roughly just fseek to bitrate*seconds into the file and be approximately where you want to be.
Valid mp3 decoders must allow "garbage" data before a header. So
cat somerandomtxtfile.txt mysong.mp3 > new.mp3
new.mp3 is now a valid mp3 file/stream.
Chances are the testers aren't actually users which is why they didn't find a really slow FFW "a problem".
Though really cumbersome MP3 players are pretty much the norm. Mine [from Samsung of all companies...] doesn't sort the files so even though my tracks are numbered they never play in any particular order [and no this is with shuffle turned off]. It also "plays" as you seek which is annoying [so it's even slower than 6min/60min as this player has].
Tom
There is no solution to that problem other than to ensure that each ISP is responsible. No matter what you do at your gateway short of just disconnecting a network you can't stop packets from comming in.
What would help SYN spoofing is responsible ISPs that check the source address and discard invalid IP packets. My proposal is for people who connect flood a server.
It's easy to send 40KB/sec when your packets are 1KB in size. Not so easy when they're 40 byte SYN packets [or whatever the size is].
I agree that my idea won't stop a SYN flood. The idea is to stop stupid kiddies who "wget flood" your box.
What I don't get is why ISPs allow forged SYNs out in the first place. If they only checked the source IP before routing it outwards this wouldn't be an issue because then other ISPs could just monitor SYN traffic and ban the ip on the fly.
Tom
How do you send 25k/sec? That's 640 SYN packets/sec or roughly a latency of 1.56ms. Considering the RTTs I get with various sites that doesn't seem plausible from a cable modem.
:-)
Besides you can also augment the module to forward the IPs to ban securely to your ISP. My god you people have no creativity.
The point is it's trivial to automatically cut people off on the server side [e.g. to avoid serving pages or even establishing the TCP connection]. If you make it securely tell your ISP what to ban you can even cut them off at that gate too.
Tom
um ... a socket is only allocated to a connect() call. If you ban the IP on the firewall side the SYN is simply ignored.
So yes, the 40 byte SYN packet consumes bandwidth coming in. But you don't expend bandwidth or cpu time otherwise [e.g. no ACK/SYN going the otherway]
Although that raises an interesting question. Who should pay for the bandwidth coming in? Just like who should pay for SMS? I didn't choose to have a SMS plan [well ok by signing up I did, but they don't have non-SMS plans]. So if some ass decides to SMS-bomb my cell why should I pay for it when my cell company didn't protect me?
So if you firewall some jackass with a fat-pipe who decides to connect flood you and you do your part by not opening the connections who should pay for it?
I think this is a good way to transfer some responsibilities back to the ISPs [in particular the originating ISP, something fishy about the same or similar HTTP request occuring 1000s of times a minute from a DSL...] and ultimately the user. Just like how spam should [ideally] be handled....
Oh yeah...
Tom
Um you can easily do an hour ban on excessive hits from a given IP. Write a module for Apache that counts the hits from a given IP. If it hits a certain threshold [say > 100 hits a minute or >x KB per second] then it simply adds the ip to a firewall [ipchains, netfilter, etc].
;-)
By making the banning automated you can easily cope with a DDoS.
Some other things to help cope
- Make small pages, well compressed images
- Don't make highly detailed pages you can get to without loging in first [e.g. avoid server cpu load]
- Load balance
Tom
About your sig.. I've seen it a few times and it pisses me off.
IIRC "do or do not, there is no try" is a Yoda quote from Episode five. Not from Spock.
Tom
It wouldn't be safe to assume a pointer can be stored in 32-bits in 64-bit mode. The OS can map your data anywhere in the 64-bit space [which maps physically to a 40-bit bus, at least on my AMD64]. It's also not portable to do that. Even if your OS maps stuff within 4GB [e.g. top 32-bits are zero] another 64-bit box [sparc, ppc, etc..] may not [and likely would not] do that.
If you build in 32-bit mode [e.g. -m32] you lose the major benefits of the 64 which is namely the extra registers.
Tom
Use a different data structure?
IIRC also a b-tree like structure could help this. Where you have to have pointers to nodes the actual elements ["leaves"] in the nodes would not need individual pointers.
Also this isn't much of an issue. If you're likely to have a huge database you're already likely to require 64-bit offsets [into memory/file/etc] as 4GB is often not enough.
So not only can you mitigate the "downside" to larger pointers by using more efficient data structures but the issue is largely moot anyways.
And FYI my Gentoo AMD64 box running Xorg6.8.x, GNOME, gaim, xmms, a few xterms, gedit and nedit only is using 200MB of ram [prolly cache too]. Which is comparable to when I was running the same software on my P4.
The bulk of memory used is for code [which could be shorter as the instruction set is more powerful] and it's data [which largely doesn't change with register size].
Tom
... psst dude it's 2004. Get with the times.
It's one thing to troll, but when you do a bad job of trolling... well that just makes you some kinda idiot. I bet you rode the "special" bus to school right?
Tom
...Posting like anyone cares...
;-)
In the middle [8 of 14] of a "-DU world" and my 2.2Ghz AMD64 is sitting at around 42C with a simple heatsink/fan.
Tom
Can't agree more. I run Gentoo on my AMD64 and from time to time there will be a package that builds only in 32-bit mode [usually cuz the developers aren't that proficient at writing portable code]. Nice to add the "-m32" switch to GCC.
Sadly though, running 32-bit code [about equivalent to a spruced up Barton core] means less people will push MSFT to make a 64-bit winders quicker.
I know a few people already that swear by their AMD64 and then run WinXP [32-bit edition] on it. For those not in the know, in 32-bit mode [e.g. not long-mode] you can't access the extra registers or 64-bit wide registers.
Essentially in 32-bit mode [say Windows] an AMD64 is a Barton with the following benefits: wider decode-bus [128-bits instead of 64-bits], SSE2 and more instructions are DirectPath instead of VectorPath [means they decode/execute quicker].
In 64-bit mode you get all that plus the extra registers [8 more ALU and SSE] as well as the 64-bit ALU registers. Which helps the most in more diverse applications [than say the mere presence of SSE2]
Tom
The K8s are much better than the K7s at power management. Granted the P4 still wins with the "never shutdown feat" the 99.999% of the time where your heatsink/fan is working fine the K8 will be taking less power, making less heat and computing more IPC.
In my experience it's the heatsink that matters the most. My fan runs at 2500RPM [constantly. It's a thermaltake K8 silentboost] and doesn't really move that much air. I'm sure it helps by a half-dozen degrees C or so but it's not as important as the HUGE BLOCK OF COPPER stuck to it.
So do you buy a P4 for that once in a million time where your heatsink falls off or a K8 which will run more efficiently?
Tom
Sorry to sound all "sick" and all...
When you take a dump and the log hits the bowl... um it's not entirely cleaned out when you flush. So no. even with pristine clear perfectly clean water coming into the bowl it wouldn't be safe to drink.
What the fuck is wrong with people? Holy crap literally!
Tom
I can attest to the power. My Athlon64 [3200+ NewCastle] runs cooler and faster than my P4 [2.8Ghz Northwood]. At 1Ghz [I clock down when idle] it goes as low as a few degrees over ambient [it's 23C now, the mobo is 21C the room with window open is probably around 17C or so].
... With a 36$ Thermaltake SilentBoost K8!!!
At 2.2Ghz [full speed] the cpu idles at ~35C or about +10C over ambient and under full load hits around ~46C [about +21C over ambient].
Compared that to my P4 which had a Polo735 Thermaltake it idled at 33C and hit 55C at full load.
When you take into account that the K8 smokes the P4 [specially for building software which is what I do]... yeah.
As for gaming, well I have a GeForce 5200 so I can't really say. I get a good framerate in ut2k4 but I can't say it's "much faster". Maybe a few fps faster when there are many bots [and I run the amd64 build...] but that's about it.
My point though is that the K8 beats the P4 in both power and performance. Right now Intel is holding onto irrelevent metrics/benchmarks to win over the crowd.
I own both cpus and I know for a fact that where it matters most [and sorry, gaming isn't it] the K8 is sweeeeet!
Tom
Seems like they're falling-through on many of their more recent promisses? That couldn't possibly be to steal thunder from other people...... no way!
Hey intel, do what many of us said years ago, ditch the P4 crap, admit that it was a mistake and go the normal high IPC route already. K8's are already smoking you at "non-gaming" [re: serious work] tasks and at least as good if not better at the little fps's anyways.
So take your Pentium-M and advance it already!
Tom