(First draft) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Frequently Asked Questions == | == Frequently Asked Questions == | ||
=== What's this Base Runtime thing anyway? === | === What's this Base Runtime thing anyway? === | ||
Base Runtime is a name for the module or collection of modules | Base Runtime is a name for the module or collection of modules that provide the minimum system runtime environment needed for the system to boot and for other modules that rely on C runtime libraries to run. What exactly would be included in this or these modules is a subject for debate but it's expected Base Runtime would include, at the bare minimum, packages such as kernel, glibc and libgcc. | ||
that provide the minimum system runtime environment needed for | |||
the system to boot and for other modules that rely on C runtime | |||
libraries to run. What exactly would be included in this or | |||
these modules is a subject for debate but it's expected Base | |||
Runtime would include, at the bare minimum, packages such as | |||
kernel, glibc and libgcc | |||
Base Runtime would be the foundation of virtually every system, be it a bare metal installation, a virtual machine or a container. | |||
=== Does it mean that every container would contain a copy of the kernel and that every VM would ship with all the kernel drivers available? === | === Does it mean that every container would contain a copy of the kernel and that every VM would ship with all the kernel drivers available? === | ||
Nope, it does not. Software being included in a module doesn't | Nope, it does not. Software being included in a module doesn't mean it has to be installed in every scenario. Which components will be included in an installation is decided by the so-called installation profiles. | ||
mean it has to be installed in every scenario. Which components | |||
will be included in an installation is decided by the so-called | |||
installation profiles. | |||
Containers don't need a kernel and VMs don't need bare metal | Containers don't need a kernel and VMs don't need bare metal drivers. Live media images might also have special needs. Modules may define arbitrary number of installation profiles. These will be used by installation and compose tooling, and selected depending on the use case or user configuration. | ||
drivers. Live media images might also have special needs. | |||
Modules may define arbitrary number of installation profiles. | |||
These will be used by installation and compose tooling, and | |||
selected depending on the use case or user configuration. | |||
=== What's the difference between Base Runtime, Modularity and Factory 2.0? === | |||
Modularity initiative is about breaking the monolithic distribution compose into smaller, standalone functional pieces with their own separate life cycles, features, application stability levels and more. Factory 2.0 is a code name for infrastructure and release tooling changes needed to make Modularity, among other things, possible. | |||
Base Runtime assumes most of the Modularity and Factory 2.0 problems are solved and is about design of the low-level module stack that makes system boot and other modules run. | |||
=== What does this mean for Fedora? === | === What does this mean for Fedora? === | ||
This is not a simple question to answer. See the [[Modularity#Fedora_Objectives|Fedora Objectives section of the Modularity page]]. | |||
=== Is Base Runtime something like the long discussed Core or Ring 0 or similar? === | === Is Base Runtime something like the long discussed Core or Ring 0 or similar? === | ||
Yes and no. | |||
The concepts of Modularity differ significantly from the original rings proposal -- there are no explicit layers; modules are expected to contain and maintain their own dependencies rather than depend on a shared components available in a release. Modules' release cycles are also totally disconnected from the operating system release cycles. However, the Base Runtime et al. are what could be considered the stable, high quality distribution core that defines Fedora releases and provides a small set of components the application modules can rely on and don't have to bundle themselves. | |||
=== How is Base Runtime going to be released? === | === How is Base Runtime going to be released? === | ||
Just like with any other module, this depends entirely on Factory 2.0. | |||
=== Who is going to develop and maintain Base Runtime? === | === Who is going to develop and maintain Base Runtime? === | ||
Base Runtime consists of the module metadata / build recipe and the RPM packages the module contains. It is a joint effort of both the Base Runtime team and the respective RPM package maintainers. That's unlikely to change in the near future. | |||
=== Why was the initial Base Runtime prototype self-hosting? === | |||
The Modularity/Factory 2.0 infrastructure doesn't normally re-use pre-built binaries from the regular Fedora releases. Modules and the packages they contain are built in buildroots defined by other modules. As Base Runtime is the first real module being built in this setup and we needed to bootstrap the infrastructure anyway, we decided to make the first prototype self-hosting, that is bundling the complete development environment needed to build the packages we actually wanted to include. This was purely for practical reasons -- to enable our tooling and simplify any future development. | |||
There's no end user requirement for any module to be self-hosting and, besides the first prototype, Base Runtime isn't going to be either. | |||
[[Category:BaseRuntime]] | [[Category:BaseRuntime]] | ||
[[Category:Modularity]] | [[Category:Modularity]] | ||
[[Category:Modularization]] | [[Category:Modularization]] | ||
Latest revision as of 11:51, 6 October 2016
Frequently Asked Questions
What's this Base Runtime thing anyway?
Base Runtime is a name for the module or collection of modules that provide the minimum system runtime environment needed for the system to boot and for other modules that rely on C runtime libraries to run. What exactly would be included in this or these modules is a subject for debate but it's expected Base Runtime would include, at the bare minimum, packages such as kernel, glibc and libgcc.
Base Runtime would be the foundation of virtually every system, be it a bare metal installation, a virtual machine or a container.
Does it mean that every container would contain a copy of the kernel and that every VM would ship with all the kernel drivers available?
Nope, it does not. Software being included in a module doesn't mean it has to be installed in every scenario. Which components will be included in an installation is decided by the so-called installation profiles.
Containers don't need a kernel and VMs don't need bare metal drivers. Live media images might also have special needs. Modules may define arbitrary number of installation profiles. These will be used by installation and compose tooling, and selected depending on the use case or user configuration.
What's the difference between Base Runtime, Modularity and Factory 2.0?
Modularity initiative is about breaking the monolithic distribution compose into smaller, standalone functional pieces with their own separate life cycles, features, application stability levels and more. Factory 2.0 is a code name for infrastructure and release tooling changes needed to make Modularity, among other things, possible.
Base Runtime assumes most of the Modularity and Factory 2.0 problems are solved and is about design of the low-level module stack that makes system boot and other modules run.
What does this mean for Fedora?
This is not a simple question to answer. See the Fedora Objectives section of the Modularity page.
Is Base Runtime something like the long discussed Core or Ring 0 or similar?
Yes and no.
The concepts of Modularity differ significantly from the original rings proposal -- there are no explicit layers; modules are expected to contain and maintain their own dependencies rather than depend on a shared components available in a release. Modules' release cycles are also totally disconnected from the operating system release cycles. However, the Base Runtime et al. are what could be considered the stable, high quality distribution core that defines Fedora releases and provides a small set of components the application modules can rely on and don't have to bundle themselves.
How is Base Runtime going to be released?
Just like with any other module, this depends entirely on Factory 2.0.
Who is going to develop and maintain Base Runtime?
Base Runtime consists of the module metadata / build recipe and the RPM packages the module contains. It is a joint effort of both the Base Runtime team and the respective RPM package maintainers. That's unlikely to change in the near future.
Why was the initial Base Runtime prototype self-hosting?
The Modularity/Factory 2.0 infrastructure doesn't normally re-use pre-built binaries from the regular Fedora releases. Modules and the packages they contain are built in buildroots defined by other modules. As Base Runtime is the first real module being built in this setup and we needed to bootstrap the infrastructure anyway, we decided to make the first prototype self-hosting, that is bundling the complete development environment needed to build the packages we actually wanted to include. This was purely for practical reasons -- to enable our tooling and simplify any future development.
There's no end user requirement for any module to be self-hosting and, besides the first prototype, Base Runtime isn't going to be either.