------------------------------------------------------------------------------ Import The work presented by this paper looks classic. The main section describes research results known by the biggest part of our community, but the rest of it covers all the resent progress in the area and describes the implementations that several research and development teams have experimented with. Novelty The observations made by the authors are not novel. They describe the improvements accomplished by the latest implementations that adopt different approaches to the same problem. Quality The observations made by the authors for the existing solutions in their problem are sound. Overall This paper should be accepted. It is a good overview of the current research in this particular subarea. ------------------------------------------------------------------------------ I enjoyed reading this paper. You explained the design choices in select operating systems in good detail. I feel that is it important to make you aware that the comments I am making below are in part due to the familiarity of the subject your group chose to write about and more importantly, due to the eloquent manner in which you expressed your thoughts. 1. The paper should have made a note about other important aspects of task management such as security, resource sharing, etc that were not addressed in the paper. 2. The unintentional use of Sprite as a benchmark should have been avoided. Perhaps it was a result of your better understanding of the Sprite OS than say, Plan 9. 3. Section 3.2 was a comparison of process migration between MOSIX and Sprite instead of a discussion on trade-off for transparency, residual dependencies, performance, and complexity. 4. Section 4 (Improvements) did not discuss applicability to the attributes and techniques of task management and operating systems discussed. 5. The paper would have been more effective in its arguments had you cited actual time costs (when discussing performance) instead of the use of ‘high’ and ‘substantial’ as a measure of performance. 6. Adopt gender-sensitive sentence structure instead of using the pronoun ‘he.’ One way around this is by using the plural form of the pronoun (they instead of he) and converting the sentence into its plural form. 7. Spell-check the final draft to catch trivial but costly typos! Overall, this well-structured paper. I grade it as follows: [ omitted ] ------------------------------------------------------------------------------ I have following questions in mind after reading the paper, The definition of Distributed system is not clear, just mainly distributed the processes to any free processors? or the processes can be combined to be one BIG task that must cooperate via distributed system. i.e. 10 processes/threads onto 10 processors process in parallel then come back with answers for some 'mother' process which invoke these 10 processes/threads. The goal for the paper (Distributed Systems) is clear, "keep all resources busy". However, in the paper, its mainly focused on, how to spread the processes onto 'idle' processors transparently and with low overhead. But what about the 'parallel' processes that can be work together? say, a big computing process split into 10 small parts, how is the task manager take care these kind of cases to improve the efficiency? afterall, that's what make distributed system attractive. (more throughputs) There aren't any performance table of any sort that would prove that with these Distributed Operating Systems are more efficient than traditional (and what are the traditional 'distributed' system looks like?). How big are the overheads of 'finding' the idle CPUs, and how effective is the algorithm? Finally, this is a interesting paper that includes lots of approaches to make distributed system work in more natural way for programmars and comparing among them, but what is the exact problem these approaches is attacking? Only Keeping All Cpu busy? or easier for programmar to program without worry about details of distributed system? Or make program run 'faster' by transparently migrate to free processors instead of waiting in the queue? ------------------------------------------------------------------------------ This is okay paper overall. It needs some work on the english but that is totally excusable. The major problem with this paper in my opinion is that there is no flow at all. There needs to be some coherency of thought through the paper (not just cut and paste). This could be be acomplished by adding in some transistional sentences. The best part of the paper by far was the conclution, which was quite well done. If the paper as a whole had been as well thought out as the conclution it would have been great. Some of the problems with the paper are: - orginization could use some work. - explain more about what it is to "evict" a process, does it remove it from the machine or is it put into the backround? Ramification of this? - more critique would be good. - the clouds paper seemed a bit out of place unless there is more contrasting. - why does nobody support memory mapped i/o? ------------------------------------------------------------------------------ Comments: 1) The main part of this paper is in this routine structure: Some concepts or issues are brought up, and then how they are implemented in each project is briefly introduced. No much analysis or comparison is there. The authors should give more about their own ideas of those projects and approaches, not just listing what they have read. 2) In section 2.2, although the title is "Remote Execution", a lot of time is spent on "process migration". You should notice that "Remote Execution" and "process migration" are two distinct concepts. The latter one means a process can move from one host to another in the middle of its execution, while the first one doesn't have such requirement. However, in this section, these two concepts are somewhat mixed up. 3) In section 2.5, "load information and control manager", only Sprite and MOSIX are discussed. How about the other systems? 4) In section 3, the comparisons are only limited within each project itself. Only Sprite and MOSIX are compared in 3.2. I think in those projects' own papers, these comparisons should have been presented already. What we need in this survey paper is more than that. There ought to be some comparisons among projects. 5) The 4th section discussed some further improvements of these systems. However, it seems a little "discrete" to put almost two pages in that section, since the content isn't quite related to first three parts of this paper. A brief introduction of those ideas might be better. ------------------------------------------------------------------------------ 1. The last paragraph of section 2.1 mentions a system called "Alpha" that is never mentioned again. 2. Section 2.2 says that Condor only supports remote execution. This is not true. Condor does support process migration. 3. It would have been helpful to have high-level summaries of the systems under consideration. Also, please mention which systems are under consideration in the Introduction. 4. The organization seems jittery. The discussion of the bulleted topics should follow in the same order in which the bullets are listed. 5. The conclusions are not obvious from the discussion. 6. Please proofread for grammar and use a spell check program (ispell). ------------------------------------------------------------------------------ The main problem I have is that your main points seem to be about migration. The other topics you present are threads and remote execution both of which are contrasted to task migration. This seemed to be the big differnce between the paradigms you present. Each of the other topics was often placed in terms of how it was needed to support one or the other paradigm. I feel therefor that your Abstract, Introduction, and Conclusion should have been focused on this. As it currently stands they don't even talk about it. There where some other small problems which brought it's quality down. An exsample is the large white space which follows the word 'Maintaining' in the last paragraph on page 3. ------------------------------------------------------------------------------ About the abstract, it do not properly present the paper contents. Please rephrase the first sentence in the abstract, if possible. Section 1, the order of techniques and attribute would better agree with the appearance of subsection in section 2, like 1-3-4-2-5. The tradeoff comparisons in section 3 introduce many special terms used in different systems. Please unify the terms to avoid confusing readers. Section 4, the further improvements are actually the attributes 4 and 5 in section 2. The readers in this topic may have more interests in the applicability to systems mentioned in section 3. In the conclusion, the claim for predicting MOSIX as the one most likely to be successful is not strong enough. Many other factors like hardware trends, portability, and capability may affect the choice of systems.