Distributed operating system: Difference between revisions

Revision as of 10:37, 7 April 2010

Revision as of 10:34, 8 April 2010

Line 33:

<br /><br />

}}

{| class="wikitable" cellpadding="0" style="border:1.0px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|35px]]

|style="background:#DFFFFF;width:500px;"|'''Again, restructured Lead/Intro sections prepatory to implementing the "body"'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 10:34, 8 April 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.0px solid black;color:#000;margin-left:18em;"

|-

Line 93 ⟶ 98:

<!-- A '''Distributed operating system''' is the minimal subset of software within a distributed system, which -- considered collectively -- provide all operating system services required to support higher-level components in empowering and maintaining the system. -->

A '''Distributed operating system''' is the compositelogical aggregatecumulative aggregation of operating system software in a Distributed System. This software – considered collectively – supports the concerted operation of the system’s independent, autonomous, and disseminated computational units (Unit). Each discrete unit contains an allocation of operating system software, which generally consists of two distinct portions. One portion, the Kernel, is a distinct minimal subset of system software – usually common to all units – devoted to the controlmanagement of a unit’s underlying hardware resources and devices;. it The kernel also supports the unit’s remaining portion of system software. A unit’s

This remaining system software, at the localunit (Unit Operating System), is an ad-hoc collection of discrete system software components, formulated to empower thea unit’s operation. The kernel and the localunit operating system work collaborativelytogether to ensure eachan individual unit's cooperative and constructive interaction with other distributed system units, and the individual unit’s successful contribution to the wholepolicies Systemand expectations of the total system. This collective cooperation, sustained at the operating system level, gives the distributed system its unified appearance.

== Overview ==

As a minimal software composition, a distributed operating system Kernel is often referred to as a Microkernel. The minimal nature of the kernel strongly enhances a distributed system’s modular potential. The kernelskernel’s ubiquitous quality also supports greater opportunity for system flexibility and scalability. Minimal by design, the microkernel usually contains only mechanisms and services which otherwise, if removed, would render thea unit and its system incapable. The microkernel primarily provides lower-level resource, process, communication, and I/O management. These services are made possible by the exposure of a comprehensive, yet concise array of primitive mechanisms. Through these primitives, the microkernel supports the higher-level functionality of its local operating system. This clear distinction between the microkernel and local operating system offers a clean separation of mechanism and policy; the difference between what is done, and how or why it is done, respectively. This policy-mechanism schism is critical to a distributed operating system’s potential for ubiquity beyond the purest unit infrastructure homogeneity.

{{Userbox

|border-c=#000

Line 106 ⟶ 117:

|info=A Diagram will be furnished to assist in illustration of this idea.

|float = right}}

A unit’s operating system is primarilylargely characterized by its composite nature. ThisThe composition of this system software composition is dictated mainly by the unit’s responsibilities to the overall system. These responsibilities focus principally on the allocation, management, and disposition of system processes and resources in fulfillment of global system policy. The unit operating system participates largelyglobally throughby means of the kernel’s communication services, and the passing of messages in fulfillment of its system-wide responsibilitiesobligations. This multi-level collaboration internally between a kernel and a unit operating system, and in turn between thedisparate units in a distributed system, is the key functionfunctional space of the distributed operating system. However, this function comes at a very high price.

As a minimal software composition, a distributed operating system Kernel is often referred to as a Microkernel. The minimal nature of the kernel strongly enhances modular potential. The kernels ubiquitous quality also supports greater opportunity for system flexibility and scalability. Minimal by design, the microkernel usually contains only mechanisms and services which otherwise removed, would render the system incapable. The microkernel primarily provides lower-level resource, process, communication, and I/O management. These services are made possible by the exposure of a comprehensive, yet concise array of primitive mechanisms. Through these primitives, the microkernel supports the higher-level functionality of its local operating system. This clear distinction between the microkernel and local operating system offers a clean separation of mechanism and policy; the difference between what is done, and how or why it is done, respectively.

The logical price of realizing a distributed system – including its operating system --– must isbe calculated in terms of overcoming vast amounts of complexity on many levels, and in many areas. This calculation also includes the depth, breadth, and breadthrange of design investment and architectural planning required in achieving even modest levels of success. These development considerations are critical and unforgiving, inas that anthe overwhelming majority of a distributed system’s architectural,details design,require andan implementationinordinate detailscompleteness areof requiredunderstanding from the start. AAs hugean amountaid ofin researchthis workeffort, hasmost beenrely donestrongly inon the pastimmense amount of documented experience and research accomplished towards distributed computing which exists, and continues today.

A unit’s operating system is primarily characterized by its composite nature. This system software composition is dictated mainly by the unit’s responsibilities to the overall system. These responsibilities focus principally on the allocation, management, and disposition of system processes and resources in fulfillment of global system policy. The unit operating system participates largely through the kernel’s communication services in fulfillment of its system-wide responsibilities. This multi-level collaboration between a kernel and a unit operating system, and in turn between the units in a distributed system, is the key function of the distributed operating system. However, this function comes at a very high price.

<br />

{{Userbox

Line 122 ⟶ 133:

|info=A Diagram will be furnished to assist in illustration of this idea.

|float = right}}

Many notable experts look to the early 1970s for the earliest distributed systems, complete by definition and capable of being considered wholly. Research and experimentation efforts began in earnest in the mid to late-1970s and continued into the early 1990s, with some implementations achieving modest commercial success. The subject of distributed systems however, has a much richer historical perspective when considering severally some of the individual primordial strides towards distributed computing. There are several instances of fundamental and pioneering implementations of primitive distributed systems and component concepts dating back to the early 1950s. Looking to the modern distributed system and its future, the accelerating proliferation of multiprocessor systems and multi-core processors has led to a re-emergence of the distributed system concept. The inherent challenges in many-core and multiprocessor science has led to an enormous increase in distributed system related research. Many of these research efforts investigate and describe plausible paradigms for the future of distributed computing.

The logical price of distributed system – including its operating system -- is calculated in terms of overcoming vast amounts of complexity on many levels, and in many areas. This calculation also includes the depth and breadth of design investment and architectural planning required in achieving even modest levels of success. These development considerations are critical and unforgiving in that an overwhelming majority of a distributed system’s architectural, design, and implementation details are required from the start. A huge amount of research work has been done in the past towards distributed computing, and continues today.

While the research and implementation efforts came to initial commercial success in the late ‘70s through the mid-‘80s, the distributed system has a much richer historical perspective. There are several instances of interesting, innovative, and almost radical implementations of distributed system components dating back to the mid-‘50s. The emergence and proliferation of multiprocessor systems and multi-core processors has led to a re-emergence of the distributed system, and an enormous increase in quality research. Many of these research papers describe plausible paradigms for the future of distributed computing.

== Description ==

Line 145 ⟶ 154:

A distributed operating system, illustrated in a similar fashion, would be a container suggesting [[Microkernel#Essential components and minimality|minimal operating system functionality and scope]]. This container would completely cover all disseminated hardware resources, defining the system-level. The container would extend across the system, supporting a layer of modular software components existing in the user-level. These software components supplement the distributed system with a configurable set of added services, usually integrated within the monolithic operating system (and the system-level). This division of minimal system-level function from additional user-level modular services provides a “[[separation of mechanism and policy]].” Mechanism and policy can be simply interpreted as "how something is done" versus "why something is done," respectively. Achieving this separation allows for an exceptionally loosely coupled, flexible, and scalable distributed system.

== Distributed computing models ==

== Overview ==

An approach to describing the unique nature of DOS

=== The nature of distribution ===

The unique nature of the Distributed operating system is both subtle and complex. A distributed operating system’s hardware infrastructure elements are not centralized, that is the elements do not have a tight proximity to one another at a single ___location. A given distributed operating system’s structure elements could reside in various rooms within a building, or in various buildings around the world. This geographically spatial dissemination defines its decentralization; however, the distributed operating system is a distributed system, not simply decentralized.

This distinction is the source of the subtlety and complexity. While decentralized systems and distributed systems are both spatially diverse, it is the specific manner of and relative degree in linkage between the elements, or nodes in the systems that differentiate the two. In the case of these two types of operating system, these linkages are the lines of [[Inter-process communication|communication]] between the nodes of the system.

=== Three basic distributions ===

To better illustrate this point, let us more closely reflect upon these three system [[Software architecture|architectures]]; centralized, decentralized, and distributed. In this examination, we will consider three tightly-related aspects of their structure: organization, connection, and control. Organization will describe physical arrangement characteristics, connection will involve associations among constituent structural entities, and control will correlate the manner, necessity, and rationale of the earlier considerations.

<br />

Line 166 ⟶ 176:

|info=Multiple Diagrams<br /><br />will be furnished to assist<br /><br />in illustration of these ideas.

|float = right}}

==== Organization ====

Firstly, we consider the subject of organization. A centralized system is organized most simply, basically one real level of structure and all constituent element’s highly influenced by and ultimately dependent upon this organization. The Decentralized system is a more [[Federation|federated structure]], multiple levels where subsets of a system’s entities unite, these entity collections in turn uniting at higher levels, in the direction of and culminating at the central element. The distributed system has no discernable or necessary levels; it is purely an autonomous collection of discrete elements.

==== Connection ====

Association linkages between elements will be the second consideration. In each case, physical association is inextricably linked (or not), to conceptual organization. The centralized system has its constituent members directly united to a central entity. One could conceptualize holding a bunch of [[balloon|balloons]] -- each on a string, -- with the hand being the central figure. A decentralized system incorporates a single-step direct, or multi-step indirect path between any given constituent element and the central entity. This can be understood by thinking of a [[Org_chart#Example_of_an_organizational_chart|corporate organizational chart]], the first level connecting directly, and lower levels connecting indirectly through successively higher levels (no lateral “dotted” lines). Finally, the distributed system has no inherent pattern; direct and indirect connections are possible between any two given elements of the system. Think of the 1970’s phenomena of “[[string art]],” a [[spirograph]] drawing, a [[spider web|spider’s web]], or the [[Interstate Highway System]] between U.S. cities.

==== Control ====

Notice, that the centralized and decentralized systems have distinctly directed flows of connection towards the central entity, while the distributed system is in no way influenced specifically by virtue of its organization. This is the pivotal notion of the third consideration. What correlations exist between a system’s organization, and its associations? In all three cases, it is an extremely delicate balance between the administration of processes, and the scope and extensibility of those processes; in essence is about the sphere of control. Simply put, in the directed systems there is more control, easing administration of processes, but constraining their possible scope. On the other hand, the distributed system is much more difficult to control, but is effectively limited in extensible scope only by the capabilities of that control. The associations of the distributed system conform to the needs of its processes, and not inherently in any way to its organizational configuration. There are key collections of extended distributed operating system processes discussed later in this article.

=== Conclusions ===

Lastly, as to the nature of the distributed system, someit expertshas statebeen stated that thea distributed operating system is not necessarily an operating system at all; but justsimply a"is" the distributed system,. becauseThis ofview is commonly justified by pointing to the attentiondeep requiredand ininextricable maintenanceintegration ofinto the distributed system. ThisThe author,absolute and bysingular extensionfocus thisof article,sustaining willand maintainmaintenance of the operating system statusis ofalso used as rationale. However, it is important to remember the separation of mechanism and policy. The distributed operating system, byand bothits observationmechanism is not affected by integration, and vacuousno amount of focus on providing this mechanism changes the responsibility of policy at the distributed system prooflevel. As mentioned earlier, a [[Square_(geometry)#Other_facts|square]] is a [[rectangle]]; and no level of effort on its behalf required to maintain four equivalent dimensions affects that fact.

== Architectural features ==