From 9178d4a998dabe3280bc882a46900f767a5261b2 Mon Sep 17 00:00:00 2001 From: Matt Prahl Date: Jan 22 2019 20:31:36 +0000 Subject: Reword the index page This commits rewords the index page so that it reads and flows better (in my opinion). --- diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index b4e935c..05485ec 100644 --- a/modules/ROOT/pages/index.adoc +++ b/modules/ROOT/pages/index.adoc @@ -1,7 +1,7 @@ -= What is Modularity += What is Modularity? Modularity introduces a new optional repository to Fedora called Modular (often referred to as the "Application Stream" or AppStream for short) that ships additional versions of software on independent life cycles. -This way users can keep their operating system up-to-date while having the right version of an application for their use case, even when the default version in the distribution changes. +This enables users to keep their operating system up-to-date while having the right version of an application for their use case, even when the default version in the distribution changes. image::modularity-appstream-overview.png[,100%,] @@ -11,37 +11,39 @@ image::modularity-appstream-overview.png[,100%,] === Too fast vs. too slow Different users have different needs. -Developers want the latest versions possible, system administrators want stability for longer period of time. -There are many Linux distributions out there, each targeting a different audience, for example Fedora vs. CentOS. +Developers often want the latest version, and system administrators often want stability for long periods of time. +There are many Linux distributions out there, each targeting a different audience. +A clear example of this is Fedora and CentOS. Fedora generally ships the latest stable versions of its component packages when it is released twice per year. That is convenient for desktop users and developers. -Even though many people use Fedora on a server, it is sometimes necessary to have a stable version of certain packages for a longer time, mostly because of third-party applications. +This can be an issue for Fedora servers because it is sometimes necessary to have a stable version of certain packages for a longer period, mostly because of third-party applications. -At the same time, some people consider Fedora to be moving too slowly for them and want even newer runtimes on their system. -Some upstreams release their software faster than twice a year. +At the same time, some people consider Fedora to move too slowly and want even newer software on their system. +Some upstreams release their software faster than twice a year, and some users want these versions as they get released. On the other hand, CentOS targets long-term stability and releases a new version once every few years. -This is convenient for server admins as there are fewer changes over longer periods of time. -But some of the software gets old for modern applications and newer versions of runtimes might be needed. +This is convenient for server administrators as there are fewer changes over longer periods of time. +The issue is that some of the software gets too old for modern applications, and newer versions might be needed. -In other words, it would be convenient to be able to choose some parts of the system to be moving slowly, and other parts to be moving faster. -Can we do that? +In other words, it would be convenient to be able to choose some parts of the system to update infrequently, while other parts update at a faster pace. === Outdated containers -There are many containers out there. -The majority of them are built manually, not actively maintained, not patched with security fixes, and still used by many people. -This is especially true for the ones using software of a different version than the distribution their are based on provides. +There are many container images out there. +A large portion of them are built manually, not actively maintained, not patched with security fixes, and still used by many people. +This is especially true for the ones using software of a different version than the distribution the container image is based on provides. If Fedora had multiple versions of software that is actively maintained and built, could we use it to produce containers? Could these containers get automatically rebuilt every time the packages get updated? === Complex packager workflows -Fedora contributors maintain their packages in multiple branches — one for each release. -Even when the packages are the same. -Leading to a series of manual steps associated with the build process. +Fedora contributors maintain their packages in multiple branches, one for each release. +This is still required even when the packages are the same across releases. +This leads to a series of manual steps associated with the build process. Could we enable packagers to maintain packages in branches that would follow the package version instead of an arbitrary distribution release version? -Having a single branch that builds across multiple releases would save some work for packagers. +Having a single branch that builds across multiple releases would save a lot of work for packagers. + +This is all possible with modularity!