Modularization: Breaking a project down like LegosAs a systems administrator, you generally worry about two things. First, the security of the systems you support. Second, that the applications you run work as designed. You would like to do those two things with as little effort as possible, however, you want to be aware of and balance the risk inherent in meeting those goals.

Enter Fedora. Fedora curates the libraries and applications that are available to install on your local system(s). Fedora makes the promise that as soon as possible after the release of a patch or a new version of a library or an application it will make it available to you as a system administrator. However it does this by ensuring the sanctity of individual libraries. Effort is also made to ensure that dependent applications are also verified which consume that library.

Modularization and dependencies

However, what happens when two applications both use the same library and only one of the applications is verified to work with the library? The library is installed anyway.

What happens when you have software that is written by in-house developers that is dependent on a library in the Fedora ecosystem? How do you know which libraries are in use by every application? How do you verify that every application which depends on that library will operate correctly in the application? In particular, as the library may have had a bug, the Fedora applications and your applications, by definition, do not have a legitimate test for the bug. Usually, you install the library anyway.

Lastly, what happens when your in-house developers noticed that a library they want to use has a bug, were unable to get the change merged upstream (including reasons like lack of time or their lack of upstream involvement), implemented a patch in their application to work around the bug, and now have a new bug if the library is updated? You install the library anyway.

Personally, all these scenarios are very scary for me. However, they are a lot better than the scenario 20 years ago where vendors (open source projects or proprietary products) had no way to deliver real time security updates to you without completely redistributing their applications. Hence, we adopted the less flawed distribution model.

Modularization makes the problem less scary

However, these days, the world has changed. Many, many applications are now open source and managed in the Fedora ecosystem. Rebuilding applications is a fully automatable process as is the testing of those applications. Disk space has become relatively cheap, as is the bandwidth required to update individual libraries.

What if we can ensure that the applications you have installed on your system(s) have been tested with the library that was just patched, and for the applications that have not been verified, they can continue to use the old version. In the cases where an application is facing internally only, this may be sufficient. However, if the application is public, you can elect to force it to take the patch and trust that it will just work, or choose to disable that application specifically because Fedora will know which applications are still at risk.

These things become possible with modularization. Please, come get involved!