Linux 7.1

 (lore.kernel.org)
1 pontos por GN⁺ 3 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Linux 7.1 foi distribuído no cronograma regular de lançamento, e a merge window deve abrir logo após o release, embora o andamento inicial possa ser um pouco irregular devido a deslocamentos e fusos horários
  • Este lançamento foi concluído sem mudanças especialmente arriscadas ou chamativas, sendo composto em sua maior parte por pequenas atualizações de drivers e correções de bugs
  • Foram corrigidos vários problemas nas camadas de drivers como USB serial·i2c·GPU(drm)·ALSA, incluindo heap overflow, use-after-free e dereferência de NULL
  • A pilha de rede, como netfilter·mlx5·tcp/ipv6, recebeu correções para falhas de segurança de memória e de validação
  • Áreas como mm·rv·mshv·thunderbolt passaram a incluir tratamento de falha de alocação, validação de entrada e correções relacionadas à virtualização

Visão geral do lançamento

  • O lançamento do Linux 7.1 ocorreu no período regular, mas devido ao fuso horário do local atual, não foi publicado no horário habitual
  • A merge window será aberta no dia seguinte ao lançamento, mas como haverá outro deslocamento de fuso nesse momento, o cronograma pode ficar um pouco irregular
  • Normalmente, o objetivo é adiantar o máximo possível de trabalho nos primeiros dias da merge window, mas desta vez isso pode ser difícil por causa de um voo longo sem notebook e sem internet
  • Alguns pull requests iniciais já foram obtidos antecipadamente, o que permitirá processar parte dos merges mesmo offline

Operação da merge window

  • Pode haver um pequeno atraso, mas a principal notícia deste lançamento é a distribuição do 7.1
  • Chegou a ser considerada a possibilidade de adiar o lançamento em uma semana, mas foi decidido que isso não valia muito a pena
  • Nos próximos dias, o tempo de resposta durante a merge window pode ficar um pouco aleatório, então é pedido entendimento prévio
  • Os testes devem continuar mesmo após o lançamento

Natureza das mudanças da última semana

  • No shortlog da última semana, não há nada especialmente interessante ou assustador em destaque, o que corresponde a um estado normal de lançamento
  • A maior parte das mudanças consiste em pequenas atualizações de drivers
    • As áreas afetadas incluem GPU, rede, som e outros drivers
  • Também estão incluídas correções relacionadas a rede e trace tooling
  • Fora isso, há várias pequenas mudanças dispersas em outras áreas

Principais áreas de correção

  • Nos drivers USB serial, foram corrigidos problemas de heap overflow e bulk-out buffer overflow
  • Na área de rede, foram corrigidos erros e vazamentos em vários subcomponentes, como Open vSwitch, netfilter, SCTP, TCP, IPv6, XDP, RDMA, mlx5 e mvpp2
  • Nas áreas de DRM e GPU, foram corrigidos erros relacionados a amdgpu, xe, i915, virtio, hyperv e colorop, além de problemas de refcount e questões ligadas a suspend e shutdown
  • Em gerenciamento de memória e nas áreas próximas a arquivos e IPC, houve diversas correções para use-after-free, dereferência de ponteiro NULL, refcount leak e resource leak
  • Também foram aplicadas pequenas correções em drivers e ferramentas ligados a I2C, GPIO, SPI, ASoC, cpufreq, firmware, thunderbolt e Hyper-V

Pontos práticos de atenção

  • Este lançamento mostra um fluxo de mudanças mais próximo de um release de correções voltado à estabilização do que de um grande anúncio de recursos
  • Em ambientes que usam drivers, rede e ferramentas de rastreamento, vale verificar os itens de correção por subsistema incluídos no shortlog
  • Foi pedido que os testes continuem após o lançamento, e é preciso considerar a possibilidade de atraso nas respostas no início da merge window

Leituras relacionadas

1 comentários

 
GN⁺ 3 일 전
Comentários do Hacker News

  • Pessoalmente, estou bem animado com este commit que corrige o Wi‑Fi lento que eu tinha na combinação modem/roteador do ISP + notebook
    https://github.com/torvalds/linux/commit/711a9c018ad252b2807...
    Espero que entre logo no Fedora

  • Estou ansioso para testar o novo driver NTFS
    Espero que esta versão seja melhor que o ntfs3 da Paragon

    • Fico curioso sobre o que faltava no driver anterior
      Tenho a impressão de que o suporte a NTFS no Linux serve principalmente para ler e gravar arquivos em discos do Windows, e, para esse uso, os drivers NTFS do Linux — incluindo o driver baseado em FUSE anterior ao da Paragon — me pareciam bons o suficiente
    • Está bom
      Empacotei no meu overlay do Gentoo e venho usando há alguns meses, e não tem os problemas estranhos que eu via no ntfs3

  • O padrão atual do Arch é 7.0.10
    Estou esperando o 7.1 entrar no rolling em breve

    • No Fedora, acho que vai levar alguns meses
      No momento está em 7.0.12

  • Empurrar para fora do kernel códigos muito antigos e quase sem uso para reduzir relatórios de bugs assistidos por IA é, na minha opinião, um dos melhores resultados que a IA trouxe
    Gosto disso
    Agora precisamos começar a cortar um pouco da gordura de tudo

    • Foi esse tipo de pensamento que fez organizações comprarem máquinas novas porque desktops perfeitamente bons não conseguiam rodar Windows 11
      Eu ainda uso servidores com 10 anos de idade, e eles rodam bem no Linux
    • “A perfeição é alcançada não quando não há mais nada a acrescentar, mas quando não há mais nada a remover.” — Antoine de Saint-Exupéry
      Um dos meus amigos ficou infame por um tempo como o cara do hoje apaguei X linhas de código
    • Já tentei enviar código para tirar drivers antigos da build do kernel em algumas distribuições, mas tudo foi rejeitado
      Até o Torvalds dizer que está tudo bem, todo mundo tem medo de quebrar a experiência do usuário
    • Talvez tenha sido uma piada à primeira vista, mas quando li entendi como remover vetores de ataque que mexem com funcionalidades quase não usadas no Linux
      Pelo menos em sistemas operacionais de celular, formatos e recursos estranhos e raros eram — ou ainda podem ser — uma fonte comum de bugs exploráveis
    • Como o usuário final pode não atualizar, seria bom ter uma definição de hardware obsoleto
      Para mim, toda impressora da HP é obsoleta, mas outra pessoa pode ter um critério totalmente diferente e igualmente válido
      Fico curioso sobre como isso é definido no caso de hardware de computador

  • Há algo particularmente interessante nesta versão?
    Acho que o primeiro número da versão só muda quando o segundo fica grande demais, e não por outro motivo

  • Mais alguém viu um avatar animado passando muito rápido pouco antes do conteúdo carregar? O que era aquilo?

  • Plantão: Linus está em movimento
    Perdi alguma coisa ou é só mais um número?

    • Mudanças de número ficam meio sem graça quando não trazem nenhuma grande transformação nem tentam melhorar tudo de uma vez
      Ainda assim, a vontade de não ficar de fora quando o número muda impulsiona a sensação de novidade, e isso tem a vantagem de tornar o ciclo de melhorias mais frequente
      As coisas interessantes e arriscadas sempre ficam atrás de flags, então, se isso realmente importa para você, dá para compilar, configurar e fazer benchmark do kernel e do sistema por conta própria
    • “De qualquer forma, pode haver alguns soluços na merge window, mas a notícia de hoje é o 7.1.”
      “Nada particularmente interessante ou assustador salta aos olhos, e é assim que deve ser.”
      Então, sim, é só um número
    • Surpreende que ninguém se ofereça para pagar o Wi‑Fi de bordo do Linus
      Em retorno por dólar gasto, provavelmente seria uma das melhores despesas possíveis!

  • Dá para assumir com segurança que no Debian Stable veremos isso por volta de 2036?

    • As versões mais recentes do kernel Linux saem na ordem 7.1, 7.0, 6.19, 6.18, …
      https://en.wikipedia.org/wiki/Linux_kernel_version_history
      O 7.0 já está no forky (atual testing) e também é oferecido como backport para o trixie (atual stable)
      https://packages.debian.org/search?keywords=linux-image-amd6...
      https://packages.debian.org/trixie-backports/linux-image-amd...
      O kernel padrão do trixie/stable é o 6.12, lançado pela primeira vez em novembro de 2024, com suporte oficial upstream até dezembro de 2028
    • Eu sei que é meme, mas uso kernel via backports no Debian Stable e estou no 6.19
      No momento, ele está só uma versão menor atrás do 7.0
      Queria que mais gente considerasse Debian para seus dispositivos. Gosto do fato de ser um sistema muito estável e, ao contrário do Ubuntu, a experiência realmente foi de “simplesmente funciona”, sem o atrito que aparece em distros menores
      Instalei o Debian Trixie quando ele ainda era Testing em um hardware bem recente; alinhei tudo para AMD por compatibilidade, mas todos os drivers de que eu precisava estavam lá
      Agora só queria descobrir como compilar pacotes para poder contribuir com o Debian, e também seria bom se a AMD organizasse direito o suporte a NPU no Linux
    • No Debian, é bem fácil compilar pacotes de kernel diretamente a partir do código-fonte vanilla
      Eu costumo subir para o 7.0.x mais recente poucas horas depois do lançamento
      Dependendo de quanto tempo você gastar revisando o ChangeLog, a compilação leva algo entre 30 e 45 minutos. Pode variar conforme o ambiente
    • Talvez a pergunta não seja séria, mas respondendo seriamente mesmo assim: nunca me preocupei com qual kernel estou usando no Debian Stable
      Se quiser um kernel mais novo, dá para usar o Debian unstable (Sid), que no momento está no 7.0.12. Esse é o equivalente ao kernel do stable atual enquanto o 7.1 é mainline
      Em servidores, o Stable — atualmente o Trixie — funciona perfeitamente bem até com o kernel 6.17.3
      O Debian Forky deve ser lançado por volta de 2027 e, dependendo da situação, vai usar kernel 7.0.x ou 7.1.x
      O kernel usado no testing atual, ou seja, na próxima versão que vai virar stable, é o 7.0.10
    • Quando o Forky/14 sair no ano que vem, não deve incluir essa versão ou uma ainda mais nova?
      O Debian anda devagar, mas se você quer algo rápido, use Arch ou Fedora; ainda assim, o Debian continua avançando