Patent Application
20230334143
The invention relates to computing devices and, more particularly, to software artifact management systems.
Software artifacts may refer to any files created by software development processes, such as packages, containers, configuration files, and/or documents along with any dependencies that may be required to build or deploy an application (such as a base image or an open source package), configuration files, and the like. Software artifact management may involve various systems used to facilitate development, testing, and/or distribution of software artifacts.
Software artifact management systems may maintain a central repository to which all software artifacts are published. The central repository may include software artifacts from a number of different vendors to facilitate a number of different use cases, such as software development, testing, and/or distribution. While the vendors may easily publish software artifacts for a particular edge repository associated with a particular environment, the software artifact management system may experience issues when attempting to move the software artifacts between edge repositories associated with different environments.
Techniques are described for facilitating software artifact management across environments. Environments may refer to different aspects of software development, such as a test (or, in other words, lab) environment and a production environment. A test environment may allow software developers to test (via a test bench, which may represent a simulated production environment) software artifacts to ensure proper operation of the software artifacts prior to being deployed to the actual live environments, which may also be referred to as the production environment. To preserve security in each environment and ensure that untested software artifacts cannot be inadvertently deployed between environments, many environments include various security measures (in terms of network security devices, such as firewalls, network address translation devices, intrusion detection prevention devices, etc.) to prevent distribution of software artifacts across environments unless explicitly authorized by network administrators, software developers, and other users.
The techniques described in this disclosure may allow for automated deployment of software artifacts across secure environments through use, at least in part, of a distribution controller that operates with respect to declarative and intent-based rules referred to as environmental descriptors. The environmental descriptors identify software artifacts that are to be stored by edge repositories associated with different environments, thereby preserving edge repository state that facilitates error recovery, while also providing the user with a declarative, intent-based rule base by which to automate software artifact distribution across environments.
Rather than manually direct the software artifact management system to distribute software artifacts from the central repository, the user may define environmental descriptors to gate distribution of software artifacts. The distribution controller may, based on the environmental descriptors, automatically interface with the central repository to distribute the software artifact to the edge repository. As the environmental descriptors are human-readable, the automated process may thereby be documented to facilitate troubleshooting and potentially allow for rapid understanding of the state of the edge repositories across environments. When moving between environments, the distribution controllers (in one or more environments) may cooperate to transfer the software artifact from the central repository to the next software environment (e.g., moving from the test environment to the production environment).
As such, various aspects of the techniques described in this disclosure may improve operation of software artifact management systems using the distribution controller to automate software artifact distribution across environments by way of the central repository. The automated nature by which the distribution controller may interface with the central repository to trigger delivery (or, in other words, distribution) of the software artifacts to different environments may reduce the likelihood of human error, while also potentially enabling the preservation of security for each environment (as the distribution controller may operate as an authorized agent in directing distribution of software artifacts from the central repository).
Furthermore, the declarative, intent-based rule base by which environmental descriptors are defined may improve traceability for distribution of software artifact while also potentially providing a defined state by which the distribution controllers may recover from errors in the various environments. In the instance of an error that corrupts edge repositories, the distribution controller may, based on the environmental descriptors, automatically recover from such error by automatically triggering redistribution of software artifacts to the edge repositories of the various environments.
In this respect, the various aspects of the techniques may improve operation of software artifact management systems themselves by potentially reducing human error, promoting automated error recovery, supporting software artifact documentation, increasing security, etc. By reducing human error that may result in additional steps to correct such error, automating error recovery to again avoid inadvertent processes, supporting software artifact documentation (via environmental descriptors), and increasing security, the various aspects of the techniques may reduce consumption of computing resources (such as processor cycles, memory, memory bus bandwidth, etc., and associated power consumption).
In one aspect, various aspects of the techniques are directed to a method comprising: storing, by a memory of a distribution controller supporting a software artifact management system, an environmental descriptor that identifies one or more software artifacts stored to a central repository located in an unsecure environment; generating, by one or more processors of the distribution controller and based on the environmental descriptor, one or more distribution operations specifying that at least one software artifact of the one or more software artifacts is to be distributed to a secure environment separate from the unsecure environment; and transmitting, by the one or more processors and to the central repository, the one or more distribution operations to cause the central repository to transfer the at least one software artifact to an edge repository in the secure environment.
In another aspect, various aspects of the techniques are directed to a distribution controller configured to support a software artifact management system, the distribution controller comprising: a memory configured to store an environmental descriptor that identifies one or more software artifacts stored to a central repository located in an unsecure environment; and one or more processors configured to generate, based on the environmental descriptor, one or more distribution operations specifying that at least one software artifact of the one or more software artifacts is to be distributed to a secure environment from the unsecure environment; and transmit, to the central repository, the one or more distribution operations to cause the central repository to transfer the at least one software artifact to the edge repository in the secure environment.
In another aspect, various aspects of the techniques are directed to a non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors of a distribution controller supporting a network artifact management system to: store an environmental descriptor that identifies one or more software artifacts stored to a central repository located in an unsecure environment; generate, based on the environmental descriptor, one or more distribution operations specifying that at least one software artifact of the one or more software artifacts is to be distributed to a secure environment separate from the unsecure environment; and transmit, to the central repository, the one or more distribution operations to cause the central repository to transfer the at least one software artifact to an edge repository in the secure environment.
In another aspect, various aspects of the techniques are directed to a software artifact management system comprising: a central repository residing in an unsecure environment and configured to store a plurality of software artifacts; an edge repository residing in a secure environment; and a distribution controller comprising: a memory configured to store an environmental descriptor that identifies one or more software artifacts of the plurality of software artifacts stored to the central repository; and one or more processors configured to generate, based on the environmental descriptor, one or more distribution operations specifying that at least one software artifact of the one or more software artifacts is to be distributed to the edge repository from the central repository; and transmit, to the central repository, the one or more distribution operations to cause the central repository to transfer the at least one software artifact to the edge repository in the secure environment.
The details of one or more aspects of the techniques are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques will be apparent from the description and drawings, and from the claims.
Environments 104A-104N may represent environments that are protected from direct access via a public network. These environments 104A-104N may be secured by way of one or more firewalls, intrusion detection prevention (IDP) devices, network address translation (NAT) devices, and/or other network security devices that attempt to prevent direct access from public network 106 unless in some instances such access is authenticated. Environments 104A-104N may therefore be referred to as secure environments 104A-104N (“secure environments 104”).
As further shown in the example of
While described with respect to unsecure environment 102, environment 102 may not represent other types of environments, such as a secure environment in the sense that environment 102 may provide firewall and other network security to ensure malicious code is unable to be deployed within environment 102. In this context, the difference between environment 102 and environments 104 is that environment 102 may be publicly accessible from public network 106 while secure environments 104 may represent private networks that are not publicly accessible from public network 106. As such, environment 102 may also be referred to as “public environment 102,” while environments 104 may be referred to as “private environments 104.”
Central repository 112 may represent any type of computer-readable media, including databases supported by non-volatile memory such as storage drives (e.g., hard drives, disc drives, tape drives, etc.), flash memory and the like, volatile memory (e.g., random access memory—RAM, synchronous RAM—SRAM, dynamic RAM—DRAM), or any other type of storage system having a hierarchical or non-hierarchical configuration capable of storing software artifacts 113. Central repository 112 may also include software by which to control central repository 112, where such software may be similar to a database management system. Edge repositories 114 may each be similar to, if not the same as, central repository 112 in terms of representing any type of computer-readable media.
In any event, management of software artifacts 113 is complex because software artifacts 113 may originate from many different sources both inside and outside an organization, where each separate system introduces a potential point of failure due to outages or other issues. For example, a single software artifact of software artifacts 113 may include files that originate from builds across multiple internal teams (meaning, internal to a given organization), open source projects (e.g., in GitHub), and/or format specific sites (as compared to open source sites).
Software artifact management system 100 may address the above complexities and reliability issues by centralizing software artifacts 113 in a single entry point. That is, software artifact management system 100 may maintain central repository 112 to which all SW artifacts 113 are published. Vendors may publish SW artifacts 113 to central repository 112 for a number of different purposes. In some instances, vendors may publish SW artifacts 113 to central repository to facilitate testing and further development of SW artifacts 113 in one or more secure environments 104. Should SW artifacts 113 successfully complete testing, vendors may distribute SW artifacts 113 to another secure environment 104 for, as an example, deployment within a network of one or more secure environments 104.
In this respect, software artifact management system 100 may act as a single source of so-called “truth” and continuous integration and continuous delivery (Cl/CD) integration point for software artifacts 113. In addition, software artifact management system 100 may provide additional features, such as version management, vulnerability scanning, and approval workflows. Software artifact management system 100 may further provide unified access control and consistent configuration while also providing consistency in automation for workflows with software artifacts 113.
However, the secure nature of secure environments 104 may prohibit direct communication between secure environments 104. As such, the vendors may attempt to manually trigger distribution of SW artifacts 113 to the different one of secure environments 104, which may by prone to human error. Furthermore, should an error occur within any of secure environments 104 (e.g., failure of storage supporting edge repositories 114), such software artifact management systems 100 may maintain no state of SW artifacts distributed to edge repositories 114 such that there is a way to rebuild distributed SW artifacts 113 at edge repositories 114 (at least in an automated way that is not further prone to human error).
In accordance with various aspects of the techniques described in this disclosure, software artifact management system 100 may facilitate automatic transfer of SW artifacts 113 across secure environments 104 using a declarative and intent-based approach. Software artifact management system 100 may include distribution controllers 124A-124N (“distribution controllers 124”) in each of secure environments 104. One or more distribution controllers 124 (e.g., distribution controller 124A) may include one or more environmental descriptions 125 (“env descry 125”) that maintain the state of edge repositories 114 in terms of which SW artifacts 113 are to be distributed to each of edge repositories 114 from central repository 112.
Distribution controllers 124 may represent a web-based service that operates according to a representational state transfer (REST or, sometimes denoted, RESTful) application programming interface (API) (REST API) that integrates with various systems, including in some instances the Cl/CD infrastructure. Although described as a distributed web-service, distribution controllers 124 may also represent dedicated networking devices and/or services running on dedicated servers or other types of network devices capable of performing the operations of distribution controllers 124 described throughout this disclosure.
Environmental descriptors 125 may represent, in other words, human-readable/-writable files that describe a state of secure environments 104 in terms of SW artifacts 113 stored at each edge repository 114. In some instances, distribution controllers 124 may maintain a separate environmental descriptor 125 for each corresponding secure environment 104. In other instances, a single one of environmental descriptors 125 may define the state of multiple secure environments 104. Regardless, environmental descriptors 125 may conform to the JavaScript Object Notation (JSON) format or any other lightweight data-interchange format utilized by webservices, such as distribution controllers 124. Environmental descriptors 125 may be language independent (meaning that JSON or other data-interchange formats are not specific to any underlying programming language such as JavaScript, C, C++, C #, Java, Perl, Python, etc.).
In any event, to redistribute SW artifacts 113 from one secure environment 104 (e.g., secure environment 104A) to another secure environment 104 (e.g., secure environment 104N), the operator (e.g., software developer, network administrator, or some other authorized user) updates environmental descriptors 125 to specify which of SW artifacts 113 are to move between secure environments 104. Once environmental descriptors 125 are updated, distribution controller 124A may automatically interface with central repository 112 to cause central repository 112 to distribute the updated SW artifacts of SW artifacts 113 to a different edge repository 114 (e.g., edge repository 114N). Distribution controller 124A may also issue reports to edge repository 114A regarding which of SW artifacts 113 should be stored at edge repository 114A, which may cause edge repository 114A to remove (or, in other words, delete) the updated SW artifacts that were redistributed from edge repository 114A to edge repository 114N.
In operation, distribution controller 124A may store environmental descriptors 125 that identifies one or more software artifacts 113 stored to central repository 112 located in unsecure environment 102. Distribution controller 124A may maintain environmental descriptors 125 locally (e.g., stored to edge repository 114A) within secure environment 104A. Distribution controller 124A may store environmental descriptors 125 to prevent unauthorized access to environmental descriptors 125 and thereby improve security.
Distribution controller 124A may next generate, based on environmental descriptors 125, one or more distribution operations 127A specifying that at least one SW artifact (e.g., SW artifact 113A) of SW artifacts 113 are to be distributed to secure environment 104A separate from unsecure environment 102. Distribution controller 124A may then transmit, to central repository 112, distribution operations 127A to cause central repository 112 to transfer (or, in other words, distribute) SW artifact 113A to edge repository 114A in secure environment 104A. Central repository 112 may, responsive to receiving distribution operations 117A, distribute SW artifact 113A to edge repository 114A.
Given that environmental descriptors 125 are declarative and intent-based, distribution controller 124A may perform declarative checks as well as possible intent-based checks to reduce if not possibly eliminate human error from resulting in improper distribution of SW artifacts 113. In addition, given the automated nature of the distribution along with maintaining, via environmental descriptors 125, a state of edge repositories 114 in terms of which SW artifacts 113 are to be distributed to which edge repositories 114, software artifact management system 100 may be more robust to failures in secure environments 104 in terms of recovery from malfunctions, hardware failures, power loss, etc.
In addition to generating distribution operations 127A, distribution controller 124A may interface with edge repository 114A to generate a report 129A indicating which of SW artifacts 113 of central repository 112 are stored at edge repository 114A of secure environment 104A. Distribution controller 124A may then transmit report 129A to central repository 112 to ensure that only authorized software artifacts of SW artifacts 113 are stored at edge repository 114. Distribution controller 124 may, in this way, act as an authorized agent that automatically generates reports 129A to ensure that no unauthorized SW artifacts 113 are distributed to secure environments 104 (or side loaded via local storage of software artifacts to edge repositories 114) that may constitute a security threat to secure environments 104.
In the example of
To authorize software artifact 113A, for example, for distribution to production environment 104N, the test engineer may interface with distribution controller 124A to modify the environmental descriptor of environment descriptors 125 associated with secure environment 104A (which may be denoted as environmental descriptor 125A) to remove SW artifact 113A. The test engineer may next interface with distribution controller 124A to modify the environmental descriptor of environment descriptors 125 associated with secure environment 104N (which may be denoted as environmental descriptor 125N) to add SW artifact 113A.
In the example of
In this example, distribution controller 124A may maintain environmental descriptors 125 for more than the secure environment in which distributed controllers 124A resides (i.e., secure environment 104A in the example of
Responsive to updating environmental descriptor 125N, distribution controller 124A may generate one or more distribution operations as updated distribution operations 127A′ specifying that SW artifact 113A is to be distributed from central repository 112 to edge repository 114N. Distribution controller 124A may then transmit updated distribution operations 127A′ to central repository 112 to cause central repository 112 to distribute (or, in other words, transfer) SW artifact 113A to edge repository 114N of production environment 104N.
Distribution controller 124N may monitor edge repository 114N to determine which of SW artifacts 113 stored to central repository 112 are stored to edge repository 114N. Responsive to central repository 112 distributing software artifact 113A to edge repository 114N, distribution controller 124N may interface with edge repository 114N to determine that SW artifact 113A was successfully stored to edge repository 114N. Distribution controller 124N may generate, responsive to determining that SW artifact 113A was successfully stored to edge repository 114N, a report 129N indicating that software artifact 113A was stored to edge repository 114N of production environment 124N. Distribution controller 124N may transmit report 129N to central repository 112 for reasons similar to those described above with respect to report 129A and updated report 129A′.
In this way, various aspects of the techniques described in this disclosure may allow for automated deployment of SW artifacts 113 across secure environments 104 through use, at least in part, of distribution controller(s) 124 that operate with respect to declarative and intent-based rules referred to as environmental descriptors 125. Environmental descriptors 125 may identify SW artifacts 113 that are to be stored by edge repositories 114 associated with different environments 104, thereby preserving edge repository 114 state that facilitates error recovery, while also providing the user with a declarative, intent-based rule base by which to automate SW artifact 113 distribution across environments 104.
Rather than manually direct software artifact management system 100 to distribute SW artifacts 113 from the central repository 112, the user may define environmental descriptors 125 to gate distribution of SW artifacts 113. In this example, distribution controller 124A may, based on environmental descriptors 125, automatically interface with central repository 112 (via distribution operations 127A/127A′) to distribute SW artifact 113A to edge repository 114A. As environmental descriptors 125 are human-readable, the automated process may thereby be documented to facilitate troubleshooting and potentially allow for rapid understanding of the state of edge repositories 114 across environments 104. When moving between environments 104, distribution controllers 125 (in one or more environments 104) may cooperate to transfer SW artifact 113A from central repository 112 to the next software environment (e.g., moving from the test environment to the production environment).
As such, various aspects of the techniques described in this disclosure may improve operation of software artifact management system 100 using distribution controller(s) 124 to automate software artifact distribution across environments 104 by way of central repository 112. The automated nature by which distribution controller(s) 124 may interface with central repository 112 to trigger delivery (or, in other words, distribution) of SW artifacts 113 to different environments 104 may reduce the likelihood of human error, while also potentially enabling the preservation of security for each environment 104 (as distribution controller(s) 124 may operate as an authorized agent in directing distribution of SW artifacts 113 from central repository 112).
Furthermore, the declarative, intent-based rule base by which environmental descriptors 125 are defined may improve traceability for distribution of SW artifacts 113 while also potentially providing a defined state by which distribution controllers 124 may recover from errors in various environments 104. In the instance of an error that corrupts edge repositories 114, distribution controller 124 may, based on environmental descriptors 125, automatically recover from such error by automatically triggering redistribution of SW artifacts 113 to edge repositories 114 of various environments 104.
In this respect, the various aspects of the techniques may improve operation of software artifact management system 100 itself by potentially reducing human error, promoting automated error recovery, supporting software artifact documentation, increasing security, etc. By reducing human error that may result in additional steps to correct such error, automating error recovery to again avoid inadvertent processes, supporting software artifact documentation (via environmental descriptors), and increasing security, the various aspects of the techniques may reduce consumption of computing resources (such as processor cycles, memory, memory bus bandwidth, etc., and associated power consumption) within software artifact distribution system 100 itself.
That is, software artifact management system 200, similar to software artifact management system 100, includes a central repository 212 that resides in unsecure environment 202, and a number of different edge repositories 214 that reside in different secure environments 204. Central repository 212 may store SW artifacts 213A-213Z (“SW artifacts 213”) similar to central repository 112. Central repository 212 may be publicly accessible via public network 206, which is also similar to, if not the same as, central repository 112. Edge repositories 214 may be similar to, if not the same as, edge repositories 114. Distribution controllers 224 may reside in respective secure environments 204 in a manner similar to distribution controllers 124, managing distribution of SW artifacts 213 from central repository to respective edge repositories 214.
However, rather than have a central distribution controller 124A that maintains a plurality of environmental descriptors 125, each of distribution controllers 124 may maintain a separate environmental descriptor 225A-225N (“environmental descriptors 225”) for a corresponding one of secure environments 204. That is, distribution controller 224A may maintain environmental descriptor 225A for edge repository 214A of secure environment 204A, distribution controller 224B may maintain environmental descriptor 225B for edge repository 214B of secure environment 204B, . . . , and distribution controller 224N may maintain environmental descriptor 225N for edge repository 214N of secure environment 204N.
In the example of
In addition to generating distribution operations 227A, distribution controller 224A may interface with edge repository 214A to generate a report 229A indicating which of SW artifacts 213 of central repository 212 are stored at edge repository 214A of secure environment 204A. Distribution controller 224A may then transmit report 229A to central repository 212 to ensure that only authorized software artifacts of SW artifacts 213 are stored at edge repository 214. Distribution controller 224 may, in this way, act as an authorized agent that automatically generates reports 229A to ensure that no unauthorized SW artifacts 213 are distributed to secure environments 204 (or side loaded via local storage of software artifacts to edge repositories 214) that may constitute a security threat to secure environments 104.
To authorize software artifact 213A, for example, for distribution to production environment 204N, the test engineer may interface with distribution controller 224A to modify environmental descriptor 225A associated with secure environment 204A to remove SW artifact 213A. The test engineer may next communicate with a production engineer to interface with distribution controller 224N to modify environmental descriptor 225N to add SW artifact 213A.
Although described as removing software artifact 213A, in some instances the test engineer may elect to maintain software artifact 213A within secure environment 204A while also being deployed to secure environment 204N. In this respect, software artifact 213A may be specified in both environmental descriptors 225A and 225N.
In the example of
In this example, distribution controller 224A only maintains environmental descriptor 125A for secure environment 204A in which distributed controllers 224A resides. As such, responsive to updating environmental descriptor 225N, distribution controller 224N may generate one or more distribution operations as distribution operations 227N specifying that SW artifact 213A is to be distributed from central repository 212 to edge repository 214N. Distribution controller 224N may then transmit distribution operations 227N to central repository 212 to cause central repository 212 to distribute (or, in other words, transfer) SW artifact 213A to edge repository 214N of production environment 204N.
Distribution controller 224N may monitor edge repository 214N to determine which of SW artifacts 213 stored to central repository 212 are stored to edge repository 214N. Responsive to central repository 212 distributing software artifact 213A to edge repository 214N, distribution controller 224N may interface with edge repository 214N to determine that SW artifact 213A was successfully stored to edge repository 214N. Distribution controller 224N may generate, responsive to determining that SW artifact 213A was successfully stored to edge repository 214N, a report 229N indicating that software artifact 213A was stored to edge repository 214N of production environment 224N. Distribution controller 224N may transmit report 229N to central repository 212 for reasons similar to those described above with respect to report 229A and updated report 229A′.
Distribution controller 124A may next generate, based on environmental descriptors 125, one or more distribution operations 127A specifying that at least one SW artifact (e.g., SW artifact 113A) of SW artifacts 113 are to be distributed to secure environment 104A separate from unsecure environment 102 (302). Distribution controller 124A may then transmit, to central repository 112, distribution operations 127A to cause central repository 112 to transfer (or, in other words, distribute) SW artifact 113A to edge repository 114A in secure environment 104A (304). Central repository 112 may, responsive to receiving distribution operations 117A, distribute SW artifact 113A to edge repository 114A.
As shown in the example of
Processors 502, in one example, are configured to implement functionality and/or process instructions for execution within computing device 500. For example, processors 502 may be capable of processing instructions stored in storage device 508. Examples of processors 502 may include, any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.
One or more storage devices 508 may be configured to store information within computing device 500 during operation. Storage device 508, in some examples, is described as a computer-readable storage medium. In some examples, storage device 508 is a temporary memory, meaning that a primary purpose of storage device 508 is not long-term storage. Storage device 508, in some examples, is described as a volatile memory, meaning that storage device 508 does not maintain stored contents when the computer is turned off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. In some examples, storage device 508 is used to store program instructions for execution by processors 502. Storage device 508, in one example, is used by software or applications running on computing device 500 to temporarily store information during program execution.
Storage devices 508, in some examples, also include one or more computer-readable storage media. Storage devices 508 may be configured to store larger amounts of information than volatile memory. Storage devices 508 may further be configured for long-term storage of information. In some examples, storage devices 508 include non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.
Computing device 500, in some examples, also includes one or more communication units 506. Computing device 500, in one example, utilizes communication units 506 to communicate with external devices via one or more networks, such as one or more wired/wireless/mobile networks. Communication units 506 may include a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. Other examples of such network interfaces may include 3G and WiFi radios. In some examples, computing device 500 uses communication unit 506 to communicate with an external device.
Computing device 500, in one example, also includes one or more user interface devices 510. User interface devices 510, in some examples, are configured to receive input from a user through tactile, audio, or video feedback. Examples of user interface devices(s) 510 include a presence-sensitive display, a mouse, a keyboard, a voice responsive system, video camera, microphone or any other type of device for detecting a command from a user. In some examples, a presence-sensitive display includes a touch-sensitive screen.
One or more output devices 512 may also be included in computing device 500. Output device 512, in some examples, is configured to provide output to a user using tactile, audio, or video stimuli. Output device 512, in one example, includes a presence-sensitive display, a sound card, a video graphics adapter card, or any other type of device for converting a signal into an appropriate form understandable to humans or machines. Additional examples of output device 512 include a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate intelligible output to a user.
Computing device 500 may include operating system 516. Operating system 516, in some examples, controls the operation of components of computing device 500. For example, operating system 516, in one example, facilitates the communication of one or more applications 522 and distribution controller 524 with processors 502, communication unit 506, storage device 508, input device 504, user interface devices 510, and output device 512. Application 522 and distribution controller 524 may also include program instructions and/or data that are executable by computing device 500 to perform various aspects of the techniques described above in more detail.
In addition to or as an alternative to the above, the following examples are described. The features described in any of the following examples may be utilized with any of the other examples described herein.
In this respect, the techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The term “processor” or “processing circuitry” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit comprising hardware may also perform one or more of the techniques of this disclosure.
Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components, or integrated within common or separate hardware or software components.
The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a non-transitory computer-readable medium or computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer readable storage media may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer-readable storage media. The term “computer-readable storage media” refers to physical storage media, and not signals or carrier waves, although the term “computer-readable media” may include transient media such as signals, in addition to physical storage media.
