Objetivo de Fedora Minimization

Si bien Fedora es muy adecuado para servidores y estaciones de trabajo físicas/virtuales, a menudo se pasa por alto para casos de uso más allá de las instalaciones tradicionales.

Algunos tipos modernos de despliegues — como IoT y contenedores — son bastante sensibles al tamaño. Para IoT estas son, normalmente, conexiones de datos lentas (para actualizaciones/administración) y para la nube y contenedores es la escala masiva.

Un ejemplo específico es Systemd — que siendo muy útil (todo el mundo ama a Systemd) y está presente siempre en los sistemas físicos, rara vez se necesita en contenedores. Por lo tanto no fue un problema que los paquetes requirieran Systemd solo para que systemd-sysusers creen usuarios. Sin embargo, en contenedores, esto significa un aumento de tamaño significativo.

A parte de eso, básicamente todos los tipos de despliegues se benefician de un tamaño reducido, ya que hay una relación directa entre la huella de la instalación y la superficie de ataque y los CVE relevantes.

Miles de individuos y contribuidores corporativos en la comunidad Fedora para explorar los problemas nuevos y construir un movimiento moderno y rápido sistema operativo con un rico ecosistema que les permita experimentar y modernizar su infraestructura.

Ayudar a los desarrolladores de código abierto, administradores de sistemas y mantenedores de la distribución Linux a centrarse en lo que es relevante para ellos.

Fedora es una plataforma popular porque su ecosistema es de vanguardia y está bien optimizado para implementaciones modernas como IoT y contenedores. Esto hace que mucha gente use Fedora en lugar de compilar y ensamblar sus propios artefactos desde proyectos upstream. Y eso alivia la presión sobre los desarrolladores de código abierto causada por los usuarios, que de otro modo, pedirían que sus problemas específicos de seguridad y otras cuestiones se resolvieran rápidamente.

Así:

Los casos de uso específicos están definidos en Fedora. Luego, la comunidad se centra en esos casos de uso con desarrollo y mantenimiento, optimización (como minimización) y pruebas (como CI y gating). Estos casos de uso pueden ser priorizados transparentemente por los recursos de infraestructura en base a los intereses de la comunidad.

Feedback Pipeline monitoriza activamente cada caso de uso y registra el tamaño y las dependencias necesarias para su ejecución. Se mantiene y muestra un histórico de datos para ver los cambios en el tiempo. Y para mantener las cosas pequeñas con el tiempo, Feedback Pipeline también detecta automáticamente incrementos de tamaño y potencialmente abre errores de Bugzilla para rastrear/corregir/justificar dichos incrementos transparentemente.

Un enfoque activo en la minimización significa que nuestros mantenedores producen contenido de tamaño optimizado con el mismo o menor esfuerzo. Las herramientas, los servicios y los datos les ayudan a tomar la decisión correcta sobre las dependencias fácilmente y mantener las cosas lo más pequeñas con el tiempo.

Identificar casos de uso relevantes y permitir a la comunidad (lo que significa no solo el Minimization Team (Equipo de Minimización) definir lo suyo. Pensamos en un caso de uso como un conjunto de paquetes instalados en un contexto específico, que tiene un propósito específico — como Apache HTTP Server Container. Define casos de uso para al menos:

También, considere mirar casos de uso nativos de contenedores, como:

Recoja casos de uso específicos hablando con gente en eventos tecnológicos, foros de internet y cualquier otro lugar viable.

Servicios extendidos de monitorización (Conducto Comentario) que:

Además de las funciones, también necesitamos:

Ser capaz de ver lo que está sucediendo es un requisito previo para implementar cualquier cambio. Ver todas las oportunidades relevantes nos ayuda a enfocarnos en las que tengan mayor impacto, un seguimiento transparente nos ayuda a demostrar la utilidad de nuestro trabajo y centrarse aún más en las actividades de mayor impacto.

Minimizar el tamaño de la instalación de los casos de uso optimizando dependencias RPM, funciones, arquitectura software y otros factores. Específicamente, buscar:

Interactúe con los desarrolladores upstream en relación con cambio más importantes en el empaquetamiento y la arquitectura. Un ejemplo es Systemd y la división del paquete systemd-sysuser.

Implementar procesos y política de cambios que reflejen cambios mayores y más generales. De nuevo, un buen ejemplo es usar Systemd en contenedores o el tema general de crear usuarios en contenedores.

Proporcionar directrices para la comunidad Fedora en forma de publicaciones en blog, videos y charlas en conferencias. Aunque tengamos directrices y políticas vigentes, siempre es importante hacer correr la voz.

Recursos en la nube para crear prototipos de servicios. No vamos a cambiar la infraestructura de Fedora de ninguna manera antes de que lo que desarrollemos resulte útil y valga la pena la estabilización y el cambio de producción.

No son necesarios en este momento recursos existentes de Fedora Infra o Release Engineering. Sin embargo, podemos necesitar ayuda con la configuración (o lograr el acceso a) los recursos en la nube.

Es definitivamente necesario el soporte activo de nuestros mantenedores, el FPC y otros miembros de la comunidad. Obviamente, esto no es algo que podamos "solicitar", pero sigue siendo un aporte necesario.

La utilidad sobre el tamaño: Hay un balance entre la utilidad y el tamaño. Lo tendremos en cuenta y no implementaremos cambios drásticos que puedan evitar que nuestros usuarios utilicen Fedora. Sin embargo, nada nos impide producir artefactos adicionales muy específicos y mínimos.

Usar RPM: Estamos haciendo esto con RPM. No estamos alcanzando esto eliminando archivos después de la instalación. Esto puede parecer obvio, pero aún así merece la pena mencionarlo.