Objetivo de Minimização do Fedora

Embora o Fedora seja bem adequado para estações de trabalho e servidores físicos/virtuais tradicionais, é frequentemente esquecido para casos de uso além das instalações tradicionais.

Alguns tipos modernos de implantações – como IoT e contêineres – são bastante sensíveis ao tamanho. Para IoT, isso geralmente é lento para conexões de dados (para atualizações/gerenciamento) e para nuvem e contêineres é a escala maciça.

Um exemplo específico é o Systemd – embora seja muito útil (todo mundo adora o Systemd) e esteja sempre presente em sistemas físicos, raramente é necessário em contêineres. Portanto, não era um problema para os pacotes exigirem o Systemd apenas para systemd-sysusers para criar usuários. No entanto, em contêineres, isso significa um aumento significativo de tamanho.

Além disso, basicamente todos os tipos de implantações se beneficiam de um tamanho reduzido, pois há uma relação direta entre a área de cobertura da instalação e a superfície de ataque e os CVEs relevantes.

Milhares de colaboradores individuais e corporativos colaboram com a comunidade Fedora para explorar novos problemas e construir um sistema operacional moderno e veloz com um rico ecossistema que lhes permite experimentar a modernização de sua infraestrutura.

Ajudar os desenvolvedores de código aberto, administradores de sistemas e mantenedores de distribuição do Linux a se concentrarem no que é relevante para eles.

O Fedora é uma plataforma popular porque seu ecossistema é de ponta e bem otimizado para implantações modernas, como IoT e contêineres. Isso faz com que muitas pessoas usem o Fedora em vez de construir e montar seus próprios artefatos diretamente de projetos upstream. E isso alivia a pressão sobre os desenvolvedores de código aberto causada por usuários que, de outra forma, solicitariam que sua segurança específica e outros problemas fossem corrigidos rapidamente.

De forma que:

Casos de uso específicos são definidos no Fedora. A comunidade então se concentra nesses casos de uso com desenvolvimento e manutenção, otimização (como minimização) e teste (como CI e gating). Esses casos de uso podem ser priorizados de forma transparente para recursos de infraestrutura com base nos interesses da comunidade.

O Feedback Pipeline monitora ativamente cada caso de uso e registra o tamanho e as dependências necessárias para sua execução. O histórico de dados é mantido e mostrado para ver as mudanças ao longo do tempo. E para manter as coisas pequenas ao longo do tempo, o Feedback Pipeline também detecta automaticamente aumentos de tamanho e, potencialmente, abre bugs do Bugzilla automaticamente para rastrear/corrigir/justificar tais aumentos de forma transparente.

Um foco ativo na minimização significa que nossos mantenedores produzem conteúdo de tamanho otimizado com o mesmo esforço ou menos. Ferramentas, serviços e dados os ajudam a tomar a decisão certa sobre dependências facilmente e a manter as coisas menores com o tempo.

Identificar os casos de uso relevantes e permitir que a comunidade (ou seja, não apenas a equipe de minimização) defina os seus próprios. Pensamos em um caso de uso como um conjunto de pacotes instalados em um contexto específico, tendo um propósito específico – como Apache HTTP Server Container. Definir casos de uso pelo menos para:

Além disso, considere examinar casos de uso nativos de contêiner, como:

Coletar casos de uso específicos conversando com pessoas em eventos de tecnologia, fóruns na Internet e quaisquer outros locais viáveis.

Estender os serviços de monitoramento (Feedback Pipeline) que:

Além dos recursos, também precisamos:

Ser capaz de ver o que está acontecendo é um pré-requisito para implementar qualquer mudança. Ver todas as oportunidades relevantes nos ajuda a focar nas que têm mais impacto, e um acompanhamento transparente nos ajuda a provar a utilidade do nosso trabalho e a focar ainda mais nas atividades mais impactantes.

Minimizar o tamanho da instalação dos casos de uso, otimizando dependências RPM, recursos, arquitetura de software e outros fatores. Especificamente, procurar:

Envolver-se com desenvolvedores de upstream em relação a mudanças maiores no pacote e na arquitetura. Um exemplo é o Systemd e a divisão do pacote systemd-sysuser.

Implementar mudanças de processo e política refletindo mudanças maiores e mais gerais. Novamente, um bom exemplo é o uso do Systemd em contêineres ou a questão geral de criar usuários em contêineres.

Fornecer orientação para a comunidade Fedora na forma de publicações de blog, vídeos e palestras. Mesmo que possamos ter diretrizes e políticas em vigor, espalhar a palavra é sempre importante.

Recursos de nuvem para serviços de protótipo. Não vamos mudar a infraestrutura existente do Fedora de forma alguma antes que tudo o que desenvolvemos se mostre útil e valha a pena o esforço de estabilização e mudança de produção.

Nenhum recurso existente de Infra ou de Engenharia de Lançamento do Fedora é necessário no momento. No entanto, podemos precisar de ajuda para configurar (ou obter acesso aos) recursos de nuvem.

O apoio ativo de nossos mantenedores, o FPC e outros membros da comunidade é definitivamente necessário. Obviamente, isso não é algo que possamos "solicitar", mas ainda é uma entrada necessária.

Usefulness over size: There is a balance between the usefulness and size. We take that in mind and will not implement drastic changes that would prevent our users from using Fedora. However, nothing prevents us from producing additional very specific and minimal artifacts.

Usando RPM: Estamos fazendo isso com RPM. Não estamos alcançando a minimização excluindo arquivos após a instalação. Isso pode ser óbvio, mas ainda assim vale a pena mencionar.