Umm... maybe read this whole thread and the posted article? It pretty much states why the Apple benchmarks are flawed.
But half of the posts on this thread explain the reasons why the benchmarks are valid and the article is wrong! Not the least of which is that the person who wrote the "article" (if you can call it that) is a known anti-Apple zealot who will say ANYTHING to make the Mac or Mac users look bad.
And the other half say they aren't valid.
- explicitly disabling SSE2 optimizations on FPU intensive benchmarks for the x86
And explicitly disabling Velocity Engine on the G5. Level playing field. Also, note that they left SSE on. Next!
Actually, this is not entirely true. Intel standard practices are that the compiler uses the SSE2 register set for FPU operations if present, even for scalar FPU operations. The reason being that the x87 stack is, and always has been, nasty. So, for all intents and purposes and according to Intel standard practices *and* the way compilers work, even if you aren't using SIMD, you *are* using the SSE2 registers simply as a set of general purpose FPU registers. The fact that the x87 FPU stack is nasty is why Apple chose to benchmark this way, even though compilers compiling for P4+ architectures will use SSE2 regardless of any SIMD. Apple knows the 970's FPU is better than the x87 stack therefore, go against common (and recommended) practice to make the numbers look better. In a nutshell, code compiled with relatively new compilers will use SSE2 by default on P4+ architectures. Forcing x87 is actually going against the norm.
- using gcc instead of the better Intel compilers for the x86 while using an optimized G5 gcc compiler
There's no such thing as "an optimized G5 GCC compiler." They used GCC 3.3, just like you can download from anywhere. And also, it makes ZERO sense to test one compiler on one machine against another compiler on another machine. That test tells you nothing about either the compiler or the machine. You have to isolate all variables except the one you're testing for, which in this case was hardware performance running the benchmark.
Are you benchmarking the compiler or the hardware? If you are benchmarking the compiler, then use the gcc on both. If you are benchmarking the hardware, use the best available compiler for each machine. It just so happens that gcc is probably the only working compiler available for the G5 at the moment. It also doesn't hurt that gcc on Intel x86 isn't that good. Last time I checked, the Intel compiler was freely downloadable. The only reason to not use the Intel compiler is marketing. Again, are you benchmarking the compiler or the hardware? I would rather see what the hardware is capable of, not what gcc is capable of.
- using a speed optimized malloc libraries for the G5 tests but using the standard malloc libraries for the Intel tests
You misunderstood THAT one too. Apple's standard Jaguar malloc() includes code for cache-coherency for dual-processor systems. Jaguar does not include a uniprocessor malloc(). So for the SPEC base tests (which run on only one processor) they replaced the dual-processor malloc() in 10.2.7 with a single-processor malloc(). Again, this puts both systems on a level playing field, because Red Hat 9 does not put a multiprocessor malloc() on a system unless it actually detects an SMP motherboard.
Not entirely. Not only was the malloc code simply a non-cache coherent malloc library, it was one optimized for certain types of memory allocations, probably ones that work well with the SPEC benchmarks. So, you have two optimizations - uni-processor and speed/specialist optimized - for the G5 tests while you simply have the one optimization for the Intel - uni-processor. I have used many malloc libraries in my career - optimized for large allocations, for small allocations, for allocation, for freeing, for garbage collection, single-threaded
Umm... maybe read this whole thread and the posted article? It pretty much states why the Apple benchmarks are flawed.
But... since Mac zealots have problems reading information that casts their beloved machines into non-favorable light or speaks disparagingly of their their beloved Temple Apple, here are but a few (summarizing the original link and pretty much these ~1000 forum posts):
- explicitly disabling SSE2 optimizations on FPU intensive benchmarks for the x86 - using gcc instead of the better Intel compilers for the x86 while using an optimized G5 gcc compiler - using a speed optimized malloc libraries for the G5 tests but using the standard malloc libraries for the Intel tests
for (big loop benchmark) {
if (systemType = "Apple")
sleep(100); }
and compiles for every OS. Everybody is running the same thing then but I can assure you that you'll have very different results. It *is* possible for a compiler to produce fast code on one architecture and suck on others. For example, prior to version 3 of GCC, gcc did fairly well on load-store architectures like SPARC and SGI machines but was horrid on Intel x86 compared to other compilers available on those platforms (such as Intel's and Microsoft's).
I heard that the reason why things are $2.99 instead of $3.00, for example, is because some group did a study on numbers and prices and found that people look more favorably on prices ending in a '9' or are just under the next higher increment. IIRC, this study was done for Little Golden Books. The story I heard was that when the books were first sold, they were priced at $0.25 each and weren't selling. The study was conducted and as a result, the book publisher raised the price to $0.29 and the books started selling very well. I think the idea is that it is common to look at the leftmost digit to assume the magnitude of the value and the rest of the number has less weight. Thus, $2999 has the illusion of being a much smaller value than $3000 to the general public, even though the actual difference is only $1. I guess it's kind of like thinking $2000 and some change vs. $3000.
I can't find any web references to back this, though, but I do remember someone telling me this at one time.
The OS memory map for the 32-bit Windows variants (since Windows NT 3.1) is 2G for user and 2G for system (which adds to 4G of memory map). You can get Windows 2000 Advanced server to run as 3G of user and 1G of system if you want, which is useful if you have larger databases and want more RAM for your DBMS. I've seen plenty of Windows server boxes with 2G+ of physical memory, mostly ones that run DBMS.
I switched from CDex to EAC on a recommendation from a friend. I have four machines I routinely rip CDs with and CDex repeatedly produced poor quality rips on all of them. I never could figure out why. I've had a much better experience with EAC and the error reporting is really nice and I've grown to trust it well enough to just check to see if any errors occurred and either re-rip it or keep it (>98% first rip is clean in my experience, very rarely do I get jitter errors).
Actually, yes you can. You can buy both Itanium machines (http://www.hp.com/workstations/itanium/index.html for example) and you can get the OS, at least I can download it using an MSDN subscription (I could downloaded the beta about 7 months ago, iirc).
Yeah, but neither is IPC alone. The better number to look for is IPC * Clock. An Athlon running at 1GHz has a higher IPC than a 3.2GHz P4 but I don't think we'd argue which was faster.
Again, IMO, focusing on the OS is the wrong thing. Do you spend more time worrying/fiddling with the OS that is inside your car or simply using your car? Do you have to dork with the OS that is in your cell phone or do you just use the cell phone?
IMO, if you are spending time worried about your OS, you are wasting time. The applications are what matter. Most folks don't care what OS they are running but are more concerned with it being familiar and not getting in the way of doing their work (at this time, I've found my Windows boxes to be as stable as my Linux boxes - seeing about the same number of kernel panics as I have seen Windows box crashes in the past year). Being able to pick up a new (to you) application and getting something done within a few minutes of installing the thing is important. Becoming a wizard at the app can take a long time but being able to do simple things real fast is important. In this regard, I still rate OSS apps behind Windows behind Apple.
Consistency is very important. I can't tell you the number of times I've run some new OSS app and had difficulty getting it to do anything and eventually leaving the app because of it. To make it even more funny, the Exit menu option (not the close window box) isn't even in a consistent place. It's almost as if every tool (as in wrenches, saws, etc.) manufacturer made their own unique tools. You'd be able to use Craftsman wrenches to work on your car engine after spending time figuring them out. However, switching to Snap-On tools would cause many delays because you have to figure out how to use the thing before you can get any work done at all.
As far as configurability and such, I gave up on that a long time ago. I use the defaults for the window managers that I use. Years ago I realized how much time I wasted dorking with custom configuration stuff only to confound anyone who was sitting down using my configuration trying to show me something or me sitting down with their custom setting trying to do something. Consistency is good from both the OS and from applications (and across applications). Many OSS apps I've seen seem to have interfaces designed by either engineers who simply wanted the options available somewhere and didn't care where, just add to the end of the menu or by folks who seem to want to show off that they can do better than anyone else with their own bizarro interface. Spare me and stop wasting my time. Make it easy to use and consistent with other apps so I don't have to spend 3 minutes (out of spite) trying to find the menu option that exits the program.
Benchmarks with the older processors were done a while back. It's not that hard to dig up the older benchmark articles and see what was posted back then. The only real variations would be video cards but you can always use numbers from benchmarks that don't use the video card to compare (RAR, MP3 encoding, SPEC, etc.)
As for you saying you got 100 mbps throughput on a 100 mbps line with routers...it's possible that the router is designed to handle that much traffic in its buffer.
You won't get that using TCP/IP anyway. Because of the overhead in the protocol (control information and such), there is a ceiling on the efficiency of user-data/total-packet-size that you will see. The calculations are pretty easy to do given the packet structure. Some of the best transfer rates I've seen (closed network bandwidth test) have been around 90% of the connection speed using a high-quality switch (not using any compression techniques, of course).
I usually see around 145KB/s ftp transfers over my 1.5Mb DSL at home for large transfers (like that 600MB file I downloaded last night) across the Internet.
Aside from that, though, I've never had Linux hang up on me.
Well... that's the way of it, though. Lots of people post on here how they can't run 5 minutes without Windows locking up on them (or BSOD) but Linux works great. I personally have had a machine that Linux just would not run on but Windows had zero problems. I've seen as many kernel panics as I have BSOD and Windows hangs. I've seen Windows NT boxes with ~1 year of uptime. I've seen Linux boxes that couldn't make 1 day of uptime. Buy cheap computer parts and you will have problems. Buy components you know to be well supported and you'll have fewer problems. Personally, I haven't found an OS yet that would solve all my problems and be good enough to be the only OS that I run on all my machines. Also, I outgrew my OS religion phase when I was in my early teens and have no problems saying that both Linux and Windows leave a lot to be desired.
because it's not built around the asinine all-your-eggs-in-one-basket registry concept.
For the record, I've had more problems with RedHat's rpm "registry-like-thing" than I have ever had with the Windows Registry. The Windows Registry is simply a lightweight database (modulo bugs that may happen and programmers who don't know how to use it but try to anyway). There is no "magic" there nor any "all-your-eggs-in-one-basket" concept - whatever that means.
But... as the zealots will maintain, it's ok for RedHat's rpm registry to have bugs because someone, somewhere, in a far away galaxy can look over the code and supposedly fix it at some time, even though that hasn't happened yet. And, it's ok to make fun of Microsoft's patching often as long as we ignore the fact that I've applied almost 2x as many patches from RedHat in the past 6 months than I have from Microsoft.
One of the benefits of religion is that you an rationalize ignoring or overlooking your own failures as long as you can draw attention to others' failures in a louder voice.
I mean, there's no agency regulating what people can leave behind when they go on a hiking trip, is there?
Depends... I go hiking/camping in Wilderness area where there are many rules about what you can and can't do. No mechanical transportation (bicycles, motored vehicles, etc.), you must carry in what you carry out, fires can only be started in certain areas, you can only camp (primitive camping only) in certain areas, etc. It is managed by the governmental agencies over parks and wildlife.
You can use common widget sets and still have very different UIs and usabilty. The fact that you are using a menu widget has little, if not completely nothing, to do with what that menu contains. Those libraries provide a menu widget, it's up to me to put stuff into it. If I don't do things logically and with a mind on workflow, my menu can still suck and be unusable.
There is still no/very little conformity between UIs of applications. Every application you run you have to learn a tremendous amount behaviour just to get things done. The fact that all Mac and Windows applications behave very similarly - menu options are familiar and grouped similarly, hotkey behaviour is the same from app to app, etc. - means that I can dive into productive work from the instant I run the application the first time. OSS apps typically cause me to spend a few minutes just figuring out how to cut-n-paste, much less how to get to the operations I want to perform. I have run some of the "mainstream" OSS apps in the attempt to do something quick, just this one time, only to eventually exit the thing because I couldn't get anything done at all. I couldn't find what I wanted to do and couldn't find out how to find what I wanted to do because of a cesspool UI of menus available from every mouse button and menu item with very little logical design, placement, or order. Something that could/should have been a less than 30 second task using an app with a sane UI design ended up with my exiting the app after around 15 minutes with nothing to show for the spent time.
UI consistency is a *good* thing. And remember... I don't sit around installing OSs all day so how easy it is to install is secondary, at best. The OS works best when I am not thinking about it and it isn't getting in my way. It's getting my work done that is important to me.
A "cluster" is a broad term. A "Beowulf" cluster is one made from commodity parts connected with low-cost (100Mb - faster as the price point drops) Ethernet. A cluster can have exotic interconnects, which knocks it out of the Beowulf category. For example, IBM SP and SP2 machines are really just clusters. The Cray T3D and T3Es were really just clusters as well, if you think about it. ASCI Red and Sandia's C-Plants are also clusters.
What usually governs what the machine is good at is more towards latency/bandwidth of accessing the data rather than the architecture. For example, a cluster with a high speed interconnect like Myrinet or a T3Es DMA works well on problems that require low-latency and/or high-bandwidth even though they are clusters. They can be almost as effective as SMP machines on some problems that SMP machines are typically better at doing.
Lots of work has been done lately on TCP/IP (reducing the number of copies in the stack, etc) to decrease latency but it is still a ways off from things like Myrinet.
Also remember that some benchmarks are basically just measures of Bisection Bandwidth of a system. Given enough Ethernet routers and CAT5 cables, you can get pretty high scores on that, too.
I guess this was kinda rambling, but basically it comes down to the fact that currently, there is no one type of architecture that is the best at everything. Sometimes we make compromises (because of cost and such) and use non-optimal architectures (Beowulfs were originally researched simply because they were a cheap alternative that gave good enough performance to do real work, not because they were the end-all, be-all of HPC).
You'd be able to borrow power anyway since the AP would broadcast power every time it transmitted (or constantly or whatever). You don't have to have a username/password to tap that power.... you just leach it off. If you broadcast it, someone can leach it. It's not like you have to decrypt power.
Plus remember that broadcasting power through space is an inverse cubed relationship. Where an ethernet cable could power something 100m away relatively easy with little loss, using wireless power would require lots more power from the source to give equivalent power at that distance. Many current wireless power devices are usually limited to very close range (in the low 1s of meters at the max) and very low power (mW at the max).
Yup... If you look at Apple's history, they have (many many times) had very poor memory subsystems tied to their CPUs. Look back at all the 68030/68040 machines that had no L2 cache and were tied to slow main memory. Even the PPC machines showed these same design decisions.
What they do is similar to the minimum/recommended system configuration listed on the sides of computer games. They don't claim to have invented anything - they just say that for "reasonable" performance you need X, Y, and Z hardware. It doesn't mean you can't run on less.
Microsoft said that they were targeting X-List of hardware as the minimum set for a MultimediaPC (and to be able to have that logo officially used on it). Of course, some folks don't understand computers and probably felt they needed to run out and buy a PC with this logo - which is one of the reasons marketing used this labeling.
Of course, all things are a plot by Microsoft to take over the world... even when I stubbed my toe this morning... it's all a part of their plan!
Slashdot Mirror
Umm... maybe read this whole thread and the posted article? It pretty much states why the Apple benchmarks are flawed.
But half of the posts on this thread explain the reasons why the benchmarks are valid and the article is wrong! Not the least of which is that the person who wrote the "article" (if you can call it that) is a known anti-Apple zealot who will say ANYTHING to make the Mac or Mac users look bad.
And the other half say they aren't valid.
- explicitly disabling SSE2 optimizations on FPU intensive benchmarks for the x86
And explicitly disabling Velocity Engine on the G5. Level playing field. Also, note that they left SSE on. Next!
Actually, this is not entirely true. Intel standard practices are that the compiler uses the SSE2 register set for FPU operations if present, even for scalar FPU operations. The reason being that the x87 stack is, and always has been, nasty. So, for all intents and purposes and according to Intel standard practices *and* the way compilers work, even if you aren't using SIMD, you *are* using the SSE2 registers simply as a set of general purpose FPU registers. The fact that the x87 FPU stack is nasty is why Apple chose to benchmark this way, even though compilers compiling for P4+ architectures will use SSE2 regardless of any SIMD. Apple knows the 970's FPU is better than the x87 stack therefore, go against common (and recommended) practice to make the numbers look better. In a nutshell, code compiled with relatively new compilers will use SSE2 by default on P4+ architectures. Forcing x87 is actually going against the norm.
- using gcc instead of the better Intel compilers for the x86 while using an optimized G5 gcc compiler
There's no such thing as "an optimized G5 GCC compiler." They used GCC 3.3, just like you can download from anywhere. And also, it makes ZERO sense to test one compiler on one machine against another compiler on another machine. That test tells you nothing about either the compiler or the machine. You have to isolate all variables except the one you're testing for, which in this case was hardware performance running the benchmark.
Are you benchmarking the compiler or the hardware? If you are benchmarking the compiler, then use the gcc on both. If you are benchmarking the hardware, use the best available compiler for each machine. It just so happens that gcc is probably the only working compiler available for the G5 at the moment. It also doesn't hurt that gcc on Intel x86 isn't that good. Last time I checked, the Intel compiler was freely downloadable. The only reason to not use the Intel compiler is marketing. Again, are you benchmarking the compiler or the hardware? I would rather see what the hardware is capable of, not what gcc is capable of.
- using a speed optimized malloc libraries for the G5 tests but using the standard malloc libraries for the Intel tests
You misunderstood THAT one too. Apple's standard Jaguar malloc() includes code for cache-coherency for dual-processor systems. Jaguar does not include a uniprocessor malloc(). So for the SPEC base tests (which run on only one processor) they replaced the dual-processor malloc() in 10.2.7 with a single-processor malloc(). Again, this puts both systems on a level playing field, because Red Hat 9 does not put a multiprocessor malloc() on a system unless it actually detects an SMP motherboard.
Not entirely. Not only was the malloc code simply a non-cache coherent malloc library, it was one optimized for certain types of memory allocations, probably ones that work well with the SPEC benchmarks. So, you have two optimizations - uni-processor and speed/specialist optimized - for the G5 tests while you simply have the one optimization for the Intel - uni-processor. I have used many malloc libraries in my career - optimized for large allocations, for small allocations, for allocation, for freeing, for garbage collection, single-threaded
Umm... maybe read this whole thread and the posted article? It pretty much states why the Apple benchmarks are flawed.
But... since Mac zealots have problems reading information that casts their beloved machines into non-favorable light or speaks disparagingly of their their beloved Temple Apple, here are but a few (summarizing the original link and pretty much these ~1000 forum posts):
- explicitly disabling SSE2 optimizations on FPU intensive benchmarks for the x86
- using gcc instead of the better Intel compilers for the x86 while using an optimized G5 gcc compiler
- using a speed optimized malloc libraries for the G5 tests but using the standard malloc libraries for the Intel tests
Nope, I'm saying the previous AC poster knows nothing about compilers or much about benchmarking.
I'm not a zealot, whether or not the Mac "kicks ass computationally as well as in all the other ways" doesn't give me wood.
However, I am convinced by the evidence that Apple's benchmarks are flawed and, as such, are pure marketing, typical of what we've seen in the past.
So? I can write one program that has a check:
for (big loop benchmark)
{
if (systemType = "Apple")
sleep(100);
}
and compiles for every OS. Everybody is running the same thing then but I can assure you that you'll have very different results. It *is* possible for a compiler to produce fast code on one architecture and suck on others. For example, prior to version 3 of GCC, gcc did fairly well on load-store architectures like SPARC and SGI machines but was horrid on Intel x86 compared to other compilers available on those platforms (such as Intel's and Microsoft's).
I heard that the reason why things are $2.99 instead of $3.00, for example, is because some group did a study on numbers and prices and found that people look more favorably on prices ending in a '9' or are just under the next higher increment. IIRC, this study was done for Little Golden Books. The story I heard was that when the books were first sold, they were priced at $0.25 each and weren't selling. The study was conducted and as a result, the book publisher raised the price to $0.29 and the books started selling very well. I think the idea is that it is common to look at the leftmost digit to assume the magnitude of the value and the rest of the number has less weight. Thus, $2999 has the illusion of being a much smaller value than $3000 to the general public, even though the actual difference is only $1. I guess it's kind of like thinking $2000 and some change vs. $3000.
I can't find any web references to back this, though, but I do remember someone telling me this at one time.
The OS memory map for the 32-bit Windows variants (since Windows NT 3.1) is 2G for user and 2G for system (which adds to 4G of memory map). You can get Windows 2000 Advanced server to run as 3G of user and 1G of system if you want, which is useful if you have larger databases and want more RAM for your DBMS. I've seen plenty of Windows server boxes with 2G+ of physical memory, mostly ones that run DBMS.
I switched from CDex to EAC on a recommendation from a friend. I have four machines I routinely rip CDs with and CDex repeatedly produced poor quality rips on all of them. I never could figure out why. I've had a much better experience with EAC and the error reporting is really nice and I've grown to trust it well enough to just check to see if any errors occurred and either re-rip it or keep it (>98% first rip is clean in my experience, very rarely do I get jitter errors).
Either that or his version of "just in time" is 1 day longer than the MWNY announcment.
Actually, yes you can. You can buy both Itanium machines (http://www.hp.com/workstations/itanium/index.html for example) and you can get the OS, at least I can download it using an MSDN subscription (I could downloaded the beta about 7 months ago, iirc).
Yeah, but neither is IPC alone. The better number to look for is IPC * Clock. An Athlon running at 1GHz has a higher IPC than a 3.2GHz P4 but I don't think we'd argue which was faster.
Again, IMO, focusing on the OS is the wrong thing. Do you spend more time worrying/fiddling with the OS that is inside your car or simply using your car? Do you have to dork with the OS that is in your cell phone or do you just use the cell phone?
IMO, if you are spending time worried about your OS, you are wasting time. The applications are what matter. Most folks don't care what OS they are running but are more concerned with it being familiar and not getting in the way of doing their work (at this time, I've found my Windows boxes to be as stable as my Linux boxes - seeing about the same number of kernel panics as I have seen Windows box crashes in the past year). Being able to pick up a new (to you) application and getting something done within a few minutes of installing the thing is important. Becoming a wizard at the app can take a long time but being able to do simple things real fast is important. In this regard, I still rate OSS apps behind Windows behind Apple.
Consistency is very important. I can't tell you the number of times I've run some new OSS app and had difficulty getting it to do anything and eventually leaving the app because of it. To make it even more funny, the Exit menu option (not the close window box) isn't even in a consistent place. It's almost as if every tool (as in wrenches, saws, etc.) manufacturer made their own unique tools. You'd be able to use Craftsman wrenches to work on your car engine after spending time figuring them out. However, switching to Snap-On tools would cause many delays because you have to figure out how to use the thing before you can get any work done at all.
As far as configurability and such, I gave up on that a long time ago. I use the defaults for the window managers that I use. Years ago I realized how much time I wasted dorking with custom configuration stuff only to confound anyone who was sitting down using my configuration trying to show me something or me sitting down with their custom setting trying to do something. Consistency is good from both the OS and from applications (and across applications). Many OSS apps I've seen seem to have interfaces designed by either engineers who simply wanted the options available somewhere and didn't care where, just add to the end of the menu or by folks who seem to want to show off that they can do better than anyone else with their own bizarro interface. Spare me and stop wasting my time. Make it easy to use and consistent with other apps so I don't have to spend 3 minutes (out of spite) trying to find the menu option that exits the program.
Benchmarks with the older processors were done a while back. It's not that hard to dig up the older benchmark articles and see what was posted back then. The only real variations would be video cards but you can always use numbers from benchmarks that don't use the video card to compare (RAR, MP3 encoding, SPEC, etc.)
Heh... reminds me of the TV Guide channels (scrolling program listings) in various places that every so often were blank screens except for:
Guru meditation: 00923409324098
at the top of the screen.
As for you saying you got 100 mbps throughput on a 100 mbps line with routers...it's possible that the router is designed to handle that much traffic in its buffer.
You won't get that using TCP/IP anyway. Because of the overhead in the protocol (control information and such), there is a ceiling on the efficiency of user-data/total-packet-size that you will see. The calculations are pretty easy to do given the packet structure. Some of the best transfer rates I've seen (closed network bandwidth test) have been around 90% of the connection speed using a high-quality switch (not using any compression techniques, of course).
I usually see around 145KB/s ftp transfers over my 1.5Mb DSL at home for large transfers (like that 600MB file I downloaded last night) across the Internet.
Aside from that, though, I've never had Linux hang up on me.
Well... that's the way of it, though. Lots of people post on here how they can't run 5 minutes without Windows locking up on them (or BSOD) but Linux works great. I personally have had a machine that Linux just would not run on but Windows had zero problems. I've seen as many kernel panics as I have BSOD and Windows hangs. I've seen Windows NT boxes with ~1 year of uptime. I've seen Linux boxes that couldn't make 1 day of uptime. Buy cheap computer parts and you will have problems. Buy components you know to be well supported and you'll have fewer problems. Personally, I haven't found an OS yet that would solve all my problems and be good enough to be the only OS that I run on all my machines. Also, I outgrew my OS religion phase when I was in my early teens and have no problems saying that both Linux and Windows leave a lot to be desired.
because it's not built around the asinine all-your-eggs-in-one-basket registry concept.
For the record, I've had more problems with RedHat's rpm "registry-like-thing" than I have ever had with the Windows Registry. The Windows Registry is simply a lightweight database (modulo bugs that may happen and programmers who don't know how to use it but try to anyway). There is no "magic" there nor any "all-your-eggs-in-one-basket" concept - whatever that means.
But... as the zealots will maintain, it's ok for RedHat's rpm registry to have bugs because someone, somewhere, in a far away galaxy can look over the code and supposedly fix it at some time, even though that hasn't happened yet. And, it's ok to make fun of Microsoft's patching often as long as we ignore the fact that I've applied almost 2x as many patches from RedHat in the past 6 months than I have from Microsoft.
One of the benefits of religion is that you an rationalize ignoring or overlooking your own failures as long as you can draw attention to others' failures in a louder voice.
I mean, there's no agency regulating what people can leave behind when they go on a hiking trip, is there?
Depends... I go hiking/camping in Wilderness area where there are many rules about what you can and can't do. No mechanical transportation (bicycles, motored vehicles, etc.), you must carry in what you carry out, fires can only be started in certain areas, you can only camp (primitive camping only) in certain areas, etc. It is managed by the governmental agencies over parks and wildlife.
You can use common widget sets and still have very different UIs and usabilty. The fact that you are using a menu widget has little, if not completely nothing, to do with what that menu contains. Those libraries provide a menu widget, it's up to me to put stuff into it. If I don't do things logically and with a mind on workflow, my menu can still suck and be unusable.
There is still no/very little conformity between UIs of applications. Every application you run you have to learn a tremendous amount behaviour just to get things done. The fact that all Mac and Windows applications behave very similarly - menu options are familiar and grouped similarly, hotkey behaviour is the same from app to app, etc. - means that I can dive into productive work from the instant I run the application the first time. OSS apps typically cause me to spend a few minutes just figuring out how to cut-n-paste, much less how to get to the operations I want to perform. I have run some of the "mainstream" OSS apps in the attempt to do something quick, just this one time, only to eventually exit the thing because I couldn't get anything done at all. I couldn't find what I wanted to do and couldn't find out how to find what I wanted to do because of a cesspool UI of menus available from every mouse button and menu item with very little logical design, placement, or order. Something that could/should have been a less than 30 second task using an app with a sane UI design ended up with my exiting the app after around 15 minutes with nothing to show for the spent time.
UI consistency is a *good* thing. And remember... I don't sit around installing OSs all day so how easy it is to install is secondary, at best. The OS works best when I am not thinking about it and it isn't getting in my way. It's getting my work done that is important to me.
A "cluster" is a broad term. A "Beowulf" cluster is one made from commodity parts connected with low-cost (100Mb - faster as the price point drops) Ethernet. A cluster can have exotic interconnects, which knocks it out of the Beowulf category. For example, IBM SP and SP2 machines are really just clusters. The Cray T3D and T3Es were really just clusters as well, if you think about it. ASCI Red and Sandia's C-Plants are also clusters.
What usually governs what the machine is good at is more towards latency/bandwidth of accessing the data rather than the architecture. For example, a cluster with a high speed interconnect like Myrinet or a T3Es DMA works well on problems that require low-latency and/or high-bandwidth even though they are clusters. They can be almost as effective as SMP machines on some problems that SMP machines are typically better at doing.
Lots of work has been done lately on TCP/IP (reducing the number of copies in the stack, etc) to decrease latency but it is still a ways off from things like Myrinet.
Also remember that some benchmarks are basically just measures of Bisection Bandwidth of a system. Given enough Ethernet routers and CAT5 cables, you can get pretty high scores on that, too.
I guess this was kinda rambling, but basically it comes down to the fact that currently, there is no one type of architecture that is the best at everything. Sometimes we make compromises (because of cost and such) and use non-optimal architectures (Beowulfs were originally researched simply because they were a cheap alternative that gave good enough performance to do real work, not because they were the end-all, be-all of HPC).
You'd be able to borrow power anyway since the AP would broadcast power every time it transmitted (or constantly or whatever). You don't have to have a username/password to tap that power.... you just leach it off. If you broadcast it, someone can leach it. It's not like you have to decrypt power.
Plus remember that broadcasting power through space is an inverse cubed relationship. Where an ethernet cable could power something 100m away relatively easy with little loss, using wireless power would require lots more power from the source to give equivalent power at that distance. Many current wireless power devices are usually limited to very close range (in the low 1s of meters at the max) and very low power (mW at the max).
Think recursive.
Yes... but there is no greater zealot than the converted.
Yup... If you look at Apple's history, they have (many many times) had very poor memory subsystems tied to their CPUs. Look back at all the 68030/68040 machines that had no L2 cache and were tied to slow main memory. Even the PPC machines showed these same design decisions.
What they do is similar to the minimum/recommended system configuration listed on the sides of computer games. They don't claim to have invented anything - they just say that for "reasonable" performance you need X, Y, and Z hardware. It doesn't mean you can't run on less.
Microsoft said that they were targeting X-List of hardware as the minimum set for a MultimediaPC (and to be able to have that logo officially used on it). Of course, some folks don't understand computers and probably felt they needed to run out and buy a PC with this logo - which is one of the reasons marketing used this labeling.
Of course, all things are a plot by Microsoft to take over the world... even when I stubbed my toe this morning... it's all a part of their plan!