Without warrant you enlarged the scope of the conversation simply so that you may argue yet another point. I only enlarged the scope for purposes of analogy.
Can you blame me for enlarging an argument against such a broad statement? "Benchmarks do not elucidate any fact". They often show repeatable trends outside of finite machines and inside finite machines (when not interupted with poor procedure) they tend to show very repeatable trends. If there are no trends shown, then maybe there are no trends to show, but those results should normally be repeatable within a finite machine.
If you would read carefully a statement such as "Benchmarks do not elucidate any fact" you would have seen that it was stated to mean simply that the graphing of numbers alone (such as a Q3 f/s or lame encode value in seconds) does not have any measure of significant value.
I take a statement as it stands. Not what was "meant" by it. A values significance is in the eye of the beholder.
Q3 and LAME time trials, do not encompass benchmarking of a whole system. They do however show very specific values which are significant in those very specific areas. I don't use the word "specific" loosely here. I don't mean that a high score in a Q3 test means that the computer is good for 3D games, I mean a high score in a Q3 test means that that computer is gave that specific result while running that test! Intelligent intepretation of those results might bring areas of weakness forward to allow for improvement.
Finding a computer system to have overall significant value based on those benchmarks alone is a stupid conclusion to come to. Which comes down to what I have been saying all along: benchmarks of a particular area need to be carried out properly and their results interpretted properly.
If you set out to find the value of a computer and in doing so benchmark it through Q3 and LAME time trials, then you have failed to properly benchmark that computer. You have not found the value of that computer, but have found it's value in Q3 and LAME processing. The benchmark of choice did not fail to highlight its very specific area of measurement.
However, if the specific area you want your computer to be the best at, is LAME encoding, then running LAME on various files with various options and comparing other computers with the same procedure might be a good benchmark for that very specific computing requirement.
The perception I have of my Sun Ultra 10 (which I am lovingly writing this to you on), is that it absolutely sucks as a desktop machine for the things that I expect from a desktop machine. The integer performance (this is a broad statement, but still a specific statement) is terrible (on average) if I compare it with my other machines. My old iBook kills it. The memory performance is terrible also. I know I can increase the memory performance by adding more memory to use two banks and use interleaving. I have discovered the lacking memory perfomance through a benchmark, so I have found out a weak area that can be improved. I have yet to test the FPU, which people claim is much better.
So maybe I would assign this to file serving tasks?
I would find it not so good here either, so should I just assume that it is the poor CPU performance and sell it on eBay to get a good price while it still has exotic value?
Or should I run some benchmarks on it and find out that the disk performance is terrible because the IDE controller sucks arse?
It only has 128MB RAM at the moment, the IDE performance is giving me about a third of what I know the disk is capable of and because I am running Solaris 9 with all the bells and whistles in this small amount of RAM, it is paging a lot through the slow IDE controller! Benchmarks allow me to pinpoint the weakest areas.
Upgrading the RAM (avoiding slow disk paging) and avoiding the IDE controller by throwing in a SCSI card on the PCI bus with the least contention does wonders. Tha
OpenBSD being in this competition is silly. I say this as a user and lover of OpenBSD since 2.5.
OpenBSD focuses on extreme security, which goes beyond just auditing code. It has mechanisms in place, which are specifically there to heighten security first and foremost. Quite happily foregoing speed and scalability (in places where it is unavoidable).
Examples are, consistency checking all over the place and randomisations, which provide greater security but inevitably, hurt performance.
This would be like comparing high performance cars and throwing in an M1 Abrams main battle tank to also be tested as a high performance car. In the end, the tank will obviously have terrible top speed, acceleration and cornering ability and everyone will pronounce it crap. But try defending a nation with Ferrari 360 Modena's.
This course is not for this horse. What's more, OpenBSD has been very tentative about moving forward on SMP for very good reasons. It opens up a huge can of worms (bugs), which makes understanding code and thus auditing extremely difficult. The machine being used for the test is SMP!
FreeBSD SMP is supposed to be fantastic in the new technology releases and so-so in the stable releases.
This test would be better conducted in about a year and without OpenBSD (even if it did have SMP by then). OpenBSD is never going to be the highest performance server because that is not what the OpenBSD project strives for and they are willing to hurt that area in the name of security.
If this machine were not SMP, my money would be on NetBSD with FreeBSD coming a close second.
In short, I'm not terribly impressed with the power of that UltraSPARC processor; especially considering it's so closely matched with my two lower-end boxes.
I have a Sun Ultra 10, 333MHz UltraSPARC IIi with 2MB cache and 128MB RAM in one bank (I realise I can get better memory bandwidth while using two banks).
I can confirm, the machine runs like a two legged dog.
If it were not for the fact that I want to improve my Solaris skills (the whole reason I bought the machine), it would be running OpenBSD as my firewall.
In everything I have thrown at it, my 300MHz G3 iBook and 300MHz PII kill it so badly that using percentages to compare them is a waste of time. I prefer to say 2-3x slower.
Compiling all of OpenBSD 3.4 -stable macppc and generating release packages (system, X11 and ports), my little iBook, with slow little 6GB notebook drive took 5 hours to complete. On the other hand, doing the same for OpenBSD sparc64 took 7 hours on this Ultra 10 with a much faster 7,200 RPM desktop drive. I would not be surprised if the iBook could have done it 2-3x faster given the same drive.
I am however interested in Linear Feedback Shift Register Pseudo Random Number Generator designs. I used to build them in hardware but that gets pretty limiting when you're just a hobbiest. I am thinking of writing a simulator that finds maximal stream length designs so I think this 64bit CPU (being the only 64bit one I have) will be a good candidate.
Then again, maybe I should just get an Opteron, declare Sun "soon-to-be-dead" and enlist this Ultra into the OpenBSD/PF armed forces.
PS, I realise that SCO's imminent death with slow the demise of Sun and I do like Sun gear and would rather not see them go belly up. I have not been watching them financially lately. Are they looking any better?
Go argue with NASA and the US Navy (whome I used to work with, in an electronic weapons engineering capacity).
Find a good benchmark.
I could be here all damn day. I could give low level examples down to the testing of gate propagation delays, to high level examples of final apps running on final hardware and everything in-between.
My quick answer would be: Any test which gives repetative meaningful results when run under a scientifically sound procedure.
You are simply covering through weak counter argument some of the points that I was trying to uncover.
Ha! When you use points to talk about benchmarking, you talk about large scale (real world) benchmarks of LAME and Q3 and propose their results to be indicative across the board! And you talk about weak arguments!
I tell you what then, prove this statement: "in benchmarking scientific rigor is always lost". What a bold, foaming at the mouth, nutcase statement. Paint the whole world with the brush you paint yourself with?
You CANNOT prove a generalization with a few weak examples. You usually can't prove most generalization.
You can't find good practices of benchmarking because there are problems in the foundations of the ideological and engineering in the tech industry. Why? Because technology is simply business.
Technology business comprises many facets. Engineers create with scientific approaches and marketing droids dull down the science to help sales. Witness Intel's MMX. The engineers called it Matrix Math eXtensions, the market droids called it MultiMedia eXtensions (how well would something with the word "math" in it sell!). Regardless of what it's called and how well it sells, it does make great improvments through a SIMD approach designed by engineers. The engineers may have been told to improve the multimedia experience and so they took a scientific approach to do it, because they know, through observation (simulation, benchmarking, etc), that multimedia often uses repetitive instructions on varying data.
Benchmarking does not have to be an entire application running on given hardware. It could be time to execute single instructions, for example.
There are barely any good consumer products produced by engineers.
Engineers take care of the technical details. Without them, we would only have pie-in-the-sky visionaries who would never deliver anything.
There are no good cars, no easily adaptive alarm clocks, etc.
Subjective crap. You have experienced every car and alarm clock that has ever existed and then based on your opinion of them, proclaimed that there are no good ones because you don't think they're good.
Looks like you've found a niche in the market for "good" cars! Quick, go make your millions designing, prototyping, refining and then mass producing, but without using any scientific rigor or benchmarking!
It's because the information concerning the production of products is private, and because there is no meaningful observation of the use of products. Visual Studio.NET 2003 would not look like it does if Microsoft ever spent time meaningfully watching people use the program.
Good stuff. Find one example, then use it to throw blanket statements.
There is only the deep-rooted creation of unauthentic demand for badly designed products.
So there is no demand for well designed products?! I really doubt that you mean this. I don't know you, but based on the way you write I see you are intelligent. That sentence though, is either ill thought out, or the author is deluded severely.
IDE HDD's sell like hotcakes because end consumers don't know of and rarely need SCSI. Yet there is a demand for SCSI by intelligent people (and some less intelligent)!
An IDE drive might have specs of: minimum sustained transfer rate 30MB/s, random see
Benchmarks are meant to ideally test minimal pairs
And they often show disparity in their results due to being interupted. This would be a baddly carried out benchmark under less than ideal conditions. This is human error. Of course there are slight variations in subsequent runs, but these should be able to be explained and compensated for. It is most certainly not a benchmark lie though. If it took that long, then it took that long, now find out why!
But in benchmarking scientific rigor is always lost
Failing to retain a scientific approach is a human failing. It does not always happen and is not the benchmark telling lies, but due to poor procedure.
But the benchmark choice is frequently meaningless or misleading.
[poor] "Choice", "Meaningless" and "misleading" [results] each require an incompetent person. Don't blame the benchmark. Even if they wrote the benchmark, they might not understand the results.
Benchmarks do not elucidate any fact.
Yes they do. Very very specific facts which can later be used to make considerations for future decisions. It could be a specific application, algorithm, overall CPU ALU, FPU or single CPU instruction, it could be bus type, etc. Specific facts leading to educated decisions.
You will always see in CPU tests LAME encoding. The p4 will always win against an Athlon.
If this is the case, then LAME as it stands is specifically faster on a P4 than an Athlon. That would be a coarse benchmark though. Some would call it "real world". And it is. It is specific to LAME, but not specific at a lower level where it could be found why this might be the case and how to improve LAME on both P4's and Athlons seperately (with an end result that might have the Athlon out-perform the P4, due to new insight gained from benchmarking specific areas).
The reviewer will not explain why this is the case and that LAME encoding is simply clock cycle dependent.
So the reviewers fault becomes the benchmarks fault?
Benchmarkers need to be able to explain all the dependent variables, to tell why the results happen.
Thus my original statements?
In graphics cards Q3 benchmarks above a certain magnitude are meaningless.
Bad choice of benchmark is the fault of the benchmark?
Benchmarks need to be interpetted by someone competent enough to do so. Just because someone carried out a poor benchmark procedure or could not understand the results, does not mean the benchmark lied.
The reviewer with meaningless variables creates an inauthentic conditioned desire in the consumer that leads to bad and lax software and hardware engineering.
Morrowind and other games have horrible problems with their graphics engine that can not be saved by faster GPUs and dx9.
So they are CPU bound? Memory? Sounds like maybe they don't know how to profile their code too well. When profiling, it helps to know how to benchmark and make meaning out of the results.
You cannot improve that which you do not understand, through anything other than luck. Benchmarks provide specific facts which, when correctly interpreted, can bring about improvements. People who can't interpret them, say they are meaningless.
Which brings up a point: both NetBSD/Sparc and NetBSD/Sparc64 will run on an Ultra 1, which is a 64 bit machine. Why doesn't somebody install each NetBSD port on two seperate Ultra 1 machines. Then the benchmark comparision can be between the normal apps that build on both systems, running in parallel on two identical systems. Its exactly the same codebase except for the 32 or 64 bittedness.
Hey there's a good idea. Is NetBSD absolutely exactly the same between the sparc and sparc64 flavours, minus the compile options of 32 vs 64bit?
I use OpenBSD. I would be willing to install OpenBSD/SPARC64 onto my Ultra 10 run some benchmarks, then install OpenBSD/SPARC and run the same benchmarks, then compare.
Anyone know if OpenBSD SPARC64 and SPARC are close enough in code difference to make this worthwhile?
I recently put OpenBSD 3.4 -stable/SPARC64 onto my 333MHz Ultra 10 and compared it with OpenBSD 3.4 -stable on my old 300MHz G3 iBook. The iBook was about 3 times faster than the Sun in ubench, and benchmarks of md5, sha1 and ssl.
Making the OpenBSD -stable release on the G3 (192Mb RAM and slow 6Gb noteboot HDD) took about 6 hours whereas on the Ultra 10 (128MB in one bank) it took about 8-9 hours.
Disk transfer rate is kinda crappy too. I have two 20Gb Seagate IDE drives, one in the Ultra and one in my Thunderbird 700. The Thunderbird gives me a transfer rate of 28Mb/s whereas the Ultra gives 12Mb/s (they are exactly the same model of drive). I realise there might be a lot involved in limiting the IDE performance on this particular Ultra 10, but I would have thought that both systems could saturate the bandwidth available from these old'ish drives. I've heard that the Ultra 5/10's IDE controller sucks, perhaps there is truth to that. Someone claimed that replacing with SCSI is like having a whole different (faster) machine.
You have now intrigued me into trying OpenBSD/SPARC. I am, however, loathe to remove Solaris 9, now that I finally got it installed again. It takes *ages* to install, even from DVD-ROM. It seems that after every thing it installs, it pauses for a set 90 or sometimes 30 seconds. Meaning I have two options, sit there and click to continue, or go away and wait ever longer.
There are 3 types lies. Lies. Damned Lies....and benchmarks.
Benchmarks don't tell lies. They usually tell truths about very specific areas which typically reflect "real world" applications to very varying degrees depending on how and how much those specific areas are used within the "real world" app. The specifics need to be analysed by someone who knows what they're looking for.
If you are in the market for a computer that will have a very specific role, then you might be interested in looking at benchmarks in great detail to find the best system for that specific role.
Benchmarks don't lie, people who interpret what they show, simply misjudge the numbers. Sometimes however, people who do understand what to look for, intentionally misrepresent benchmark numbers to increase marketability of their product. They are the liars, not the benchmark.
PS, I realise this is humour, but I often hear people state that benchmarks are useless. That is not true. They are very useful if their output is analysed properly. These are the same sorts of people who claim the Y2K bug to be all hype.
I agree completely. But... of the 50% which are not toggled, the original bit remains unchanged...I may well have made a mistake.
Sorry for taking so long to actually do this. My life has been upside down the past 2 weeks.
I can report, that I would appear to be most certainly, absolutely wrong on this matter. I honestly beleived that the bits which would not be toggled would colour the output enough to provide strong enough patterns for humans to discriminate from the noise.
How very wrong I was! I wrote a quick and dirty little C, to XOR a raw audio and image file while keeping the headers intact. I verified this with a hex editor to make sure I was not rendering the files to noise via header corruption.
The audio file went to complete noise, as did the image which I made especially with high contrast (black and white) shapes.
However, I think I found the cause of my original bogus results. An off-by-one error in my usage of rand(). If I set RAND_MAX to 256, I would get an image with the patterns intact under the noise. I mistakenly thought that this would yield 0-255 random values, but it does not, it yields 0-256. Setting RAND_MAX to 255 provides completely noisy files. : )
Appologies to those I doubted and to those I sent on a wild goose chase.
I am still intrigued if there is some "colouring" going on with the bits that don't get toggled. So I may verify this manually. But looking at the image, it looks like complete noise to me.
The article is clueless technically. The panorama cam takes hundreds of 1 megapixel images and stitches them together to produce the panoramas that have been published on the web.
Exactly. That "article" is completely wrong on most counts and is obviously written by some tech illiterate who has misinterpretted what he has been told by NASA.
Using a 1MP CCD to capture 9 images for a 3x3 stitched matrix (for example), could have been acheived with one 9MP CCD.
"NASA's Spirit Rover is providing a lesson to aspiring digital photographers: Spend your money on the lens, not the pixels."
Who on Earth : ) wants to painstakingly take multiple photos and then stitch them together every bloody time?! Just buy a high MP camera and be glad that you'll never feel the need to do that.
Imagine the photos from Mars if the CCD was 5MP and good stitching was being done. I know (and knew before reading the silly article) that bigger CCD pixels would result in greater sensitivity. But I wonder if this is the true reason NASA wanted larger pixels. Do they really need hyper sensitive CCD's on Mars? I would have thought that they were more interested in the reduced noise that comes with larger sensors.
If you XOR a message with truly random bits, the result will consist of truly random bits. This is because for each bit of message there is a 50-50 chance that you will flip that bit, and these chances are all independent. So the output bit has a 50-50 chance of being 0 or 1, independent of other output bits.
I agree completely. But... of the 50% which are not toggled, the original bit remains unchanged. This is more than enough to render a text message to gibberish, but with audio seems to leave enough information behind for the Worlds most powerful signal processor (human hearing) to have something to play with.
Contrast this with what would happen if you AND or OR the message with a (pseudo-)random bit stream.
I may well have made a mistake. But I was most definately using XOR. XOR is my favorite operand. It intrigued me since my delve into 6502 assembler, 17 years ago. The cool things that can be done with XOR (not obvious to most), make it very useful.
Maybe he XOR'd the entire 8 bits of each byte with the same bit, effectively XORing each byte with either FF or 00. In that case, a lot of the original audio is still there.
Have you ever used XOR? If I XOR'ed with 0, then I would get no change in the file at all. I'm pretty sure that if I XOR'ed with 255, I'd simply get an inverted waveform, and thus the audio would remain completely intact, as far as human hearing is concerned. This of course assumes non-signed raw 8 bit audio files.
In these cases, all of the original audio is still there.
I reckon the human brain, looking as it does for patterns in the world outside, would be able to find what remained of the original pattern in the data.
That was my theory after I found this strange result.
I'm not the parent, but it seems to me that an XORed file would sound like a noisy copy of the original.
I may even try it myself and see.
That would be great, to have someone else either refute or back up what I found (I'd be happy for clarification). I haven't coded in years, but I might knock up a little C, record a short raw audio file and post the results on my web page for others to compare.
I wouldn't mind trying it on a raw image (with high contrast patterns) too see if the human brain can find those patters behind the noise.
Actually, an experiment showed that when cutting all but the LSB of a music wave file, the tune remains still recognizable!
Many years ago (10+), just out of interest in crypto, I XOR'ed a raw audio file (my own speech) with pseudo random data (all bits, from LSB to MSB). The result, was one very noisy audio file with the speech still audible! I thought "WTF!?"
I figured that since, on average, 50% of bits would be toggled, some of the audio information would still be present in a form a human could recognise. I have been meaning to do this again and pass it through a low pass filter to see if I could make the audio come more to the foreground.
perfectly (pseudo) random data
This is a contradiction in terms. Pseudo random data cannot be perfect, that is why it is pseudo (fake). Although, based on reading your interesting message, I'm sure you know this.
It has no practical solution.
How about stego software that detects how many LSB's span the noise floor, replace those with real white noise and then replace lower LSB's with the stego? I wonder if one could go about the noise floor LSB replacement so that it was a gradual replacement near the bits which border between noise and information? So as to prevent detection of the sudden (obvious) change which would be a "stego fingerprint" in itself!
Did you measure the main memory speed? I would have thought the laptop would be about 10% slower than the desktop, considering the resolution/colour depth and the usage of DDR main memory.
I think i'm (hopefully) sitting pretty thanks to DDR.
Definitely. The quicker main memory becomes, the easier they can get away with profit maximizing techniques like this. Dedicated frame buffer memory of equal speed to main memory (all other things being equal), will always be faster. But if it's only 2%, then the cost might not be worth it.
Funny I was just reading an article over on Tom's Hardware guide about that
I wouldn't put too much emphasis on what you read at THG. Once upon a time, an article at Tom's hardware tried to claim that AGP provided no gains over PCI, by comparing current (at the time) PCI and AGP 3D cards. A stupid stupid way to prove the point.
The AGP cards were new and working in glorified PCI mode. Not using advanced AGP features. What's more, the software being used to benchmark "PCI vs AGP" exploited fill rate limits and NOT PCI/AGP bus limits.
Bert McComas I beleive was the "experts" name.
The irony was, that later, using a specially crafted Quake 2 level (by S3), which used huge textures, a slow AGP Matrox G200 could be seen running the benchmark faster than a "super fast" PCI setup of dual Voodoo2's!
This benchmark took the emphasis off fill rate limits and onto the PCI/AGP bus. Suddenly a G200 was faster than dual Voodoo2's?! And it all came down to PCI vs AGP.
THG was trying to prove that AGP sucks by saying, "look this PCI card is faster than this AGP card, therefore AGP sucks". They refused to back down too, when techs working in the design of this industry informed them, point by point, why they were wrong. Hell, there is data on THG that proves THG wrong.
THG has little credibility as far as I am concerned.
Now, to your question. Does this consume a ton of bandwidth and affect performance?
I don't think he is concerned with 3D rendering performance. He is concerned with the impact on main memory bandwidth, since a part of main memory is being used as a frame buffer.
For a constant image to appear on screen, the frame buffer must read for each frame displayed. 70 times per second for 70Hz. This can add up to hundreds of megabytes per second, depriving this bandwidth from the CPU.
These shared main memory/frame buffer memory systems are not going to be real 3D speed demons.
That being said, for normal 2D work, bandwidth utilization is negligible and shouldn't seriously impact performance... I wouldn't expect results to vary significantly, since memory requirements for 2D work are relatively low.
Using a portion of main memory as a frame buffer, even to display a static 2D image, is going to mean that that portion of memory is read completely for each frame displayed. That might be a lot of bandwidth out of that available.
If someone can afford a system with DDR main memory (where the lost bandwidth will be less noticable), then they probably can also afford a cheapo video card with a real, dedicated frame buffer.
Those typical "Joe Users" are the same ones that the open source market needs to get using their systems in order to succeed 'cause those "real users" have "real money."
Microsoft has plenty of money. So what is their excuse?
Secondly, I do blame most of the problems on the user's inexperience.
If you install XP, then connect to the internet, you will have Blaster within minutes. Unless you take preventative steps which Joe average knows nothing about. Joe average is the intended customer. Before he has a chance to read about going to windows.update, or even if he is in the process of going there... he has Blaster and is wondering why the hell his PC keeps telling him that it will shut down in 60 seconds.
Now, how is this his fault?
Linux would have the same problems if Joe User's began using it.
Typical Joe average, playing with Linux, will give up and go back to Windows. If he persists, he learns and progresses beyond Joe average status.
The reason Apple OS does so well is because it has...oh...3% of the market share. Compared to Windows XP -- that's nothing. (READ: Not enough people use it so nobody is going to write a virus/trojan/spyware/other stupid shit for that operating system. It wouldn't affect enough users.)
Not true. People DO write those for Mac OS. This point is probably impossible to prove, until Apple has more systems on the internet.
Secondly (and in line with the last paragraph) of course Windows ports are scanned all the time. It's because, again, everybody uses Windows.
The sudden explosions of MS port scanning I see in my logs are not due to sudden explosions in hacking activity, they are due to Windows systems becoming infected with new worms. The deluge I see are not hackers, they are victims desktops.
There are a lot of posters in here who claim to have had so many problems with XP. Obviously then it is a lack of knowledge and experience on your part. Just because you can't get it going well doesn't mean it is a problem with the OS. Lots of Joe Home Users are very happy with it. I am a very happy XP user, and have absolutely none of the problems that are bleated on about here. Turn into real users.
Windows XP is marketed to the average Joe, who will not fit your definition of "real users". When these average Joes connect to the internet with XP's out of the box settings, they get worms, viruses, spyware, etc.
XP can be hardened, but not with the knowledge of the users which it is marketed for.
I agree with one of the other posters, when he says the Joe average users who are happy with XP are actually oblivious to the reality that their PC is actually on a rampage infecting other peoples computers, sending SPAM and their credit card information. So many times I have visited client sites, only to find they have spyware, etc. And don't blame me for these problems, my introduction to these people is usually due to them having security problems in the first place.
I come home to my mostly OpenBSD network (plus some hardened Wintel) and relax. But then, I'm not your Joe average XP user.
I do hope XP SP2 helps and XP/Win2k are certainly leaps and bounds ahead of the Win9x abominations. But please don't try to claim that XP is great and the ignorant users are to blame. Microsoft claims to provide a stable, secure product for the World at large? Then this is a lie.
Apple's Mac OSX is much closer to delivering that claim.
BTW, relying on automatic updates is a dangerous game. Does XP use crypto and authentication by default for automatic updates? I would hope so. Sometimes patches are retracted, because they cause more grief than they solve. I call that a lottery. I prefer to firewall then wait before deploying patches, where ever possible.
PS, I'll leave you with this... do you run a firewall? Do you ever watch the logs? I'm running an OpenBSD pf firewall for my home network and I tell you, watching the attempts at typical Microsoft ports coming thick and fast is scary. If you don't, I suggest you do and then come back here and tell us that "most [XP users] have no trouble with Blaster or random spywares, or indeed security hacks".
I'm a windows user (but not zealot.. if *nix did what I wanted easily on a day to day basis, I'd prefer it)...
Tried MacOS X?
For some people, *nix is easier than Windows (even someone running some *nix less polished than OSX).
I switch between OpenBSD, Debian, Win2k and XP due to differences between play and work. I often find myself fighting Windows and Windows configurations tend to rot. With OpenBSD and Debian, once they're set up, they just keep going...
Slashdot Mirror
Without warrant you enlarged the scope of the conversation simply so that you may argue yet another point. I only enlarged the scope for purposes of analogy.
Can you blame me for enlarging an argument against such a broad statement? "Benchmarks do not elucidate any fact". They often show repeatable trends outside of finite machines and inside finite machines (when not interupted with poor procedure) they tend to show very repeatable trends. If there are no trends shown, then maybe there are no trends to show, but those results should normally be repeatable within a finite machine.
If you would read carefully a statement such as "Benchmarks do not elucidate any fact" you would have seen that it was stated to mean simply that the graphing of numbers alone (such as a Q3 f/s or lame encode value in seconds) does not have any measure of significant value.
I take a statement as it stands. Not what was "meant" by it. A values significance is in the eye of the beholder.
Q3 and LAME time trials, do not encompass benchmarking of a whole system. They do however show very specific values which are significant in those very specific areas. I don't use the word "specific" loosely here. I don't mean that a high score in a Q3 test means that the computer is good for 3D games, I mean a high score in a Q3 test means that that computer is gave that specific result while running that test! Intelligent intepretation of those results might bring areas of weakness forward to allow for improvement.
Finding a computer system to have overall significant value based on those benchmarks alone is a stupid conclusion to come to. Which comes down to what I have been saying all along: benchmarks of a particular area need to be carried out properly and their results interpretted properly.
If you set out to find the value of a computer and in doing so benchmark it through Q3 and LAME time trials, then you have failed to properly benchmark that computer. You have not found the value of that computer, but have found it's value in Q3 and LAME processing. The benchmark of choice did not fail to highlight its very specific area of measurement.
However, if the specific area you want your computer to be the best at, is LAME encoding, then running LAME on various files with various options and comparing other computers with the same procedure might be a good benchmark for that very specific computing requirement.
The perception I have of my Sun Ultra 10 (which I am lovingly writing this to you on), is that it absolutely sucks as a desktop machine for the things that I expect from a desktop machine. The integer performance (this is a broad statement, but still a specific statement) is terrible (on average) if I compare it with my other machines. My old iBook kills it. The memory performance is terrible also. I know I can increase the memory performance by adding more memory to use two banks and use interleaving. I have discovered the lacking memory perfomance through a benchmark, so I have found out a weak area that can be improved. I have yet to test the FPU, which people claim is much better.
So maybe I would assign this to file serving tasks?
I would find it not so good here either, so should I just assume that it is the poor CPU performance and sell it on eBay to get a good price while it still has exotic value?
Or should I run some benchmarks on it and find out that the disk performance is terrible because the IDE controller sucks arse?
It only has 128MB RAM at the moment, the IDE performance is giving me about a third of what I know the disk is capable of and because I am running Solaris 9 with all the bells and whistles in this small amount of RAM, it is paging a lot through the slow IDE controller! Benchmarks allow me to pinpoint the weakest areas.
Upgrading the RAM (avoiding slow disk paging) and avoiding the IDE controller by throwing in a SCSI card on the PCI bus with the least contention does wonders. Tha
OpenBSD being in this competition is silly. I say this as a user and lover of OpenBSD since 2.5.
OpenBSD focuses on extreme security, which goes beyond just auditing code. It has mechanisms in place, which are specifically there to heighten security first and foremost. Quite happily foregoing speed and scalability (in places where it is unavoidable).
Examples are, consistency checking all over the place and randomisations, which provide greater security but inevitably, hurt performance.
This would be like comparing high performance cars and throwing in an M1 Abrams main battle tank to also be tested as a high performance car. In the end, the tank will obviously have terrible top speed, acceleration and cornering ability and everyone will pronounce it crap. But try defending a nation with Ferrari 360 Modena's.
This course is not for this horse. What's more, OpenBSD has been very tentative about moving forward on SMP for very good reasons. It opens up a huge can of worms (bugs), which makes understanding code and thus auditing extremely difficult. The machine being used for the test is SMP!
FreeBSD SMP is supposed to be fantastic in the new technology releases and so-so in the stable releases.
This test would be better conducted in about a year and without OpenBSD (even if it did have SMP by then). OpenBSD is never going to be the highest performance server because that is not what the OpenBSD project strives for and they are willing to hurt that area in the name of security.
If this machine were not SMP, my money would be on NetBSD with FreeBSD coming a close second.
In short, I'm not terribly impressed with the power of that UltraSPARC processor; especially considering it's so closely matched with my two lower-end boxes.
I have a Sun Ultra 10, 333MHz UltraSPARC IIi with 2MB cache and 128MB RAM in one bank (I realise I can get better memory bandwidth while using two banks).
I can confirm, the machine runs like a two legged dog.
If it were not for the fact that I want to improve my Solaris skills (the whole reason I bought the machine), it would be running OpenBSD as my firewall.
In everything I have thrown at it, my 300MHz G3 iBook and 300MHz PII kill it so badly that using percentages to compare them is a waste of time. I prefer to say 2-3x slower.
Compiling all of OpenBSD 3.4 -stable macppc and generating release packages (system, X11 and ports), my little iBook, with slow little 6GB notebook drive took 5 hours to complete. On the other hand, doing the same for OpenBSD sparc64 took 7 hours on this Ultra 10 with a much faster 7,200 RPM desktop drive. I would not be surprised if the iBook could have done it 2-3x faster given the same drive.
I am however interested in Linear Feedback Shift Register Pseudo Random Number Generator designs. I used to build them in hardware but that gets pretty limiting when you're just a hobbiest. I am thinking of writing a simulator that finds maximal stream length designs so I think this 64bit CPU (being the only 64bit one I have) will be a good candidate.
Then again, maybe I should just get an Opteron, declare Sun "soon-to-be-dead" and enlist this Ultra into the OpenBSD/PF armed forces.
PS, I realise that SCO's imminent death with slow the demise of Sun and I do like Sun gear and would rather not see them go belly up. I have not been watching them financially lately. Are they looking any better?
However, in most of the benchmarks he did with Sun's compiler, 64 bit programs came ahead of 32 bit ones.
Looks like to me that Sun's 64bit code won 7 out of 22 tests against Sun 32bit code.
The rest are either loses or near ties.
Link a good case of benchmarking.
.NET 2003 would not look like it does if Microsoft ever spent time meaningfully watching people use the program.
Go argue with NASA and the US Navy (whome I used to work with, in an electronic weapons engineering capacity).
Find a good benchmark.
I could be here all damn day. I could give low level examples down to the testing of gate propagation delays, to high level examples of final apps running on final hardware and everything in-between.
My quick answer would be: Any test which gives repetative meaningful results when run under a scientifically sound procedure.
You are simply covering through weak counter argument some of the points that I was trying to uncover.
Ha! When you use points to talk about benchmarking, you talk about large scale (real world) benchmarks of LAME and Q3 and propose their results to be indicative across the board! And you talk about weak arguments!
I tell you what then, prove this statement: "in benchmarking scientific rigor is always lost". What a bold, foaming at the mouth, nutcase statement. Paint the whole world with the brush you paint yourself with?
You CANNOT prove a generalization with a few weak examples. You usually can't prove most generalization.
You can't find good practices of benchmarking because there are problems in the foundations of the ideological and engineering in the tech industry. Why? Because technology is simply business.
Technology business comprises many facets. Engineers create with scientific approaches and marketing droids dull down the science to help sales. Witness Intel's MMX. The engineers called it Matrix Math eXtensions, the market droids called it MultiMedia eXtensions (how well would something with the word "math" in it sell!). Regardless of what it's called and how well it sells, it does make great improvments through a SIMD approach designed by engineers. The engineers may have been told to improve the multimedia experience and so they took a scientific approach to do it, because they know, through observation (simulation, benchmarking, etc), that multimedia often uses repetitive instructions on varying data.
Benchmarking does not have to be an entire application running on given hardware. It could be time to execute single instructions, for example.
There are barely any good consumer products produced by engineers.
Engineers take care of the technical details. Without them, we would only have pie-in-the-sky visionaries who would never deliver anything.
There are no good cars, no easily adaptive alarm clocks, etc.
Subjective crap. You have experienced every car and alarm clock that has ever existed and then based on your opinion of them, proclaimed that there are no good ones because you don't think they're good.
Looks like you've found a niche in the market for "good" cars! Quick, go make your millions designing, prototyping, refining and then mass producing, but without using any scientific rigor or benchmarking!
It's because the information concerning the production of products is private, and because there is no meaningful observation of the use of products. Visual Studio
Good stuff. Find one example, then use it to throw blanket statements.
There is only the deep-rooted creation of unauthentic demand for badly designed products.
So there is no demand for well designed products?! I really doubt that you mean this. I don't know you, but based on the way you write I see you are intelligent. That sentence though, is either ill thought out, or the author is deluded severely.
IDE HDD's sell like hotcakes because end consumers don't know of and rarely need SCSI. Yet there is a demand for SCSI by intelligent people (and some less intelligent)!
An IDE drive might have specs of: minimum sustained transfer rate 30MB/s, random see
Benchmarks are meant to ideally test minimal pairs
And they often show disparity in their results due to being interupted. This would be a baddly carried out benchmark under less than ideal conditions. This is human error. Of course there are slight variations in subsequent runs, but these should be able to be explained and compensated for. It is most certainly not a benchmark lie though. If it took that long, then it took that long, now find out why!
But in benchmarking scientific rigor is always lost
Failing to retain a scientific approach is a human failing. It does not always happen and is not the benchmark telling lies, but due to poor procedure.
But the benchmark choice is frequently meaningless or misleading.
[poor] "Choice", "Meaningless" and "misleading" [results] each require an incompetent person. Don't blame the benchmark. Even if they wrote the benchmark, they might not understand the results.
Benchmarks do not elucidate any fact.
Yes they do. Very very specific facts which can later be used to make considerations for future decisions. It could be a specific application, algorithm, overall CPU ALU, FPU or single CPU instruction, it could be bus type, etc. Specific facts leading to educated decisions.
You will always see in CPU tests LAME encoding. The p4 will always win against an Athlon.
If this is the case, then LAME as it stands is specifically faster on a P4 than an Athlon. That would be a coarse benchmark though. Some would call it "real world". And it is. It is specific to LAME, but not specific at a lower level where it could be found why this might be the case and how to improve LAME on both P4's and Athlons seperately (with an end result that might have the Athlon out-perform the P4, due to new insight gained from benchmarking specific areas).
The reviewer will not explain why this is the case and that LAME encoding is simply clock cycle dependent.
So the reviewers fault becomes the benchmarks fault?
Benchmarkers need to be able to explain all the dependent variables, to tell why the results happen.
Thus my original statements?
In graphics cards Q3 benchmarks above a certain magnitude are meaningless.
Bad choice of benchmark is the fault of the benchmark?
Benchmarks need to be interpetted by someone competent enough to do so. Just because someone carried out a poor benchmark procedure or could not understand the results, does not mean the benchmark lied.
The reviewer with meaningless variables creates an inauthentic conditioned desire in the consumer that leads to bad and lax software and hardware engineering.
Incompetent reviewer, ignorant consumer, deceitful engineering.
Morrowind and other games have horrible problems with their graphics engine that can not be saved by faster GPUs and dx9.
So they are CPU bound? Memory? Sounds like maybe they don't know how to profile their code too well. When profiling, it helps to know how to benchmark and make meaning out of the results.
You cannot improve that which you do not understand, through anything other than luck. Benchmarks provide specific facts which, when correctly interpreted, can bring about improvements. People who can't interpret them, say they are meaningless.
You have now intrigued me into trying OpenBSD/SPARC.
Actually, forget it. I've just realised, OpenBSD/SPARC probably won't have a kernel that supports the devices in a typical SPARC64 system.
For all I know, OpenBSD/SPARC64 is compiled 32-bit. I shall have to investigate this. I can't beleive this Ultra 10 has been flogged by my little G3.
On early systems, particularly before the 286, the mass differential between 0 and 1 was a serious issue.
Yes, it was most evident during the paper tape and and punch card days, when it was actually tangible.
Here on planet Jokeania, we laugh at his statement.
Ahh, but real geeks take more delight in humour that points out the truth in the geekiest manner possible.
Which brings up a point: both NetBSD/Sparc and NetBSD/Sparc64 will run on an Ultra 1, which is a 64 bit machine. Why doesn't somebody install each NetBSD port on two seperate Ultra 1 machines. Then the benchmark comparision can be between the normal apps that build on both systems, running in parallel on two identical systems. Its exactly the same codebase except for the 32 or 64 bittedness.
Hey there's a good idea. Is NetBSD absolutely exactly the same between the sparc and sparc64 flavours, minus the compile options of 32 vs 64bit?
I use OpenBSD. I would be willing to install OpenBSD/SPARC64 onto my Ultra 10 run some benchmarks, then install OpenBSD/SPARC and run the same benchmarks, then compare.
Anyone know if OpenBSD SPARC64 and SPARC are close enough in code difference to make this worthwhile?
I recently put OpenBSD 3.4 -stable/SPARC64 onto my 333MHz Ultra 10 and compared it with OpenBSD 3.4 -stable on my old 300MHz G3 iBook. The iBook was about 3 times faster than the Sun in ubench, and benchmarks of md5, sha1 and ssl.
Making the OpenBSD -stable release on the G3 (192Mb RAM and slow 6Gb noteboot HDD) took about 6 hours whereas on the Ultra 10 (128MB in one bank) it took about 8-9 hours.
Disk transfer rate is kinda crappy too. I have two 20Gb Seagate IDE drives, one in the Ultra and one in my Thunderbird 700. The Thunderbird gives me a transfer rate of 28Mb/s whereas the Ultra gives 12Mb/s (they are exactly the same model of drive). I realise there might be a lot involved in limiting the IDE performance on this particular Ultra 10, but I would have thought that both systems could saturate the bandwidth available from these old'ish drives. I've heard that the Ultra 5/10's IDE controller sucks, perhaps there is truth to that. Someone claimed that replacing with SCSI is like having a whole different (faster) machine.
You have now intrigued me into trying OpenBSD/SPARC. I am, however, loathe to remove Solaris 9, now that I finally got it installed again. It takes *ages* to install, even from DVD-ROM. It seems that after every thing it installs, it pauses for a set 90 or sometimes 30 seconds. Meaning I have two options, sit there and click to continue, or go away and wait ever longer.
There are 3 types lies. Lies. Damned Lies. ...and benchmarks.
Benchmarks don't tell lies. They usually tell truths about very specific areas which typically reflect "real world" applications to very varying degrees depending on how and how much those specific areas are used within the "real world" app. The specifics need to be analysed by someone who knows what they're looking for.
If you are in the market for a computer that will have a very specific role, then you might be interested in looking at benchmarks in great detail to find the best system for that specific role.
Benchmarks don't lie, people who interpret what they show, simply misjudge the numbers. Sometimes however, people who do understand what to look for, intentionally misrepresent benchmark numbers to increase marketability of their product. They are the liars, not the benchmark.
PS, I realise this is humour, but I often hear people state that benchmarks are useless. That is not true. They are very useful if their output is analysed properly. These are the same sorts of people who claim the Y2K bug to be all hype.
I agree completely. But... of the 50% which are not toggled, the original bit remains unchanged...I may well have made a mistake.
Sorry for taking so long to actually do this. My life has been upside down the past 2 weeks.
I can report, that I would appear to be most certainly, absolutely wrong on this matter. I honestly beleived that the bits which would not be toggled would colour the output enough to provide strong enough patterns for humans to discriminate from the noise.
How very wrong I was! I wrote a quick and dirty little C, to XOR a raw audio and image file while keeping the headers intact. I verified this with a hex editor to make sure I was not rendering the files to noise via header corruption.
The audio file went to complete noise, as did the image which I made especially with high contrast (black and white) shapes.
However, I think I found the cause of my original bogus results. An off-by-one error in my usage of rand(). If I set RAND_MAX to 256, I would get an image with the patterns intact under the noise. I mistakenly thought that this would yield 0-255 random values, but it does not, it yields 0-256. Setting RAND_MAX to 255 provides completely noisy files. : )
Appologies to those I doubted and to those I sent on a wild goose chase.
I am still intrigued if there is some "colouring" going on with the bits that don't get toggled. So I may verify this manually. But looking at the image, it looks like complete noise to me.
The article is clueless technically. The panorama cam takes hundreds of 1 megapixel images and stitches them together to produce the panoramas that have been published on the web.
Exactly. That "article" is completely wrong on most counts and is obviously written by some tech illiterate who has misinterpretted what he has been told by NASA.
Using a 1MP CCD to capture 9 images for a 3x3 stitched matrix (for example), could have been acheived with one 9MP CCD.
"NASA's Spirit Rover is providing a lesson to aspiring digital photographers: Spend your money on the lens, not the pixels."
Who on Earth : ) wants to painstakingly take multiple photos and then stitch them together every bloody time?! Just buy a high MP camera and be glad that you'll never feel the need to do that.
Imagine the photos from Mars if the CCD was 5MP and good stitching was being done. I know (and knew before reading the silly article) that bigger CCD pixels would result in greater sensitivity. But I wonder if this is the true reason NASA wanted larger pixels. Do they really need hyper sensitive CCD's on Mars? I would have thought that they were more interested in the reduced noise that comes with larger sensors.
If you XOR a message with truly random bits, the result will consist of truly random bits. This is because for each bit of message there is a 50-50 chance that you will flip that bit, and these chances are all independent. So the output bit has a 50-50 chance of being 0 or 1, independent of other output bits.
I agree completely. But... of the 50% which are not toggled, the original bit remains unchanged. This is more than enough to render a text message to gibberish, but with audio seems to leave enough information behind for the Worlds most powerful signal processor (human hearing) to have something to play with.
Contrast this with what would happen if you AND or OR the message with a (pseudo-)random bit stream.
I may well have made a mistake. But I was most definately using XOR. XOR is my favorite operand. It intrigued me since my delve into 6502 assembler, 17 years ago. The cool things that can be done with XOR (not obvious to most), make it very useful.
I intend to redo this... (watch this space) ; )
Maybe he XOR'd the entire 8 bits of each byte with the same bit, effectively XORing each byte with either FF or 00. In that case, a lot of the original audio is still there.
Have you ever used XOR? If I XOR'ed with 0, then I would get no change in the file at all. I'm pretty sure that if I XOR'ed with 255, I'd simply get an inverted waveform, and thus the audio would remain completely intact, as far as human hearing is concerned. This of course assumes non-signed raw 8 bit audio files.
In these cases, all of the original audio is still there.
I reckon the human brain, looking as it does for patterns in the world outside, would be able to find what remained of the original pattern in the data.
That was my theory after I found this strange result.
I'm not the parent, but it seems to me that an XORed file would sound like a noisy copy of the original.
I may even try it myself and see.
That would be great, to have someone else either refute or back up what I found (I'd be happy for clarification). I haven't coded in years, but I might knock up a little C, record a short raw audio file and post the results on my web page for others to compare.
I wouldn't mind trying it on a raw image (with high contrast patterns) too see if the human brain can find those patters behind the noise.
Actually, an experiment showed that when cutting all but the LSB of a music wave file, the tune remains still recognizable!
Many years ago (10+), just out of interest in crypto, I XOR'ed a raw audio file (my own speech) with pseudo random data (all bits, from LSB to MSB). The result, was one very noisy audio file with the speech still audible! I thought "WTF!?"
I figured that since, on average, 50% of bits would be toggled, some of the audio information would still be present in a form a human could recognise. I have been meaning to do this again and pass it through a low pass filter to see if I could make the audio come more to the foreground.
perfectly (pseudo) random data
This is a contradiction in terms. Pseudo random data cannot be perfect, that is why it is pseudo (fake). Although, based on reading your interesting message, I'm sure you know this.
It has no practical solution.
How about stego software that detects how many LSB's span the noise floor, replace those with real white noise and then replace lower LSB's with the stego? I wonder if one could go about the noise floor LSB replacement so that it was a gradual replacement near the bits which border between noise and information? So as to prevent detection of the sudden (obvious) change which would be a "stego fingerprint" in itself!
about 2% slower overall
Did you measure the main memory speed? I would have thought the laptop would be about 10% slower than the desktop, considering the resolution/colour depth and the usage of DDR main memory.
I think i'm (hopefully) sitting pretty thanks to DDR.
Definitely. The quicker main memory becomes, the easier they can get away with profit maximizing techniques like this. Dedicated frame buffer memory of equal speed to main memory (all other things being equal), will always be faster. But if it's only 2%, then the cost might not be worth it.
Funny I was just reading an article over on Tom's Hardware guide about that
I wouldn't put too much emphasis on what you read at THG. Once upon a time, an article at Tom's hardware tried to claim that AGP provided no gains over PCI, by comparing current (at the time) PCI and AGP 3D cards. A stupid stupid way to prove the point.
The AGP cards were new and working in glorified PCI mode. Not using advanced AGP features. What's more, the software being used to benchmark "PCI vs AGP" exploited fill rate limits and NOT PCI/AGP bus limits.
Bert McComas I beleive was the "experts" name.
The irony was, that later, using a specially crafted Quake 2 level (by S3), which used huge textures, a slow AGP Matrox G200 could be seen running the benchmark faster than a "super fast" PCI setup of dual Voodoo2's!
This benchmark took the emphasis off fill rate limits and onto the PCI/AGP bus. Suddenly a G200 was faster than dual Voodoo2's?! And it all came down to PCI vs AGP.
THG was trying to prove that AGP sucks by saying, "look this PCI card is faster than this AGP card, therefore AGP sucks". They refused to back down too, when techs working in the design of this industry informed them, point by point, why they were wrong. Hell, there is data on THG that proves THG wrong.
THG has little credibility as far as I am concerned.
Now, to your question. Does this consume a ton of bandwidth and affect performance?
... I wouldn't expect results to vary significantly, since memory requirements for 2D work are relatively low.
I don't think he is concerned with 3D rendering performance. He is concerned with the impact on main memory bandwidth, since a part of main memory is being used as a frame buffer.
For a constant image to appear on screen, the frame buffer must read for each frame displayed. 70 times per second for 70Hz. This can add up to hundreds of megabytes per second, depriving this bandwidth from the CPU.
These shared main memory/frame buffer memory systems are not going to be real 3D speed demons.
That being said, for normal 2D work, bandwidth utilization is negligible and shouldn't seriously impact performance
Using a portion of main memory as a frame buffer, even to display a static 2D image, is going to mean that that portion of memory is read completely for each frame displayed. That might be a lot of bandwidth out of that available.
If someone can afford a system with DDR main memory (where the lost bandwidth will be less noticable), then they probably can also afford a cheapo video card with a real, dedicated frame buffer.
Those typical "Joe Users" are the same ones that the open source market needs to get using their systems in order to succeed 'cause those "real users" have "real money."
Microsoft has plenty of money. So what is their excuse?
Secondly, I do blame most of the problems on the user's inexperience.
If you install XP, then connect to the internet, you will have Blaster within minutes. Unless you take preventative steps which Joe average knows nothing about. Joe average is the intended customer. Before he has a chance to read about going to windows.update, or even if he is in the process of going there... he has Blaster and is wondering why the hell his PC keeps telling him that it will shut down in 60 seconds.
Now, how is this his fault?
Linux would have the same problems if Joe User's began using it.
Typical Joe average, playing with Linux, will give up and go back to Windows. If he persists, he learns and progresses beyond Joe average status.
The reason Apple OS does so well is because it has...oh...3% of the market share. Compared to Windows XP -- that's nothing. (READ: Not enough people use it so nobody is going to write a virus/trojan/spyware/other stupid shit for that operating system. It wouldn't affect enough users.)
Not true. People DO write those for Mac OS. This point is probably impossible to prove, until Apple has more systems on the internet.
Secondly (and in line with the last paragraph) of course Windows ports are scanned all the time. It's because, again, everybody uses Windows.
The sudden explosions of MS port scanning I see in my logs are not due to sudden explosions in hacking activity, they are due to Windows systems becoming infected with new worms. The deluge I see are not hackers, they are victims desktops.
Waiting for an excuse to replace my current PC hardware with a Mac.
;-)
I'm waiting for money to do the same. ; )
Damn this reliable well-perfoming PC hardware! It just keeps going... should've bought a flaky iBook instead
My iBook is still going (old clamshell 300MHz G3).
There are a lot of posters in here who claim to have had so many problems with XP. Obviously then it is a lack of knowledge and experience on your part. Just because you can't get it going well doesn't mean it is a problem with the OS. Lots of Joe Home Users are very happy with it. I am a very happy XP user, and have absolutely none of the problems that are bleated on about here. Turn into real users.
Windows XP is marketed to the average Joe, who will not fit your definition of "real users". When these average Joes connect to the internet with XP's out of the box settings, they get worms, viruses, spyware, etc.
XP can be hardened, but not with the knowledge of the users which it is marketed for.
I agree with one of the other posters, when he says the Joe average users who are happy with XP are actually oblivious to the reality that their PC is actually on a rampage infecting other peoples computers, sending SPAM and their credit card information. So many times I have visited client sites, only to find they have spyware, etc. And don't blame me for these problems, my introduction to these people is usually due to them having security problems in the first place.
I come home to my mostly OpenBSD network (plus some hardened Wintel) and relax. But then, I'm not your Joe average XP user.
I do hope XP SP2 helps and XP/Win2k are certainly leaps and bounds ahead of the Win9x abominations. But please don't try to claim that XP is great and the ignorant users are to blame. Microsoft claims to provide a stable, secure product for the World at large? Then this is a lie.
Apple's Mac OSX is much closer to delivering that claim.
BTW, relying on automatic updates is a dangerous game. Does XP use crypto and authentication by default for automatic updates? I would hope so. Sometimes patches are retracted, because they cause more grief than they solve. I call that a lottery. I prefer to firewall then wait before deploying patches, where ever possible.
PS, I'll leave you with this... do you run a firewall? Do you ever watch the logs? I'm running an OpenBSD pf firewall for my home network and I tell you, watching the attempts at typical Microsoft ports coming thick and fast is scary. If you don't, I suggest you do and then come back here and tell us that "most [XP users] have no trouble with Blaster or random spywares, or indeed security hacks".
I'm a windows user (but not zealot.. if *nix did what I wanted easily on a day to day basis, I'd prefer it)...
Tried MacOS X?
For some people, *nix is easier than Windows (even someone running some *nix less polished than OSX).
I switch between OpenBSD, Debian, Win2k and XP due to differences between play and work. I often find myself fighting Windows and Windows configurations tend to rot. With OpenBSD and Debian, once they're set up, they just keep going...
Thanks for the tip Gary.