Abstract: In one general aspect, various embodiments of the present invention can include a motorized surgical cutting and fastening instrument having a drive shaft, a motor selectively engageable with the drive shaft, and a manual return mechanism configured to operably disengage the motor from the drive shaft and retract the drive shaft. In at least one embodiment, a surgeon, or other operator of the surgical instrument, can utilize the manual return mechanism to retract the drive shaft after it has been advanced, especially when the motor, or a power source supplying the motor, has failed or is otherwise unable to provide a force sufficient to retract the drive shaft.

Abstract: A tissue thickness compensator may generally comprise a compressible core comprising a plurality of movable particles, and a wrap surrounding the compressible core. The plurality of movable particles may comprise at least one medicament. A tissue thickness compensator may generally comprise a compressible core comprising a plurality of crushable particles, and a wrap surrounding the compressible core. The plurality of crushable particles may comprise at least one medicament. The compressible core may comprise a material selected from a group consisting of a biocompatible material. The wrap may comprise a material selected from a group consisting of a biocompatible material. Articles of manufacture comprising the tissue thickness compensator and methods of making and using the tissue thickness compensator are also described.

Abstract: A layered composite boot device, and a corresponding layered composite file system, can be implemented by a boot manager. Requests directed to the layered composite boot device and file system, can be serviced from a primary device and file system that are encapsulated by the layered composite boot device and file system. The primary device and file system can correspond to a virtualized file system within a container environment, thereby enabling changes within the container environment to affect early stages of operating system booting in the container environment. Should such requests not be serviceable from the primary layers, the composite device and file system can comprise secondary layers that can correspond to a container host connection and the host file system, providing fallback to existing data if changes within the container environment were not made, thereby enabling booting to proceed in a traditional manner.

Abstract: A layered composite boot device, and a corresponding layered composite file system, can be implemented by a boot manager. Requests directed to the layered composite boot device and file system, can be serviced from a primary device and file system that are encapsulated by the layered composite boot device and file system. The primary device and file system can correspond to a virtualized file system within a container environment, thereby enabling changes within the container environment to affect early stages of operating system booting in the container environment. Should such requests not be serviceable from the primary layers, the composite device and file system can comprise secondary layers that can correspond to a container host connection and the host file system, providing fallback to existing data if changes within the container environment were not made, thereby enabling booting to proceed in a traditional manner.

Abstract: A fine-grain selectable partially privileged container virtual computing environment provides a vehicle by which processes that are directed to modifying specific aspects of a host computing environment can be delivered to, and executed upon, the host computing environment while simultaneously maintaining the advantageous and desirable protections and isolations between the remaining aspects of the host computing environment and the partially privileged container computing environment. Such partial privilege is provided based upon directly or indirectly delineated actions that are allowed to be undertaken on the host computing environment by processes executing within the partially privileged container virtual computing environment and actions which are not allowed.

Abstract: A layered composite boot device, and a corresponding layered composite file system, can be implemented by a boot manager. Requests directed to the layered composite boot device and file system, can be serviced from a primary device and file system that are encapsulated by the layered composite boot device and file system. The primary device and file system can correspond to a virtualized file system within a container environment, thereby enabling changes within the container environment to affect early stages of operating system booting in the container environment. Should such requests not be serviceable from the primary layers, the composite device and file system can comprise secondary layers that can correspond to a container host connection and the host file system, providing fallback to existing data if changes within the container environment were not made, thereby enabling booting to proceed in a traditional manner.

Abstract: A host operating system running on a computing device monitors network communications for the computing device to identify network resources that are requested by the computing device. The host operating system compares requested network resources against security policies to determine if the requested network resources are trusted. When an untrusted network resource is identified, the host operating system accesses the untrusted network resource within a container that is isolated from the host operating system kernel using techniques discussed herein. By restricting access to untrusted network resources to isolated containers, the host operating system is protected from even kernel-level attacks or infections that may result from an untrusted network resource.

Abstract: Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.

Abstract: Different containers are used for different usage sessions, a container referring to a virtualization layer for a computing device and used for isolation as well as hardware resource partitioning. A usage session refers to the time span beginning when one or more users begin to use the computing device, and ending when the one or more users cease using the computing device. During a particular usage session that uses a container, all interaction with the computing device is maintained in the container. The container is deleted when the usage session ends, leaving no data from the usage session behind after the usage session ends. Additionally, some usage sessions need not be run in containers, so data generated during such usage sessions is maintained after usage session ends. The host operating system automatically determines which usage sessions to run in containers and which usage sessions to run separate from any containers.

Abstract: Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.

Abstract: Different containers are used for different usage sessions, a container referring to a virtualization layer for a computing device and used for isolation as well as hardware resource partitioning. A usage session refers to the time span beginning when one or more users begin to use the computing device, and ending when the one or more users cease using the computing device. During a particular usage session that uses a container, all interaction with the computing device is maintained in the container. The container is deleted when the usage session ends, leaving no data from the usage session behind after the usage session ends. Additionally, some usage sessions need not be run in containers, so data generated during such usage sessions is maintained after usage session ends. The host operating system automatically determines which usage sessions to run in containers and which usage sessions to run separate from any containers.

Abstract: Techniques for implementing operating system layering are described herein. In one example, a method includes managing one or more container temporary storage spaces and one or more container runtime environments. Furthermore, the method includes loading, one or more drivers to provide compatibility between a container operating system and a host operating system, the one or more drivers comprising application program interface (API) compatibility libraries to enable API compatibility between the container operating system and the host operating system; metadata arbitration logic to enable compatibility between the container operating system and the host operating system by modifying container operating system references; and file arbitration logic to modify operating system file locations accessed by the container operating system and the host operating system.

Abstract: A host operating system running on a computing device monitors network communications for the computing device to identify network resources that are requested by the computing device. The host operating system compares requested network resources against security policies to determine if the requested network resources are trusted. When an untrusted network resource is identified, the host operating system accesses the untrusted network resource within a container that is isolated from the host operating system kernel using techniques discussed herein. By restricting access to untrusted network resources to isolated containers, the host operating system is protected from even kernel-level attacks or infections that may result from an untrusted network resource.

Abstract: Techniques described herein can dynamically generate images. In one example, a method includes detecting a request to generate a container image based on a policy file and identifying a host image from a host operating system. The method can also include generating the container image based on the host image and the policy file, the policy file indicating a first set of files to be copied from the host image to the container image, a set of reparse points corresponding to a second set of files not to be copied from the host image to the container image, and a third set of files to be loaded into the container image from a remote source.

Abstract: Configuring a node. A method includes at a first configuration layer, modifying configuration settings. The method further includes propagating the modified configuration settings to one or more other configuration layers implemented at the first configuration layer to configure a node.

Abstract: Techniques for implementing operating system layering are described herein. In one example, a method includes managing one or more container temporary storage spaces and one or more container runtime environments. Furthermore, the method includes loading, one or more drivers to provide compatibility between a container operating system and a host operating system, the one or more drivers comprising application program interface (API) compatibility libraries to enable API compatibility between the container operating system and the host operating system; metadata arbitration logic to enable compatibility between the container operating system and the host operating system by modifying container operating system references; and file arbitration logic to modify operating system file locations accessed by the container operating system and the host operating system.

Abstract: Configuring a node. A method includes determining a current state of a target node. The current state of the target node refers to objects currently deployed or running in the remote target node. It includes at least one of an operating system, one or more applications, or configuration setting at the target node. The method further includes determining a desired state for the target node to change the current state. The method further includes accessing a dependency graph based on the version of an agent running on the target node. The dependency graph is supplied to a state machine. The state machine is particular to the target node. The state machine using the current state of the target node, the desired state and the dependency graph, performs operations to drive the target node toward its goal.

Abstract: A containment mechanism provides for the grouping and isolation of multiple processes running on a single computer using a single instance of the operating system. A system is divided into one or more side-by-side and/or nested isolated environments enabling the partitioning and controlled sharing of resources by creating different views of hierarchical name spaces via virtual hierarchies.

Abstract: Methods, systems, and computer-readable media for deploying an update to nodes propagated throughout a data center are provided. Launching new upgrade to hosting environment residing on the nodes typically invokes a mechanism (e.g., fabric controller) to form a group of nodes that are independent of one another with respect to upgrade domains, which are assigned to tenants (e.g., program components of service applications running within the data center) presently hosted by the nodes. The constraints of the update domains are articulated by service level agreements established for the service applications, respectively. Forming the group involves identifying independent nodes for membership, where no two members of the group host analogous tenants (belonging to a common service application) that are assigned to distinct update domains. However, it is acceptable to join to the group those nodes hosting analogous tenants that are each assigned to the same update domain.

Abstract: Embodiments described herein are directed to updating the various software associated with a distributed application in a piecemeal fashion. All instances of the software are analyzed and separated into different portions, called “roles.” Each instance of a role is strategically assigned to an update domain based on the structural information included in the service model of the distributed application. The distributed application is upgraded one update at a time by selecting an update or host update domain, bringing the roles assigned thereto offline, updating the offline roles, bringing the roles back online, and repeating for other update or host update domains.