From Operators to Operating Systems--论文代写范文精选

这样做是通过编写程序来执行操作,而编译器的诞生使成本降低成为可能，从历史上看,这是机械化过程导致的现代操作系统。此外,运营商开始准备工作,按计划执行。下面的essay代写范文进行详述。

Abstract
The ENIAC and the other early computational machines, which are implementations of the Von Neumann’s architecture, rely on human operators interacting with the machinery. These operators were responsible for coding the input i and for interpreting the output o according to the goal g. Also, engineers first and programmers later—from the 1950s onward—were responsible to write the program p deputed to process the data. Operators were not required to understand the internals of their computing machines, while programmers had to do so, thus different roles, or inforgs in our terminology, exist, each role with distinct competences. In particular, operators were expected to interact with some hidden information provided by programmers. As machines were expensive, and a number of highly trained people were needed to operate them, both as programmers and as operators, there was a need to reduce the amount of persons and, consequently, the costs. 

This was done by writing programs to perform part of the duties of operators, a fact made possible by the birth of compilers: historically, this was the start of the mechanisation process which lead to the construction of the modern operating systems (Ceruzzi, 2003; Donovan, 1974). Also, it was a waste of money to keep a machine idle when programmers and operators were preparing an execution. So, operators started to prepare ‘jobs’ for the machine, which were scheduled to execute one after the other with no pauses—it was called ‘batch execution’. In this activity, they were assisted by the machine, which was able to take a job from a queue, execute it, signal that the output was finished and remove the job from the queue, restarting the execution cycle. Soon, it was clear that machines were spending a large amount of time accessing devices and disks (or other storage devices). 

This was perceived as inefficient, as the machine as a whole was working, although all but one part of it were waiting. It would have been much more interesting and economical to use all the parts of the machine all the time to their maximum performance. So, special ‘job control languages’ were devoted to describe the scheduling task and their masters were the operators. But it was evident that operators, being human, were too slow to manage the interleaved executions of many processes. Hence, the need for an appropriate program became clear: its input was a series of jobs (pairs of programs and corresponding inputs), while its output was the results of the executions of the jobs. This special program had to find the optimal usage of the machine’s resources and devices and, at the same time, to ensure that all the jobs were eventually executed. 

This kind of programs were the first operating systems. The modern concept of ‘operating system’ (Donovan, 1974) can be seen as a new LoA: some tasks are hidden in an abstract machine operating on the computer system so that humans can forget them instead of manually perform their task as living operators: information gets hidden, without being lost. The hidden information is how to operate devices and how to optimally schedule computational tasks. The side effect of operating systems was that the user could think to processes as being executed in parallel, as if each of them had a machine for its own purposes. Computing machineries were fast enough to convey the impression of parallel executions, even if no more than one process was really executed at any moment in time. These systems were called multitasking systems. If we want to model multitasking systems, we must recognise two different abstractions: in the first place, we have a single physical machine M ‘executing’ a number of ‘parallel’ jobs. 

This abstraction, that enables us to use the quotes in the previous sentence, is the operating system. In the second place, each job is conceived to work inside an environment where the machine is fully dedicated to its execution. Again, this ability to isolate jobs from undesired interactions is the result of the operating system’s action. But these abstractions are essential to write correct programs: programmers can safely assume to have the machine for their own purposes, without taking care of the possible interactions with other programs. The resulting model of computation is depicted in Figure 2: it looks complex because we have all the abstractions at work—it is possible to simplify the diagram by cancelling arrows which can be obtained by composition, but they are useful in the following explanation. If we consider the top and the bottom lines, they form the physical von Neumann’s inforg, as previously described. This inforg operates on the set of goals g, inputs i and programs p, so to produce the output o. 

In fact, if each goal is considered individually, focusing on just one of them, gk , it produces the internal (Figure 3) Von Neumann’s inforg, which is the programmer’s abstraction, that operates on the Mk ‘virtual machine’, eventually producing the ok result. The ‘parallel execution’ of the set of jobs is the picture in the mind of the operative system’s designer, see Figure 4: in fact, he is part of an inforg which can be appropriately retrieved by composing projection arrows – i.e., the πs in the diagram. As before, projections take care of hiding most of the work behind the scenes of the operating system. Obviously, the concrete machine is still present, as the reader can see in Figure 5, and it wraps the preceding abstractions via appropriate projections. In this respect, it is interesting to notice that projections take care of ‘implementing’ the relations among the various LoAs, an intuition we borrowed from Floridi. In the diagrams, the dashed and double dotted arrows refer to interpretations—the act of matching the output of a machine with the corresponding goal; dotted arrows show the part of the multitasking system that are hidden in the considered inforg.

Operating system, which takes care of automatically dividing the output according to the process which produced it. This is an example of LoO. Historically, soon after the development of the first multitasking operating systems, processes were allowed to interact. This behaviour requires another level of abstraction, which is the notion of application. This is best illustrated by an example: in Unix, printing a document requires to invoke a command, lpr, which takes the document as an argument. This program does not really print anything: it just prepares the document for printing and put it on a queue; another process, lpd, periodically takes the document on the top of the queue and prints it. 

This pair of commands forms an application: the Unix printing system. In our picture, applications are modelled by introducing another pair of LoAs in the previous diagram—as done in Figure 6, which models groups of processes working together as a unit, as if they were a unique program in a standing alone Von Neumann’s architecture. In the example above, if we do not introduce process interaction, the output of the process lpr (documents prepared for printing) could not be the input of the process lpd (printing queue) and hence its output would be null, as nobody had populated the queue, which is not what the user is expected to obtain by his goal, i.e., document printing. Apart the complex technical appearance, it is worth remarking that the diagrams are obtained as interleaved composition of Von Neumann’s architectures. For this reason, we have shown with some details the multitasking example, the dotted arrows meaning the hidden relations. The interested reader can do the same with Figure 6, which is again a collection of abstract VNMs working together.

Internet and Distributed Applications 
There is no doubt that Internet changed the way in which we perceive applications: after the development of its infrastructure, the potential to write distributed applications was at hand. In fact, most Internet structural services are distributed applications, e.g., the Domain Name Server (DNS) system is a distributed database to convert numerical addresses into names and vice versa. After the deployment of the World Wide Web (WWW) in the early 1990s, whose architecture is a traditional client-server platform, not essentially different from a terminalmainframe system in the 1960s except for being distributed over the network, Internet became almost a synonymous of the Web, at least in popular culture, a usage reinforced in advertising (Berners-Lee and Fischietti, 2000). As far as we are concerned, Internet applications are a natural evolution of a concurrent multitasking system, where the background is no more a single computing machinery, but a network of intercommunicating computers. So, in abstract terms, the architecture of the whole Internet can be depicted as in Figure 7. It is the same picture as Figure 6, except that the bottom line2 , the concrete implementing machine, has disappeared. This behaviour is clear: the concrete level of Internet is the set of computers which are interconnected, and they have not to be simulated, as we did in a multitasking environment. In fact, a single computer can simulate—at least in principle—the entire Internet. This fact is due to the associative and commutative properties of the product, modulo isomorphisms. Again, we see here the power of rigorous abstraction as a driving force to system design.（essay代写)

51Due网站原创范文除特殊说明外一切图文著作权归51Due所有；未经51Due官方授权谢绝任何用途转载或刊发于媒体。如发生侵犯著作权现象，51Due保留一切法律追诉权。
更多essay代写范文欢迎访问我们主页 www.51due.com 当然有essay代写需求可以和我们24小时在线客服 QQ:800020041 联系交流。-X（essay代写)