BR-Linux.org

Quero começar dizendo algo que precede: tenho imenso respeito pelo legado de Andrew Tridgell, o desenvolvedor em questão. Sua principal criação – o Samba (1992-) – foi um dos grandes impulsionadores da vitória do código aberto nos conflitos da interoperabilidade com redes proprietárias, na virada do século. Não satisfeito, ele também co-inventou o rsync (1996-), que há décadas é um fundamento da sincronização de arquivos entre servidores, e um elemento central em muitas estratégias de backup.

Isso não impede minha rejeição (na verdade, aumenta o tamanho da decepção, embora eu não negue que ele tenha o direito de se posicionar como bem entender) à resposta que ele publicou sobre a recente controvérsia causada pelas regressões no código do rsync, iniciadas quando ele resolveu aplicar vibe coding ao seu desenvolvimento, como vimos neste post anterior aqui no BR-Linux: “Novas versões do rsync trazem bugs críticos surpreendentes e foram feitas com IA”.

A resposta dele me desaponta por vários motivos, mas o principal é se esforçar para desqualificar coletivamente quem criticou a situação.

A resposta dele me desaponta por vários motivos, mas o principal é ele concentrar boa parte dela em uma visão que desqualifica coletivamente (com expressões como “uma enxurrada de lama dos assim chamados especialistas da internet”) quem criticou a situação atual do código – que objetivamente não é boa, ainda mais se comparada ao histórico do próprio projeto.

A resposta dele também me preocupa, porque ele confirma que preferiu uma estratégia em que a IA não apenas escreve o código novo para o rsync, mas escreve os testes que validam esse código novo. O resultado nós vimos nas atualizações recentes (e não surpreende, dado o método), Mas Tridge defende longamente essa escolha, e rejeita (literalmente) os PhDs que apontam os riscos dessa estratégia, como se estivéssemos falando de um risco teórico, e não da sua materialização na forma de regressões em um sistema previamente estável.

A resposta de Tridge também me causa rejeição porque ele – que acusou os outros de jogarem lama – aproveitou para jogar lama no openrsync (que eu uso há anos, e agora vou usar em mais máquinas) como alternativa a quem deseja migrar do seu projeto, com o argumento de que não passa em boa parte da sua nova suíte de testes (aquela que ele acabou de pedir para a IA criar…).

Esse argumento dele é duplamente ruim: primeiro, porque desconsidera que o openrsync atualiza segurança e compatibilidade, mas intencionalmente congelou sua base nos recursos e interfaces do rsync de uma versão estável de um bom tempo atrás (é com o rsync 3.1.3, de 2018), portanto naturalmente não passaria em testes desenhados para atestar compatibilidade com versões posteriores. E segundo, porque no mesmo post, Tridge sugere aos descontentes que instalem versões anteriores do próprio rsync (mesmo sabendo que elas possuem falhas de segurança, que foi o que o motivou a usar vibe coding no projeto, conduzindo à situação atual).

Em suma, uma má resposta, que não resolve nenhum problema, por mais que o autor tenha direito de se sentir injustiçado ou desvalorizado pela enxurrada de críticas.

Mas há algo que me dói um pouco mais, e aí é a favor do Tridge, e não contrário ao seu posicionamento: ele abre o texto dizendo que está aposentado, e prefere ir velejar do que ficar cuidando de softwares. Ao longo do texto, ele retorna a essa ideia. É evidente o quanto ele está em busca de uma alternativa que permita viabilizar isso (e pensou ter encontrado na IA).

Eu concordo com ele quanto ao desejo: ele tem direito, e merece poder desfrutar da aposentadoria. Sabemos que ele já tentou passar o rsync para outro mantenedor, mas não deu certo, e o projeto voltou a ele.

Tomara que uma próxima tentativa dê mais certo, Tridge possa se aposentar efetivamente, e deixe o projeto em boas mãos.