O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Versões e atualizações de kernel estável

O modelo de lançamento estável do kernel Linux começou em 2005, quando foi determinado que o modelo de desenvolvimento de kernel existente (um novo lançamento a cada 2-3 meses) não atendia às necessidades da maioria dos usuários. Os usuários queriam correções de bugs feitas durante esses 2-3 meses, e as distribuições do Linux acharam difícil manter os kernels atualizados sem feedback da comunidade do kernel. Em geral, as tentativas de manter os kernels individuais seguros e com as últimas correções de bugs foi um esforço grande e confuso de muitos indivíduos diferentes.

Lançamentos estáveis ​​de kernel são baseados diretamente nos lançamentos de Linus Torvalds e são lançados a cada semana ou mais, dependendo de vários fatores externos (época do ano, patches disponíveis, carga de trabalho do mantenedor, etc.). A numeração das versões estáveis ​​começa com o número da versão do kernel e um número adicional é adicionado ao final dela. Por exemplo, o kernel 4.4 é lançado pela Linus, e as versões estáveis ​​do kernel baseadas neste kernel são numeradas como 4.4.1, 4.4.2, 4.4.3 e assim por diante. Esta sequência é geralmente encurtada com o número 4.4.y quando se refere a uma árvore de lançamento de kernel estável. Cada árvore de lançamento de kernel estável é mantida por um único desenvolvedor de kernel, que é responsável por escolher os patches necessários para o lançamento e gerenciar o processo de revisão / lançamento.

Kernels estáveis ​​são mantidos durante todo o ciclo de desenvolvimento atual. Após o Linus lançar um novo kernel, a árvore de lançamento do kernel estável anterior é interrompida e os usuários devem migrar para o kernel lançado mais recente.

Kernels estáveis ​​de longo prazo

Após um ano desse novo processo de lançamento estável, foi determinado que muitos usuários diferentes do Linux queriam que um kernel tivesse suporte por mais do que apenas alguns meses. Em resposta, o lançamento do kernel Long Term Supported (LTS) foi criado, com o primeiro kernel LTS (2.6.16) lançado em 2006. Desde então, um novo kernel LTS foi selecionado uma vez por ano e a comunidade do kernel mantém esse kernel por um mínimo de 2 anos.

No momento em que este livro foi escrito, os kernels LTS eram as versões 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y e 5.10.y. Um novo kernel é lançado semanalmente. Devido às necessidades de alguns usuários e distribuições, alguns kernels mais antigos adicionais são mantidos por desenvolvedores de kernel em um ciclo de lançamento mais lento. Informações sobre todos os kernels estáveis a longo prazo, que é responsável por eles, e quanto tempo eles serão mantidos, podem ser encontrados no kernel.org libera página.

Os lançamentos do kernel LTS, em média, são aceitos de 6 a 8 patches por dia, enquanto os lançamentos normais do kernel estável contêm de 10 a 15 patches por dia. O número de patches varia por lançamento, considerando a hora atual do lançamento do kernel de desenvolvimento correspondente e outras variáveis ​​externas. Quanto mais antigo é um kernel LTS, menos patches são aplicáveis ​​a ele, pois muitas correções de bugs recentes não são relevantes para kernels mais antigos. No entanto, quanto mais antigo for um kernel, mais difícil será fazer o backport das alterações que precisam ser aplicadas, devido às alterações na base de código. Portanto, embora possa haver um número menor de patches gerais sendo aplicados, o esforço envolvido em manter um kernel LTS é maior do que manter o kernel estável normal.

Regras de patch de kernel estável

As regras para o que pode ser adicionado a uma versão estável do kernel permaneceram quase idênticas desde sua introdução e estão resumidas abaixo:

  • Deve estar obviamente correto e testado.
  • Não deve ter mais de 100 linhas.
  • Deve consertar apenas uma coisa.
  • Deve corrigir algo que foi relatado como um problema.
  • Pode ser um novo id de dispositivo ou peculiaridade de hardware, mas não adiciona novas funcionalidades importantes.
  • Já deve estar mesclado na árvore de Linus Torvalds.

A última regra, "Já deve ser fundido na árvore de Linus Torvalds", evita que a comunidade do kernel perca as correções. A comunidade nunca quer uma correção para um lançamento de kernel estável que ainda não esteja na árvore de Linus Torvalds, de forma que qualquer um que fizer upgrade nunca verá uma regressão. Isso evita muitos problemas que outros projetos que mantêm um branch estável e de desenvolvimento possam ter.

Atualizações de kernel

A comunidade do kernel do Linux prometeu a sua base de usuários que nenhuma atualização jamais quebrará qualquer coisa que esteja funcionando atualmente em uma versão anterior. Essa promessa ainda é válida hoje. Regressões acontecem, mas esses são os bugs de maior prioridade e são corrigidos rapidamente ou a alteração que causou a regressão é rapidamente revertida da árvore do kernel do Linux.

Essa promessa é verdadeira tanto para as atualizações estáveis ​​incrementais do kernel, quanto para as atualizações principais maiores que acontecem a cada três meses. No entanto, a comunidade do kernel só pode fazer essa promessa para o código que é mesclado na árvore do kernel do Linux. Qualquer código que é incorporada pela semente de um dispositivo que não está nos kernel.org lançamentos é desconhecida e interações com ela nunca pode ser planejado, ou mesmo considerado.

Dispositivos baseados em Linux que têm grandes conjuntos de patches podem ter grandes problemas ao atualizar para kernels mais novos, devido ao grande número de alterações entre cada versão (10-14 mil alterações por versão). Os conjuntos de patches SoC são especialmente conhecidos por terem problemas com a atualização para kernels mais recentes devido ao seu grande tamanho e à modificação pesada do código do kernel específico da arquitetura e, às vezes, do núcleo. Como resultado, a maioria dos fornecedores de SoC está começando a padronizar o uso de versões LTS para seus dispositivos, permitindo que esses dispositivos recebam atualizações de bug e segurança diretamente da comunidade do kernel Linux.

Segurança

Ao fazer lançamentos de kernel, a comunidade do kernel Linux quase nunca declara mudanças específicas como correções de segurança. Isso se deve ao problema básico da dificuldade em determinar se uma correção de bug é uma correção de segurança ou não no momento da criação. Além disso, muitas correções de bugs só são determinadas como relacionadas à segurança depois de muito tempo, então a comunidade do kernel recomenda sempre pegar todas as correções de bugs que são lançadas.

Quando problemas de segurança são relatados à comunidade do kernel, eles são corrigidos o mais rápido possível e colocados publicamente na árvore de desenvolvimento e nas versões estáveis. Conforme descrito acima, as mudanças quase nunca são descritas como uma "correção de segurança", mas se parecem com qualquer outra correção de bug do kernel. Isso é feito para permitir que as partes afetadas atualizem seus sistemas antes que o relator do problema o anuncie.

Para mais detalhes sobre relatar bugs de segurança para a comunidade do kernel para obtê-los resolvido e corrigido o mais rápido possível, referem-se a bugs de segurança no guia do usuário do kernel Linux e administrador da AT www.kernel.org .

Como os bugs de segurança não são anunciados ao público pela equipe do kernel, os números CVE para problemas relacionados ao kernel do Linux geralmente são lançados semanas, meses e às vezes anos depois que a correção foi incorporada aos branches stable e development.

Manter um sistema seguro

Ao implantar um dispositivo que usa Linux, é altamente recomendável que todas as atualizações do kernel LTS sejam obtidas pelo fabricante e enviadas para seus usuários após o teste adequado mostrar que a atualização funciona bem. Isso tem várias vantagens:

  • As versões foram revisadas pelos desenvolvedores do kernel como um todo, não em partes individuais.
  • É difícil, senão impossível, determinar quais patches corrigem problemas de "segurança" e quais não. Quase todo lançamento LTS contém pelo menos uma correção de segurança conhecida, e muitas ainda "desconhecidas".
  • Se o teste mostrar um problema, a comunidade de desenvolvedores do kernel reagirá rapidamente para resolver o problema.
  • As tentativas de filtrar apenas as alterações executadas resultarão em uma árvore do kernel que é impossível mesclar corretamente com versões futuras do upstream.