Douglas Roberts wrote: > It addresses fault tolerance and dynamic load balancing requirements > which become incredibly important when computing on this scale. I'd much rather have checkpointing and load balancing done at the operating system level, like by Linux kernel features (e.g. http://kvm.qumranet.com/kvmwiki/Migration), Then all the queuing system would have to do is send suspend/resume signals to processes -- users could assume processes to persist until killed or finished. Further, any program would be supported. I find that fitting random jobs within queueing system resource constraints is a bigger productivity sink than jobs actually failing from bugs or system problems. The stakes get higher as the job size gets bigger because you are waiting longer to get scheduled and once you do you can still absorb a lot of system resources for a job that ultimately does not complete the way you want (which in turn increases the wait for future jobs).
It's just nuts this hasn't been addressed properly because the costs are so high for users (not to mention energy usage). > It also supports OO software development methodology, which in spite > of a few dissenting voices on this list is generally viewed as a > superior environment for software development (to include ABM systems) > than the old, hoary procedural environments. OO is just one methodology. Not even everyone that studies typing systems would say they are doing OOP research. E.g. some don't really fit at all, like linear typing which lends itself more to functional programming. And there are other whole viable ways to approach modeling, e.g. combinatory logic. It's a false choice between OOP and procedural programming. ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
