Debian 13 "Trixie" lançado

• O projeto Debian lançou a nova versão estável Debian 13 "Trixie" após aproximadamente 2 anos, 1 mês e 30 dias de desenvolvimento
• O Debian 13 oferece suporte padrão a vários ambientes de desktop, incluindo GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0 e Xfce 4.20
• Foram adicionados mais de 14.100 novos pacotes; o total de pacotes chegou a 69.830, e 8.840 pacotes foram removidos por estarem obsoletos
• Foram atualizados 44.326 pacotes e feita uma grande revisão da base de código; o uso total de disco ficou em 403GB e o número de linhas de código atingiu 1,4 bilhão
• Arquiteturas suportadas: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x
  • O suporte oficial ao riscv64 foi adicionado pela primeira vez
  • Decisão de encerrar o suporte ao i386: sem kernel oficial e ferramentas de instalação fornecidas, com uso limitado apenas em CPUs de 64 bits
  • A arquitetura armel é o último suporte nesta liberação
• Em todas as arquiteturas, exceto i386, foi aplicada a ABI time_t de 64 bits, com suporte a datas após 2038

• Software e ferramentas de desenvolvimento

  • Mais de 63% dos pacotes totais foram disponibilizados atualizados
  • Principais softwares e ferramentas de desenvolvimento: Apache 2.4.64, Bash 5.2.37, BIND 9.20, curl/libcurl 8.14.1, Emacs 30.1, GNU Compiler Collection 14.2, GIMP 3.0.4, LibreOffice 25.2, Linux kernel 6.12 LTS, LLVM/Clang 19, Python 3.13, Rustc 1.85, Systemd 257, Vim 9.1, entre outros
  • Apropriado para diversas finalidades, como arquitetura, servidor, desktop, cluster, banco de dados, web e armazenamento
  • O processo de garantia de qualidade foi reforçado com testes automatizados de instalação e atualização

• Suporte a nuvem e instalação ao vivo

  • Fornecimento de imagens para serviços de nuvem como Amazon EC2, Microsoft Azure, OpenStack, PlainVM e NoCloud
  • As imagens em nuvem incorporam automação cloud-init e otimização de kernel/bootloader para inicialização rápida de instâncias
  • As imagens live estão disponíveis para amd64, arm64 em formato de DVD, USB e inicialização via rede
  • As imagens live permitem experimentar vários ambientes de desktop e também há uma imagem padrão sem interface gráfica (GUI)
  • É possível instalar com Calamares e o Debian Installer padrão, além de usar diferentes métodos de instalação, como suporte a HTTP Boot

[zihado]

Não sei se quem ficava no canal #debian do IRC ainda está bem. Na época do Debian Potato, eu brincava bastante no IRC... kkk

[jungmin1237]

A tag do Docker também já saiu mesmo.
https://hub.docker.com/layers/library/…

[dongjinahn]

Também estava usando Ubuntu em um VPS de 512 MB de RAM por US$ 2,50/mês e depois migrei para o Debian, e gostei disso. Como já vinha do Ubuntu, ficamos naturalmente familiarizados, e também consome menos memória.

[GN⁺]

Discussão no Hacker News

• Estou escrevendo isso em um sistema Debian e, como sistema de uso diário, estou muito satisfeito em utilizá-lo. Depois que o Ubuntu ficou bem pior do que antes, mudei para o Debian 6 e não me arrependi disso. O que eu gosto no Debian é o equilíbrio entre ideologia e praticidade: por padrão ele prioriza software livre, mas, se necessário, também torna fácil instalar software e firmware non-free, além das diretrizes de pacote, do dpkg e de uma documentação muito robusta (a documentação da Arch é ótima, é verdade). Também é bom ter os fluxos de pacotes stable/testing, para escolher entre a estabilidade de versões mais antigas ou algo mais novo quase estável. Mais importante, salvo quando erro, nunca tive meu sistema quebrar por defeito do próprio Debian. Já houve ocasiões de boot falhar ou de problema sério, e todas foram causadas por algo como adicionar repositório de terceiros ou mexer errado na configuração.

  • Concordo que o Debian é ótimo, mas eu também teria dificuldade em dizer que tenho a mesma experiência de que ele não quebra até eu cometer um erro. Em especial no Debian stable, como há muitos patches aplicados ao kernel, já enfrentei várias quedas difíceis de debugar em que o problema aparece durante backports no subsistema DRM de rápida mudança. O número da versão do kernel parece permanecer o mesmo durante todo o período de lançamento, mas, para reduzir esse estresse de patches, usar kernels atualizados continuamente como o Ubuntu com a linha hwe parece mais adequado. Por isso, uso Debian em VM e Ubuntu em bare metal. Eu nunca tentei usar o kernel do repositório debian-backports.

  • Eu também passei bastante sufoco com problemas de upgrade no Ubuntu Server e acabei deixando de usá-lo. Opero mais de 75 VPS e, em cada atualização de manutenção, já tive muitas experiências de medo com a possibilidade de algum ficar indisponível. Cada recuperação desses incidentes adicionava 1 a 2 horas por VPS. Desde que migramos para Debian lá em torno da versão 8.x em 2015, ficou muito mais estável. Se eu não fizer nada errado, não quebra.

  • Fico curioso para saber em quais pontos você sentiu que o Ubuntu piorou tanto.

  • A única desvantagem que vejo no Debian é que ele tenta iniciar serviços imediatamente ao instalar novos softwares no servidor. Embora a maior parte das configurações padrão seja segura, ainda dá um frio na barriga ver um serviço subir antes de eu configurá-lo. No Red Hat, os serviços só sobem quando eu ligo manualmente, e isso me agrada mais.

  • Debian é a base das operações dos meus servidores. Deixo os servidores em Old Stable e testo funcionalidades de releases novos em sistemas temporários. No Bookworm aprendi nftables e no Trixie experimentei o labwc. O labwc é uma configuração no estilo Openbox com suporte a Wayland.

• Obrigado aos voluntários da comunidade Debian. Vocês que permitiram que Debian e inúmeros projetos baseados nele existam, em especial todos vocês. Muitas pessoas e empresas se beneficiam do trabalho de vocês, de fato. Pessoalmente, estou especialmente animado porque o lançamento do Trixie incluiu o meu projeto paralelo, ntfy, como pacote. Só no fim do ciclo de lançamento do Trixie fiquei sabendo que o mantenedor de pacote fez uma consulta de licença, e no pacote Debian o app web acabou não vindo, além de várias funcionalidades terem sido removidas por patch. Adicionei build tags para facilitar remover Stripe, Firebase e WebPush, então espero que no próximo release Debian haja menos patches. Do ponto de vista de um mantenedor upstream, é frustrante não ter uma orientação clara sobre por que o app web foi removido. Está claro que foi removido de propósito, mas não sei bem o que fazer para colocá-lo no próximo release. Se alguém fizer apt install ntfy e o app web não funcionar, provavelmente ficará decepcionado. Sugestões ou orientações seriam bem-vindas. O código fonte também pode ser útil.

  • O mantenedor do pacote acrescentou uma explicação relacionada: aqui. O app web é baseado em nodejs, e esses pacotes nodejs não existem no Debian. Pela filosofia Debian, evitar incluir diretamente no pacote a origem das dependências. Se você quisesse fazer isso, teria que criar e manter também pacotes de dependência, o que pareceu pesado.

  • A construção de pacote npm no Debian precisa ser possível de fato, então você precisa substituir as dependências npm por pacotes Debian em um package.json específico para Debian, portar para pacotes Debian ou fornecer um pacote separado. Isso pode demandar bastante trabalho, potencialmente bem mais do que imagina. Se o lockfile for grande, o esforço aumenta muito. Provavelmente o mantenedor achou essa carga grande demais. No padrão Debian, parece mais natural oferecer algo separado como ntfy-web.

  • Sou muito grato pelo ntfy. Uso no dia a dia para receber notificações de eventos do meu nó Meshtastic em casa.

  • O software ntfy realmente é ótimo.

  • Se você quiser resolver as questões de dependência, uma alternativa melhor pode ser distribuir como imagem de container.

• O Debian é a base estável da minha vida de computação livre. Aprendi bastante sobre voto Condorcet, consenso processual, tomada de decisão baseada em princípios... Esse projeto e essa cultura tiveram uma influência imensurável no mundo. Parabéns de coração.

• Sobre o i386: enfim saiu o suporte geral. Não tem mais kernel e instalador recentes, e agora é recomendado usar apenas CPUs de 64 bits; para hardware estritamente 32-bit, atualização não é mais recomendada. Foi incrível o suporte até agosto de 2025. Ainda tinha um Debian 10 Buster rodando em hardware baseado em Pentium 3 (EOL em junho de 2024). Fico grato por isso ter durado tanto para poder testar em máquinas antigas. Se alguém ainda quiser um OS moderno em i386, vale considerar o OpenBSD também.

  • Eu achava que tinha parado de usar Pentium 3 por volta de 2007, e agora é possível comprar um PC 100 vezes mais rápido por US$ 1.

  • Se o i386 migrar para a infraestrutura de ports atual (como, por exemplo, m68k), espero que ainda possa ser usado experimentalmente no Debian 14 ou 15.

  • Lembro que o old stable costuma ter suporte estendido por cerca de um ano. Ou seja, mesmo depois de 2025 isso não termina totalmente.

  • Isso é sobre suporte no Debian. O kernel Linux em si continua a suportar CPUs de 32 bits desde o Pentium original (com exceção de alguns chipsets clones).

  • Não foi confusão entre “386” e 32bit, certo? O 686 costuma ser a arquitetura 32-bit de uso geral; o 386 é história dos anos 1980.

• O sysvinit ainda pode ser usado. Já testei em servidor e desktop. Em alguns casos de dependência de pacotes, dá para evitar problemas removendo e instalando simultaneamente com um comando como este abaixo. Pelo bug report do Debian, a parte chave é remover systemd-sysv e systemd com - no final. Com esse método, o build do sysvinit feito com debootstrap fica quase idêntico ao do bookworm (incluindo desktop). Como no bookworm ou buster, basta manter só o libsystemd0 em apt preferences e bloquear os outros pacotes systemd com priority -1.

  • Fico curioso se o Debian 13 também funciona de verdade com sysvinit. Em outras palavras, é possível operar servidor com sysvinit sem systemd?

  • Obrigado por compartilhar. Pelo menos vou avaliar no mínimo em container lxc.

  • Fico curioso sobre o motivo de fazer tudo isso.

• Quem procura onde estão as imagens .torrent para x86-64 pode encontrar os links abaixo:
  Minimal: netinstall ISO
  Full: DVD ISO

  • A maioria dos usuários não precisa da imagem DVD (full). Para instalação, o CD netinstall minimal já é suficiente, pois baixa pacotes durante a instalação.

• As 7 arquiteturas oficialmente suportadas no trixie são:

  • amd64 (PC de 64 bits)
  • arm64
  • armel (ARM EABI)
  • armhf (ARMv7 EABI hard-float)
  • ppc64el (PowerPC little-endian de 64 bits)
  • riscv64 (RISC-V little-endian de 64 bits)
  • s390x (IBM System z)
    Embora exista pouco hardware RISC-V realmente utilizável, fico feliz em vê-lo finalmente tratado como plataforma de primeira linha. Hoje em dia fico curioso onde PowerPC e System z estão sendo usados fora de amd64/arm64/riscv64.

  • Power e z ainda são negócios bilionários. Ambas as arquiteturas são muito usadas no setor financeiro e bancário. A IBM ainda tem orgulho no z, mas no Power dá a impressão de estar apenas em manutenção. O Power é uma arquitetura e um sistema muito bem feitos.

  • Mainframes continuam em cenários onde um único servidor precisa ficar operando por décadas sem parar. Até mesmo processador e memória podem ter hot-swap e há monitoramento/diagnóstico de hardware contínuo independente do serviço de SO. Quando um problema de hardware é detectado, o dono e a IBM recebem alerta automaticamente. Desde o início dos anos 2000 a IBM oferece suporte a Linux como OS de primeira classe em mainframes. Do ponto de vista de quem desenvolve, o s390x ainda é a última arquitetura big-endian remanescente (ainda existe SPARC, mas é basicamente manutenção e a Oracle cuidando de Solaris), e é útil para caçar bugs de endianness. As únicas arquiteturas de 32 bits restantes são armel e armhf, e este é o último release com suporte a armel (referência). Em breve, provavelmente o suporte oficial de 32 bits terminará.

  • A IBM investe bastante para manter essas duas arquiteturas funcionando bem em distribuições principais. Então, diferente de outras arquiteturas, parece que continuam incluídas principalmente por causa do suporte da IBM, em vez de evoluírem naturalmente no ecossistema.

• Se houver preocupação com o tema de naming de NIC no systemd, veja as release notes. Com o comando udevadm dá para verificar previamente se os nomes das interfaces vão mudar após upgrade. Uma one-liner (sem a interface bond/lo) também permite conferir a lista. Nos testes até agora, nunca vi o nome da interface mudar por causa de upgrade, então não tenho certeza se o método acima realmente pega mudanças antecipadas.

  • Talvez essa seja a última grande mudança de naming de interface. O rótulo enoX deveria sempre permanecer estável porque a BIOS (tabelas ACPI etc.) informa qual porta tem qual ID. O formato ensX se baseia em slots PCIe, mas como a árvore PCIe pode permitir várias NICs por slot, isso pode ficar confuso. O systemd já alterou a lógica de naming de interface várias vezes para tratar esses casos de exceção. Antigamente teve conflito por ler indiretamente o número do slot PCIe; isso foi corrigido no systemd 257.

  • Fico curioso se os nomes de interface ainda podem mudar quando o Predictable Network Interface Names do systemd foi desativado antes do upgrade.

• Uso Debian desde o slink. Hoje ainda tenho que digitar apt-get ... e ele ainda funciona com algumas peripécias. Em mais de 25 anos de upgrades tive problemas pequenos e grandes, mas o tempo e esforço eram realmente pequenos perto do de outros Linuxes ou software proprietário. Uma coisa que me arrependo é não ter colaborado mais com a comunidade. Um dos maiores pontos fortes do Debian é que ele pressupõe que o usuário entenda, pelo menos em parte, como o sistema funciona. Por isso, acho que mantém bem a filosofia de “simples o bastante sem ser simplório demais”.

• A principal vantagem do Debian é que a atualização de stable para stable é possível em menos de 15 minutos. No meu primeiro sistema a migração terminou em menos de 10 minutos, incluindo download de pacotes e reboot. Não tinha um computador especialmente potente, nem rede rápida; era um mini PC de 50 Mbps.