they depend to maintain a reasonable notification process that is not onerous to anyone involved. Strict compatibility requirement in code development and maintenance If the applications and libraries are developed and maintained with guaranteed downward compatibility in mind, any application or library can be replaced with a newer version at any time without breaking anything. While this does not alleviate the multitude of dependency, it does make the jobs of package managers or installers much easier. Software appliances Another approach to avoiding dependency issues is to deploy applications as a software appliance. A software appliance encapsulates dependencies in a pre-integrated self-contained unit such that users no longer have to worry about resolving software dependencies. Instead the burden is shifted to developers of the software appliance. Containers and their images (such as those provided by Docker and Docker Hub) can be seen as an implementation of software appliances. Portable applications An application (or version of an existing conventional application) that is completely self-contained and requires nothing to be already installed. It is coded to have all necessary components included, or is designed to keep all necessary files within its own directory, and will not create a dependency problem. These are often able to run independently of the system to which they are connected. Applications in RISC OS and the ROX Desktop for Linux use application directories, which work in much the same way: programs and their dependencies are self-contained in their own directories (folders). This method of distribution has also proven useful when porting applications designed for Unix-like platforms to Windows, the most noticeable drawback being multiple installations of the same shared libraries. For example, Windows installers for gedit, GIMP, and HexChat all include identical copies of the GTK toolkit, which these programs use to render widgets. On the other hand, if different versions of GTK are required by each application, then this is the correct behavior and successfully avoids dependency hell. Platform-specific On specific computing platforms, "dependency hell" often goes by a local specific name, generally the name of components. DLL Hell a form of dependency hell occurring on Microsoft Windows. Extension conflict a form of dependency hell occurring on the classic Mac OS. JAR hell a form of dependency hell occurring in the Java Runtime Environment before build tools like Apache Maven solved this problem in 2004. RPM hell a form of dependency hell occurring in the Red Hat