AFAIK, most OSes shut down the MMU in kernel mode - linux for instance. Address space remaps are costly because of a lot of explicit, non-cached memory accesses. Though I don't see why some more PAE bits can't replace 64-bit mode - you just need an IOMMU. And possibly hardware virtualization with a simple hypervizor. Though that might actually be faster, considering all the savings you make from pointers, not to mention that if the MMU and wide load/store instructions trap to the hypervizor directly - the context switch cost is the same as calling the OS.
The second they try something smart - someone is gonna pull a HT interconnected chip and screw them over. Though the cache coherency protocol may be an issue. OTOH, 4x1Gbps backplane Ethernet, is standard, and wouldn't be too expensive to slap between chips, and let Xen in cluster mode handle the cache coherency. Beowulf SSI in a box. Sounds nice.
Liquid salt heat tanks. Oh, and the materials for solar thermal are much more resilient due to their very nature. The mirrors would be practically eternal, and the number of collectors would be magnitudes smaller. Oh, and funny how incandescent lights burn out from evaporation way before fatigue sets in. Not to mention the many car engines that get started every day for many years.
ObjC didn't have GC until recently, still doesn't have compiler memory protection. Oh, and, what do you mean by win2k? The look? Sorry, themes have been invented for a long time, and frankly I (and many others) don't mind the look. You thin Python would have never taken off if it hadn't been for Apple.
Re:Which streams does this head end carry?
on
Got (Buffer) Bloat?
·
· Score: 1
Shared slot best effort isochronous, per client. Eat the set-up/tear-down cost. Screw the abuser on bandwidth - cap isochronous transfers at sub-link speed, inversely proportional to network load. That would not upset multiple transfers, or multiple backends - only the idiots using that for torrents.
Re:Keeping big buffers but managing them better
on
Got (Buffer) Bloat?
·
· Score: 1
"verified legitimate voice gateways" are anti-competitive practice, and port based anything is discrimination against destination and source, not to mention that NAT would screw up that scheme totally.
Re:Keeping big buffers but managing them better
on
Got (Buffer) Bloat?
·
· Score: 1
Multiple smaller ques would be more efficient.
Re:Keeping big buffers but managing them better
on
Got (Buffer) Bloat?
·
· Score: 1
QoS policies can be written neutral, or at least reasonably so, provider abuse is a market problem, not a technical one. Also, a genetic timing algorithm (coming to all FLOSS apps in 3...2...1...), can and will screw up anything at all that tries to do something sneakier than bandwidth*latency*jitter=const, so let them shoot themselves in the foot. Unless they do true destination based scheduling, they won't be able to screw with anything. But QoS can't save you from bufferbloat. ECN can. Simple standard solution to all of bufferbloats' problems.
There is no protection against stupidity - death by meth or alcohol - what's the difference? Lack of means is a valid argument - but that is brought on by the establishment, and not characteristic of homebrew drugs, in, and of themselves.
People are too stupid and lazy to handle the fact that the universe doesn't tick at their rhythm only - I think it's a question of ego. Personally, I'd like to see Hex time or similar come in to general use - the current peanut gallery of radixes is infuriating.
What's wrong with Node and Hadoop? They seem to have reasonable use cases. Social networking is a great money maker if you are handy with data mining, though it does seem a fad, somewhat.
You got me - though I've never actually heard of the MMU being used in the kernel.
Neither do neurons and synapses.
Paging is shutdown. The MMU does paging. The segmentation mechanism is separate.
If only more people ditched MySQL, nobody would bother offering it, and would set some reasonable prices on VPS hosting. Oh, wait... http://www.postgresql.org/support/professional_hosting_northamerica
SSI can be done in the system firmware/hypervizor/kernel. Linux supports it.
AFAIK, most OSes shut down the MMU in kernel mode - linux for instance. Address space remaps are costly because of a lot of explicit, non-cached memory accesses. Though I don't see why some more PAE bits can't replace 64-bit mode - you just need an IOMMU. And possibly hardware virtualization with a simple hypervizor. Though that might actually be faster, considering all the savings you make from pointers, not to mention that if the MMU and wide load/store instructions trap to the hypervizor directly - the context switch cost is the same as calling the OS.
I can't imagine a better workaround than dropping MySQL.
Raytracing.
The second they try something smart - someone is gonna pull a HT interconnected chip and screw them over. Though the cache coherency protocol may be an issue. OTOH, 4x1Gbps backplane Ethernet, is standard, and wouldn't be too expensive to slap between chips, and let Xen in cluster mode handle the cache coherency. Beowulf SSI in a box. Sounds nice.
Thermoacoustic is more elegant and less maintenance.
Liquid salt heat tanks. Oh, and the materials for solar thermal are much more resilient due to their very nature. The mirrors would be practically eternal, and the number of collectors would be magnitudes smaller. Oh, and funny how incandescent lights burn out from evaporation way before fatigue sets in. Not to mention the many car engines that get started every day for many years.
Nothing serious - shift development to Direct3D state tracker in Gallium3D.
PDF includes a non-Turing complete PS implementation.
ObjC didn't have GC until recently, still doesn't have compiler memory protection. Oh, and, what do you mean by win2k? The look? Sorry, themes have been invented for a long time, and frankly I (and many others) don't mind the look. You thin Python would have never taken off if it hadn't been for Apple.
Shared slot best effort isochronous, per client. Eat the set-up/tear-down cost. Screw the abuser on bandwidth - cap isochronous transfers at sub-link speed, inversely proportional to network load. That would not upset multiple transfers, or multiple backends - only the idiots using that for torrents.
It's called ECN and nobody is arsed to use it.
"verified legitimate voice gateways" are anti-competitive practice, and port based anything is discrimination against destination and source, not to mention that NAT would screw up that scheme totally.
Multiple smaller ques would be more efficient.
QoS policies can be written neutral, or at least reasonably so, provider abuse is a market problem, not a technical one. Also, a genetic timing algorithm (coming to all FLOSS apps in 3...2...1...), can and will screw up anything at all that tries to do something sneakier than bandwidth*latency*jitter=const, so let them shoot themselves in the foot. Unless they do true destination based scheduling, they won't be able to screw with anything. But QoS can't save you from bufferbloat. ECN can. Simple standard solution to all of bufferbloats' problems.
There is no protection against stupidity - death by meth or alcohol - what's the difference?
Lack of means is a valid argument - but that is brought on by the establishment, and not characteristic of homebrew drugs, in, and of themselves.
EFI has a legacy BIOS mode, Boot Camp just turns it on when appropriate.
It's not called a BIOS. A BIOS is a system firmware standard, much as (U)EFI and Open Firmware is.
I think it's sad - we are like monkeys - always experimenting, though as if never learning...
People are too stupid and lazy to handle the fact that the universe doesn't tick at their rhythm only - I think it's a question of ego.
Personally, I'd like to see Hex time or similar come in to general use - the current peanut gallery of radixes is infuriating.
What's wrong with Node and Hadoop? They seem to have reasonable use cases. Social networking is a great money maker if you are handy with data mining, though it does seem a fad, somewhat.