"apt" ou "apt-get" — enfim, um motivo prático, concreto

Já faz uns 10 anos que apareceu o comando “apt” – muitas vezes descrito como um “apt-get simplificado”. – Digo “uns 10 anos”, com base nesta postagem de Junho 2016, pois eu realmente não lembro a data exata:

No entanto, o “apt-get” continuou existindo – e sempre foi dito que “não era igual”. – Durante vários anos, tentei entender essa treta… principalmente, quando alguma coisa não dava certo com um, ou com o outro.

Googlei, li as “manpages” de um e do outro, salvei trocentos Bookmarks – mas nunca consegui entender nada.

Até uns 4 anos depois, parece que muitos colegas também não encontraram motivos práticos, concretos, para usar um, ou o outro – afora que digitar “apt” dá menos trabalho do que digitar “apt-get” trocentas mil vezes ao longo da vida. – Digo isso, com base nesse tópico aqui:

Eu também adotei essa “economia de teclagem” – e nunca mais pensei no assunto – já que não ganhei nada, pensando nesse enigma durante anos e anos.

Estou falando de 2 ou 3 situações diferentes: – (1) Debian e derivados diretos, que se mantém “Debian-like”; (2) Buntus seus derivados; (3) Mint e suas modificações, que anotei aqui. – Para evitar um nó-cego nos meus pobres neurônios, nunca pratiquei o uso do “apt” nem do “apt-get” no PCLinuxOS, por se tratar do “APT-RPM”, com regrinhas um tanto diferentes (preferi usar só o Synaptic, nessa distro).

No início de 2025, o apt list --upgradable do meu Debian (testing >> Trixie) começou a “paginar” os resultados. – Uma imagem meramente ilustrativa, que peguei agora no Reddit:

Para não perder tempo, teclo logo “PageDown” 3 ou 4 vezes seguidas, e quando pára no “End”, teclo “Q” para sair (Quit) – supondo que se tratasse de algum “less” embutido no “apt”:

Achei isso, xato pra xuxu! – mas fui procrastinando o dia em que iria tirar um tempinho pra “corrigir” essa bagaça. – Nunca parei de procrastinar, até que…

… hoje, um colega pediu socorro num grupo do Facebook – porque essa bagaça tava atrapalhando um script dele.

Em 8 respostas, várias dicas aleatórias. – Uma ou outra me pareceram razoáveis – mas eu não ia sair do meu Artix só pra testá-las no Debian.

Googlei, encontrei mais 300 dicas (idem, idem)… até encontrar a “Resposta de 1 milhão de dólares”:

1 - Uma advertência que já enjoei de receber, no Konsole – mas até agora “não fazia nenhum sentido” para meus pobres neurônios:

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

2 - Umas sutilezas do “manpages” do “apt” – de que ele fornece uma “interface para usuário final”, com opções melhor adaptadas para “uso interativo” – ao contrário do (compared to) “apt-get”:

apt provides a high-level commandline interface for the package management system. It is intended as an end user interface and enables some options better suited for interactive usage by default compared to more specialized APT tools like apt-get(8) and apt-cache(8).

Much like apt itself, its manpage is intended as an end user interface and as such only mentions the most used commands and options partly to not duplicate information in multiple places and partly to avoid overwhelming readers with a cornucopia of options and details.

Digo “sutilezas”, porque – além de serem escritas num idioma obtuso (inglês), as “manpages” parecem ser escritas por trogloditas de pensamento abstruso – que só eles mesmos entendem, e ninguém mais. :rofl:

Ou seja: – Só entende, quem já sabe. – Quem ainda não sabe, dificilmente consegue entender.

Portanto, se você pretende criar um script, use “apt-get” – cuja interface CLI é “estável” – pois a interface CLI do “apt” está sujeita a mudanças, gracinhas, novidades etc., sem aviso prévio.

(exceto, avisos feitos por trogloditas, para trogloditas).

Isso, para resumir. – Muitas outras coisas passaram a fazer sentido, para mim, pelo menos.

Por exemplo, o help do “apt” omite muita coisa. – Coisas que ele faz – mas tiraram do help, pra não confundir os simples mortais.

Desculpa, mas não consegui entender nada do que escreveu por isso fui procurar no Google e achei esse site da Amazon explicando qual a diferença entre os dois. APT é a versão moderna do APT-GET que junta vários comandos que eram separados no apt get.

3 backends pra fazer o trabalho de 1… Que distribuição.

Isso e resultado de um desenvolvimento instavel.

Salve, @ruanelivelton18

Não sei se entendi corretamente:

  • A quais 3 backends você se refere?

  • A qual distribuição você se refere?

:rofl:

Acho que compliquei demais, ha ha! – Em resumo, o que eu (acho que) entendi hoje, foi isso:

  • “apt” é para uso interativo – e sua interface CLI tenta evitar um excesso de informações – para não sobrecarregar a mente do usuário

  • “apt-get” é para uso automatizado – em scripts, por exemplo

Achei que o AWS se perdeu um pouco – analisando vários detalhes periféricos – e deixou de destacar o essencial.

Por exemplo, onde ele diz – lá no final – como se fosse apenas um detalhe:

Você não precisa substituir os comandos apt-get por comandos apt em nenhum script Linux existente. Eles ainda operam conforme o esperado e o apt-get ainda é compatível. Algumas das funcionalidades dos comandos antigos do apt-get são ligeiramente alteradas no apt, portanto, manter o apt-get nos scripts ajuda a garantir as operações corretas.

Não é que “não precisa substituir”. – É “não deve substituir o apt-get pelo apt em nenhum script existente”.

Não é que “ainda operam conforme o esperado” – É “os comandos apt-get visam continuar operando conforme o esperado” – ao contrário do “apt”.

Não é “ainda é compatível”. – A existência do apt-getvisa manter a compatibilidade”.

Não é “são ligeiramente alteradas no apt”. – O escopo do apt é, exatamente, poder receber alterações em benefício do usuário e da melhor interatividade – sem quebrar as aplicações que usam o apt-get.

Não é “ajuda a garantir as operações corretas”. – A existência / persistência do “apt-get” visa, exatamente, garantir as operações corretas – permitindo que inovações / alterações sejam feitas no “apt”.

Ou alguém consegue ver outra razão de existirem “apt-get” e “apt” – a menos que seja para: – O “apt” poder receber inovações – e o “apt-get” manter a compatibilidade necessária às aplicações que dependem de um comportamento estável e previsível?

apt (..) is intended as an end user interface and enables some options better suited for interactive usage by default — compared to more specialized APT tools like apt-get(8) and apt-cache(8)

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Quanto à hipótese de serem duplicações de 1 coisa só etc. – talvez sejam apenas 2 interfaces CLI para uma coisa só: – O pacote “libapt-pkg”?

(mas aí, já entra em profundidades que nem quero imaginar).

A Diferença Essencial: APT vs. APT-GET

Para entender de forma simples, imagine a engenharia do Linux como um carro:

  • O Motor (libapt-pkg): Lá no fundo do sistema, existe uma biblioteca oculta que realmente sabe como instalar, remover e calcular as dependências dos pacotes.

  • Os Painéis de Controle (Interfaces): O apt e o apt-get são apenas duas “telas” diferentes para controlar esse mesmo motor.

A diferença crucial entre eles está na estabilidade da interface e no público-alvo:

:hammer_and_wrench: apt-get (O Automatizado / Scripts)

O apt-get é uma ferramenta antiga, robusta e especializada. A sua principal característica é a previsibilidade. O formato de texto que ele solta na tela nunca muda. Se um script foi escrito em 2010 usando apt-get, ele vai rodar hoje exatamente da mesma forma. O script sabe exatamente o que esperar da resposta do comando.

:technologist: apt (O Interativo / Usuário Humano)

Lançado anos depois, o apt foi feito para nós, seres humanos. Ele junta os comandos mais usados do apt-get e do apt-cache em um lugar só. Ele foi desenhado para ser bonito e agradável: tem barra de progresso colorida, conta quantos pacotes podem ser atualizados e simplifica o texto na tela para não sobrecarregar nossa mente. Porém, ele não tem uma interface estável. Isso significa que em uma atualização futura, os desenvolvedores podem mudar a barra de progresso ou o formato do texto para deixá-lo ainda mais bonito, o que quebraria um script que estivesse tentando ler aquela tela.

:clipboard: Exemplo Prático: Onde usar cada um?

1. Quando usar o apt? (No seu dia a dia)

Sempre que você abrir o terminal para digitar um comando manualmente. O apt vai te dar uma experiência visual muito melhor.

  • Exemplo Prático: Você acabou de instalar o sistema e quer atualizar tudo e instalar o VLC para assistir a um filme.

    Bash

    sudo apt update && sudo apt upgrade
    sudo apt install vlc
    
    

    Por que usar o apt aqui? Porque você vai ver a barra de progresso subindo bonitinha, vai receber alertas amigáveis na tela e o comando é mais curto e rápido de digitar.

2. Quando usar o apt-get? (Em Scripts e Automações)

Sempre que você estiver escrevendo um arquivo de texto (script) que o computador vai executar sozinho, sem nenhum humano olhando para a tela.

  • Exemplo Prático: Você criou um script para rodar na madrugada no servidor da sua empresa, que atualiza o sistema e limpa os arquivos temporários de forma totalmente silenciosa.

    Bash

    #!/bin/bash
    # Script de manutenção da madrugada
    sudo apt-get update -y
    sudo apt-get upgrade -y
    sudo apt-get autoremove -y
    
    

    Por que usar o apt-get aqui? Porque a flag -y (responder sim para tudo) funciona de forma 100% garantida, a saída de texto é pura e padronizada (perfeita para gerar arquivos de log) e você tem a certeza absoluta de que uma atualização do sistema não vai mudar o comportamento do comando e quebrar a sua automação.

Não querendo mudar o assunto, mais tem o nala que te da mais detalhes na hora de baixar ou atualizar, fica a dica pra que não conhece.

Belo resumo, @Danilo_Machado !

Encontrei um tópico de 2016 no Unix StackExchange, onde o usuário Faheem Mitha responde à pergunta “Por que foi criado o apt se já temos o apt-get?” – e cita uma resposta dada a ele por um dos desenvolvedores do apt, Michael Vogt, no IRC-OFTC-net:

(…) temos receio de alterar qualquer coisa no apt-get porque ele já é usado em zilhões de scripts. O “apt” nos permite fazer isso, além de ser mais fácil de digitar e podermos combinar apt-get / apt-cache. Portanto, acho que todas as respostas estão corretas; o ponto principal é que o apt é mais conveniente de usar / digitar.

(…) a essência é que apt / apt-get / apt-cache compartilham a mesma biblioteca e código, apenas alguns ajustes no padrão.

  • O tópico, aqui.

  • O lançamento do “apt 1.0”, em 2014, exatamente 16 anos após o lançamento do APT original, aqui.

Dizia ele, em 2014:

A grande novidade desta versão é a inclusão de um novo binário “apt” que combina os comandos mais usados ​​do “apt-get” e do “apt-cache”. Os comandos são os mesmos que os seus equivalentes no apt-get / apt-cache, mas com opções de configuração ligeiramente diferentes.

  • O anúncio da escolha do nome “apt”, em 1998 – pois inicialmente o nome era outro – aqui.

Um pouco da origem remota do APT, aqui:

The original effort that led to the apt-get program was the dselect replacement project known by its codename Deity.[24] This project was commissioned in 1997 by Brian White, the Debian release manager at the time. The first functional version of apt-get was called dpkg-get and was only intended to be a test program for the core library functions that would underpin the new user interface (UI).[25]

Much of the original development of APT was done on Internet relay chat (IRC), so records have been lost. The ‘Deity creation team’ mailing list archives include only the major highlights.

The ‘Deity’ name was abandoned as the official name for the project due to concerns over the religious nature of the name. The APT name was eventually decided after considerable internal and public discussion. Ultimately the name was proposed on IRC, accepted and then finalized on the mailing lists.

… e eu achava que “APT” significasse “Advanced Package Tool” – como tenho visto muitas vezes. – Mas agora, não vale a pena procurar as fontes dessa crença.

Aptitude, apt, apt-get = dpkg

Praticamente qualquer uma dentro do ecosistema debian.

Salve, @ruanelivelton18

É normal haver opções:

  • No Fedora, temos yum, dnf = rpm
  • No openSUSE, zypper, YaST2 = rpm
  • No Mageia, dnf, urpmi = rpm
  • No Debian, apt, aptitude = dpkg
    • Os comandos apt e apt-get são apenas interfaces CLI do mesmo pacote apt

onde dpkg e rpm são os mecanismos de baixo nível – usados pelos outros, que acrescentam camadas de facilidades que o dpkg e o rpm não têm – como obter os pacotes, gerenciar as dependências, e outras coisas.

  • Tenho a impressão de que no openSUSE também se pode optar pelo dnf – abrindo mão de várias vantagens da distro – mas não quero afirmar, pois nunca prestei atenção nessa possibilidade.

O essencial, no Debian (acima do dpkg), são o pacote apt – que fornece tanto os comandos apt quanto os comandos apt-get – e a biblioteca libapt-pkg.

O aptitude é uma alternativa – que usa a mesma biblioteca libapt-pkg. – Eu não tenho aptitude do meu Debian…

… da mesma forma como sempre evitei o yum (nem sei se está instalado no Fedora) – e sempre evitei o dnf no Mageia.

No PCLinuxOS, sempre usei só o apt / Synaptic. – Só agora, passei a usar o dnf, e a evitar o apt / Synaptic.

Sobre utilizar o get resumidamente em scripts é pela estabilidade ou pela função de fazer uma requisição no servidor diferente do que apenas o apt que presumidamente você saberia que esta fazendo e que teria no repositório correto ?

1. A requisição ao servidor é exatamente a mesma

Tanto o apt quanto o apt-get fazem a mesmíssima requisição aos servidores do Ubuntu ou do Zorin OS. Eles não conversam com o servidor de formas diferentes, não usam protocolos diferentes e não buscam em repositórios distintos.

Ambos usam o mesmo “motor” oculto no sistema (a biblioteca libapt-pkg). Quando você digita apt update ou apt-get update, a requisição de rede que vai buscar os arquivos nos servidores da distribuição é idêntica.

:hammer_and_wrench: 2. Por que usamos o apt-get em scripts? (O motivo real)

Se a conexão com o servidor é igual, por que o apt-get é o rei dos scripts? É aqui que entra o conceito de Estabilidade da Interface de Linha de Comando (CLI):

  • Previsibilidade Total: O apt-get foi feito para ser lido por máquinas. O formato do texto que ele joga na tela nunca muda. Se um script seu precisa ler a resposta do comando para saber se a instalação deu certo, o apt-get garante que esse texto vai ser o mesmo hoje ou daqui a 10 anos.

  • O perigo do apt em scripts: O próprio comando apt exibe um aviso oficial dizendo que ele não tem uma interface estável para scripts. Como ele foi feito para humanos, os desenvolvedores do Linux se reservam o direito de alterar o formato da barra de progresso, mudar as cores ou simplificar as mensagens em uma atualização futura. Se eles mudarem um detalhe visual, um script automatizado que tenta interpretar a tela pode quebrar ou travar.

  • Gerenciamento de Interação: O apt-get é muito mais rígido e seguro para rodar de forma “cega” (em segundo plano). Ele foi desenhado para não fazer perguntas bobas ao sistema e aceitar automações de forma muito mais robusta.

    Resumo de bancada

Você usa o apt-get em scripts não porque ele baixa os pacotes de um jeito melhor ou diferente, mas sim porque ele promete nunca mudar o comportamento dele na tela. Isso garante que a sua automação vai rodar de forma previsível e segura, sem surpresas na madrugada!

Ainda sobre DPKG versus APT – ou sobre RPM versus YUM, DNF, URPMI, ZYPPER…

1 - No tempo das cavernas

Lá no início do “Linux” – ou “GNU / Linux”, pois não bastava o Kernel (núcleo, cerne), sem as ferramentas – instalar um pacote era como ir à floresta, cavar minério, fundir o ferro, fazer um machado, serrote, plaina, pregos, martelo etc., derrubar uma árvore, serrar as tábuas, aplainar, lixar com uma bucha e areia etc., até conseguir montar uma mesa e uma cadeira… para finalmente poder usar seu PC de Mesa;

Em outras palavras: – baixar um arquivo comprimido, descomprimir seu conteúdo, executar scripts, compilar, instalar – e agradecer aos ceus, que já existissem ferramentas (funcionando!) para inspecionar e editar scripts, executá-los, compilar etc.:

2 - O inferno das dependências

Com os gerenciadores de baixo nível DPKG e RPM, a coisa ficou mais fácil – pero, no mucho! – Você ainda tinha de procurar um pacote, baixar, para só então começar a tentar a instalação.

“Tentar” – porque, logo de cara, o DPKG ou RPM acusava a falta de uma dependência. – Então, você procurava aquele outro pacote, baixava, tentava instalar… e ele também reclamava da falta de outra dependência… e cada sub-dependência ainda poderia precisar de outra, sub-sub-sub-dependência.

Isso, no caso da 1ª dependência de cada pacote – pois cada pacote poderia facilmente exigir 3 ou 4 dependências – e a coisa tornava-se uma avalanche em progressão geométrica.

“Felizmente”, tudo era muito simples, muito tosco, de modo que a progressão geométrica não ia muito longe. – O que ia longe, eram o tempo e o trabalho necessários. – Aquela fase ficou conhecida como “o inferno das dependências”.

Isso ainda pode acontecer, até hoje, com a instalação de alguns pacotes no Slackware – embora um pouco mais facilitado. – É a distro mais antiga, ainda “em atividade”, e que até hoje continua evitando a etapa seguinte de “super-facilidade”:

Slackware, Debian e Red Hat são os 3 primeiros “ramos” principais da árvore de distribuições Linux. – openSUSE veio depois, primeiro com base no Slackware e logo em seguida mudou para a “base RPM”:

ATT.: - Não confie demais nesses prints de respostas da IA do Google – que estou usando só para traçar um quadro simples (e simplório!), para não ficar enjoado demais – como aconteceria, se fosse esmiuçar todas as vírgulas e cedilhas de uma história que foi 1 zilhão de vezes mais complexa do que isso.

Meu propósito, aqui, é apenas mostrar um quadro bem resumido (e muito por alto) da evolução da instalação de pacotes – e a cronologia das distros apenas ajuda a nos situarmos nesse quadro.

Pedi “as 20 primeiras” – mas dessa vez, a IA já não numerou – e ainda tirou da ordem cronológica… e alterou algumas datas, em relação ao print anterior.

É interessante notar que Slackware e Debian aparecem como reações contra algum desleixo ou abandono do SLS – muito citado como um dos marcos importantes dos primórdios das distros Linux:

Nesta segunda pesquisa, o SuSE aparece com “foco em pacotes RPM” (omitindo a fase inicial de “base-Slackware”); – o Gentoo aparece com data mais recente (1999); – Mandrake aparece 2 ou 3 vezes (ambas, “1998”); – e aparece o Conectiva (Brasil).

Também sem pretensão de ser exato, nem de esgotar todas as vírgulas e cedilhas da história, o prof. Juliano Ramos traça um resumo super-resumido – focado no que pode interessar mais ao candidato a profissional de TI – inclusive as certificações (em 2023):

3 - Facilitando instalar pacotes

Superar a trabalheira insana para instalar pacotes foi um esforço marcante da 2ª metade dos anos 90 – quando se desenvolveram o APT e o YUM (por exemplo) – e ajuda a entender por que, do final da década em diante, a criação de novas distros tendeu a se agrupar em “base-Deb” e “base-RPM”:

Ainda surgiram distros “independentes” – como Gentoo, Arch, Void, entre outras, com sistemas próprios de empacotamento e gerenciamento de pacotes – mas a disponibilidade dos aperfeiçoamentos já feitos no Debian e no Red Hat facilitava muito seu aproveitamento em novas distros como Mandrake, Conectiva, Knoppix, Kurumin, Ubuntu – e toda enxurrada de “sub-derivadas” que se seguiu.

“YaST” é um nome abrangente demais – e não posso afirmar que ao ser lançado, em 1995, já facilitasse a instalação de pacotes – em substituição ao “inferno de dependências” do RPM:

(Se fosse assim, talvez o SuSE tivesse se adiantado ao Debian e ao Red Hat, e conquistado uma fatia muito maior de usuários).

O URPMI, sim, era claramente um substituto / aperfeiçoamento do RPM:

É interessante essa equivalência:

rpm -i     urpmi
rpm -e     urpme
rpm -q     urpmq

No Brasil, a Conectiva desenvolveu o APT-RPM, com o mesmo objetivo de facilitar a busca / download / instalação / remoção de pacotes e suas dependências:

Logo em seguida, o Synaptic:

Também não sei até que ponto o RPMdrake resolvia essas questões, ao ser lançado, nos idos de 1998:

O Aptitude também surgiu logo após o APT – como um facilitador TUI do APT, usando a biblioteca ncurses:

É provável que não tenha sido suficientemente bom para “vencer a concorrência” – do próprio APT, por um lado – e de opções como o Synaptic.

Quando comecei a experimentar o Kurumin, em 2007, encontrei outros “concorrentes” – como o Adept, o KPackage, os Ícones Mágicos – e nos anos seguintes, a suíte Muon (instalador, atualizador, gerenciador), depois substituída pelo Plasma Discover – além das iniciativas do Gnome, e o “multi-plataforma” PackageKit.

4 - Facilitando mais ainda

Em 2006, apareceu o Zypper – não sei exatamente com quais vantagens, naquele exato momento:

Dia a IA do Google que o Void Linux e seu gerenciador xbps são de 2008:

Novos saltos de qualidade ocorreram na década de 2010 – o DNF, o DNFdragora:

E o aperfeiçoamento do APT – desdobrando os comandos apt-get / apt-cache numa interface CLI mais simples e amigável para uso interativo, nos comandos apt:

Conclusões?

Este breve resumo da “saga” talvez ajude a compreender por que surgiram tantas distros “base-Deb” – e ainda mais, “sub-base-Buntu”, devido a outras facilidades adicionais – e muitas distros “base-RPM” (incluindo aí as originadas via SuSE e Mandrake / Mandriva).

Resumindo. Os primeiros gerenciadores de pacotes tinham o problema crônico de não conseguir baixar as dependências necessárias ao instalar um programa. Por isso surgiu posteriormente os gerenciadores de pacotes que fazem esse trabalho automatizado. Antes, por exemplo, se você tentasse instalar VLC, a instalação iria travar por faltar dependências, mas nos gerenciadores atuais, ele procura e instala automaticamente as dependências necessárias. Os gerenciadores modernos são atualizados constantemente e por isso não são recomendados para scripts que exigem estabilidade.

Salve, @sidneyfmn

Eu não diria “os primeiros gerenciadores de pacotes”. – Eles não tinham as funções que hoje chamamos de “gerenciador de pacotes”. – Eram apenas “instaladores de arquivos locais”. – O usuário é que tinha de procurar, baixar, e fornecer as dependências necessárias.

Eu também não diria que os “instaladores” dpkg e rpm tivessem “problemas crônicos”. – Eles continuam funcionando até hoje – por baixo do capô do apt, do yum, do dnf, do zypper etc.

Exato.

Os “gerenciadores” que vieram depois, sim, acrescentaram essas novas camadas de funcionalidades: – Acessar os repositórios, procurar, filtrar, baixar, atualizar, remover – e tudo isso, gerenciando as dependências.

Na hora de “instalar”, utilizam o dpkg, ou o rpm.

Isso foi um avanço – da mesma forma que o dpkg e o rpm já tinham sido um avanço, em relação à situação anterior, em que cada usuário precisava compilar e instalar na unha.

Depois, os “gerenciadores” evoluíram mais: – O apt foi desdobrado em novos comandos – de modo que o usuário pode fazer tudo, digitando apenas “apt” – enquanto os scripts podem continuar usando “apt-get” e “apt-cache”.

Acho que o Aptitude foi uma tentativa de facilitar, usando uma interface TUI – assim como o Synaptic, usando interface GUI. – Ambos usam o apt, que por sua vez usa o dpkg.

É o velho princípio de que cada pacote deve ter 1 função – e desempenhá-la bem – e recorrer a outros, que desempenham bem as outras funções.

No mundo Red Hat, o yum foi um avanço inicial – e depois desenvolveram o dnf – cujo significado, dizem que é “yum elegante” (dandified yum).

No entanto, também houve iniciativas paralelas, como o apt-rpm, o zypper, o urpmi etc. – pois o openSUSE, o Conectiva, o Mandrake procuraram desenvolver caminhos próprios.

Como “terceira camada”, há ou houve o RPMdrake, o DNFdragora, YaST, MCC etc. – usando interfaces GUI.

Tenho muito medo desse adjetivo – “moderno” – porque pode significar qualquer coisa – e por isso, não significa nada.

Os comandos apt não são “modernos” – só porque “vieram depois”. – Os comandos apt-get e apt-cache não ficaram “obsoletos”, nem “arcaicos”. Eles continuam fazendo seu trabalho, com toda confiabilidade, e com absoluta exatidão técnica – enquanto os comandos apt são mais amigáveis para uso humano, interativo. Perguntam, param para aguardar resposta, têm um help mais simples para ajudar melhor sem despejar 1 zilhão de informações técnicas.

A “terceira camada” (GUI) é que tem evoluído muito mais. – Lembro que no Kurumin existiam o Synaptic, o Adept, e o KPackage, que nunca mais ouvi falar. – Depois, veio a suíte Muon, formada por Muon Discover (procurar, instalar), Muon Update (verificação, notificação, atualizações), Muon Package Manager (gerenciador) – e por fim, o Plasma Discover.

(No mundo Gnome, há ou houve alguns aplicativos GTK, mas deles não sei quase nada).

E hoje, já estamos na 4ª camada – o PackageKit, “agnóstico”, porque se propõe unificar todas as distros, com todos os tipos de empacotamento (deb, rpm, e sei lá o que mais).

Por exemplo: – O PackageKit usa o Plasma Discover – que usa apt – que usa o dpkg.

Em outra distro, o PackageKit usa o Plasma Discover – que usa o dnf, ou o zypper, ou sei lá o qual outro gerenciador – que usa o instalador rpm.

  • Em algum ponto desse encadeamento, alguém aproveita para usar também o flatpak, e / ou o snap – para maior glória do usuário que não quer saber de nada. – Só quer que “funcione para ele”.

Isso me lembra o Pamac (GUI) do Manjaro – que se propõe a gerenciar pacotes do Arch, do AUR, e também Snaps, e Flatpaks – tudo, em 1 só clique, ha ha.

Foi assim que consegui quebrar o Manjaro 3 ou 4 vezes, logo nas primeiras semanas, em 2017. – Naquele tempo, o gerenciador GUI era um tal de “Octopi” – mas já tinha essa proposta de ser fácil.

– “Vai ser fácil quebrar, não foi?” – perguntou o coelhinho. :rabbit_face:

E o passo seguinte, é uma enxurrada de pedidos de socorro nos fóruns das distros – e agora, uma corrida à IA.

Isso é muito mais do que “moderno”. – É a pós-modernidade.