Saí do Red Hat (Enterprise Linux)
(jeffgeerling.com)- Jeff Geerling, que permaneceu no ecossistema da Red Hat mesmo após o fim do CentOS, encerrou o suporte oficial ao Enterprise Linux após a mudança no acesso ao código-fonte do RHEL
- A nova política altera o fluxo de código-fonte necessário para reconstruir o RHEL, abalando a base de distribuições derivadas como Rocky Linux e AlmaLinux
- Pela GPL, até é possível colocar o código-fonte atrás de uma assinatura paga, mas termos que permitem cancelar a assinatura em caso de redistribuição podem gerar problemas jurídicos e de confiança da comunidade
- Desenvolvedores e mantenedores de EPEL/Fedora agora têm o ônus de redesenhar a infraestrutura de testes para se adequar à Red Hat Developer Account e às 16 licenças de RHEL
- Geerling avalia que a Red Hat está perdendo, por lucro, a confiança construída na comunidade open source, enquanto Rocky Linux e AlmaLinux dizem que vão buscar seus próprios caminhos de sobrevivência
A polêmica do acesso ao código-fonte do RHEL volta após o fim do CentOS
- Há dois anos, a Red Hat encerrou o CentOS, uma distribuição gratuita de Enterprise Linux amplamente usada
- A comunidade de usuários do CentOS foi chamada de “freeloaders”, por usar o trabalho da Red Hat sem pagar, e Geerling se via como parte dessa comunidade
- O CentOS servia de base para desenvolvedores open source, contribuidores do kernel Linux e desenvolvedores de software fazerem testes e builds
- Geerling destaca que a própria Red Hat também constrói seus produtos sobre o Linux, que ela não criou nem possui
A promessa de 2020 e o impacto nas distribuições derivadas
- É mencionado que, após a mudança no CentOS em 2020, a Red Hat havia prometido continuar publicando o código-fonte no git
- A mudança atual também traz grandes dificuldades para projetos mais antigos que o próprio CentOS, como distribuições derivadas do RHEL, caso de SDL/PUIAS
- Geerling entende que essas distribuições estão sofrendo danos colaterais na situação atual
Como Rocky Linux e AlmaLinux evitaram uma debandada maior
- Mesmo após o fim do CentOS, Geerling permaneceu no ecossistema da Red Hat por dois motivos
- Alguns funcionários da Red Hat tentaram dialogar, perguntando “como podemos fazer melhor?”, em vez de atacar a comunidade de usuários de open source
- Rocky Linux e AlmaLinux surgiram como alvos estáveis de trabalho open source para desenvolvedores
- Ainda assim, as duas distribuições dependiam de uma estrutura em que a Red Hat compartilhava o código-fonte
O fluxo anterior de publicação do código-fonte do RHEL
- A forma anterior podia ser entendida na seguinte sequência
- A Red Hat pega uma cópia do Linux
- A Red Hat adiciona suas próprias mudanças para transformá-lo em Red Hat Enterprise Linux
- Lança uma nova versão
- Atualiza o repositório de código-fonte com os dados necessários para fazer o build do zero
- A visão apresentada é que, no open source, o essencial é que o código-fonte fique aberto e que todos compartilhem seu trabalho para benefício mútuo
- A licença GPL usada pelo Linux exige legalmente o compartilhamento do código-fonte
- Sem esse compartilhamento, seria difícil imaginar a existência de tantas distribuições Linux como Debian, Arch, Mint, Ubuntu, PopOS e Fedora
Código-fonte atrás de assinatura paga e a controvérsia dos termos
- A Red Hat decidiu colocar o código-fonte atrás de um paywall
- Geerling reconhece que, tecnicamente, esse modelo pode ser compatível com a GPL
- Ainda assim, critica a prática como rude e irritante, já que boa parte do código bloqueado se baseia em código open source feito por outras pessoas
- A questão mais séria, porém, está nos atuais termos de assinatura da Red Hat
- A Red Hat diz que pode cancelar a conta de quem baixar o código-fonte e redistribuí-lo
- Se alguém baixar o código com uma assinatura da Red Hat, montar uma nova versão do Rocky Linux e a Red Hat cancelar essa assinatura, Geerling considera que isso renderia uma disputa judicial digna de atenção
- Não está claro se a comunidade conseguiria levantar dinheiro para enfrentar os advogados poderosos da IBM, embora a Oracle seja citada como um ator que poderia fazê-lo
- A medida da Red Hat é vista como algo muito próximo do limite de legalidade das condições da GPL do Linux, e é citado como referência o texto da Software Freedom Conservancy
A avaliação de que o objetivo é pressionar as derivadas
- Pelos indícios observados por Geerling, a Red Hat estaria tentando pressionar distribuições derivadas como Rocky, Alma e Oracle Linux
- Na visão dele, a empresa quer deixar os usuários dessas distribuições inseguros para empurrá-los a assinaturas da Red Hat
- Ele também acrescenta uma leitura cínica de que essa medida seria necessária para garantir lucro de curto prazo e agradar à IBM
A imagem histórica da empresa open source versus o presente
- No passado, a Red Hat era uma empresa rebelde e se posicionava como a parte mais fraca, usando até anúncios com citações de Gandhi, para desafiar empresas tradicionais de software proprietário por meio do open source
- Hoje, a Red Hat ocupa uma posição próxima da escolha padrão para rodar Linux em grandes empresas
- Geerling considera que a descrição de Cory Doctorow sobre a decadência de plataformas também se aplica à Red Hat
- Primeiro, a plataforma trata bem os usuários; depois, passa a explorá-los em favor dos clientes corporativos; por fim, explora até os clientes corporativos para extrair valor para si mesma, e então morre
- Para ele, a Red Hat está jogando fora, por lucro, a boa vontade que acumulou na comunidade open source em torno do Linux
O peso operacional para desenvolvedores e mantenedores
- Desenvolvedores como Geerling, mantenedores do repositório EPEL e mantenedores do Fedora estão preocupados com os efeitos de longo prazo
- A orientação dada a eles é aderir à Red Hat Developer Account para obter 16 licenças de RHEL para testes
- Geerling entende que isso o força a refazer sua infraestrutura de testes e automação para se adequar às licenças da Red Hat
- Debian, Ubuntu, FreeBSD e Rocky Linux não exigem esse tipo de procedimento
- Ele também rejeita a sugestão de funcionários da Red Hat de usar o CentOS Stream
- Há um motivo para Rocky e Alma Linux terem sido baixados milhões de vezes
- Na visão dele, o CentOS Stream não é um substituto para o CentOS
Fim do suporte ao Enterprise Linux e preocupação com o Ansible
- Geerling removeu, desde a última sexta-feira, o suporte oficial ao Enterprise Linux de todo o seu trabalho
- Ele também tem recebido perguntas sobre o Ansible
- Descreve o Ansible como o Red Hat Ansible Automation Platform, ou seja, um produto da IBM
- Diz não achar provável que o Ansible tente fechar o acesso, mas considera anormal que essa possibilidade sequer precise ser cogitada
- Sua posição é que não quer construir nada sobre um ecossistema em que usuários de open source são chamados de freeloaders e em que dois grandes episódios de caos aconteceram em sequência, no meio de ciclos de lançamento e sem aviso prévio
Rocky e Alma dizem que vão encontrar um caminho
- Geerling não acredita que isso ajude a Red Hat no longo prazo
- A situação é resumida como triste para três grupos
- Usuários que usavam o CentOS e desenvolviam ferramentas para atrair pessoas ao ecossistema da Red Hat
- A Red Hat, que antes lutava pelo open source, mas agora ergue barreiras em torno do próprio código-fonte
- As pessoas que continuam dentro do ecossistema da Red Hat e precisam lidar com questões de licença e com o afastamento da comunidade open source
- Rocky Linux e AlmaLinux anunciaram que vão encontrar, cada uma, uma forma de seguir em frente
- Geerling diz que continuará dando suporte a Rocky Linux e AlmaLinux dentro do melhor esforço possível, mas que já não tem confiança de que conseguirá oferecer suporte a Enterprise Linux no futuro
1 comentários
Comentários do Hacker News
Acho que esse tipo de comentário improvisado tão emocional e frouxo com os fatos não é muito construtivo
Estou insatisfeito com essa decisão da Red Hat, e a direção que a Red Hat está tomando também me preocupa muito. Pela primeira vez em mais de 10 anos, estou reavaliando o ecossistema no qual meu trabalho e as empresas onde tomo decisões se baseiam
Está difícil acreditar que a liderança da Red Hat ainda se importa de verdade com open source e, mesmo que se importe, acho que mostrou que pode prejudicar o open source para aumentar a receita de curto prazo
Dito isso, pelo que sei, a expressão freeloaders foi usada por uma pessoa só, e nem está claro pelo contexto a quem ela se referia, nem se era uma opinião pessoal ou da empresa. Também não parece que estivesse se referindo às pessoas que usavam CentOS e de fato contribuíam para a comunidade
Em organizações grandes sempre vai haver alguém com opiniões com as quais a empresa inteira não concorda, e pintar toda a organização com base na fala de uma pessoa é injusto e improdutivo
Não entendo qual é o objetivo aqui. Polarizar tudo em termos de bem contra mal, para que todo mundo passe a defender apenas seu lado com medo de que o “outro lado” use palavras e decisões para atacar?
Gosto muito do conteúdo do OP, mas fico um pouco preocupado porque ele parece estar entrando fundo demais na fórmula de sucesso do YouTube baseada em emoção, especialmente em provocar indignação e raiva, e por isso está tratando esse assunto de forma excessivamente emocional
Nem todo usuário de CentOS era alguém pegando carona, e o mesmo vale para os usuários das distribuições que deram continuidade a esse espírito. Mas a maioria dos usuários de CentOS não devolvia nada de forma alguma ao CentOS nem à comunidade mais ampla de software livre/open source
E uma parte considerável usava CentOS porque queria todas as vantagens do Red Hat EL sem querer pagar o custo
Isso soa bastante como pegar carona. Licenças open source copyleft permitem isso [1], e a Red Hat também pode restringir o acesso ao código-fonte. Desde que cumpra suas obrigações de licença com os clientes, não há problema
A Red Hat investe uma quantidade enorme de dinheiro no ecossistema de software livre/open source, e acho totalmente justo incentivar clientes com plena capacidade de pagar a assinarem. Para os demais usuários, também há muitas alternativas
[1] Se fosse uma licença não copyleft, a Red Hat obviamente não teria obrigação de fornecer o código-fonte
“Depois que chegou a hora de eliminar a maioria dos clones, a Red Hat também acabou com a versão gratuita oficial de seu principal produto pago. Em vez disso, passou a oferecer uma versão gratuita para testes e anunciou isso com palavras de aparência positiva, como participação da comunidade. Na prática, cortou aqueles que, do ponto de vista da Red Hat, podem parecer um bando de aproveitadores. Essa medida também incluiu a implantação gratuita em produção do RHEL para desenvolvedores, mas limitada a no máximo 16 máquinas”
https://www.theregister.com/2023/06/23/red_hat_centos_move/
Eu senti algo parecido no segundo post sobre a Red Hat. Às vezes ele publica coisas que despertam interesse, mas na maior parte do tempo o marketing estilo YouTube é exagerado demais
Sei que ele faz isso de propósito para conseguir métricas, e espero que esse método funcione bem para ele e reúna o público que ele quer. Pelo fato de não mudar, imagino que deva ser o caso
Lembro quando saiu o anúncio inicial de que o CentOS seria encerrado e substituído pelo CentOS Stream. Muitos funcionários da IBM, ou seja, da Red Hat, defenderam a mudança descrevendo os usuários de CentOS como pessoas usando de graça um produto pago
Muita gente também defendia isso no Hacker News, Reddit etc. Espero que não tentem reescrever a história
Eles precisam temer a reação negativa toda vez
As pessoas precisam estar de fato prontas para ir embora. Caso contrário, acaba tudo voltando ao normal, como no Reddit
Entendo a posição do Jeff, mas acho que na semana passada este já foi o terceiro post dele sobre esse tema a chegar à primeira página do HN
Agora parece que não há mais nada a extrair dessa pedra. O Jeff é livre para pegar a bola e ir para casa, e na verdade a Red Hat também
Mas acho que isso já passou da fase de “notícia digna de destaque”, e não vejo a conversa avançando mais porque o Jeff publique outro texto sobre a sua frustração
Não sei se eram necessários três posts, nem se todos precisavam ir para a primeira página do HN, mas no geral também não me parece um problema tão grande. Foi assim que as pessoas votaram
Brincadeiras à parte, eu mesmo precisei pesquisar o nome dele no Google alguns dias atrás. Hoje em dia não acompanho muitos canais de YouTubers de tecnologia
Para citar a formulação do Jeff, o jeito antigo era a Red Hat pegar uma cópia do Linux, adicionar a “fonte mágica” que a transformava no Red Hat Enterprise Linux, lançar uma nova versão e atualizar no repositório de código-fonte todos os dados necessários para compilar tudo do zero
Só acrescentando alguns pontos: agora essa parte da fonte mágica desapareceu. Todo o molho secreto ou equipamento de caixa-preta está exposto no CentOS Stream
A Red Hat não desenvolve mais o RHEL atrás do firewall corporativo; todo o trabalho é feito publicamente no CentOS Stream. Há uma exceção para CVEs de segurança, mas, na prática, quando o embargo cai, entra ao mesmo tempo no CentOS Stream e no RHEL
No fim, esse argumento nasce de ignorar deliberadamente o CentOS Stream. Os clones do RHEL podem simplesmente acompanhar o CentOS Stream, e também é possível reproduzir a “fonte secreta”, que é o fluxo de CI/CD do CentOS Stream
Hoje em dia, o processo de reproduzir o RHEL é muito mais fácil do que em qualquer outro momento no passado
Reproduzir com os mesmos bugs, de forma idêntica, passou a exigir mais esforço do que há algumas semanas. E isso significa fazer esse trabalho em paralelo com a própria Red Hat, gerando duplicação de esforço
Além disso, vendo que essa mudança forçou Rocky e AlmaLinux a se adaptarem no meio do ciclo de lançamentos da série 9.x, e que o encerramento anterior do CentOS também aconteceu no meio do ciclo 8.x com menos de 24 horas de aviso, é difícil sentir que essa mudança foi feita “apenas para melhorar o desenvolvimento do CentOS e do RHEL”
Se esse fosse realmente o objetivo, isso deveria ter sido anunciado com pelo menos algumas semanas de antecedência, idealmente alguns meses, para que a comunidade pudesse se planejar. Em vez disso, fomos pegos de surpresa duas vezes seguidas
Dito isso, a expressão “pegar uma cópia do Linux” reduz de forma exagerada a enorme quantidade de trabalho que a Red Hat faz para produzir um lançamento do RHEL
A Red Hat reúne centenas ou milhares de projetos upstream para montar o RHEL, participa de muitos deles, testa tudo em conjunto, ajuda parceiros a certificarem software em cima disso e faz muito mais
É verdade que a Red Hat não “possui” o kernel Linux, mas ao longo de muito tempo contribuiu enormemente para o desenvolvimento do kernel. E o RHEL nem é só o kernel, nem um único upstream. É o resultado de testar milhares de pacotes em conjunto e lançá-los como um produto com suporte
O que a Red Hat está tentando proteger não é o código-fonte de um projeto específico, nem de vários projetos, mas o valor criado ao juntar todas essas partes. E, por coincidência, o que empresas, concorrentes e a comunidade querem não é o código-fonte em si, mas exatamente esse valor
Todos querem, na prática, um snapshot de um momento específico sobre o qual todos concordaram como padrão de fato. Isso acontece porque a comunidade como um todo não conseguiu chegar a outro padrão viável que permita direcionar aplicações de forma ampla. Esse padrão tem nome, é o RHEL, e pertence à Red Hat
Se quiser, você pode pegar todas as peças e montar tudo por conta própria. Mas, fora a Red Hat, ninguém tem o direito de certificar isso como RHEL, oficialmente ou não
Se isso te irrita, eu sinceramente recomendo tentar fazer do Debian o padrão que todos usem para certificação. Ou então criar uma empresa que supere a Red Hat e ocupe a posição que o RHEL tem hoje
Mark Shuttleworth passou anos criticando o modelo de negócios da Red Hat com o RHEL, mas agora, vendo o Ubuntu Pro empurrar atualizações de pacotes para depois de 5 anos e cobrar por atualizações dos repositórios Universe e Main, parece que está fazendo algo bem parecido
Oracle Linux, Alma Linux e Rocky Linux são todos downstreams do RHEL
Você pode passar o dia inteiro defendendo o quanto o CentOS Stream é parecido com o RHEL. Pode até dizer que, para você, não é grande coisa ele agora ser o upstream
Mas, na prática, ser upstream ou downstream importa para muitos usuários e empresas
Também importa que a IBM esteja tentando impedir o acesso ao código open source e tentando restringir assinantes para que não possam redistribuir esse mesmo código open source
A IBM está causando um dano enorme ao ecossistema open source do qual ela mesma lucra
Fui eu quem escreveu aquele tweet
O Mike, que tinha apontado isso primeiro no Mastodon, acabou de atualizar o próprio tweet — ou melhor, toot — dizendo que seu contato na Red Hat confirmou que isso é um bug
A assinatura de desenvolvedor continua limitada a 16 servidores
https://twitter.com/fareszr/status/1673145072714665984
O RHEL tem uma grande vantagem no ecossistema de drivers da qual talvez eles mesmos não tenham plena noção. Acho que há o risco de estragarem isso
Quando o setor começou a levar Linux a sério, o RHEL era a distribuição dominante. Como resultado, por acaso o RHEL e suas distribuições derivadas viraram o principal alvo dos drivers comerciais de hardware
Por exemplo, placas de rede de baixa latência pouco conhecidas ou placas de captura de pacotes são mais fáceis de fazer funcionar em distribuições derivadas do RHEL do que em outros sistemas. Quando você conversa com as empresas que fabricam esse tipo de equipamento, elas partem do pressuposto de que a linha RHEL é o padrão
Graças ao suporte de drivers, as distribuições derivadas do Red Hat viraram o padrão entre as distribuições comerciais. Mas não foi a Red Hat que ficou com essa escala de implantação. O volume real está no CentOS/Rocky/Alma instalados em hedge funds, empresas de proprietary trading, grids de exploração de petróleo etc.
Na minha visão, essa situação dos drivers é o verdadeiro valor do ecossistema Red Hat. O user space é meio bagunçado e o gerenciador de pacotes não impressiona. Mesmo assim, implantamos distribuições derivadas do RHEL porque os drivers funcionam sem grandes problemas
Se a Red Hat conseguir eliminar as distribuições derivadas, isso vai desencadear um ponto de virada em que o setor deixará de tratar a linha RHEL como alvo padrão para drivers
Uma empresa que usava CentOS em 5 mil servidores não vai de repente pagar US$ 350 por servidor por ano. Vai migrar para Debian e suportar a dor da transição. A cultura dos drivers comerciais vai acompanhar rapidamente. Uma mudança cultural dessas pode acontecer em dias, não em anos
Acho ingênuo o modelo de cobrança por servidor da Red Hat. Por US$ 350 por ano, você só obtém uma licença sem suporte. Pode gerar alguma receita com empresas pequenas e com companhias que têm expectativas tradicionais de serviço, mas será que a oportunidade real está aí
Quando se monta um datacenter, você quer conseguir dar boot via PXE em cada servidor. Assim, dá para mudar a imagem de sistema do grid criando uma nova imagem PXE e reiniciando os hosts. Montar essa configuração é trabalhoso, e seria bom se a Red Hat oferecesse uma solução pronta bem feita
Algo como US$ 2.000 por ano por site para 100 servidores, incluindo suporte ao próprio dispositivo PXE. Se a Red Hat seguir por esse caminho, pode coexistir com as distribuições derivadas. Se isso virar um appliance, pode se tornar um produto comum como firewall ou switch de rede
Minha impressão é que o RHEL basicamente aplica patches sem mudar muito as interfaces no mesmo kernel. Então parece que drivers em código-fonte, ou mesmo alguns drivers em forma de blob binário, deveriam compilar e funcionar de forma quase igual a um kernel comum
Além do fato de os desenvolvedores de drivers usarem RHEL/CentOS e validarem o funcionamento ali, existe algo que eu esteja deixando passar
A análise jurídica do RHEL e da GPL da Software Freedom Conservancy, linkada pelo OP, foi o ponto mais interessante
https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...
Você pode usar código GPL de outras pessoas em um produto e cobrar por isso. Se houver solicitação, precisa “divulgar” o código-fonte GPL e o seu próprio código derivado do código GPL. Aqui, divulgar significa entregar a quem pedir, não manter uma página pública de download nem facilitar o acesso
Você pode enviar em DVD, pendrive ou qualquer mídia desejada, e pode cobrar algo como o custo da mídia. Ou seja, não é necessário facilitar a obtenção do código-fonte, nem oferecer gratuitamente o produto já compilado
Há muita coisa que pode ser feita dentro dos limites da GPL. Se a IBM/Red Hat está fazendo isso dentro desses limites, qual é exatamente o problema
Esse tipo de coisa também é possível sem GPL. Por exemplo, o SQLite3 está em domínio público, mas existe o SQLite Consortium, e imagino que renda bastante para D. R. Hipp e seus funcionários. Quase não há concorrência de forks porque é muito difícil fazer um fork confiável do SQLite3, e isso acontece porque a melhor suíte de testes é proprietária e secreta
Para empresas, open source é uma ferramenta. Para indivíduos, open source também é uma ferramenta. Se uma pessoa jovem, no começo da carreira e com poucos recursos, quiser criar software útil como open source, ela pode ganhar reputação e conseguir oportunidades de emprego melhores ou a chance de abrir um negócio
Os MBAs da IBM finalmente assumiram o controle da Red Hat
É aquela lógica de tentar arrancar nem que seja mais US$ 1, mesmo que no longo prazo isso dê errado. Eu sabia que isso ia acontecer algum dia e, sinceramente, me surpreende que tenha demorado tanto
É o que se vê em muitas empresas hoje em dia. Começam projetos que não levam a lugar nenhum ou que logo serão cancelados, os bônus são pagos, as pessoas vão embora, e o ciclo se repete
Quem fica pensando no lucro de longo prazo é que acaba parecendo bobo. Por outro lado, talvez os trabalhadores finalmente tenham descoberto o segredo das empresas
Essa decisão parece ter sido tomada com forte participação de pessoas com muitos anos de casa. E se a realidade fosse justamente o oposto
A ideia de “ignore também o fato de que a Red Hat constrói um produto em cima do Linux, que ela não criou nem possui” parece deixar passar que uma parte considerável do sucesso contínuo do Linux se deve à Red Hat
O impacto de a Red Hat ter impulsionado conformidade regulatória e financiado desenvolvimento alinhado a isso foi grande para permitir a competição em contratos governamentais, e o desenvolvimento de Linux apoiado diretamente pela Red Hat também foi enorme
Claro, a Red Hat não é a única razão do sucesso do Linux, mas é evidente que o sucesso do RHEL teve um papel importante para tornar o Linux adequado a datacenters
O Linux ficou popular por meio de implantações de base, e só depois as empresas passaram a ganhar dinheiro com isso. Hoje em dia surgiu uma narrativa de que as empresas é que moveram as peças desde o começo, mas isso não é verdade
Há alguns motivos pelos quais o Stream não pode ser um substituto da linha CentOS, ou seja, alternativas como Alma ou Rocky
Primeiro, o Stream não pode ser usado como base para compilar pacotes compatíveis com EL. Não há garantia de que o Stream não quebre a compatibilidade de ABI
Segundo, o Stream não tem um ciclo de suporte longo, de vários anos, então não pode ser usado como um sistema estável. Claro, não é necessário o suporte de licença paga da Red Hat, e existe uma grande comunidade pronta para ajudar com relatórios de bugs e testes
Em termos rigorosos, dá para dizer que não há garantia, mas esse tipo de quebra também quebraria futuras releases do RHEL, então é um bug
O período de suporte é de 5 anos
Apoio 100% e sou grato pelo direito de qualquer pessoa, incluindo o Jeff, de tomar uma posição ao decidir onde usar seu tempo
O tempo que temos é finito, e principalmente quando aquilo que consideramos importante muda, esse tempo também precisa ser usado de acordo com isso. O texto “Saying No” do Jeff mostra bem por que isso é importante
O que é difícil de entender, porém, é o uso excessivo de histórias sobre a IBM, as formulações reconstruídas de forma a fazer parecer que a Red Hat fez declarações desrespeitosas à comunidade, e a cara de pau necessária para fazer afirmações como “digam aos funcionários para parar de [algum comportamento]”
Entendo que isso possa ter sido sentido como uma quebra de confiança, e que o rompimento da confiança provavelmente seja o que mais dói. Então também entendo a reação emocional
Mas, como mantenedor ou contribuidor de open source, para reduzir muito a própria carga cognitiva, teria sido melhor simplesmente encerrar o suporte e seguir em frente
https://www.jeffgeerling.com/blog/2022/just-say-no