You present bandwidth as a rebuttal to the first bit latency problem original poster, yet bandwidth and latency (though related) are different animals.
For example, take your Socket939/754 example. Lets take a 2.0 GHz core (for simplicity) and SDRAM with a pretty good latency of 2 (HTT) cycles. This CPU is running 10x as fast as memory, stock. So (assuming HTT is idle), 1 HTT cycle to send request, 2 cycles to service the request in memory, 1 cycle to bring it back to the CPU. Ignoring the cost of traveling the on-die cache hierarchy, and recalling the CPU is running 10 times the HTT buss, that is at least a 40 instruction bubble waiting on core. Note that this delay is entirely independent of 754/939 bandwidth.
Put two cores on a chip, and suddenly there is contention on the HTT buss (unless your friendly motherboard manufacturer happens to give you independent memory banks, you populate them, and your OS is NUMA aware). Granted, if you slow down the CPU clock there are less wasted CPU cycles, but again that has nothing to do with bandwidth--due to the CPU running at a multiple of the HTT buss (and memory), memory bandwidth remains independent.
You can find a reasonably good primer on these subjects at http://arstechnica.com/paedia/b/bandwidth-latency/ bandwidth-latency-1.html
The solution to maintaining packages on Linux in general is the distribution. Put yet another way, when you speak of Linux in general (kernel + GNU utilities + *sh + / + stdlibs + user_programs) you can only practically mean the various distros. Now, with that in mind, allow me to restate your question: is the distribution solution creating documentation/ease-of-use hell? Probably.
Try to think of the various distros as competing package management systems (like KDE/Gnome are competing desktop environments). The Linux community only receives de facto standards; that is, standards the community itself decides on. That lynch mob swarming you are not those concerned about stifling choice. They are the n% of the community who's 'standard' you didn't choose.
i was under the impression that symlinks and versioning (e.g. libxml2.so && libxml2.so.2 -> libxml2.so.2.6.12 coexisting in/usr/lib) had mitigated (if not eliminated).so hell. Are people still having this trouble?
Slashdot Mirror
A tidbit to get you started on the trouble: http://en.wikipedia.org/wiki/Volusia_error
You present bandwidth as a rebuttal to the first bit latency problem original poster, yet bandwidth and latency (though related) are different animals.
/ bandwidth-latency-1.html
For example, take your Socket939/754 example. Lets take a 2.0 GHz core (for simplicity) and SDRAM with a pretty good latency of 2 (HTT) cycles. This CPU is running 10x as fast as memory, stock. So (assuming HTT is idle), 1 HTT cycle to send request, 2 cycles to service the request in memory, 1 cycle to bring it back to the CPU. Ignoring the cost of traveling the on-die cache hierarchy, and recalling the CPU is running 10 times the HTT buss, that is at least a 40 instruction bubble waiting on core. Note that this delay is entirely independent of 754/939 bandwidth.
Put two cores on a chip, and suddenly there is contention on the HTT buss (unless your friendly motherboard manufacturer happens to give you independent memory banks, you populate them, and your OS is NUMA aware). Granted, if you slow down the CPU clock there are less wasted CPU cycles, but again that has nothing to do with bandwidth--due to the CPU running at a multiple of the HTT buss (and memory), memory bandwidth remains independent.
You can find a reasonably good primer on these subjects at http://arstechnica.com/paedia/b/bandwidth-latency
The solution to maintaining packages on Linux in general is the distribution. Put yet another way, when you speak of Linux in general (kernel + GNU utilities + *sh + / + stdlibs + user_programs) you can only practically mean the various distros. Now, with that in mind, allow me to restate your question: is the distribution solution creating documentation/ease-of-use hell? Probably.
/usr/lib) had mitigated (if not eliminated) .so hell. Are people still having this trouble?
Try to think of the various distros as competing package management systems (like KDE/Gnome are competing desktop environments). The Linux community only receives de facto standards; that is, standards the community itself decides on. That lynch mob swarming you are not those concerned about stifling choice. They are the n% of the community who's 'standard' you didn't choose.
i was under the impression that symlinks and versioning (e.g. libxml2.so && libxml2.so.2 -> libxml2.so.2.6.12 coexisting in