Por favor, não estraguem este software no “vibe coding”

• Esta issue terminou com status Closed e, por ser um post de contestação sem passos de reprodução nem proposta de correção no corpo, não aparecem branches, PRs nem milestones vinculados
• A crítica original era a preocupação de que mudanças em que a IA esteve envolvida estariam abalando a estabilidade do rsync, e o post foi publicado principalmente com imagens, sem explicação textual
• Um usuário relatou que, como o log2ram usa rsync, uma impressora 3D passou a operar com CPU em 100%, dizendo que a IA acabou introduzindo esse bug em um robô
• Outro usuário argumentou que o rsync era uma ferramenta estável que precisava apenas de atualizações de segurança e correções de bugs, não de novos recursos nem de reescrita, e que nas duas releases de patch mais recentes surgiram problemas que não deveriam alterar funcionalidades existentes
• Um usuário que usa rsync em trabalho de DFIR explicou que, só pelo fato de a IA participar das atualizações, isso já passa a enquadrar o software como “ferramenta de IA” segundo a política da organização, exigindo revisão adicional
• Do lado oposto, houve quem respondesse que o issue tracker não é um espaço para reclamações virais e que, sem relatório de bug concreto ou passos de reprodução, o tópico deveria ser movido para Discussions ou resolvido via fork
• O conflito central cresceu entre a posição de que “é software livre, então faça um fork se não gostar” e a visão de que o rsync já é uma ferramenta de infraestrutura crítica, de modo que o próprio debate sobre pinning ou forks em downstream já é um sinal de problema
• Alguns usuários mencionaram uma reescrita em Rust ou um fork, mas outros traçaram uma linha clara: o rsync é valorizado justamente por sua estabilidade e por continuar funcionando como sempre, e uma reescrita seria um projeto separado
• Entre os defensores do uso de IA, argumentou-se que nem toda menção a IA deve ser tratada como “vibe slop” e que é preciso auditar diretamente o log de commits desde março para verificar os motivos das mudanças
• kaithar explicou que o trabalho recente inclui correções de bugs e falhas de segurança, além de hardening, como leitura de memória não inicializada, overflows/underflows no protocolo de rede, timestamps de 32 bits e ajustes relacionados ao padrão C
• O mesmo comentário rebate que fixar em releases antigas como a 3.4.1 pode manter o usuário em versões com vários CVEs, e que regressões podem surgir em edge cases que os testes deixaram passar
• No fim, a issue não convergiu para uma correção de bug específica e permaneceu como um debate sobre como lidar com confiança, auditoria e governança do desenvolvimento assistido por IA em infraestruturas estáveis de longo prazo como o rsync

[GN⁺]

Comentários do Hacker News

• Esse comportamento de manada é realmente bizarro, e parte disso parece irracional. Até entendo, em certo nível, a motivação de querer “vencer” essa briga, mas não desse jeito — isso só faz as pessoas parecerem fanáticas
  Basta procurar por regression na página de issues; dá para passar pelos 17 resultados em 5 minutos. Pode até haver mais no rastreador que era usado antes do GitHub
  Esse tipo de comportamento é muito tolo, e parece que as pessoas estão se agarrando a qualquer coisa possível para justificar o ódio à IA. Como se tivessem esquecido que as pessoas já cometiam erros antes da IA
  Se houver evidência de que a IA aumentou de forma significativa o número de issues não resolvidas no rsync, seria bom ver isso. Eu mudaria de opinião com prazer

  • Não acho que seja só uma questão de “as pessoas odeiam IA e por isso se agarram a qualquer coisa”. Quando as pessoas sentem que algo tem um problema, elas reagem
    Pode não ser a causa direta deste commit, mas pode ser uma reação a outros problemas acumulados, e isso por si só merece consideração
    Parece que as pessoas estão cansadas de ter que engolir à força narrativas do tipo “IA é a melhor coisa desde [metáfora cultural]” e estão tentando resistir agarrando qualquer palha, e isso me parece uma reação bem normal
  • A forma como estão correndo atrás com imagens de meme é estranha. Dito isso, a linguagem usada em si está no mesmo nível do que Tridgell estava acostumado a ver na LKML, então essa não é a principal preocupação
    Se ninguém disser que os usuários não confiam na IA, como o mantenedor vai saber? O rsync era muito estável. As pessoas deveriam simplesmente migrar em silêncio para o Openrsync e não dizer nada?
  • Se uma ferramenta muito estável e confiável de repente começa a desandar, acho perfeitamente justificável que as pessoas fiquem irritadas. No Linux Mint Timeshift há uma issue que organiza várias regressões abertas na página de issues do rsync, e elas parecem ter sido introduzidas só depois do vibecoding (https://github.com/linuxmint/timeshift/issues/548)
    Um dos links ali leva a uma compilação maior de bugs relatados em distribuições derivadas (https://github.com/void-linux/void-packages/issues/60825)
    Dada a reputação de software feito com vibecoding, a indignação é muito racional. Até especialistas de que eu gosto dizem algo como “para não introduzir bugs, é preciso lidar com isso de um jeito muito específico, e provavelmente é melhor usar só em versão 0 para explorar o domínio”
    Só que aqui estamos falando de uma ferramenta central de backup padrão da indústria, e o mantenedor, na tentativa de “adicionar mais funcionalidades”, está claramente puxando o tapete dos usuários de uma forma insegura
    Na thread do Timeshift também há o relato de que “depois da atualização do rsync, o uso de CPU durante o backup diário ficou tão alto que foi preciso interromper o timeshift porque ele parecia rodar para sempre”
    Em outras palavras, as pessoas estão frustradas e irritadas porque uma ferramenta à qual confiavam seus backups e seus dados está quebrando toda a infraestrutura de backup com uma enorme quantidade de regressões e bugs novos, e isso porque o desenvolvedor principal está fazendo vibecoding
    Até especialistas em vibecoding como Simon Wilson deixam explícito que isso só funciona “quando se lida com as ferramentas de uma determinada maneira”; então ou esse mantenedor não está fazendo isso, ou essa afirmação não é verdadeira
    Se você realmente ler a thread em vez de só passar os olhos pela parte em que duas pessoas estão brigando, há vários relatos de usuários em ambientes industriais e governamentais que precisam refazer todo o procedimento para atualizar esse software. Isso porque o software se tornou imediatamente não confiável, causando prejuízo direto aos usuários e minando a própria razão de existir dele
    Se eu também tivesse confiado mais de 500 GB de backups a esse software, acho que estaria irritado, e ficaria me perguntando quantos outros problemas entraram ali e só vão aparecer quando uma empresa sofrer uma perda de dados de 10 milhões de dólares por não testar seus backups com regularidade
  • Parece síndrome de comportamento de aversão à IA
  • A IA já virou uma questão política partidária, com todas as consequências que vêm junto. A esta altura, reclamar disso é quase como reclamar que o sol nasce no leste :(

• Eu realmente não entendo
  Existe um software robusto usado por inúmeras pessoas e serviços. Ele funciona bem, cumpre seu papel e, de vez em quando, só precisa de pequenas atualizações de correção de bugs
  Por que a IA é necessária aqui?
  E além disso, também não entendo por que as pessoas dizem “faça um fork e use a versão anterior”. Deveria ser o contrário. Deveriam criar forks paralelos como younamethetool-ai e deixar o original em paz
  Agora eu vou ter que fazer fork e manter todas as minhas ferramentas de sistema?

• Sobre “por que a IA é necessária aqui”, como também foi dito em vários comentários da issue, cabe aos desenvolvedores que contribuem para o pacote de código aberto decidir como vão trabalhar
  Reclamar no rastreador de issues, sem provas, que a IA está estragando o software é uma forma do assédio a contribuidores de código aberto frequentemente discutido no Hacker News [1]
  https://github.com/RsyncProject/rsync/issues/929#issuecommen...
  “O rastreador de issues não é um lugar para colher posts virais de rede social. Reporte bugs acionáveis ou faça você mesmo um fork. Desabafar sobre escolhas dos desenvolvedores não é produtivo”
  https://github.com/RsyncProject/rsync/issues/929#issuecommen...
  “@II-Paulus-II pare. Você não sabe de nada. Implantou zero funcionalidades manualmente. Ninguém dependeu do seu código. Você é apenas mais um apontador de dedo do tipo ‘a IA escreveu isso’, escondido atrás de uma suposta superioridade moral por escrever projetos de brinquedo e scripts do zero. Você não consegue entregar, não consegue se adaptar e nem entende que o rastreador de issues não é lugar para esse tipo de atitude”
  [1] https://news.ycombinator.com/item?id=43077833

• Concordo 100% com o sentimento de “por favor, não estraguem esse trabalhador estável e confiável”
  Não li em detalhes, mas a frase “6 CVEs foram corrigidos nesta release. Todos os seis foram atribuídos pela VulnCheck como CNA. As versões afetadas são, em todos os casos, a 3.4.2 ou anteriores” parece uma resposta bem forte ao “por quê?”
  https://download.samba.org/pub/rsync/NEWS#3.4.3

• É triste a sensação de senso de direito que muitos desenvolvedores de código aberto precisam aguentar. Basta imaginar que você criou algo de graça como hobby e depois tem que lidar com uma multidão irritada de gente que nunca pagou um centavo porque você fez algo de que eles não gostaram
  A primeira reação naturalmente seria querer mandar todo mundo ir embora

• Isso não cabe ao mantenedor decidir? Se ele decidir escrever mais testes com IA, então que faça isso. Ele também não deve nada ao público
  Se o “público” quiser assumir e manter o projeto, pode fazer um fork, mas é um trabalho ingrato

• Por que o mantenedor teria que fazer fork do próprio repositório? Isso não faz sentido. Quem vai manter o repositório antigo?
  Além disso, nem é preciso ter um motivo para mudar quais ferramentas se usam em um projeto de código aberto, e também não se deve essa explicação a você

• A forma como essa issue foi aberta é realmente desagradável, mas não entendo por que parece que os mantenedores soltaram IA em cima do rsync. Por que fariam isso? Quando você já conquistou reputação e confiança, lidera um nicho específico, está livre da pressão de mercado, as pessoas gostam da ferramenta e ela faz exatamente bem o que precisa fazer, por que tentar uma tranqueira relativamente experimental?
  Parece aquele breve monólogo de Matrix sobre como a mente humana primitiva não consegue aceitar o paraíso. Você tinha uma ferramenta perfeita, venceu, é quase insubstituível no nicho, confiável e, metaforicamente, virou um nome conhecido por todos. Apostar nisso ou mexer nisso não faz sentido para ninguém e é realmente desconcertante
  Ainda assim, fazer isso no rastreador oficial de issues continua sendo um comportamento realmente desagradável. A atitude é ruim e não parece haver boa-fé

  • Alguns anos atrás eu provavelmente teria defendido ativamente os mantenedores. Manter qualquer projeto open source é um trabalho árduo e pouco reconhecido, e ainda mais no caso de um projeto estabelecido como o rsync
    Mas agora a IA não parece algo positivamente líquido em lugar nenhum, e vejo essa reação contrária ao uso de IA generativa como uma boa correção de rumo por parte do público
    Há textos sobre a gratificação instantânea do uso de LLM, e quanto mais interajo com pessoas que usam essa ferramenta, mais acho que isso pode mesmo ser o problema central. Nossa biologia não dá conta
    Vejo pessoas originalmente muito inteligentes fazendo coisas realmente idiotas porque a caça-níquel mandou, e até sendo treinadas para ficar impotentes quando a caça-níquel falha
    Acabam me tratando como um ludita que não enxerga o progresso, enquanto vejo colegas criando benchmarks sem sentido e anexando gráficos bonitos feitos por IA
    Aí preciso escolher entre sorrir e fingir que é um bom trabalho, ou repreendê-los dizendo que o benchmark não significa nada porque está testando um trecho cravado como constante. De qualquer forma, acabo tratando-os não como colegas inteligentes, mas como crianças de 7 anos
  • A resposta para “por quê?” é que todo mundo, incluindo este fórum, está viciado na gratificação instantânea dos LLMs. É pura arrogância: dar uma passada de olho na saída e acreditar que ela funciona como se pensou
  • Essa opinião foi formada só olhando a issue, ou há evidências reais? Esse link do GitHub é interessante, mas fora “Claude” quase não há contexto sobre qual é o drama
    Não temos como saber em que ponto os mantenedores do rsync estão numa escala que vai de mantenedores perfeitos e responsáveis até crianças incompetentes
  • Concordo que não faz sentido soltar IA em cima do rsync, e também concordo que a forma de levantar a issue foi realmente desagradável
    Mas, correndo o risco de sair um pouco do assunto, fico com este pensamento. Tirando o fato de que um software maduro como o Rsync não precisa desse tipo de movimentação medida em linhas de código alteradas, vamos assumir que os mantenedores estão gerindo o projeto com as melhores intenções
    Se isso está acontecendo no open source, em que estado estará a qualidade do software fechado?
    O volume de uso de IA, isto é, o input, entra na avaliação de funcionários como se fosse métrica de sucesso, e as pessoas estão em pânico com a ameaça de demissões em massa causadas por IA
    Assustador
  • O que realmente não entendo é dizer que soltaram IA no rsync quando nem você nem eu sabemos como Claude foi usado
    https://github.com/RsyncProject/rsync/issues/929#issuecommen... mostra que ele não funciona mais em Darwin antigo e em Linux < 5.6, e o Linux 5.6 é uma versão cuja descontinuação já estava prevista em 2020. Além disso, há alguns outros bugs
    Não dá para esperar que um mantenedor dê suporte a sistemas antigos e saiba todos os impactos que uma mudança vai causar. Isso vale tanto se foi feito com IA quanto à mão

• Aliás, o próprio bug entrou em 30656c5e, gerado pelo Claude Code, e aparentemente houve revisão e testes inadequados da pessoa errada
  https://github.com/RsyncProject/rsync/commit/30656c5e
  Alguém usou IA para fazer bisseção do rsync recente: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
  Alguém tentou corrigir com ainda mais Claude Code: https://github.com/RsyncProject/rsync/pull/930
  Ticket relacionado: https://github.com/RsyncProject/rsync/issues/915
  Recomendo adicionar mais testes de regressão no commit imediatamente anterior a 30656c5e e fazer rebase para frente preservando a funcionalidade

  • Então a reclamação original parece simplesmente estar errada
    Isso não era um “novo recurso indesejado”. Tridge estava corrigindo um problema de segurança relacionado ao relato de bug. Eu simpatizo. Todos nós estamos apanhando de problemas de segurança. Corrigir isso não é opcional
    Não posso dizer que lidar com isso voltando a um software de 10 anos atrás seja divertido, então acho impressionante que o tridge esteja se esforçando
    Eu também carrego a culpa de usar LLM para atravessar essa bagunça. Não sei o que tridge faz, mas eu verifico linha por linha do código que o LLM cospe. Mesmo assim, o risco de bugs escaparem claramente é grande
    Faz muito tempo que não olho aquele código, e já não tenho a mesma familiaridade de antes. Então não é grande surpresa que bugs escapem
    O ponto estranho nessa explosão é que a pessoa que fez a reclamação original parece ser extremamente protetora com seu sistema de backup, mas o commit do tridge tinha só duas semanas. Sei que o tridge é excelente, mas isso obviamente não deveria ser tratado como software alfa? O que essa pessoa estava pensando? Talvez ela também precise aprender um pouco sobre como construir sistemas confiáveis

• Alguns anos atrás, a chance de um post desse tipo chegar à página principal do Hacker News teria sido praticamente zero. Independentemente de o conteúdo estar certo ou errado, isso porque aqui não estava cheio de gente comum que não entende que tipo de comportamento é inaceitável
  Do que se está falando aqui é da linguagem violenta da issue. Mas agora estamos cercados de pessoas que não conseguem distinguir nem o mais óbvio

  • Abrir uma issue chamada “Please Do Not Vibe Fuck Up This Software” com base em uma captura de tela de algum serviço estilo Twitter e em uma pessoa “que ninguém sabe quem é” dizendo ter encontrado um bug não é nem um pouco apropriado
    Não é assim que se diz a um mantenedor que você discorda da direção do projeto. Essa issue é completamente inútil. Teria sido melhor até um relatório de bug sobre algo “quebrado por causa de vibe coded”
    Isso foi direto ao ponto. Nenhum relatório de bug sequer tenta documentar a alegada regressão de --compare-dest=. Mesmo dando Ctrl-F, não vi ninguém mencionar “compare-dest” de novo
    As pessoas que estão postando comentários inúteis de indignação sobre IA poderiam ter pedido ao Opus 4.8 para rodar rsync 3.4.3 e 3.4.1, documentar minuciosamente a regressão e encontrar o commit quebrado com git bisect, produzindo um relatório de bug mil vezes mais profissional e útil
    Se a sociedade quer que o trabalho humano seja visto como mais valioso que o trabalho de IA, é melhor evitar comportamentos idiotas que só humanos podem ter
  • O mesmo pode ser dito sobre usar termos depreciativos como “normies”
    Não seria possível que isso chegou à página principal porque outras pessoas também se sentem assim sobre um software que usam todos os dias em trabalho importante?
    É verdade que issues no GitHub são um trabalho ingrato e muitas vezes banal, mas, na prática, o rsync é a base de muitos pipelines sensíveis
  • É estranho descrever aquela issue como “violenta”. Se você ler um pouco, fica claro que a situação é grande e que ninguém envolvido tem superioridade moral
    Se você realmente acredita que está fora de tópico, a resposta educada é fechar a issue
    Ainda não entendo bem o que seria tão obviamente claro. Para mim, “pare. você não sabe nada. entregou zero funcionalidades à mão. ninguém dependeu do seu código” parece muito mais violento do que “please do not vibe fuckup this software”
  • Talvez eu tenha ficado cético demais. Um número cada vez maior de comentários no HN e em issues do GitHub está parecendo bots tentando provocar raiva em outras pessoas, incluindo os mantenedores
  • Gosto que este comentário seja vago o bastante para se aplicar aos dois lados :)

• Naquela thread da issue, alguém realmente explicou a issue? Tipo passos de reprodução, comportamento esperado e comportamento real
  Isso foi postado em um rastreador de issues. “Claude é mencionado na mensagem de commit, e alguém no Bluesky acha que um problema inespecífico que teve está relacionado àqueles commits” não é uma issue acionável
  Deixando toda a discussão de lado, se fosse no meu projeto eu teria fechado e bloqueado por “falta de informações para reproduzir”. Discussões gerais sobre IA, forks e desabafos raivosos têm lugar melhor

  • A issue real parece ser mais ou menos esta
    Usuários de Linux < 5.6 não conseguem compilar a partir do GitHub. Isso me parece uma regressão bem pequena. Quem usa versões de manutenção do 5.6, principalmente versões com suporte de segurança estendido, provavelmente terá mantenedores da distribuição detectando a falha de build e corrigindo isso a tempo
    O reforço contra ataques de path traversal causa falhas para usuários que usam o protocolo nativo do rsync sem chroot. Ironicamente, chroot = no não é algo fortemente recomendado
    Você não deveria usar rsync nativo de forma automatizada, e talvez eu até recomendasse não usar de forma alguma. O CVE que aquele commit corrige se aplica exatamente a esse caso de uso
    https://www.cve.org/CVERecord?id=CVE-2026-29518
    É necessário daemon + no chroot. “daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.”
    Portanto, o workflow afetado é justamente o mais vulnerável, e mesmo assim as pessoas estão recomendando voltar a versão
    Além disso, se um teste de regressão deveria ter pego isso, então esse teste já deveria ter sido escrito antes

• Algumas pessoas parecem ter esquecido como projetos FOSS funcionam
  “15. Renúncia de garantia
  Na medida permitida pela lei aplicável, não há garantia para este programa. Exceto quando declarado de outra forma por escrito, os detentores de copyright e/ou outras partes fornecem o programa ‘no estado em que se encontra’, sem garantia de qualquer tipo, expressa ou implícita, incluindo, mas não se limitando, às garantias implícitas de comerciabilidade e adequação a um propósito específico. Todo o risco quanto à qualidade e ao desempenho do programa é seu. Caso o programa apresente defeito, você arca com o custo de todo serviço, reparo ou correção necessários”

  • Aqui vai também uma isenção de responsabilidade do usuário de OSS
    Eu reservo o direito de reclamar, resmungar, criticar, me irritar ou comentar de outra forma sobre toda e qualquer decisão, commit, patch, marketing ou outra decisão tomada por um projeto. Tais comentários não garantem adequação a qualquer finalidade, nem incluem garantia implícita de que sejam corretos, úteis ou gentis. Se meus comentários se mostrarem indesejados, você reserva o direito de enfiá-los em algum lugar onde o sol não bate
    Você pode imprimir esta isenção para consultar quando encontrar críticas indesejadas a projetos FOSS
    Não entendo por que as pessoas não percebem que essa atitude de “eles podem fazer o que quiserem” vale para os dois lados. Usuários também podem fazer o que quiserem. Se não gostarem, podem se manifestar
  • Legalmente, sim, você pode fazer isso, mas aí você só está sendo uma pessoa ruim
    Um dos comentários da issue dizia o seguinte
    “Só porque você dá sopa grátis a um morador de rua não significa que pode urinar nela”
  • “Sem garantia” não é o mesmo que “sem reclamações”. Se fosse, não haveria razão para existir rastreador de issues nem seção de discussão
    Aquela issue já virou um caos, e o seu argumento já apareceu lá. Todo mundo poderia ter lidado melhor com isso, mas citar texto jurídico cegamente não resolve nem melhora nada

• Este é o terceiro post no HN que leio sobre esse tema. Toda vez se repetem os mesmos tuítes, ou aquele tipo de postagem do Mastodon/Bluesky, seja lá como chamam isso. Alguém realmente chegou a depurar o problema?
  A causa foi código gerado de forma descuidada, ou foi uma correção de segurança legítima que quebrou algo por acaso? Quero dizer, de um jeito que uma pessoa também poderia ter feito

  • Há uma lista parcial em https://github.com/RsyncProject/rsync/issues/929#issuecommen...

• Essa histeria anti-IA é um típico pânico moral

  1. identificar algo como tendo sido feito por IA
  2. atacar e excluir quem possa ter se envolvido na produção disso
     Como em todo pânico moral, se o item 1 é verdadeiro ou não é algo totalmente secundário. O ponto central é obter uma espécie de gratificação quase sexual no item 2
     Neste caso, eu sei que há código gerado por IA no rsync. Como já acontece, a esta altura, com a maior parte do software útil. Mas, online, você vê uma caça às bruxas todos os dias e, como em toda caça às bruxas, se a acusação é verdadeira mal importa. A própria histeria é o objetivo
  • É perigoso se recusar a entender o que está acontecendo de forma ampla agora e o que está acontecendo neste tópico, e continuar sinalizando que não é preciso entender
    A raiva em torno da IA não existe porque o público está mal informado ou porque a mensagem saiu errada, mas por causa da realidade física
    Essa única coisa está sendo usada como pretexto para demissões em massa, CEOs de tecnologia dizem quase todos os dias que vão tomar também o emprego de todo mundo, e as grandes empresas de nuvem estão sugando todo o oxigênio da sala. Nem a indústria de games ficou a salvo
    Tratar isso como “só um pânico moral típico” é como ver para que lado o mar está recuando e sair correndo exatamente naquela direção
  • Quando vejo um raciocínio frouxo como “o ponto central é obter uma espécie de gratificação quase sexual no item 2”, fica difícil levar a resposta a sério
    E, lendo mais, a própria pessoa usa linguagem emocional como “caça às bruxas” e “histeria”
    Isso é mesmo uma caça às bruxas? E dá para saber se as pessoas do outro lado da internet estão chegando perto de uma libertação sexual?
    Não seria o caso de a pessoa estar reagindo da mesma forma à linguagem emocional e ao raciocínio frouxo dos outros?

• Desde quando uma issue no GitHub virou lugar para postar screenshot de publicação de outras plataformas?
  Eu só via esse tipo de coisa em lugares voltados para memes ou conteúdo de entretenimento
  Não há relato de bug acionável nem pedido de funcionalidade. Não há nem versão em texto. Nem sequer um link para a postagem original
  Quem postou isso confundiu o GitHub Issues com a própria conta pessoal no Twitter?

  • Postar screenshots é uma forma mais fácil de impedir respostas automáticas de LLM. A maioria usa modelos de texto sem visão, que custam menos.