On Fri, Dec 19, 2008 at 5:44 PM, Michael B. Smith <mich...@theessentialexchange.com> wrote: > BSD and Linux took MANY YEARS to get their scheduler and memory management > up to the level of Windows and traditional UNIX.
Even that is a rather imprecise claim. It largely depends on the workload, the application, and the hardware. More examples: Several years back, Solaris vs Linux, head-to-head, Linux was winning in network performance. Sun investigated, and found their network stack had design assumptions built around old single-processor SPARCstations. They adjusted their code and saw a huge performance increase. (This was reported to me, not first-hand.) Circa 2000: Solaris vs Linux, older SPARC hardware, more modern Solaris software. Linux often performed better, because even back then, Solaris was generally optimized for newer architectures and/or giant multi-processor boxes. Present day: Linux now has a choice of algorithms for things like the scheduler, memory management, network routing, network queuing, etc., so one can tune the kernel for specific workloads. Commercial OSes tend to have a one-size-fits-all mentality. You need to know how to do the tuning, of course, but with that knowledge you may gain better results. And that last example brings me to another point: How well a system performs usually has far more to do with the knowledge of the admin than the quality of the system. The best product in the world will generally stink if it's not used correctly, and I've seen incredible results coaxed out of marginal components in the hands of guru-level experts. Indeed, I think this whole discussion is more about *this* than the quality of the hardware/OS/applications. People claim X performs better than Y, but can't say why or how. Sounds more like they just don't know what's going on; the performance results could be reversed and they'd be in the same boat. This list is supposed to be for professional system administrators. We're not supposed to be treating the computer like a magic box. We're supposed to know the reasons why they work, and why they don't. In closing: "SCSI is *NOT* magic. There are *fundamental technical reasons* why you have to sacrifice a young goat to your SCSI chain every now and then." -- John Woods ;-) -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
