Dúvida sobre kernel em distribuições LTS

Estou pensando em usar uma distribuição LTS. Além do Debian e Ubuntu, vi que tem o Rocky Linux e o Opensuse Leap.
Não entendo muito sobre como funciona as atualizações de kernel em distribuições LTS. Vi que o Ubuntu 24.04 que está no kernel 6.8 receberá o kernel 6.11 futuramente. Alguém sabe se as outras distros que eu citei também seguem essa mesma forma de atualizar o kernel LTS?
Minha idéia era ficar em um kernel inferior ao 6.10 sem ter problemas de segurança etc. Eu sei que chegará um dia que não vai dar para ficar com kernel antigo, mas por enquanto queria ficar no <=6.9.

Acho que não existe uma regra geral, sobre qual Kernel cada distro vai usar – nem sobre o significado que cada um atribui à sigla “LTS”.

No Kernel-ORG, os significados atualmente são estes:

Isso não tem relação alguma com a sigla LTS da Canonical – lançamentos bienais em Abril – em geral, usando algum Kernel que não é LTS.

No Arch, eu instalei “Kernel LTS” – e o que tenho no momento é “6.6.56-1-lts”.

No Manjaro, também escolhi “Kernel LTS” – e o que tenho no momento é “5.10”.

5 curtidas

Acho que podemos resumir o LTS como: uma versão que recebe apenas atualizações de segurança e correções de bugs específicos, só! Nada de novas features ou aprimoramentos, apenas manutenção para manter a estabilidade e segurança. É pensado para ser uma rocha.

Para um usuário comum, pode ser um porre, pois vc vai perder várias atualizações de performance e QoL, mas se você precisa de um ambiente extremamente confiável e sólido, LTS é o caminho.

6 curtidas

Acho que não é tão simples assim:

Isso que você descreve, é o que o Debian chama de “estável”.

No Debian, não existe “calendário” a ser cumprido, com data pré-estabelecida. – Em geral, uma versão “estável” do Debian costuma durar +/- 2 anos. – Depois que lança a “estável” seguinte, a anterior torna-se “old-stable”, e ainda recebe manutenção (não sei os detalhes exatos).

Na Canonical, tanto as LTS quanto as “intermediárias” costumavam ser como você descreveu (não sei se ainda é assim). – A diferença era que “LTS” recebe “suporte de longo prazo” (3 ou 5 anos) – enquanto as “intermediárias” tinham suporte só por (9 meses?).

Digo que “não sei se ainda é assim”, porque não uso Kubuntu desde 2019.

O Mint utiliza como base versões LTS do Ubuntu – mas há muito tempo, introduziu um “gerenciador de Kernel”, que facilita muito a instalação / remoção de Kernel – tanto para um número “mais novo”, quanto para um número “mais antigo”.

Esse Gerenciador de Kernel funciona, porque a Canonical mantém vários Kernels disponíveis no repositório do LTS que o Mint utiliza como base. – Tenho a vaga impressão de que nas revisões X.1, X.2, X.3 o Mint mudava de Kernel, mas realmente não posso garantir. Talvez, só quando reinstalava? Ou também quando se faz upgrade de “versão de ponto”?

Vi Gerenciador de Kernel no Manjaro (desde muitos anos), no finado Sabayon – e agora também no MX Linux (Debian stable). – Por isso, imagino que mesmo o Debian Stable permite opções.

O Fedora tem versões “de lançamento fixo”, mas não lembro se mantém o mesmo Kernel, ou se muda de Kernel espontaneamente dentro de uma versão. – A verdade é que não presto a menor atenção (uso o Kernel que vier, com raras exceções).

O Mageia, sim, me chamou atenção, porque suas versões de “lançamento fixo” (em geral, de 2 anos), de repente, mudavam de Kernel – com versões sempre super novas.

@SobDex falou “LTS”, referindo-se ao Debian, Rocky Linux e openSUSE Leap, mas acho meio estranho. – Nunca ouvi falar em “Debian LTS”. – No tempo em que usei openSUSE Leap (2017-2019), também nunca ouvi falar de “Leap LTS”.

2 curtidas

Fiz uma confusão mesmo com o termo LTS :rofl: :rofl:
O certo seria “lançamento fixo” talvez?

Mas, no geral entendi tua resposta. Cada distribuição lida com o kernel de forma diferente… Talvez o debian 12 seja o que mais segure a versão do kernel.

É que depois do kernel 6.10 começou aparecer uns erros no journalctl que não apareciam antes.

1 curtida

Então, para esse meu pc que quero por uma distro LTS não tem problema ter pacotes antigos etc. Vai ser só para trabalho, office, internet/wordpress. No meu notebook principal uso o Arch e lá, por ser bleeding edge e roling release os programas mudam com muita frequência. Além da máquina estar apresentando uns erros quando usa um kernel acima de 6.9 quando usa wayland

1 curtida

No caso, eu estava falando só sobre o kernel em si.

Um kernel LTS é só um kernel que é estável o suficiente para produção, que será mantido assim, estável, congelando-se a introdução de novas features e etc., fazendo-se apenas correções de segurança. E a versão definida como LTS terá suporte apenas durante o período especificado, isso para que todos possam se programar, migrar, atualizar, enfim, estar pronto para mudar de versão quando o EOL chegar.

No seu print, por exemplo, o kernel 5.4 é um LTS e pode muito bem ser usado em um ambiente de produção hoje, pois é estável e sua segurança está em dia. Claro, o kernel 5.4 não tem as melhorias de desempenho e features do 6.1, mas ainda é um kernel totalmente viável e continuará assim até 2025. Se vc usa o 5.4 hoje, vc sabe que em 2025 ele deixará de ser viável, então vc tem tempo mais que suficiente para testar/validar e migrar sua aplicação/ambiente/etc para uma versão mais nova.

As distros seguem mais ou menos esse princípio, com prazos mais curtos.

3 curtidas

Pacotes antigos não são pacotes ruins, só são antigos.

Eu uso Debian justamente pq gosto de ter tempo para me ajustar. Tem pessoas que gostam de ver tudo virando de cabeça para baixo todos os dias, tudo bem, cada um é cada um.

Na verdade, hoje em dia, o desenvolvimento open-source consolidado, no geral, é bem consciente sobre a politica de “manter funcional”, então mesmo as distros bleeding edge não saem se quebrando sempre que uma feature é lançada.

Via de regra, é o seguinte:

O PC é para trabalho/educação? = LTS; ou
É crucial o PC estar 100% disponível e operacional? = LTS

O PC é para lazer? = Bleeding Edge; ou
Se o PC não estiver funcionando eu vou fazer outra coisa e eu posso voltar depois para resolver? = Bleeding Edge.

2 curtidas

Acho que não existem palavras ou expressões 100% garantidas – porque não existe uma “autoridade padronizadora” para zelar por significados “biunívocos” – onde um termo tem só 1 significado, e para cada significado exista só 1 termo…

“Lançamento fixo” significa que não é “rolling release” (e vice-versa) – mas veja o exemplo do Mageia, que de repente introduz um Kernel “de ponta” (ou quase) em um “lançamento fixo” que já existia, e que no início usava outro Kernel menos recente. – No fundo, cada distro estabelece suas próprias regras. Então, nada é 100% garantido.

É possível, embora eu não possa confirmar, porque uso Debian Testing – que no momento já está com Kernel 6.10.

Pelas notas de lançamento, o Debian 12 foi lançado com Kernel 6.1 – e vejo que meu MX Linux também está com Kernel 6.1.

Uma correção: – Onde eu disse que nunca ouvi falar em “Debian LTS” – Acabo de ouvir! :grimacing:

O ciclo de vida do Debian 12 abrange 5 anos: os 3 anos iniciais de suporte total ao Debian, até 10 de junho de 2026, e 2 anos de Suporte de Longo Prazo (LTS), até 30 de junho de 2028.

Eu já tive essa mesma impressão que você está tendo:

Eu estava muito feliz com o Kernel 4.4 no Kubuntu 16.04 LTS – e comecei a “sentir” que havia algum problema com as distros que vieram com / ou instalaram outra versão mais nova – acho que Kernel 4.9 (não lembro exatamente).

Depois, vi que não tinha nenhum problema com outras versões ainda mais novas – digamos, Kernel 4.14 e 4.16. – É como se o “problema” fosse só com uma versão (digamos, 4.9); mas não com outras que vieram depois… Ou talvez, o problema fosse a implementação do Kernel 4.9 em determinada distro… Ou talvez o problema estivesse “na distro” (em determinado momento), e não no Kernel.

Depois disso, nunca mais tive certeza de nada. :joy:

O fato é que não preciso de Kernel super-hiper-ultra “de ponta” – porque meu hardware continua o mesmo de 4 anos atrás. – Se algum Kernel super-recente funciona, tudo bem.

O único problema que tenho certeza que foi causado por um Kernel, foi quando o Arch parou de carregar. – Pesquisei as palavras-chave das mensagens de erro, e vi que realmente, era o Kernel. – Fiquei sabendo que o Arch não altera os pacotes recebidos de upstream. Eu tinha instalado o Kernel “corrente”, e todos concordaram que o problema estava nele. – Foi quando instalei o Kernel LTS no meu Arch, e tudo se resolveu.

Ah, tá. – Eu tinha pensado que você se referia à distro (em vez de ao Kernel).

2 curtidas

Comigo desde o 6.10 no Arch já aparece um erro quando entro pelo wayland e o erro está no 6.11 também. Tomara que futuramente resolvam, já vi algumas postagens de outras pessoas relatando o mesmo bug.

Talvez esse seja o meu caso. Tenho os dois kernels instalados, o lts 6.6 e o arch-6.11 (corrente). Apenas o kernel corrente apresenta os erros, no Kernel LTS está tudo uma maravilha, meu medo é quando o LTS chegar no 6.10 e o problema aparecer denovo :joy:.

Vlw pela resposta

1 curtida

O fedora atualiza o kernel constantemente, praticamente alinhado com o mainline do linus, mas sempre mantém 3 versões antigas do kernel instaladas, no momento estou rodando 6.11, mas tenho a 6.9 e 6.6 no “backup” para bootar no grub

1 curtida

Só receberá um kernel mais novo quem instalar o kernel Hardware Enablement (HWE) manualmente ou quem fizer uma instalação do Ubuntu a partir da versão 24.04.2.

Mesmo que seu sistema venha com o HWE ativado, será possível instalar o kernel 6.8, pois este é o kernel General Availability (GA) do Ubuntu 24.04.

As distros LTS que você citou ficam presas na mesma versão de kernel.

O Mint sempre ficava na mesma versão de kernel, mas isso mudará porque o Mint passará a usar os kernels HWE.

Embora eu prefira distros LTS, eu reconheço que existem desvantagens consideráveis em usar pacotes antigos, principalmente quando o hardware da pessoa é recente.

Uma vantagem que o Windows tem sobre o Linux é o fato de receber novas funcionalidades, mas mudar pouco.

1 curtida

Verdade:

Venci a preguiça, e fui olhar meus registros:

Fiz upgrade para Fedora 40 no dia 28 Abril, e ele instalou:

  • Kernel 6.8.7-300.fc40

Atualmente – após atualização no último Domingo:

$ ls -1 | grep config
config-6.10.10-200.fc40.x86_64
config-6.10.12-200.fc40.x86_64
config-6.10.7-200.fc40.x86_64

Não recebe correção de bug, o período para correção de bug é os email entre os desenvolvedores e dps apenas no período de rc, dps disso é apenas vulnerabilidades detectadas no kernel main e o código da correção do main é aplicado em todos os LTS vulneráveis, nenhuma vulnerabilidade detectada nos kernel LTS são corrigidas sem antes serem corrigidas no main, todos os códigos que entram na LTS foram portados do kernel main.

Se um bug fatal para o seu hardware estiver presente nas versões do kernel LTS, pois bem, vc vai ter que ir para o main, eles não recebem correção de bug.

Isso é a forma em que o desenvolvimento do kernel.org funciona, o Debian é um sistema operacional, apesar de algumas distros fornecerem as suas próprias versões do Linux, os patchs saem do kernel.org. Essas distros tem um monte de trabalho para fazer, cuidar de um kernel próprio sem puxar nada do kernel.org é preciso um esforço técnico muito grande, e talvez por isso o kernel Hurd ainda nem ter sido terminado.

2 curtidas

Mantive na minha maquina um sistema operacional(Ubuntu 16.04) por 5 anos. Só atualizei porque a steam removeu o suporte ao 16.04.

1 curtida

O prazo é de 5 anos.

Obrigado mano, tava procurando essa informação por tudo que é lado da internet. Pensei que o HWE era padrao no Ubuntu. Iclusive testei o Ubuntu em live cd e tudo funcionou no hardware.

1 curtida

Estou testando o OpenSuse Leap, estou achando muito bom e confesso que gostei dos ecossistema Yast. Ainda não consegui ver se tem todos os programas que uso no repositório deles.
Pelo que eu entendi, o OpenSuse Leap lança versões menores como por exemplo 15.6 (atualmente) que têm uns 18 meses de suporte, mas quando a versão mudar para 16 ( o que seria a versão principal) o suporte fica até chegar a versão 17.

1 curtida