Objectif de minimisation de Fedora

Bien que Fedora soit bien adaptée aux stations de travail et aux serveurs physiques/virtuels traditionnels, les cas d’utilisation hors des installations traditionnelles sont souvent négligés.

Certains types de déploiements modernes — tels que l’IdO et les conteneurs — sont assez sensibles à la taille. Pour l’IdO, il s’agit généralement de connexions de données lentes (pour les mises à jour/la gestion), tandis que pour le nuages et les conteneurs l’échelle est massive.

Un exemple spécifique est Systemd — tout en étant très utile (tout le monde aime Systemd) et étant toujours présent sur les systèmes physiques, il est rarement nécessaire dans les conteneurs. Ce n’était donc pas un problème pour les paquets d’exiger Systemd juste pour créer des utilisateurs avec systemd-sysusers. Cependant, pour les conteneurs, cela signifie une augmentation significative de la taille.

En outre, tous les types de déploiements bénéficient d’une taille réduite, car il existe une relation directe entre l’empreinte de l’installation et la surface d’attaque et les CVE correspondants.

Des milliers de contributeurs individuels et d’entreprises collaborent au sein de la communauté Fedora pour explorer de nouveaux problèmes et pour construire un système d’exploitation moderne en évolution rapide avec un riche écosystème leur permettant d’expérimenter la modernisation de leur infrastructure.

Aider les développeurs de logiciels libres, les administrateurs système et les mainteneurs de distributions Linux à se concentrer sur ce qui les intéresse.

Fedora est une plateforme populaire, car son écosystème est à la fois à la pointe du progrès et bien optimisé pour les déploiements modernes tels que pour l’IdO et les conteneurs. C’est pourquoi de nombreuses personnes utilisent Fedora plutôt que de construire et d’assembler leurs propres artéfacts directement à partir de projets en amont. Et cela soulage la pression sur les développeurs de logiciels libres causée par les utilisateurs qui, autrement, demanderaient que leurs problèmes de sécurité et autres problèmes spécifiques soient rapidement résolus.

Ainsi :

Les cas d’utilisation spécifiques sont définis dans Fedora. La communauté se concentre ensuite sur ces cas d’utilisation avec le développement et la maintenance, l’optimisation (comme la minimisation) et les tests (comme l’intégration continue et le gating). Ces cas d’utilisation peuvent être hiérarchisés de manière transparente pour les ressources d’infrastructure en fonction des intérêts de la communauté.

Feedback Pipeline surveille activement chaque cas d’utilisation et enregistre la taille et les dépendances nécessaires à son fonctionnement. L’historique des données est conservé et affiché pour voir les changements dans le temps. Et pour que les choses restent petites au fil du temps, Feedback Pipeline détecte également automatiquement les augmentations de taille et ouvre potentiellement automatiquement des bogues Bugzilla pour suivre/corriger/justifier ces augmentations de manière transparente.

Une attention active à la minimisation signifie que nos mainteneurs produisent des contenus de taille optimisée avec un effort égal ou inférieur. Les outils, les services et les données les aident à prendre facilement la bonne décision concernant les dépendances et à réduire la taille des contenus au fil du temps.

Identifier les cas d’utilisation pertinents et permettre à la communauté (pas seulement à l’équipe de minimisation) de définir les leurs. Nous considérons les cas d’utilisation comme un ensemble de paquets installés dans un contexte spécifique, ayant un but précis — tel que Conteneur Serveur Apache HTTP. Définissez des cas d’utilisation au moins pour :

Il faut également envisager de se pencher sur les cas d’utilisation de conteneurs natifs, par exemple :

Recueillir des cas d’utilisation spécifiques en discutant avec des personnes lors d’évènements technologiques, de forums Internet et de tout autre évènement viable.

Services de monitorage étendu (Feedback Pipeline) qui :

Outre les fonctionnalités, nous devons également :

Pouvoir voir ce qui se passe est une condition préalable à la mise en œuvre de tout changement. Voir toutes les opportunités pertinentes nous aide à nous concentrer sur celles qui ont le plus d’impact, et un suivi transparent nous aide à prouver l’utilité de notre travail et à nous concentrer davantage sur les activités les plus percutantes.

Minimiser la taille d’installation des cas d’utilisation en optimisant les dépendances RPM, les fonctionnalités, l’architecture logicielle et d’autres facteurs. Plus précisément, vérifier :

Prendre contact avec les développeurs en amont concernant des changements plus importants dans le packaging et l’architecture. Un exemple est Systemd et la division du paquet systemd-sysuser.

Mettre en œuvre des changements de processus et de politique reflétant des changements plus importants et plus généraux. Encore une fois, un bon exemple est l’utilisation de Systemd dans des conteneurs, ou la question générale de la création d’utilisateurs dans des conteneurs.

Fournir des conseils à la communauté Fedora sous forme de billets de blogue, de vidéos et de conférences. Même si nous avons mis en place des directives et des politiques, il est toujours important de faire passer le message.

Des ressources dans le cloud jusqu’aux prototypes de services. Nous n’allons en aucun cas modifier l’infrastructure existante de Fedora avant que ce que nous développons ne s’avère utile et ne vaille la peine d’être stabilisé et de modifier la production.

Aucune ressource d’infrastructure Fedora ou d’ingénierie de publication n’est nécessaire pour le moment. Cependant, nous pourrions avoir besoin d’aide pour mettre en place (ou obtenir l’accès) aux ressources du cloud.

Le soutien actif de nos mainteneurs, du FPC et d’autres membres de la communauté est absolument nécessaire. Ce n’est évidemment pas quelque chose que nous pouvons « demander », mais cela est tout de même un apport nécessaire.

Utilité plutôt que taille : Il y a un équilibre entre l’utilité et la taille. Nous gardons cela à l’esprit et ne mettrons pas en place de changements drastiques qui empêcheraient nos utilisateurs d’utiliser Fedora. Cependant, rien ne nous empêche de produire des artéfacts supplémentaires très spécifiques et minuscules.

Utiliser les RPM : Nous utilisons les RPM. Nous n’atteignons pas la minimisation en supprimant les fichiers après l’installation. C’est peut-être évident, mais ça vaut quand même la peine de le mentionner.